WebAssembly has long been praised for its predictable performance, thanks to static typing and ahead-of-time compilation. But with the arrival of WasmGC—expanding support for garbage-collected languages like Java, Kotlin, and Dart—the need for dynamic optimizations has grown. In Chrome M137, V8 introduced two powerful techniques: speculative call_indirect inlining and deoptimization support for WebAssembly. Together, they leverage runtime feedback to generate smarter machine code, delivering significant speedups especially for WasmGC programs. This Q&A dives into how these optimizations work, why they matter, and what performance gains they unlock.
1. What are the new speculative optimizations for WebAssembly in V8 and Chrome M137?
V8 recently shipped two complementary optimizations in Chrome M137: speculative call_indirect inlining and deoptimization support for WebAssembly. Speculative inlining means the compiler makes an educated guess about which function will be called at an indirect call site—based on previous executions—and inlines that function directly into the caller. If the guess turns out wrong later, the system can revert via deoptimization. This combination allows V8 to generate faster machine code that adapts to actual program behavior. These optimizations are especially beneficial for WasmGC programs, which use higher-level constructs like structs and arrays. For instance, Dart microbenchmarks show an average speedup of over 50%, while larger real-world applications see gains between 1% and 8%. Deoptimizations also lay the groundwork for even more advanced optimizations in the future.
2. How does deoptimization work in WebAssembly compared to JavaScript?
Deoptimization (or “deopt”) is a well‑established mechanism in JavaScript engines like V8. When the JIT compiler makes an assumption—for example, that a + b adds two integers—it generates fast code for that case. If the program later behaves differently (say, a becomes a string), the engine throws away the optimized code and falls back to unoptimized code, collecting fresh feedback to tier up again. For WebAssembly, deoptimization is new. Before WasmGC, Wasm 1.0 programs from C/C++/Rust were already statically typed and well-optimized ahead of time, so deopts weren’t needed. With WasmGC, the bytecode is more dynamic—featuring subtyping and polymorphic operations—so assumptions about types and targets can be made. If an assumption is violated, V8 now supports deoptimization to revert to a safe, generic execution path, exactly like it does for JavaScript.
3. Why didn’t WebAssembly need speculative optimizations before WasmGC?
Traditional WebAssembly (Wasm 1.0) is designed for statically‑typed languages like C, C++, and Rust. These languages give the compiler a lot of information at compile time: every function signature, every instruction type, every variable type is known. Ahead‑of‑time toolchains like Emscripten (based on LLVM) and Binaryen can therefore optimize the binary thoroughly before it even reaches the browser. There’s little need for runtime speculation because the types and control flow are fixed. In contrast, JavaScript is highly dynamic—types change at runtime, and function calls are often polymorphic—forcing engines to rely on speculative optimizations with deopts. Wasm 1.0 simply didn’t require that complexity. The introduction of WasmGC changes the picture: it brings managed, garbage‑collected languages to WebAssembly, and those languages introduce runtime polymorphism and indirect calls that benefit greatly from speculation.
4. What is WasmGC and why does it benefit from speculative optimizations?
WasmGC is a WebAssembly extension that adds garbage collection support to the platform. It introduces high‑level types: structs, arrays, and subtyping, along with operations on them. This enables languages like Java, Kotlin, and Dart to compile to WebAssembly more efficiently, because their object models and memory management can be expressed directly. However, these richer types lead to more dynamic behavior: a function might handle different subtypes, or an indirect call might have several possible targets. In such cases, static analysis alone cannot always produce optimal code. Speculative optimizations—like inlining the most frequent target of an indirect call—can dramatically improve performance. Runtime feedback tells V8 which types actually appear, allowing it to generate fast, specialized machine code. When assumptions break, deoptimization ensures correctness. The result is a speedup that can exceed 50% on some workloads.
5. How much performance improvement can users expect from these optimizations?
Performance gains vary by workload. On a set of Dart microbenchmarks, the combination of speculative inlining and deoptimization yields an average speedup of more than 50%. For larger, more realistic applications—such as those generated by Dart or Kotlin frameworks—the improvements range from 1% to 8%. These numbers are impressive because they come from “free” runtime feedback, not requiring developer effort. Even modest gains matter in production settings where every millisecond counts. Additionally, deoptimization support is an enabling technology: it paves the way for future optimizations that can push WasmGC performance even higher. Users running WasmGC–enabled code in Chrome M137 and later will automatically benefit—no configuration needed.
6. What role does inlining play in these optimizations?
Inlining is a classic compiler optimization that replaces a function call with the body of the called function. In the context of WasmGC, speculative call_indirect inlining is key. An indirect call (via call_indirect) can have multiple possible targets at runtime. Instead of emitting a generic dispatch table, V8 records which target was most frequently called in the past. It then speculatively inlines that target directly into the caller. This eliminates call overhead and opens the door for further optimizations (like constant propagation) across the inlined code. If a different target is later invoked, the deoptimization mechanism rolls back the speculation and falls back to the generic path. Without inlining, the code would remain slower due to dispatch logic and missed optimization opportunities. Together, speculative inlining and deopts let WasmGC programs execute nearly as fast as statically compiled ones.
7. What future optimizations do deoptimizations enable for WebAssembly?
Deoptimization support is a fundamental building block for many advanced JIT techniques. Beyond speculative inlining, it can enable type specialization—generating code for a specific subtype of a polymorphic operation. For example, if a field access on a struct frequently treats it as a particular subclass, V8 can optimistically load the field with minimal checks. Deopts also allow adaptive compilation: the engine can re‑optimize when assumptions change, collecting new feedback after a deopt. This creates a feedback loop that continuously improves code quality over time. Moreover, with deopts in place, the team can explore loop unrolling, escape analysis, and constant folding that rely on speculative runtime information. For WasmGC in particular, where object allocation and method dispatch resemble Java or C# patterns, these techniques can bring WebAssembly performance much closer to native code.