TC39 General on 2021-11-04

00:45	<TabAtkins>	okay so if we're champs no need to answer the doodle, or shoudl we do so to kick off time planning?
02:11	<jmdyck>	devsnek: I'm working on it, but progress is slow.
11:00	<nicolo-ribaudo>	Can anyone give me an example of an observable effect of what is explained in the second pagraph of the first note of https://tc39.es/ecma262/#sec-weakref-execution? I initially came up with this: `let obj = { x: 1 }; let ref = new WeakRef(obj); await null; // I think we need to wait to allow WeakRefs to be emptied console.log(ref.deref(), obj.x);` which I though might log `undefined, 1` because it doesn't observe the identity of `obj`. However, an hypothetical WeakRef-oblivious execution (as defined in "9.10.2 - Liveness") might be `obj === obj`, which observes the identity of `obj` and thus makes it "live" and non-collectable, so `ref.deref()` must return `obj`.
11:02	<nicolo-ribaudo>	Maybe my question is "is an hypothetical WeakRef-oblivious execution any possible execution of any possible code, or just any possible execution flow in my code?"
11:57	<pokute>	It's still weird that I don't have much idea what happened after the latest meeting. I understand that it takes a while to get the complete notes, but I really wish someone made an summary that has a sentence or two for each agenda item soon after a meeting.
11:57	<pokute>	it still feels weird
12:02	<nicolo-ribaudo>	pokute Justin Ridgewell has been doing an awesome job reporting the conclusion of each important topic at https://github.com/babel/proposals/issues/77
12:04	<pokute>	pokute Justin Ridgewell has been doing an awesome job reporting the conclusion of each important topic at https://github.com/babel/proposals/issues/77 Oh, I didn't know about that. Thank you!
12:05	<nicolo-ribaudo>	Note that it should not be considered an "official source" (only the notes are official), but it's a good approximation
13:43	<devsnek>	Can anyone give me an example of an observable effect of what is explained in the second pagraph of the first note of https://tc39.es/ecma262/#sec-weakref-execution? I initially came up with this: `let obj = { x: 1 }; let ref = new WeakRef(obj); await null; // I think we need to wait to allow WeakRefs to be emptied console.log(ref.deref(), obj.x);` which I though might log `undefined, 1` because it doesn't observe the identity of `obj`. However, an hypothetical WeakRef-oblivious execution (as defined in "9.10.2 - Liveness") might be `obj === obj`, which observes the identity of `obj` and thus makes it "live" and non-collectable, so `ref.deref()` must return `obj`. it's saying "if your code could be evaluated with defef() always returning null and still observe the identity of the object, the object is live"
13:43	<devsnek>	your example is correct afaict, assuming the engine optimized that
13:44	<nicolo-ribaudo>	Ok thanks 👍
17:36	<Mathieu Hofman>	Can anyone give me an example of an observable effect of what is explained in the second pagraph of the first note of https://tc39.es/ecma262/#sec-weakref-execution? I initially came up with this: `let obj = { x: 1 }; let ref = new WeakRef(obj); await null; // I think we need to wait to allow WeakRefs to be emptied console.log(ref.deref(), obj.x);` which I though might log `undefined, 1` because it doesn't observe the identity of `obj`. However, an hypothetical WeakRef-oblivious execution (as defined in "9.10.2 - Liveness") might be `obj === obj`, which observes the identity of `obj` and thus makes it "live" and non-collectable, so `ref.deref()` must return `obj`. FYI, the releasing of kept objects is a host defined operation, so it may not happen at a promise job boundary. In particular, AFAIK most engines only clear kept objects when the promise queue is drained.
17:41	<Mathieu Hofman>	Correct. Here is the PR that introduced the weak-ref oblivious execution: https://github.com/tc39/proposal-weakrefs/pull/142 I don't know how shu came up with it, but it was very clever!
17:46	<devsnek>	yeah everything in the spec here is sort of "outer limits" on what engines must do. in practice they are not perfect at removing dead objects and cannot run gc immediately every time the job queue is empty, etc.
17:49	<nicolo-ribaudo>	Thanks everyone!
18:00	<shu>	yeah, the spec only says when it is allowed to empty a WeakRef, so that you can reason about WeakRefs which must not be emptied according to the spec
18:00	<shu>	conversely, an implementation that never empties WeakRefs, or never GCs at all, is always compliant
18:00	<shu>	not that anyone really does that
18:01	<shu>	IOW you cannot write interoperable tests that test for "this WeakRef must be empty now", only "this WeakRef must not be empty now"
18:04	<shu>	you can write tests that test implications, though, like "if this WeakRef is now empty, then these other properties must hold"
18:04	<shu>	test262 have tests of that shape
18:04	<devsnek>	shu now you need to write a turbofan pass that inlines `obj.x`
18:04	<Mathieu Hofman>	test262 have tests of that shape They're actually broken, I have on my todo to fix them
18:04	<shu>	oh yeah?
18:06	<Mathieu Hofman>	The hooks and most tests still use `cleanupSome`.
18:06	<shu>	oh lol
18:06	<devsnek>	i miss cleanupSome
18:06	<Mathieu Hofman>	I rewrote the hooks locally already, I need to fix all the tests
18:06	<shu>	excellent, than kyou
18:07	<devsnek>	is cleanupSome just waiting on the champions at this point
18:08	<Mathieu Hofman>	Would be neat to have a flag to the test262 execution that says "this implementation supports GC and has all host hooks implemented, so these tests must collect as expected"
18:09	<shu>	devsnek: more than that was my understanding; Apple already rejected the wasm use case as compelling enough to add cleanupSome, and i don't know that a more compelling argument has been presented
18:09	<devsnek>	are you saying people provide no-op hooks? :O
18:10	<Mathieu Hofman>	Correct the current gc hooks are not, afaik, provided by the different implementations, so it's relying on a fallback, which is not working right.
18:11	<devsnek>	its weird that apple cares about the aesthetics of cleanupSome but not of Atomics, both being designed to be used in weird non-idiomatic-js cases
18:11	<Mathieu Hofman>	I'm talking about the `clearKeptObjects` and "cleanupFinalizationRegistries" which is not a currently requested hook but should be
18:13	<devsnek>	hmm why don't i implement clearKeptObjects 🤔
18:13	<devsnek>	does $262.clearKeptObjects just call ClearKeptObjects
18:13	<devsnek>	its not in INTERPRETING.md
18:15	<Mathieu Hofman>	FYI, here is the async-gc harness fixed to not rely on `cleanupSome` and one test fixed: https://github.com/mhofman/test262/commit/a4ae8c8102586a29e06292556bc565776d19b045 Haven't gotten around on fixing the rest
18:26	<Mathieu Hofman>	hmm why don't i implement clearKeptObjects 🤔 Yeah I remember engine262 didn't expose the hooks, and the built-in fallbacks didn't work, so I couldn't check it worked there. The fallbacks I wrote cover at least JSC, SM, v8 and XS
18:26	<Mathieu Hofman>	I also found some weird behaviors in engine262 which claimed some things get cleaned up when they shouldn't. That was a separate and much more involved test, and I didn't have time to dig in
18:27	<devsnek>	stuff should be pretty easy to impl in engine262 when you're testing
18:28	<devsnek>	like https://gc.gy/65d126c9-a354-42e7-a63f-2555a9f035c1.png