Wasm: The Garbage Collection proposal

While you can compile languages that rely on a Garbage Collector to Wasm already, there is a big downside: They need to ship with a Garbage Collector.

For example: PHP to Wasm compiled modules ship with a compiled GC. That’s contrary to the idea of Webassembly to serve thin modules.

Furthermore it doesn’t make much sense to come with a compiled GC, because the host most of the time already has a Garbage Collector.

As an example: When running PHP -> Wasm compiled modules in the browser, the Garbage Collector of Chromiums V8 engine could be used. Instead of it the module needs to ship with a Garbage Collector.

But help is under its way: A proposal for supporting Garbage Collection in Wasm exists and is currently in Phase 4, the last state before standardizing it.

What the proposal introduces

The proposal does not introduce a new GC! As said before, Web-based runtimes already have GCs which can be used.

Instead, the proposal is about interoperability: It brings the heap-types to the runtimes and makes them interoperable with the compiled languages.

So, it brings: New types and new instructions!

You can find the supported types in the section Use Cases of the proposal. The can be categorized in the following ones:

• function types - functions within the module.
• external types - external references. Possibly owned by the embedder.
• aggregate types - dynamically allocated managed data (structures, arrays or unboxed scalars).

Conclusion

This article gives first insights, why Wasm needs to support Garbage Collection.

Look out for the following articles to read more about it:

• WebAssembly Garbage Collection (WasmGC) now enabled by default in Chrome
• Wasm GC: What Exactly Is It (and Why I Should Care) - youtube.com

A more technical introduction gives A new way to bring garbage collected programming languages efficiently to WebAssembly in the v8.dev blog.