4 ms·

The GC spec has been stalled for a while with no clear path forward in sight (because the goals for WASM GC are incredibly hard to meet). DOM access will be po

• weberc2 7y ago
  I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance). LLVM has an interface for GCs such that the host language can provide LLVM with information about what kind of code to generate at the boundary between the application and the GC, but that’s just shim code; not a full GC implementation, and even then I’m not sure of any languages that make use of it. Even still, it’s cool to see the WASM folks trying to tackle these big tricky problems!
  • pcwalton 7y ago
    GC in wasm is proposed for two purposes: (1) DOM objects are garbage collected and so first-class support for them in wasm requires a GC; (2) optimal moving GC requires runtime support. A garbage collector needs to be able to walk stacks to find the root set of pointers, but the stack is hidden from the program in wasm.
  • tcard 7y ago
    In mobile code, a builtin runtime means less code to download, which may be preferable to GC performance.