> I've seen numerous discussions about integrating WebAssembly with the JavaScript heap. That might not require full GC; ownership semantics might suffice (such that either wasm or JS can own the object at any given time, and within the wasm world it can use wasm memory management).
Those discussions have not resulted in a proposal.
Ownership semantics are most likely not going to work. The options being considered are:
- WebAssembly has strong or weak handles to JS objects. That's not ownership.
- WebAssembly can allocate GC'd objects. That's not ownership.
- WebAssembly exposes enough stuff so that you can write your own GC. That's ownership, sorta, but doesn't allow wasm to access JS objects. Wasm would simply own objects it allocated in its own heap and would never be able to claim ownership of JS objects or relinquish ownership of its objects to JS. By itself, this means zero GC interop with JS.
Most likely, we'll end up with all three options.
It sounds like you're proposing that WebAssembly can somehow come to own a JS object. That's not practical, since it would imply either eagerly ref-counting all JS objects (that's a 2x slow-down), or it would imply full synchronous GC every time you share any object (totally impractical), or it would imply pretending that WebAssembly can own an object without first proving it (then wasm code could create use-after-free bugs to escape the web sandbox).
> What we have today seems very close to that in practice.
You have to use JS API to load wasm, so we're not close to this at all.
> A combination of a fast bytecode interpreter and compiled code caching could probably manage that. Or a fast, targeted JIT.
So long as WebAssembly is a low-level compiler target, that implies that developers shipping WebAssembly will also be shipping a userland for whatever their source language is. See emscripten for example, which has a large userland (the "emsdk", which includes libc and other things). So long as this is the pattern, WebAssembly will necessarily take longer to load than JS because the same program written in wasm will be bigger than its JS variant.
> Still an improvement, but also see above about ownership semantics.
I don't think your ownership idea will work, see above.
