Four tiers and how warm-up works

Four tiers, one cost-versus-speed curve

The overview lesson V8’s four-tier JIT pipeline sketched the ladder; this unit opens each rung. Start with the shape of the trade. Every tier sits at a point on a single axis: how long it takes to produce code versus how fast that code runs. Cheaper to compile means slower to run; faster to run means more expensive to compile. V8 ships four because no single point on that curve is right for all code.

Ignition is the interpreter. The parser hands it an AST; Ignition lowers it once to compact, register-based bytecode and then executes that bytecode on a virtual machine. There is no machine-code generation here at all — execution is a dispatch loop that reads a bytecode, jumps to a handler, runs it, and advances. Entry cost is effectively zero (you already paid to produce the bytecode), and it is the only tier that records the type feedback the upper tiers depend on. Per operation it is roughly an order of magnitude slower than optimised native code, because every step pays the interpreter’s table-lookup-and-indirect-jump dispatch overhead.

Sparkplug is the baseline JIT, shipped in V8 9.1 (2021). It is the rung people most often misunderstand, so be precise: Sparkplug does no optimisation. It builds no intermediate representation (IR), performs no inlining, no escape analysis, no type specialisation. It walks the existing bytecode once and emits a near-1:1 template of machine instructions — for each bytecode, a fixed small block of native code plus the occasional call back into the runtime. What it removes is exactly the interpreter’s dispatch overhead: no more table lookup and indirect jump per operation, just straight-line native code. That alone buys roughly 1.5–2× over Ignition, and it compiles in microseconds (about 1 ms per kilobyte of bytecode). Because compilation is so cheap, Sparkplug code can be produced lazily on first hotness or eagerly.

Maglev is the mid-tier optimising compiler, shipped in 2023. It is a genuine optimiser — it builds an SSA-form IR and uses the recorded type feedback to specialise property loads and arithmetic — but a lightweight one. It uses a fast linear-scan register allocator and skips TurboFan’s heaviest passes (escape analysis, polymorphic inlining, iterative type narrowing). The result compiles about 10× faster than TurboFan while reaching roughly 50–70% of its code quality: the right tool for “hot but not the hottest” functions, where TurboFan’s compile latency would hurt more than its extra speed helps.

TurboFan is the full optimising compiler — sea-of-nodes IR, aggressive inlining, escape analysis, the works (lesson 03 of this unit opens it). It produces the fastest code V8 can make, at a compile cost of tens to hundreds of milliseconds per function. You only want to pay that for code that is both very hot and type-stable.

How warm-up actually triggers a tier-up

A function does not climb because of a wall-clock timer. It climbs because two counters cross budgets. The first is the invocation count — how many times the function has been entered. The second is the back-edge count — how many times execution has jumped backwards to the top of a loop inside the function. V8 maintains a per-function budget (the “interrupt budget” / feedback budget); each invocation and each loop back-edge decrements it, and when it reaches zero the runtime fires a tier-up check. This is why both hot functions (called often) and hot loops (iterated often, even inside a function called once) can request a higher tier — the back-edge counter is what lets a single long-running loop get optimised without ever returning.

// Called many times -> invocation count drives tier-up.
function distance(a, b) {
  const dx = a.x - b.x, dy = a.y - b.y;
  return Math.sqrt(dx * dx + dy * dy);
}
for (let i = 0; i < 1_000_000; i++) distance(p, q);

// Called once, but the loop's back-edges drive tier-up of THIS frame.
function sumTo(n) {
  let total = 0;
  for (let i = 0; i < n; i++) total += i; // each iteration = one back-edge
  return total;
}
sumTo(100_000_000);

The thresholds are dynamic and tuned per release — roughly speaking, Sparkplug kicks in after low hundreds of invocations, Maglev after low thousands, TurboFan after tens of thousands — but never hardcode a number; treat them as ordering, not constants.

Concurrent compilation: the interpreter never blocks

You might expect a 100 ms freeze when a function graduates to TurboFan — if compilation were synchronous, you would get exactly that. It is not. A tier-up does not stop your program. When the budget trips, V8 enqueues a compilation job and a background thread runs Maglev or TurboFan while the main thread keeps executing the function on its current tier. When the optimised code is ready, V8 swaps it in for the next entry (or mid-loop, via on-stack replacement — lesson 06). This is why you never see a 100 ms freeze when a function tiers up to TurboFan: the freeze would happen if compilation were synchronous, but it is not. The cost shows up instead as background CPU and a brief window where the function runs at the old speed despite being “scheduled” for the new tier.

You can watch all of this. --trace-opt logs every optimisation decision (which function, which tier, why); --no-opt disables the optimising tiers entirely so you can compare against pure Ignition plus Sparkplug. In Node: node --trace-opt --trace-deopt app.js. In d8, add --allow-natives-syntax to call %OptimizeFunctionOnNextCall(fn) and force a tier-up immediately rather than warming up by hand.