In V8, when a WebAssembly module streams over the network, Liftoff is the first mind to touch it. It compiles functions on the fly, turning a byte stream into executable machine code with almost no ceremony. This is a world apart from TurboFan's layered architecture—a single pass where each opcode triggers its own tiny burst of instruction emission. To appreciate the elegance, let's walk through a single function from arrival to first call, watching Liftoff's hands work byte by byte.
The function body arrives within the module streaming API. The decoder has already parsed the type section and knows the function's signature—say `(func (param i32 i32) (result i32))`, a simple addition. As the bytes land, a callback fires: Liftoff's `CompileFunction` begins. It allocates a `LiftoffCompiler` instance and a virtual stack, a data structure that maps logical Wasm stack slots to either machine registers or spill slots on the native stack. At the outset, all slots are "unassigned"—they have no fixed location yet. There's no global register allocator waiting to run; assignments will be made greedily, opcode by opcode, and frozen only at control‑flow boundaries.
The decoder now hands Liftoff the first byte: `0x20`—`local.get 0`. Liftoff peeks at the current cache state. The parameter is already sitting in a register because of the calling convention; it simply records that the top of the virtual stack now holds that register, updating its mapping. Nothing is emitted. Next comes `0x20` for `local.get 1`. The second parameter arrives in its designated register, and the virtual stack grows: two values, each in a register. Still no instructions.
Now the addition: `0x6a` (`i32.add`). Liftoff sees two i32s on the virtual stack, both in registers. It calls `LiftoffAssembler::emit_i32_add`, which spits out a raw machine instruction—on x64, an `add reg1, reg2`—and then updates the cache state: the two operands are consumed, the result sits in one of the original registers (the other is freed). The entire code‑generation logic for this opcode is a handful of lines, with no intermediate representation, no abstract syntax tree. It's a direct, callback‑driven translation from one Wasm instruction to one or a few machine instructions.
What if an operand had been spilled earlier? Liftoff would emit a reload from the stack before the add, temporarily occupying a register. The cache state tracks which slots are in registers, which on the stack, and which registers are free. This static location determination is updated after every opcode, ensuring the next opcode can always find its operands without a separate analysis pass.
Memory operations are equally direct. An `i32.load` arrives: Liftoff ensures the address is in a register (spilling if necessary), then emits a load instruction with the correct memory‑base register. The memory base itself is obtained from an instance field; if it's not already cached in a dedicated register across the block, Liftoff emits a reload here. No effort is made to hoist that reload out of loops—Liftoff's job is speed, not optimal scheduling. Later, TurboFan will fix that with load elimination.
When control flow appears—a `block` or `loop`—Liftoff freezes the cache state at the merge point. For the end of a loop body, for instance, it forces all live virtual stack values into their canonical stack slots. This avoids having to construct phi nodes or reconcile register assignment across different incoming paths. It's a deliberate simplification: at control‑flow joins, everything goes to memory, and subsequent opcodes reload what they need. The premium on simplicity is occasionally redundant loads and stores, but the overall code still runs plenty fast for startup, and the hot path will soon be replaced.
The function ends with `end`. Liftoff emits a return sequence, finalising the code buffer. It records safepoint positions for garbage collection if the function references any JS objects, building a compact stack map. Then the compiled `Code` object is installed into the WebAssembly module's function table. The whole process—from the first bytes of the function body to a callable machine‑code object—took microseconds. It happened in the same thread that is streaming the network data, with no multi‑pass optimisation and no background threads yet involved. That's why Liftoff code is not cached: recompilation is nearly as fast as loading from disk.
Now contrast with TurboFan. When the same function later qualifies as hot, TurboFan takes over with an entirely different rhythm. It builds multiple internal representations to perform advanced optimizations—register allocation, load elimination, inlining—that Liftoff skipped. These passes run on a background thread, producing significantly faster code, but they take longer, easily tens of milliseconds for a complex function. The result is a tighter, more efficient code object that exploits cross‑instruction opportunities Liftoff never considered.
The tier‑up handoff is straightforward: V8's WebAssembly runtime simply replaces the function table entry. Once TurboFan finishes, the compiled code is atomically registered; new calls jump to the optimised code, while any in‑flight execution in Liftoff runs to completion in Liftoff. V8 currently does not perform on‑stack replacement for WebAssembly, so no frame translation is needed—the transition happens entirely at the level of the next call. When profiling identifies a function as hot, TurboFan recompiles it, and that recorded behaviour guides the optimizations.
Together, Liftoff and TurboFan embody the two extremes of V8's compiling minds: one a feverish, single‑pass transliterator that translates bytes to machine code in a straight line, the other a deliberate, multi‑pass architect that rearranges and refines. Watching a single function pass through Liftoff's fingers is to see that minimal beauty—an algorithm that does exactly one thing and does it instantly, trusting a future mind to add the missing elegance later.
Comments
No comments yet — be the first.