Hacker News Reader

Comment by tux3 | Hacker News Reader

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.

https://webassembly.github.io/spec/core/appendix/changes.htm...

View on HN

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

https://github.com/WebAssembly/spec/blob/main/proposals/mult...

Reference types: Added and as new value types and respective instructions

Table instructions: Added instructions to directly access and modify tables

Multiple tables: Added the ability to use multiple tables per module

Bulk memory and table instructions: Added instructions that modify ranges of memory or table entries

https://github.com/WebAssembly/spec/blob/main/proposals/refe...

https://github.com/WebAssembly/spec/blob/main/proposals/bulk...

Vector instructions: Added vector type and instructions that manipulate multiple numeric values in parallel (also known as SIMD, single instruction multiple data)

https://github.com/WebAssembly/spec/tree/main/proposals/simd...

Sign extension instructions: Added new numeric instructions for performing sign extension within integer representations.

https://github.com/WebAssembly/spec/blob/main/proposals/sign...

Non-trapping float-to-int conversions: Added new conversion instructions that avoid trapping when converting a floating-point number to an integer

https://github.com/WebAssembly/spec/blob/main/proposals/nont...

So it looks like it's basically slapping a 2.0 on standardized features from the roadmap: https://webassembly.org/roadmap/

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.

Just realised this will make it easier for tools like caniuse. Instead of listing all features, they can just have "webgpu 2.0 availability"

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.

Are you talking about the MathJax rendering used for instruction names?

False alarm. I think it's a font rendering problem on Safari. When I tried Chrome and Firefox it didn't appear. For example, under "External Types" at https://www.w3.org/TR/wasm-core-2/syntax/types.html#external... you see this grammar rule:

    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.

I mean, it is definitely a problem. https://pasteboard.co/xzgTi4TxK326.jpg

SEE I’M NOT INSANE!

Am I still correct in saying these two features are still missing from Wasm? 1. Native Strings 2. DOM interaction

The additions that look interesting to me are multiple return values for functions, and table manipulations.

IIRC tables are used to communicate things like function pointers with the host executor, maybe like a vtable but more general.

No garbage collection integration yet? Or is it done as a separate work?

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."

https://github.com/WebAssembly/proposals

https://github.com/WebAssembly/meetings/blob/main/process/ph...

Here's the proposal:

https://github.com/WebAssembly/gc

And you can see it's being actively worked on:

https://github.com/WebAssembly/gc/commits/main

Under implementation in Chromium too https://bugs.chromium.org/p/v8/issues/detail?id=7748

And Dart has an experimental wasm backend that leverages that work in v8 here: https://github.com/dart-lang/sdk/blob/main/pkg/dart2wasm/dar...

Is garbage collection really needed?

isn't it part of the runtime ?

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.

Right now wasm is really designed for C/C++/rust

> JS host VMs have very good GCs these days

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.

Go ships its own GC as part of the binary for non-wasm targets. Why should wasm be special?

If you share objects between wasm and JS then you want to share garbage collectors so you don’t have to pin them.

Is bringing your own GC that hard? I think putting one in the spec would bloat Wasm runtimes which would be more concerning.

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.

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).

Flash, Silverlight, Java, TinyGo and .NET are doing just fine on WebAssembly.

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.

Great times are ahead of us.

You mean like using JScript alongside C# and IronPython on the CLR, ah the circles of rediscovery.

Exactly like that, but also in a secure sandbox and in the browser. Can CLR do that without Wasm?

In the browser, that is what Silverlight was all about.

Outside of the browser, WebAssembly is still a shadow of CLR capabilities, including sandboxing.

As for the "secure" in WebAssembly, I advise a good read about the security section, specially memory corruption

https://webassembly.org/docs/security

https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf

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.

The new NoSQL and big data hype of bytecode based runtimes.

Not really, just finally a real common language runtime.

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.

"No, but it helps."

Opens up the target to an additional subset of devs.

Only way to get rid of JS as an intermediary for DOM access, yes. GC and the DOM are intimately related.

Direct Dom access could already be implemented with reference types. GC integration is not necessary for that.

What is blocking it from being implemented in browsers at the moment?

Reply on news.ycombinator.com