[vivin]

> For now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent.

Does this worry anyone else? Or I am getting worked up over nothing?

[white-flame]

Dynamic, managed languages can compile to JS.

Static languages can compile to wasm. Low-level runtime implementations of other managed languages which don't mesh well with JS backends can compile to wasm.

Webasm doesn't replace JS, it complements it.

[thaumasiotes]

It seems like the normal thing to do would be to develop for a runtime that does feature GC?

Of all the things you've ever encountered called "assembly language", how many supported GC?

[tyingq]

It is on the wasm roadmap, along with other things that sound more like a virtual machine, and less like ASM. I assume to allow for dynamically typed languages without a download of the entire runtime.

[vivin]

I wasn't talking about the language, but the runtime I guess.

[pfooti]

Yeah, it's of moderate concern. I can see why it's not really a priority here, since they're probably targeting languages that already don't have GC to compile into WASM, like c++ as a canonical example. I have to imagine that GC is also a pretty huge section of performance / JIT compilation problems in the javascript runtime. So shipping a spec that doesn't support it is no worse than allowing statically compiled code to run on desktop computers.

That said, I wonder how the WASM runtime is sandboxed. Not having a runtime-provided memory manager makes me worry not just about memory leaks, but also about explicit shenanigans in different memory zones. It's hard to believe that a WASM runtime doesn't protect against this sort of escaping though, so it's more of an academic wondering than a real concern.

[white-flame]

The addressable memory space doesn't include code, globals, stack, etc, but only that memory which could be considered the heap.

Pointers into memory are 32bit base + 32bit offset, non-wrapping, so 33-bit distances from a base pointer. Each memory access needs a check to that (relatively non-changing) pointer. Memory spaces can request expansion in multiples of 64KB, and can have configured maximum sizes. This leaves it all compatible with using the MMU to trap accesses beyond allowed memory. The example from the paper linked elsewhere is that on a 64 bit machine, you can allocate 8GB of virtual address space, which covers the entire possible addressable range of wasm instructions, and use permissions to trap out of boundness. The very notion of allocating that 8GB already encapsulates memory sandboxing, as long as the addressability limits of instructions can't be usurped (and it's formally been shown to be sound).

[moosingin3space]

> The addressable memory space doesn't include code, globals, stack, etc

Really? In that case, how does a language like Rust, where stack allocation is used regularly, compile to WASM?

[krallja]

GP is referring to the call stack. It is still possible to use the WASM heap as a stack, by maintaining a stack pointer and a base pointer.

[bigato]

That only means that for now, languages will have to provide their own garbage collectors, like Go initially implemented their garbage collector in C which is a language that manages memory manually.