4 ms·

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

by 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.
    - em-bee 1y ago
      now that would make a lot of sense, thanks
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

by em-bee 1y ago

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.
  - em-bee 1y ago
    now that would make a lot of sense, thanks

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