| 22:59 | <shu> | Didn't V8 also initially consider banning shared to local edges? Do we know more about what led V8 to change their minds? there are two things you get out of banning all shared->local edges:
|
| 23:02 | <shu> | as we experimented more, we realized that 2) wasn't possible. as part of the shared WasmGC proposal, it's very clear from the partner feedback that we can't get away with banning all shared->local edges. Flutter, among a bunch of other Google partners, have been clear that they need either thread-bound (i.e. a shared struct can hold a reference to some unshared thing, but it is an error to access that reference from another thread), or thread-local data |
| 23:03 | <shu> | implementing support for thread-bound or thread-local data in almost all cases, boil down to the same work required in the GC as implementing support for shared things as keys in WeakMaps |
| 23:03 | <shu> | the WeakMap itself isn't shared and is local to a particular thread, so you still have the correctness property (1) above. but it asks extra complexity of the GC because you now have a local things whose liveness depends on a shared thing |
| 23:04 | <shu> | the bulk of this discussion has been happening on the Wasm side |
| 23:07 | <shu> | the high-level recap for folks here is that the difficulty in the GC is in collecting cycles that span multiple threads. if you have a reference cycle T1 -> T2 -> T1, nobody's GC is set up to detect and collect that without significant work. the main counterproposal is to say, don't support shared structs as WeakMap keys. instead let the toolchains and compilers figure it out. my counterargument to that counterproposal is, that means toolchains will use strong Maps, which means in practice applications will leak everything. that seems strictly worse to me than supporting shared structs as WeakMap keys, but leak the cycles in the meantime until the GC work can be done. acyclic entries can be collected without additional work |
| 23:08 | <shu> | there is also another counteproposal which is to push manual memory management to the user: some kind of dispose() or drop() or whatever to manually break cycles |
| 23:09 | <shu> | i gave a presentation of this like a year ago in TC39 |
| 23:10 | <shu> | but i don't think people were paying attention |
| 23:11 | <shu> | the highest order bit here i think is, from the shared WasmGC side, WeakMap support is a hard requirement from our partners |
| 23:12 | <shu> | debates about language feature compositionality and implementation difficulty are both downstream from that |
| 23:13 | <shu> | that is, arguments against WeakMap support without an alternative that the partners can live with won't be compelling |
| 23:15 | <shu> | I am not convinced that it makes incremental adoption so much harder that it outweighs the benefit of being able to ship something sooner. |
| 23:15 | <shu> | perhaps incremental in the JS space, but "initial" when taking both JS+WasmGC into account given what i said above |
| 23:18 | <shu> | i think that's why we were talking past each other about the shipping timeline |
| 23:18 | <shu> | if this is the thing that delays shipping, then... yeah, it's gonna have to, because the folks the V8 team have been talking to who're most interested in the feature need it even for the MVP |
| 23:27 | <shu> | i think the takeaway here is "please wait for more implementation experience from V8", because it's certainly hard for us too but we have some ideas of threading the needle |