4 ms·

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

richdougherty 5y ago
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/proposals https://github.com/WebAssembly/meetings/blob/main/process/phases.md https://github.com/WebAssembly/meetings/blob/main/process/ph... Here's the proposal: https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc And you can see it's being actively worked on: https://github.com/WebAssembly/gc/commits/main https://github.com/WebAssembly/gc/commits/main
- mhoad 5y ago
  Under implementation in Chromium too https://bugs.chromium.org/p/v8/issues/detail?id=7748 https://bugs.chromium.org/p/v8/issues/detail?id=7748
  - markdog12 5y ago
    And Dart has an experimental wasm backend that leverages that work in v8 here: https://github.com/dart-lang/sdk/blob/main/pkg/dart2wasm/dart2wasm.md https://github.com/dart-lang/sdk/blob/main/pkg/dart2wasm/dar...
gigatexal 5y ago
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.
- 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?

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/proposals https://github.com/WebAssembly/meetings/blob/main/process/phases.md https://github.com/WebAssembly/meetings/blob/main/process/ph... Here's the proposal: https://github.com/WebAssembly/gc https://github.com/WebAssembly/gc And you can see it's being actively worked on: https://github.com/WebAssembly/gc/commits/main https://github.com/WebAssembly/gc/commits/main

mhoad 5y ago
Under implementation in Chromium too https://bugs.chromium.org/p/v8/issues/detail?id=7748 https://bugs.chromium.org/p/v8/issues/detail?id=7748
- markdog12 5y ago
  And Dart has an experimental wasm backend that leverages that work in v8 here: https://github.com/dart-lang/sdk/blob/main/pkg/dart2wasm/dart2wasm.md https://github.com/dart-lang/sdk/blob/main/pkg/dart2wasm/dar...

gigatexal 5y ago

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