I assume this page describes what changed since 1.0:
Since the original release 1.0 of the WebAssembly specification, a number of proposals for extensions have been integrated. The following sections provide an overview of what has changed.
Thanks! Here's a quick summary from there, with links to the implemented proposals.
Multiple values: Generalized the result type of blocks and functions to allow for multiple values; in addition, introduced the ability to have block parameters
Vector instructions: Added vector type and instructions that manipulate multiple numeric values in parallel (also known as SIMD, single instruction multiple data)
I think that's the process, yes. Features get proposed, discussed, implemented, then eventually when they're done they're moved into the spec and tagged with a version.
Appreciate this. Can you explain why there appear to be English-looking letters used for terms but with alternate Unicode versions? Makes everything look jumbly but I'm sure there's a good reason.
externtype ::= func functype | table tabletype | mem memtype | global globaltype
On Safari, the tokens fun, table, men, and global render with weird font baselines on some letters: c, o, e and a are raised a few points higher than they should be. I just figured these were odd substitutions for ASCII characters from further in the Unicode alphabet, maybe to avoid collisions with other reserved token names or something (vamping here because it was all I could think of). Sorry about that.
It looks like garbage collection is at the 'proposal' stage, one step before it would start to be implemented.
"During this phase:
"One or more implementations proceed on prototyping the feature to the point that a comprehensive set of tests can be added.
"A test suite is added. These tests need not pass the reference interpreter at this point, but should pass on some implementation."
It's for proper integration of garbage collected languages -- otherwise you need to embed your GC too, which bloats the wasm. JS host VMs have very good GCs these days, so hooking into them allows for better integration by e.g. go, Java, C#, etc.
Also, WebAssembly can't support most GC runtimes now, because you can't scan the stack for roots. You can keep your own shadow stack on the heap, but that has a bunch of pretty bad performance implications. This actually impacts C/C++/Rust codegen as well, since they can't create references/pointers to anything on the stack, and have to build their own shadow stack (I think this is done in binaryen or LLVM itself?). I understand it's a security thing to disallow direct stack access, but most languages and runtimes expect it.
Anyways, that's why there needs to be support in WebAssembly for GC, because there needs to be a safe way to walk the stack (aside from the obvious JS interop considerations).
Aren't all of them single-threaded, though? That is, they only work in a VM with a single thread which the GC shares? Since WASM is supposedly finally bringing real multi threading to the web, how would that work? It seems like you'd need a new GC for WASM rather then just repurposing the JS GC.
Many JS GCs are internally multi-threaded and can handle multiple allocators. Even though JS isn't itself multi-threaded, the JIT and runtime systems now are, and they can concurrently allocate onto the heap. V8 has had to move towards this ability very gradually because of assumptions from the single-threaded world, but it's much more likely to support multi-threaded Wasm GC, should it be necessary, in the future.
I've done it for Virgil. It's a major pain, because Wasm, by design, does not give access to the value stack. So to find roots you need to spill them into memory into what is called a "shadow stack".
The problem with bringing your own GC isn't just that, though. It's that using linear memory for everything, you're forced to put external references in a table, which roots them. Tables aren't weak...and even if they were, it's possible to set up a cycle between the linear-memory GC references and external references so that leaks happen. This was a problem in other contexts, for example, in V8 embedded into Chromium, and the ultimate result is that you need cooperative garbage collection across two heaps, with queues. While V8 and Chromium trust each other, both not to screw up, and to be fast, it's hard to see how to make that cooperative garbage collection contract work with untrusted Wasm code.
In isolation, but no cross-language invocations, reference sharing etc yet.
It'll work as promised when I can import a C# class in my JS code, instantiate it and then pass one of its methods to a Python module and invoke it from there.
Silverlight never had even the slightest hint of security, and no interop with JS or non-CLR (e.g. JVM) languages.
It was also comically slow and worked only in IE.
I'm well versed in security of Wasm. Much better than anything else available today or in the past, obviously still not perfect.
One of the best features of Wasm is entirely social - seems like everyone has agreed on it, finally. That's enough for me even if it was a 1:1 copy of JVM or CLR.
So says the marketing, usually pushed by those with an agenda with WebAssembly, forgetting about all those that trace back to the early 1960's and mainframe language environments with capabilities.
Lets sell old stuff as something new, never done before, rewriting history.
More recent chapter, application servers with WebAssembly, what a great idea!
I really don't think anybody is forgetting anything since people like you keep writing about it in every Wasm discussion thread since at least 2015. At this point, literally everybody involved with Wasm knows.
And people have seen what was in the past and created a modern, well-composed solution that is accepted by all major players. Excellent if you ask me. Yeah nobody has invented a new wheel here - but that's not necessary, actually it might be counter-productive to the goals of Wasm. Wasm wants to take stable, well-known ideas, improve upon the warts of previous tech like CLR and JVM and put it on 100 billion devices.
Supporting GC on WebAssembly has been a _major_ pain for TinyGo because WebAssembly doesn't allow access to the stack. It's really slow and I'm still not confident it's bug free. Having a GC integrated in WebAssembly itself should solve these issues.
Unfortunately, the current GC design for WebAssembly doesn't support interior pointers which is going to be difficult to work around (but I don't think it's impossible). Interior pointers are normally required in Go.
