Hacker News Reader

Comment by mpolun | Hacker News Reader

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

View on HN

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

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

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.

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.

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.

Reply on news.ycombinator.com