Really? I had the impression it's the other way around.

If it would have GC, other languages would have to use the supplied GC.

If it wouldn't have GC, other languages could simply implement their own GC.

(author of WAVM here)

WebAssembly definitely benefits from being able to avoid the JavaScript garbage collector.

I'm working on a garbage collected language that will use WebAssembly/WAVM as that backend. It's possible as-is, but may require some non-standard extensions to get good performance (e.g. to find GC roots on the stack). I'll certainly contribute anything I do there for standardization, but I suspect the WebAssembly committee will beat me to it.

No. They could implement their own GC either way. However the native GC would be faster than one running inside the VM.

There might not be that big of a performance penalty once WebAssembly gets SIMD, shared memory threads and 64bit ints though.

> implement their own GC

when that would be so easy, maybe. But especially on top of the browser restrictions that will be even harder.

Garbage collection is not magic. It's a fairly simple (but byzantine) matter of tracking references, and allocating and freeing memory. Why would this be so much harder for WebAssembly? Why can't existing garbage collectors be compiled to WA?

> Why can't existing garbage collectors be compiled to WA?

Yes I think that's the idea.

Exactly. From what I've seen of WebAsm, you can request pages of memory using grow_memory. Upon this, you could implement a memory pool system to handle malloc and free. Using this, it is trivial to port existing GC's.

I don't understand why people moan about GC in WebAsm. WebAsm is a compiler target for lower level languages, not the JVM.