Chrome M137 Ships Speculative Deopts and Inlining for Wasm

WHY IT MATTERS: WebAssembly execution has historically relied on static typing and ahead-of-time optimization through toolchains like Emscripten and Binaryen rather than the speculative JIT techniques that make JavaScript fast. This worked because Wasm 1.0 binaries compiled from C, C++, and Rust expose enough static structure for AOT compilers to produce highly optimized code. That assumption breaks down with WasmGC, the garbage collection extension that lets managed languages like Java, Kotlin, and Dart target the web. WasmGC code is higher level than Wasm 1.0, using structs, arrays, subtyping, and virtual methods that create indirect call targets opaque to static analysis. Without speculative optimization based on runtime feedback, these programs leave significant performance on the table, especially in call-heavy code where virtual dispatch dominates.

WHAT CHANGED: Chrome M137 ships two new V8 optimizations for WebAssembly: speculative call_indirect inlining and deoptimization support. V8 now collects runtime feedback to guess which functions are called at indirect call sites, inlines those hot paths, and emits machine code optimized for those assumptions. If the program later violates an assumption, for example by calling a different virtual method at a previously monomorphic site, V8 deoptimizes back to unoptimized code and gathers new feedback for future recompilation. On Dart microbenchmarks, the combination yields over 50% average speedup. On larger realistic WasmGC applications and benchmarks, gains range from 1% to 8%. Deoptimization support is not just a safety net; it is a critical building block that unlocks future speculative optimizations beyond inlining, bringing WebAssembly closer to the tiered compilation strategies used in modern JavaScript engines.

WHAT TO WATCH: If your team ships Java, Kotlin, or Dart to the browser through WebAssembly, update your Chrome test baseline to M137 and measure production workloads immediately. The biggest wins will appear in codebases with heavy virtual method dispatch or polymorphic call sites where static analysis cannot predict targets. Monitor your telemetry for deoptimization frequency, as excessive deopts can indicate type instability in hot paths. Watch for future V8 releases to expand speculative optimizations now that the deoptimization infrastructure is in place, potentially closing the remaining performance gap between managed language runtimes and native code in the browser.