- GC types in WebAssembly. That's still an open problem, but that would give you API access.
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).
- Ability to load WebAssembly via something like <script>.
What we have today seems very close to that in practice.
- WebAssembly would have to load and start as quickly as JS.
A combination of a fast bytecode interpreter and compiled code caching could probably manage that. Or a fast, targeted JIT.
Note also that GC types would make it harder to compile existing languages to wasm, since those GC types will probably have to have JS semantics built into them from the start to allow API interoperability. So, even if wasm succeeds in the way you'd like, it would probably mean that the language of the web is still something JavaScriptey.
Still an improvement, but also see above about ownership semantics.
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
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).
What we have today seems very close to that in practice.
A combination of a fast bytecode interpreter and compiled code caching could probably manage that. Or a fast, targeted JIT.
Still an improvement, but also see above about ownership semantics.
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.
For reference, the current GC proposal is here: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
I expect it'll be discussed at an upcoming CG meeting. Either the next one or the one after.