I've been tracing the cooperation between Liftoff and TurboFan in V8's WebAssembly pipeline, and the design is a masterclass in balancing startup latency with peak throughput. When a WebAssembly module arrives — often streamed over the network — V8 must start executing it as quickly as possible, but it also wants to eventually run that code at the highest possible speed. The solution is a two-tier compilation strategy: a blazing-fast baseline compiler called Liftoff, and a multi-pass optimizing compiler, TurboFan.
Liftoff's key trick is single-pass code generation. While the module bytes are still streaming in, Liftoff decodes each function body and emits machine code in one linear pass, never backtracking. To make that work without a slow register allocator, it maintains what's called a virtual stack cache. For every WebAssembly stack value that's produced by an instruction, the cache records where that value lives at that point in the linear stream — maybe it's in a specific CPU register, maybe it's an integer constant, or maybe it's spilled to the actual memory stack frame. When a later instruction needs an operand, Liftoff simply looks up the virtual stack mapping and knows exactly where to fetch the value without having to re-read the stack. Branch targets complicate this: multiple incoming control-flow edges might expect different register assignments. Liftoff handles that by freezing the cache state at branch destinations, forcing a consistent register layout that every predecessor can target with minimal moves. The result is correct, reasonably fast code that appears almost instantly — often before the download even finishes.
Of course, this hurried register mapping leaves a lot of performance on the table. That's where TurboFan comes in. V8 counts how often each WebAssembly function is called (and likely also monitors loop back-edges), and once a threshold is crossed the function is deemed hot. It gets recompiled by TurboFan on a background thread while Liftoff code continues running, so there's no pause. Crucially, on-stack replacement is not done for WebAssembly; only future calls use the new code. Once TurboFan finishes, the optimized machine code replaces the Liftoff version at the function's entry point — all direct and indirect call sites will transparently land in the new code from then on.
TurboFan doesn't just patch up the existing code. It rebuilds the function from scratch, constructing its Sea of Nodes intermediate representation, applying sophisticated register allocation, load elimination, and other heavyweight optimizations. What used to be a rough virtual-stack-to-register mapping from Liftoff is replaced by a finely tuned assignment that squeezes the maximum out of the CPU registers. The difference in execution speed is dramatic, and because the replacement happens atomically, callers — whether they themselves are still Liftoff or already TurboFan — simply invoke the function and get the best code available.
That's the core of the cooperation: Liftoff gets you running immediately, and TurboFan catches up later to deliver peak performance. But there's an additional layer I find fascinating. When you open DevTools to debug WebAssembly, V8 actually tiers down: it replaces all TurboFan code with Liftoff code because TurboFan's optimizations often reorder or eliminate instructions, making reliable breakpoints impossible. Liftoff's one-to-one instruction mapping preserves debugging fidelity. Conversely, when you start a performance recording in DevTools, V8 proactively tiers up every function to TurboFan so that the profile reflects real-world steady-state performance. Both of these DevTools behaviors lean on the same infrastructure that replaces function code on the fly.
In the end, the Liftoff–TurboFan tandem gives WebAssembly a uniquely smooth performance curve: instant startup with no compilation pause, and a quiet background upgrade to highly optimized code. It's a satisfying demonstration that you don't have to choose between fast loading and fast running — you can have both, provided you build a compiler that knows how to cooperate with its smarter, slower sibling.
Comments
No comments yet — be the first.