| 18:02 | <Ashley Claymore> | PSA: There is the monthly Records&Tuples call tomorrow, 16th, 7pm UTC |
| 20:45 | <bakkot> | shu you may be interested in this thread on liveness on es-discourse: https://es.discourse.group/t/liveness-barriers-and-finalization/1082/ |
| 20:52 | <shu> | interesting |
| 20:52 | <shu> | felix wants a portable liveness fence |
| 20:52 | <shu> | i don't think that exists |
| 20:52 | <shu> | (for the reasons that they point out, basically) |
| 20:53 | <shu> | well let me think about it some more |
| 20:53 | <shu> | one probably does exist for any given program (and a closed world assumption) |
| 20:53 | <shu> | but i'm not sure one exists for all implementations for all given programs |
| 21:13 | <Ashley Claymore> | one probably does exist for any given program (and a closed world assumption) eval to try and disable all optimisations would be cheating right?.. |
| 21:15 | <bakkot> | new WeakRef(obj) actually is a liveness fence, by my reading |
| 21:16 | <bakkot> | since it adds obj to KeptAlive |
| 21:22 | <shu> | well, for one turn |
| 21:23 | <shu> | oh, like, constantly creating new WeakRefs? |
| 21:23 | <shu> | in practice i agree that is a fence |
| 21:23 | <shu> | but we hung all of this on observability which we also agreed to be too hard to pin down |
| 21:24 | <shu> | if the new WeakRef(obj) itself is unobservable, i'd imagine its effects to also be up for as-if DCE |
| 21:24 | <shu> | (though in practice of course nobody does that) |
| 21:28 | <shu> | i guess it's not that the new WeakRef(obj) would be unobservable, but whether the [[KeptAlive]] addition is unobservable |
| 21:33 | <bakkot> | right, and it is in fact observable, because addition to [[KeptAlive]] prevents collecting on the current turn |
| 21:34 | <shu> | i think there are cases that could be unobservable, but only theoretically |
| 21:35 | <shu> | like, if you have no FinalizationRegistrys or if the finalizer functions themselves are unobservable |
| 21:36 | <shu> | cause, like, are malloc and free observable? with an oracle i could stack allocate it |
| 21:37 | <bakkot> | well, sure, but then you can't tell it's not acting as a fence |
| 21:37 | <bakkot> | by definition |
| 21:37 | <shu> | you can, because there's always an observability gap between the debugging tools and the optimizer |
| 21:38 | <shu> | debugging tool (looking at RSS size or whatever) has the assumption all memory in a process is observable |
| 21:38 | <shu> | the optimizer obviously does not have that assumption |
| 21:38 | <shu> | if there is no gap, then i'd agree |
| 21:38 | <shu> | again this is academic, in practice it is a universal fence because we'll never be that optimized |
| 21:38 | <bakkot> | well, ok, ignoring the debugger |
| 21:39 | <shu> | but how else do you observe that your finalizers are firing? |
| 21:39 | <shu> | like practically speaking |
| 21:39 | <bakkot> | they have side effects? |
| 21:39 | <shu> | yeah, they consider freeing up memory or a resource a side effect |
| 21:39 | <bakkot> | no, I mean, you can have a finalizer which has side effects |
| 21:39 | <bakkot> | in javascript |
| 21:39 | <shu> | right |
| 21:39 | <bakkot> | like, actual program-level side effects, not just freeing memory or whatever |
| 21:39 | <shu> | i'm saying, if the finalizer is observable |
| 21:40 | <shu> | then [[KeptAlive]] is observable |
| 21:40 | <shu> | if it is not, i see it as fair game to optimize away too |
| 21:40 | <bakkot> | right, sure |
| 21:40 | <bakkot> | because it's not observable that you did that |
| 21:40 | <shu> | and the tricky thing is, whether we should consider a finalizer to be observable |
| 21:40 | <bakkot> | (without using the debugger or looking at memory usage) |
| 21:41 | <shu> | because if you ask most practitioners, do you think free is observable |
| 21:41 | <shu> | they'd say yes |
| 21:41 | <shu> | if you ask a POPL author |
| 21:41 | <shu> | then shrug |
| 21:41 | <bakkot> | I think JS programmers generally aren't thinking about memory usage, at least not as a property of their program rather than of a particular implementation |
| 21:41 | <shu> | maybe the right answer here is, ignore my PL semantics rambling and just use [[KeptAlive]] |
| 21:42 | <shu> | let me say that |
| 21:44 | <shu> | okay, back to the real world where liveness is just simple reachability of a particular implementation |