WASM-Garbage-Collection und Referenztypen

Early WASM had only linear memory, forcing managed languages (Java, Kotlin, C#, Dart) to ship their own garbage collector compiled to WASM — bloating binaries.

Reference types add opaque references like externref and funcref that the engine manages, instead of stuffing everything into linear memory.

externref lets WASM hold a handle to a host (JS) object without serializing it into memory — passed by reference, managed by the host GC.

WasmGC introduces engine-managed struct and array heap types. The browser GC reclaims them, so languages reuse the existing collector.

By dropping a bundled collector, WasmGC languages produce much smaller modules and integrate cleanly with the host GC for cyclic references across boundaries.

WasmGC lets you declare typed structs the engine allocates and collects.

Kotlin/Wasm, Dart, Java (via projects like TeaVM), and Scala targets are moving to WasmGC to run efficiently in browsers.

With reference types, passing a DOM node or callback to WASM no longer needs an integer handle table — the reference is held directly.

WasmGC is not a general object model; it offers low-level GC-managed structs/arrays. Language runtimes still build their own object layouts on top.

Existing linear-memory modules keep working; WasmGC is additive. Toolchains opt in, and engines without support fall back or refuse the module.

Combined with the Component Model, WasmGC moves WASM toward being a universal, high-level compile target for nearly any language.

What problem does WasmGC primarily solve for managed languages?

You explored reference types (externref/funcref) and WasmGC heap types. Together they let managed languages target WASM without a bundled collector, producing smaller binaries and seamless host-object interop — a key part of WASM future.