3 ms·

No one has ever articulated the details of what they mean by these runtimes having different GC requirements. JavaScript garbage collection has no "semantics"--

by titzer 5y ago

No one has ever articulated the details of what they mean by these runtimes having different GC requirements. JavaScript garbage collection has no "semantics"--it is entirely invisible to applications. Even WeakMap and WeakSet do not expose garbage collection details because they are not iterable. The memory profile of JavaScript applications tends to look a lot like the memory profile of typical Java applications. It tends to be a law of large numbers. Now if you want to talk about details of how we implement runtimes that do have observable GC details, like weak callbacks, Java's zoo of reference types, etc, then let's do that, because Wasm GC will eventually need to have low-level mechanisms to support those. But if we're talking about a Wasm engine GC's ability to allocate, trace, move (or not!) little blocks of memory around, then I don't see any fundamental stumbling blocks to making that mechanism efficient and universal.

pjmlp 5y ago
For example, the existing JS GC doesn't need to expose ability to stop the GC, execute on demand, support value types, pinning memory, interior pointers, control GC regions, marshaling to native code to the developer, whereas a .NET or D GC does. So if a future WASM GC doesn't offer APIs for such capabilities, it is useless from those runtimes point of view.
- titzer 5y ago
  Thanks for getting down to brass tacks. Of the things that you mentioned, I think that interior pointers are the only thing that is relevant. Java has an API for executing the GC on demand, and VM engineers I have talked to over the years think it's a knob that apps shouldn't have. Wasm already supports multiple return values, so you don't need to box value types on any boundary--they can be flattened whereever they occur. Pinning memory has to do with interfacing native code that could potentially do unsafe things. That doesn't fit into wasm's model, and would only be necessary for interacting with platform APIs, which are being designed not to need that. Same for "marshalling to native code". I don't understand what you mean by GC regions. Realtime Java had GC regions and a complex system for trying to allow threads to run without touching the heap. It really didn't go well. I think if regions are useful for a GC, the engine should do inference of them, because adding regions to the type system infects everything.

by titzer 5y ago

pjmlp 5y ago

For example, the existing JS GC doesn't need to expose ability to stop the GC, execute on demand, support value types, pinning memory, interior pointers, control GC regions, marshaling to native code to the developer, whereas a .NET or D GC does. So if a future WASM GC doesn't offer APIs for such capabilities, it is useless from those runtimes point of view.

titzer 5y ago
Thanks for getting down to brass tacks. Of the things that you mentioned, I think that interior pointers are the only thing that is relevant. Java has an API for executing the GC on demand, and VM engineers I have talked to over the years think it's a knob that apps shouldn't have. Wasm already supports multiple return values, so you don't need to box value types on any boundary--they can be flattened whereever they occur. Pinning memory has to do with interfacing native code that could potentially do unsafe things. That doesn't fit into wasm's model, and would only be necessary for interacting with platform APIs, which are being designed not to need that. Same for "marshalling to native code". I don't understand what you mean by GC regions. Realtime Java had GC regions and a complex system for trying to allow threads to run without touching the heap. It really didn't go well. I think if regions are useful for a GC, the engine should do inference of them, because adding regions to the type system infects everything.