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.
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.
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.
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:
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"?
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.
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.
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|5 months ago
ridiculous_fish|5 months ago
phickey|5 months ago
flohofwoe|5 months ago
https://github.com/emscripten-core/emscripten/blob/main/syst...
em-bee|5 months ago
bryanlarsen|5 months ago
Garbage collection is a small part of the go run time, but it's not insignificant.
aag|5 months ago
circuit10|5 months ago