Begriff

WebAssembly GC (Garbage Collection)

WebAssembly Programming Languages S4

2 Quellen 0 Lernpfade 1 Backlink enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

WebAssembly (2017) war perfekt für C++ und Rust (Sprachen ohne GC). Sie verwalten ihren Speicher selbst (linear memory). Aber Sprachen wie Java, Kotlin, Dart, Python, C# brauchen einen Garbage Collector. Früher (vor WasmGC) musste man den ganzen GC der Sprache mit in das Wasm-Modul kompilieren. Ergebnis: "Hallo Welt" in Java = 10 MB Wasm-Datei. (Unbenutzbar im Web). WasmGC erlaubt es Wasm, den Garbage Collector des Browsers (V8, JavaScriptCore) mitzunutzen. Die Wasm-Datei enthält nur noch den Code, keinen eigenen GC. Ergebnis: "Hallo Welt" in Java/Kotlin = 50 KB. Das ist der Durchbruch für High-Level-Sprachen im Browser.

Merksatz: Eine Erweiterung des WebAssembly-Standards, die es Wasm-Modulen ermöglicht, direkt auf den Garbage Collector des Host-Systems (z. B. Browser) zuzugreifen, statt einen eigenen GC mitliefern zu müssen.

1. Structs & Arrays

Klassisches Wasm hatte nur Zahlen (i32, f64). WasmGC führt High-Level-Typen ein: struct, array. Der Browser weiß: "Dies ist ein Objekt mit Referenzen auf andere Objekte." Deshalb kann der Browser-GC Zyklenerkennung machen und Speicher freigeben.

2. Interop

Da Wasm jetzt Objekte versteht, wird die Interaktion mit JavaScript viel billiger. Man kann ein Java-Objekt direkt an JS übergeben (und umgekehrt), ohne teures Kopieren/Serialisieren.

1. WasmGC Type System (Structs und Arrays)

WasmGC ist eine fundamentale Änderung des Typsystems. Bisher war Wasm "untyped" (nur Zahlen). Jetzt gibt es sub-Typing und heap-typen. (type $point (struct (field $x f32) (field $y f32))) Der Wasm-Bytecode kann nun Objekte auf dem Heap des Browsers allozieren. Wenn Java-Code in Wasm diese Structs nutzt, weiß der Browser-GC genau, wo die Pointer liegen. Das macht die Garbage Collection so performant, als wäre es natives JavaScript, da der Browser nicht in das "innere" des Wasm-Binärblocks schauen muss – er verwaltet den Heap direkt.

2. Interaction with JS Memory

Ein Problem bei Wasm war immer die "Insel-Isolation". WasmGC bricht das auf. Man kann jetzt eine Referenz auf ein Wasm-Objekt (z.B. ein Kotlin-Objekt) direkt in eine JS-Variable speichern. Wird das Objekt in JS nicht mehr gebraucht, kann der Browser-GC es löschen, solange auch das Wasm-Modul keine Referenz mehr hält. In der Produktion (z.B. bei Google Sheets Web, das Wasm nutzt) erlaubt dies eine extrem enge Verzahnung von komplexer C++/Java-Logik mit dem Browser-UI, ohne dass der Speicher jemals "leckt" (Memory Leak).

3. Br Table und Tail Calls

High-Level-Sprachen nutzen oft Rekursion und dynamische Dispatches. WasmGC wird daher oft zusammen mit der Tail Call Extension genutzt. Damit können Funktionen sich gegenseitig unendlich oft aufrufen, ohne dass der Stack überläuft (Stack Overflow). Dies ist essentiell für funktionale Sprachen wie Clojure oder Scala, die nun endlich verlustfrei und ohne Performance-Einbußen direkt in Wasm (via WasmGC) übersetzt werden können. Chrome ist hier Vorreiter und bietet die stabilste Implementierung für diese Enterprise-Features.

Quick-Check

Rust?
Rust braucht WasmGC nicht, weil Rust keinen GC hat (Ownership Model). Aber Rust kann WasmGC nutzen, um besser mit dem Browser-DOM zu interagieren ("Reference Types").
Server-Side Wasm?
Auch Wasm-Runtimes auf dem Server (WasmEdge, Wasmtime) implementieren WasmGC. Damit kann man Java-Microservices als winzige Wasm-Module deployen (Startzeit < 1ms).
Ist JVM tot?
Nein. Die JVM ist extrem optimiert (JIT). WasmGC ist noch jung und oft langsamer als eine echte JVM. Aber für Serverless (Cold Starts) ist Wasm unschlagbar.