Interesting - they essentially ship a GC inside the Wasm runtime that replaces what the language VM - be it the JVM, the .NET CLR, Go's GC would supply.
But that raises the question - wouldn't it imply that this GC needs to support every special feature of every language (interior pointers, pinning, value types etc.), and have access to the stack layout to have a chance of working?
Sounds like a hairy problem to me.
Although not having to ship a GC might be a major boon since in my experience, WASM runtimes tend to be on the larger size.
Yes, that's definitely true: a single GC will not be optimal for everything, or even possible. Atm interior pointers are not supported at all, for example, but they are on the roadmap for later:
What launched now is enough WasmGC to support a big and useful set of languages (Java, Kotlin, Dart, OCaml, Scheme), but a lot more work will be required here!
WASM still grants access to a PL to simply decide to allocate a byte and manage it itself. interior pointers and value types seem like they could be handled by reference counting + native memory allocation. Much like Python is trying to do to introduce tracing GC. Use RC when you can't use the tracing GC.
But that raises the question - wouldn't it imply that this GC needs to support every special feature of every language (interior pointers, pinning, value types etc.), and have access to the stack layout to have a chance of working?
Sounds like a hairy problem to me.
Although not having to ship a GC might be a major boon since in my experience, WASM runtimes tend to be on the larger size.