5 ms·

Not including GC would have been a mistake. Having to carry a complete garbage collector with every program, especially on platforms like browsers were excelle

by aag 1y ago

Not including GC would have been a mistake. Having to carry a complete garbage collector with every program, especially on platforms like browsers were excellent ones already exist, would have been a waste.

ridiculous_fish 1y ago
Doesn't every WASM program have to carry its own malloc/free today?
- phickey 1y ago
  Yes, every wasm program that uses linear memory (which includes all those created by llvm toolchains) must ship with its own allocator. You only get to use the wasm GC provided allocator if your program is using the gc types, which can’t be stored in a linear memory.
- flohofwoe 1y ago
  Yes, but Emscripten comes with a minimal allocator that's good enough for most C code (e.g. code with low alloc/free frequency) and only adds minimal size overhead: https://github.com/emscripten-core/emscripten/blob/main/system/lib/emmalloc.c https://github.com/emscripten-core/emscripten/blob/main/syst...
em-bee 1y ago
how is that different from compiling against a traditional CPU which also doesn't have a built in GC? i mean those programs that need a GC already have one. so what is the benefit of including one on the "CPU"?
- aag 1y ago
  The "CPU" in every browser already has one. This lets garbage-collected languages use that one. That's an enormous savings in code size and development effort.
  - em-bee 1y ago
    i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. so most GC-languages being ported to webassembly already have a GC, so what is the benefit of using a provided GC then? on the other hand i see GC as a feature that could become part of any modern CPU. then the benefit would be large, as any language could use it and wouldn't have to implement their own at all anymore.
    - 0x457 1y ago
      > i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. I'd think porting an existing GC to WASM is more effort than using WASM's GC for a GC'd language?
      - em-bee 1y ago
        i don't think so. first of all, you don't rewrite your code for every CPU but you just adapt some specific things. most code is just compiled for the new architecture and runs. second, those languages that are already running on wasm have already done the work. so at best new languages who haven't been ported yet will get any benefit from a reduced porting effort.
    - aag 1y ago
      Writing a GC that performs well often involves making decisions that are tightly coupled to the processor architecture and operating system as well as the language implementation's memory representations for objects. Using a GC that is already present can solve that problem.
    - phickey 1y ago
      Aside from code size the primary benefit on the Web is that the GC provided to wasm is the same one for the outer JavaScript engine, so an object from wasm can stay alive get collected based on whether JS keeps references to it. So it’s not really about providing a GC for a single wasm module (program), its about participating in one cooperatively with other programs.
- bryanlarsen 1y ago
  The fact that a minimum size go program is a few megabytes in size is acceptable in most places in 2025. If it was shipped over the wire for every run time instead of a single install time download, that would be a different story. Garbage collection is a small part of the go run time, but it's not insignificant.
  - onionisafruit 1y ago
    I will be interested to see if Go is able to make use of this GC and if so, how much that wasm binaries
    - davey48016 1y ago
      https://github.com/golang/go/issues/63904 https://github.com/golang/go/issues/63904 Skimming this issue, it seems like they weren't expecting to be able to use this GC. I know C# couldn't either, at least based on an earlier state of the proposal.
      - em-bee 1y ago
        this thread confirms my suspicions. some languages may benefit from a built in GC, but those languages probably use a generic GC to begin with. wheras any language that has a highly optimized GC for their own needs won't be able to use this one.
- circuit10 1y ago
  WebAssembly programs can't directly read their own stack because of how it's designed, meaning that scanning for live objects within WASM is inefficient as you have to keep a separate stack in software for GC
AgentME 1y ago
It's also important because sometimes you want a WebAssembly instance to hold a reference to a GC object from Javascript, such as a DOM object, or be able to return a similar GC object back to Javascript or to another separate WebAssembly instance. Doing the first part alone is easy to do with a little bit of JS code (make the JS code hold a reference to the GC object, give the Wasm an id that corresponds to it, and let the Wasm import some custom JS functions that can operate on that id), but it's not composable in a way that lets the rest of those tasks work in a general way.

by aag 1y ago

ridiculous_fish 1y ago

Doesn't every WASM program have to carry its own malloc/free today?

phickey 1y ago
Yes, every wasm program that uses linear memory (which includes all those created by llvm toolchains) must ship with its own allocator. You only get to use the wasm GC provided allocator if your program is using the gc types, which can’t be stored in a linear memory.
flohofwoe 1y ago
Yes, but Emscripten comes with a minimal allocator that's good enough for most C code (e.g. code with low alloc/free frequency) and only adds minimal size overhead: https://github.com/emscripten-core/emscripten/blob/main/system/lib/emmalloc.c https://github.com/emscripten-core/emscripten/blob/main/syst...

em-bee 1y ago

how is that different from compiling against a traditional CPU which also doesn't have a built in GC? i mean those programs that need a GC already have one. so what is the benefit of including one on the "CPU"?

aag 1y ago
The "CPU" in every browser already has one. This lets garbage-collected languages use that one. That's an enormous savings in code size and development effort.
- em-bee 1y ago
  i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. so most GC-languages being ported to webassembly already have a GC, so what is the benefit of using a provided GC then? on the other hand i see GC as a feature that could become part of any modern CPU. then the benefit would be large, as any language could use it and wouldn't have to implement their own at all anymore.
  - 0x457 1y ago
    > i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. I'd think porting an existing GC to WASM is more effort than using WASM's GC for a GC'd language?
    - em-bee 1y ago
      i don't think so. first of all, you don't rewrite your code for every CPU but you just adapt some specific things. most code is just compiled for the new architecture and runs. second, those languages that are already running on wasm have already done the work. so at best new languages who haven't been ported yet will get any benefit from a reduced porting effort.
  - aag 1y ago
    Writing a GC that performs well often involves making decisions that are tightly coupled to the processor architecture and operating system as well as the language implementation's memory representations for objects. Using a GC that is already present can solve that problem.
  - phickey 1y ago
    Aside from code size the primary benefit on the Web is that the GC provided to wasm is the same one for the outer JavaScript engine, so an object from wasm can stay alive get collected based on whether JS keeps references to it. So it’s not really about providing a GC for a single wasm module (program), its about participating in one cooperatively with other programs.
bryanlarsen 1y ago
The fact that a minimum size go program is a few megabytes in size is acceptable in most places in 2025. If it was shipped over the wire for every run time instead of a single install time download, that would be a different story. Garbage collection is a small part of the go run time, but it's not insignificant.
- onionisafruit 1y ago
  I will be interested to see if Go is able to make use of this GC and if so, how much that wasm binaries
  - davey48016 1y ago
    https://github.com/golang/go/issues/63904 https://github.com/golang/go/issues/63904 Skimming this issue, it seems like they weren't expecting to be able to use this GC. I know C# couldn't either, at least based on an earlier state of the proposal.
    - em-bee 1y ago
      this thread confirms my suspicions. some languages may benefit from a built in GC, but those languages probably use a generic GC to begin with. wheras any language that has a highly optimized GC for their own needs won't be able to use this one.
circuit10 1y ago
WebAssembly programs can't directly read their own stack because of how it's designed, meaning that scanning for live objects within WASM is inefficient as you have to keep a separate stack in software for GC

AgentME 1y ago

It's also important because sometimes you want a WebAssembly instance to hold a reference to a GC object from Javascript, such as a DOM object, or be able to return a similar GC object back to Javascript or to another separate WebAssembly instance. Doing the first part alone is easy to do with a little bit of JS code (make the JS code hold a reference to the GC object, give the Wasm an id that corresponds to it, and let the Wasm import some custom JS functions that can operate on that id), but it's not composable in a way that lets the rest of those tasks work in a general way.