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.
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.
Binary bytecode, which is what webassembly apps are, is often, generally, almost always smaller than source code. Except for really small programs.
Also, js code needs to be parsed previously. Webassembly code does not. Webassembly should load faster and execute faster.
I believe the thought was that, for many languages, there is an additional, standard runtime, which is not always remove-able from the language itself, which may not always be of a trivial size, and which is not guaranteed to be already available on a client machine.
Comments
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).
You have to use JS API to load wasm, so we're not close to this at all.
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.
I don't think your ownership idea will work, see above.
Binary bytecode, which is what webassembly apps are, is often, generally, almost always smaller than source code. Except for really small programs.
Also, js code needs to be parsed previously. Webassembly code does not. Webassembly should load faster and execute faster.
Happy times ahead on the browser side...
I believe the thought was that, for many languages, there is an additional, standard runtime, which is not always remove-able from the language itself, which may not always be of a trivial size, and which is not guaranteed to be already available on a client machine.
I think you're misunderstanding Fil's point: JS is more expressive, and can often encode more things in a smaller package.
For same-code wasm / asm.js / x86 comparison (not what Fil was talking about) see section 7.3: https://github.com/WebAssembly/spec/blob/master/papers/pldi2...
Additionally, WebAssembly definitely needs to be parsed. See: https://github.com/WebKit/webkit/blob/master/Source/JavaScri... and https://github.com/WebKit/webkit/blob/master/Source/JavaScri...
Granted, that's simpler than parsing JavaScript.