How Engines Execute Wasm

46.1 Compilation Pipeline (Browsers)

V8 also has a fast Wasm interpreter (DrumBrake) for some platforms. Wasmtime uses Cranelift (optimizing), Winch (baseline), and Pulley (portable interpreter). Wasmer offers Singlepass, Cranelift, and LLVM backends.

.wasm bytes → streaming decode & validate (per function, in parallel)
            → Baseline compiler (fast startup: V8 Liftoff, SpiderMonkey baseline, JSC BBQ)
            → Optimizing compiler for hot functions (V8 TurboFan/Turboshaft, SpiderMonkey Ion, JSC OMG)
            → Tier-up via dynamic tiering + on-stack replacement; code caching

46.2 Memory Implementation

Wasm32 linear memory reserves up to 8 GiB of virtual address space with guard pages, so bounds checks become hardware page faults (nearly free). Memory64 and constrained platforms use explicit bounds checks.

memory.grow commits more pages within the reservation (no copy) when possible.

46.3 Calls and Interop

JS-to-Wasm and Wasm-to-JS wrappers handle type conversion (e.g., Number ↔ i32, BigInt ↔ i64). Engines inline small wrappers and optimize "fast API" paths.

call_indirect uses table lookup + signature check. Typed function refs (call_ref) avoid the check.

WasmGC objects share the JS heap and GC (V8's Oilpan/Orinoco), with cycle collection across both.

46.4 Interpreters vs JIT vs AOT

Interpreter (wasm3, Wasmi, Pulley, WAMR classic) Fast startup, tiny, portable, works where JIT is forbidden (iOS) Quick compile, decent speed Not peak performance

AOT (Wasmtime compile, WAMR AOT, WasmEdge) Instant startup, peak speed