6 ms·

Is garbage collection really needed?

m00dy 5y ago
isn't it part of the runtime ?
mpolun 5y ago
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
- kllrnohj 5y ago
  > 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.
  - titzer 5y ago
    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.
- tormeh 5y ago
  Go ships its own GC as part of the binary for non-wasm targets. Why should wasm be special?
  - astrange 5y ago
    If you share objects between wasm and JS then you want to share garbage collectors so you don’t have to pin them.
- usrn 5y ago
  Is bringing your own GC that hard? I think putting one in the spec would bloat Wasm runtimes which would be more concerning.
  - titzer 5y ago
    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.
- rlp 5y ago
  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).
- pjmlp 5y ago
  Flash, Silverlight, Java, TinyGo and .NET are doing just fine on WebAssembly.
  - emteycz 5y ago
    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.
    - pjmlp 5y ago
      You mean like using JScript alongside C# and IronPython on the CLR, ah the circles of rediscovery.
      - emteycz 5y ago
        Exactly like that, but also in a secure sandbox and in the browser. Can CLR do that without Wasm?
        pjmlp 5y ago
        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://webassembly.org/docs/security https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf
        emteycz 5y ago
        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.
aaaaaaaaata 5y ago
"No, but it helps." Opens up the target to an additional subset of devs.
colordrops 5y ago
Only way to get rid of JS as an intermediary for DOM access, yes. GC and the DOM are intimately related.
- the_duke 5y ago
  Direct Dom access could already be implemented with reference types. GC integration is not necessary for that.
  - colordrops 5y ago
    What is blocking it from being implemented in browsers at the moment?

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

kllrnohj 5y ago
> 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.
- titzer 5y ago
  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.
tormeh 5y ago
Go ships its own GC as part of the binary for non-wasm targets. Why should wasm be special?
- astrange 5y ago
  If you share objects between wasm and JS then you want to share garbage collectors so you don’t have to pin them.
usrn 5y ago
Is bringing your own GC that hard? I think putting one in the spec would bloat Wasm runtimes which would be more concerning.
- titzer 5y ago
  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.
rlp 5y ago
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).
pjmlp 5y ago
Flash, Silverlight, Java, TinyGo and .NET are doing just fine on WebAssembly.
- emteycz 5y ago
  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.
  - pjmlp 5y ago
    You mean like using JScript alongside C# and IronPython on the CLR, ah the circles of rediscovery.
    - emteycz 5y ago
      Exactly like that, but also in a secure sandbox and in the browser. Can CLR do that without Wasm?
      - pjmlp 5y ago
        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://webassembly.org/docs/security https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf
        emteycz 5y ago
        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.

aaaaaaaaata 5y ago

"No, but it helps." Opens up the target to an additional subset of devs.

colordrops 5y ago

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

the_duke 5y ago
Direct Dom access could already be implemented with reference types. GC integration is not necessary for that.
- colordrops 5y ago
  What is blocking it from being implemented in browsers at the moment?