TC39 Structs and Shared Structs on 2024-09-02

10:39	<nicolo-ribaudo>	Hey I have a question
10:39	<nicolo-ribaudo>	Can a shared struct store a SharedArrayBuffer in one of its fields?
10:40	<nicolo-ribaudo>	I was originally assuming yes, because a SharedArrayBuffer is shareable, however I'm now having doubts because the value of the field would actually be the object wrapper around the shared buffer
13:43	<rbuckton>	Unfortunately, no, due to how a SAB is a regular JS object. The proposal adds a SharedArray, but it's not quite the same.
14:13	<shu>	I was originally assuming yes, because a SharedArrayBuffer is shareable, however I'm now having doubts because the value of the field would actually be the object wrapper around the shared buffer no, not unless we introduce a SharedArrayBuffer2ThatsActuallySharedHaha or something
14:13	<shu>	which, i mean, we could
14:14	<shu>	like the easiest intermediate solution is probably a `SAB.token` that returns some opaque, shareable thing that can be passed back into a SAB constructor. this is not great because it encourages multiple wrappers, but that's already how SABs are
14:16	<nicolo-ribaudo>	If typed array constructors accept that opaque thing as a parameter, then probably we are good
14:17	<nicolo-ribaudo>	Since most uses of a SharedArrayBuffer is to just pass it to a TypedArray constructor
16:06	<littledan (PTO until September 16)>	shu: Can you give us any more information about the partner use cases?
20:18	<shu>	shu: Can you give us any more information about the partner use cases? flutter's is the easiest to explain, i think. they will be compiling Dart to shared WasmGC. they associate DOM nodes with Dart objects that represent app state, including event listener callbacks. Dart objects themselves will be shareable across threads, but the event listener will only be accessible on the main thread (what we're calling thread-bound data). event listener callbacks close over the DOM node (in the main thread heap), the DOM node references the Dart object (in the shared heap), forming a cross-heap cycle
20:19	<shu>	the simplest implementation technique for thread-bound data is a per-thread ephemeron map internally keyed by shared objects
20:19	<shu>	so the GC work needed to support that use case boils down to the same work as supporting shared objects as weakmap keys (if you want to collect cycles)
20:20	<shu>	does that help?
20:21	<shu>	If typed array constructors accept that opaque thing as a parameter, then probably we are good yeah, that's what i'm thinking
20:21	<shu>	i'm not proposing it in this proposal though, since it's large enough. easy to tack on as a separate proposal
20:26	<shu>	shu: Can you give us any more information about the partner use cases? my suspicion is the event listener pattern will be responsible for the lion's share of actual use cases for cross-heap cycles. the interesting property there is that those really only concern cycles between the main thread (since the DOM only exists there) and the shared heap. V8's current prototyping plans (as an FYI, not as a promise) is to see if it's sufficient for memory use if we can only collect main thread cycles like that, not arbitrary cycles. the idea is that the main thread is already very special on the web, so, if we trace through the shared heap at the same time as a main thread major GC, that might be good enough. and indeed, for a full multithreaded GC we'd need actual workload data to determine how to tune / architect anyway
20:29	<shu>	and to bring it full circle, that's where we are in the "please wait for V8 impl experience" takeaway i said above