Optimizing WebAssembly (Wasm) Garbage Collection for JavaScript Interop

1. Executive Summary & Problem Formulation

WebAssembly (Wasm) promises near-native execution speed for heavy computational tasks in the browser. Developers compile Rust, C++, or Go code into .wasm binaries, load them into JavaScript, and expect a 10x performance boost for rendering, physics simulations, or cryptography.

In reality, many developers find that moving their algorithms to Wasm actually degrades performance. The bottleneck is the JavaScript interoperability boundary. Wasm operates inside an isolated, linear memory space (a massive contiguous byte array). It has no inherent concept of JavaScript objects, arrays, or DOM nodes.

If a JavaScript application wants to pass an array of $100,000$ coordinates to a Wasm physics engine, it cannot just pass a pointer. It must serialize the JavaScript objects into JSON or flat arrays, allocate space inside the Wasm linear memory, copy the binary bytes across the boundary, let Wasm process the bytes, and then serialize the results back out into the JavaScript heap. This serialization/deserialization overhead takes longer than the actual physics calculation.

Furthermore, managing memory inside Wasm is a nightmare when dealing with high-level languages. If you compile Java or C# to Wasm, you must compile their entire garbage collector (GC) runtime into the binary. This inflates the .wasm file size by megabytes and creates a duplicate GC system fighting the browser's native V8 GC.

The solution is the WebAssembly Garbage Collection (WasmGC) proposal. WasmGC extends the WebAssembly instruction set to natively define managed structs and arrays. It allows Wasm code to create managed objects that live inside the host browser's JavaScript V8 heap, eliminating the serialization boundary and offloading memory management to the browser's highly optimized engine.

2. Mathematical & Architectural Theory

The Linear Memory Chasm

Standard WebAssembly 1.0 defines memory as a single WebAssembly.Memory object. This is essentially an ArrayBuffer.

If Rust allocates a string "Hello", it places bytes [72, 101, 108, 108, 111] at memory address 0x0400. To read this in JS, you must instantiate a Uint8Array view over the Wasm memory buffer, slice from 0x0400, and run a UTF-8 string decoder.

Because this memory is entirely opaque to the browser, the JavaScript Garbage Collector cannot track pointers inside the Wasm buffer. If Wasm holds a pointer to a JS DOM object, it must use an indirect integer table (the externref table). If the Wasm code forgets to manually free that integer handle, the JS DOM object leaks forever.

The WasmGC Architecture

WasmGC fundamentally alters the architecture. Instead of restricting Wasm to primitive integers and floats (i32, f64), it introduces managed types: struct, array, and ref.

When a WasmGC binary executes a struct.new instruction, it does not write bytes into its isolated linear memory array. Instead, it asks the host browser's engine (V8, SpiderMonkey) to allocate an object directly inside the JavaScript heap.

The Wasm binary holds a ref (a managed reference) to this object. Because the object lives in the JS heap, the V8 Garbage Collector can see exactly which Wasm functions hold references to it. When the Wasm function returns and the reference is dropped, V8 automatically reclaims the memory. No embedded garbage collector is required inside the .wasm file.

Eliminating the Serialization Boundary

With WasmGC, interop becomes zero-cost. 1. The JS code passes a managed array object directly into a Wasm function. 2. The Wasm code uses array.get to read elements instantly, without copying the array. 3. The Wasm code uses struct.new to generate result objects and returns the ref to JS. 4. JS reads the struct properties precisely as if it were a standard JavaScript object.

This eliminates the JSON serialization overhead entirely and shrinks the .wasm binary footprint by removing the need for a bundled memory allocator like wee_alloc.

3. Concrete Implementation: WasmGC with Rust and wasm-bindgen

Implementing raw WasmGC text format (WAT) is masochistic. In production, we use a compiler toolchain that understands WasmGC. While Kotlin and Dart currently have the most aggressive WasmGC support, Rust's wasm-bindgen is evolving to utilize reference types to bypass linear memory bottlenecks.

Below is an architectural pattern demonstrating how to pass large typed arrays efficiently across the boundary without JSON serialization, utilizing shared memory views and externref.

use wasm_bindgen::prelude::*;
use js_sys::{Float32Array, Object, Reflect};

// 1. Using `externref` to hold opaque JS objects safely
// We can store a reference to a DOM node or JS Object inside Rust without copying its data.
#[wasm_bindgen]
pub struct PhysicsEngine {
    // This holds a garbage-collected reference to a JS object.
    // When the PhysicsEngine struct is dropped in Rust, the ref count drops in V8.
    callback_object: JsValue,
}

#[wasm_bindgen]
impl PhysicsEngine {
    #[wasm_bindgen(constructor)]
    pub fn new(js_callback: JsValue) -> PhysicsEngine {
        PhysicsEngine {
            callback_object: js_callback,
        }
    }

    // 2. Zero-copy array processing
    // Instead of passing a Rust Vec (which forces a memory copy into the JS heap),
    // we accept a JS Float32Array directly and mutate it in place.
    #[wasm_bindgen]
    pub fn step_simulation(&self, positions: &mut [f32], velocities: &[f32], dt: f32) {
        // Iterate over the raw memory slice without serialization
        for i in 0..positions.len() {
            // Standard Euler integration
            positions[i] += velocities[i] * dt;
            
            // Artificial boundary collision
            if positions[i] > 100.0 {
                positions[i] = 100.0;
            }
        }

        // We can invoke the JS callback object directly without converting arguments to JSON
        if self.callback_object.is_object() {
            let func = Reflect::get(&self.callback_object, &JsValue::from_str("onStepComplete"));
            if let Ok(f) = func {
                if f.is_function() {
                    let js_func = f.unchecked_into::<js_sys::Function>();
                    let _ = js_func.call0(&JsValue::NULL);
                }
            }
        }
    }
}

import { PhysicsEngine, memory } from './pkg/physics_engine.js';

// 1. Allocate arrays directly in the Wasm Linear Memory from JavaScript
// By allocating inside the Wasm buffer, we guarantee zero-copy access for the Rust code.
const numParticles = 100000;
const bytesPerFloat = 4;

// (In a real setup, we would export an allocation function from Rust. 
// For demonstration, we assume memory is large enough).
const ptrPositions = 0; // Pointer address
const ptrVelocities = numParticles * bytesPerFloat;

// Create JS typed array views overlaying the Wasm memory buffer
const positions = new Float32Array(memory.buffer, ptrPositions, numParticles);
const velocities = new Float32Array(memory.buffer, ptrVelocities, numParticles);

// Initialize data from JS
for (let i = 0; i < numParticles; i++) {
    positions[i] = Math.random() * 10;
    velocities[i] = Math.random();
}

// 2. Initialize the Wasm engine, passing an opaque JS object via externref
const engine = new PhysicsEngine({
    onStepComplete: () => {
        // This executes during the Rust function call
        // console.log("Physics step completed in Wasm.");
    }
});

// 3. Execution Loop
function animate() {
    // The Rust Wasm code mutates the TypedArray in place instantly.
    // There is ZERO JSON serialization or memory copying here.
    engine.step_simulation(positions, velocities, 0.016);

    // Read the updated positions directly from the shared memory view to render via WebGL
    renderWebGL(positions);
    
    requestAnimationFrame(animate);
}

animate();

4. Edge Cases, Optimization & Memory Considerations

The Memory View Invalidation Trap

When you create a Float32Array view over the WebAssembly.Memory.buffer, you are creating a pointer to a specific chunk of physical RAM.

If the Wasm code (e.g., Rust's allocator) requests more memory to store a new string, the Wasm engine may execute a memory.grow instruction. When Wasm memory grows, the browser must allocate a larger contiguous chunk of physical RAM and move all the data. This completely invalidates the underlying ArrayBuffer.

If you try to read the Float32Array in JS after a memory.grow, the browser throws a fatal TypeError: detached ArrayBuffer. To fix this, you must recreate all JS TypedArray views every single time Wasm allocates memory, or pass memory indices back and forth to reconstruct the views dynamically before every render loop.

WasmGC Browser Support and Toolchains

WasmGC reached Phase 4 (Standardized) in late 2023. It is fully supported in Chrome 119+ and Firefox 120+. However, LLVM and the Rust compiler do not yet natively emit WasmGC struct.new instructions. Rust relies on a flat memory layout, so bridging JS objects still relies heavily on externref (opaque handles) and shared typed arrays.

Languages built heavily on garbage collection, like Kotlin/Wasm and Dart (Flutter), compile natively to WasmGC. They define their Java/Dart classes as WasmGC structs. The V8 engine collects Dart objects alongside JavaScript objects perfectly, eliminating the $2\text{ MB}$ Dart VM bundle and slashing load times.

String Interop Complexity

Strings remain the most expensive interop boundary. JavaScript strings are UTF-16 encoded in the V8 heap. Rust and Go strings are UTF-8 encoded in linear memory. WasmGC introduces a stringref proposal to allow Wasm to hold native JS strings, but until it finalizes, passing a string across the boundary requires a linear time $O(N)$ encoding/decoding sweep. Never pass strings inside a 60 FPS Wasm render loop. Pass integer IDs and maintain a string dictionary on the JS side.

5. Benchmarks & Practical Engineering Takeaways

We benchmarked passing an array of 500,000 3D vectors (1.5 million floats, $\approx 6\text{ MB}$) between JS and Rust across different interoperability strategies.

Engineering Guidelines

• Stop using JSON across the boundary: If your wasm-bindgen code uses serde_json to pass complex objects, you are destroying your performance. Flatten complex structs into structural arrays of floats/integers (Struct of Arrays layout) and pass them via shared memory.
• Isolate DOM manipulation: Wasm cannot touch the DOM directly. It must invoke JS functions via externref to update UI. Every boundary crossing incurs a microsecond overhead. Batch DOM updates into a single JS call at the end of the Wasm computation loop.
• Use Web Workers for heavy Wasm: Even with zero-copy memory, a Wasm function that takes $100\text{ ms}$ to compute a cryptography hash will completely lock the JS main thread. Always instantiate heavy .wasm modules inside a Web Worker.

6. References & Cross-Links

• W3C WebAssembly Community Group. (2023). WebAssembly Garbage Collection (WasmGC) Specification.
• V8 Engineering Blog. (2023). A new way to bring garbage collected programming languages efficiently to WebAssembly.
• Susam, A. (2026). Advanced IndexedDB Strategies for Gigabyte-Scale Offline Caching. Read Article.
• Susam, A. (2026). Handling Large Binary Buffers in Client-Side JavaScript. Read Article.