Tiered compilation

Start simple, then specialize

JavaScript engines do not know which code deserves expensive machine-code compilation when a page first loads. A tiny analytics helper might run once, while a parser, animation step, or hot render helper might run thousands of times. Tiered compilation is the engine's compromise: start cheap, watch what happens, then spend more compiler effort only where the program proves it is worth it.

Keep the scope sharp. This lesson covers interpreters versus compilers, JIT compilation, the tier names in V8, SpiderMonkey, and JavaScriptCore, and the counters that trigger tier-up. The next lessons go deeper on type feedback, inline caches, speculative optimization, deoptimization, and inlining. For the larger map, revisit Meet the engines, Bytecode & interpreters, and Startup performance.

An interpreter starts almost instantly because it can execute bytecode one instruction at a time. That makes it perfect for cold code, but each operation pays dispatch overhead. An ahead-of-time compiler spends time before execution to create fast machine code; that can be excellent for known programs, but it is too slow to do for every function on page load. A just-in-time compiler runs in the middle: compile at runtime when the engine has evidence that the compile cost will pay back.

1function totalTime(compileCost, callCost, calls) {2  return compileCost + callCost * calls;3}4 5console.log(totalTime(0, 5, 4));      // interpreter: cheap start6console.log(totalTime(120, 0.6, 4));  // top tier: too much compile cost7console.log(totalTime(120, 0.6, 400)); // top tier: compile cost pays back

Line 1 models the total cost as compile cost plus call cost. Line 5 is cheap to start: four interpreted calls cost 20 simulated units. Line 6 shows why top-tier code is a bad deal for a short script: the compile cost dominates. Line 7 shows the other side of the curve: hundreds of calls can repay expensive compilation.

V8's current teaching map is Ignition to Sparkplug to Maglev to TurboFan. Ignition is V8's bytecode interpreter. Sparkplug, announced by V8 in 2021, is a non-optimizing baseline compiler that compiles from bytecode directly to machine code. It is designed to be fast enough that short-lived code can benefit before a heavy optimizer would finish.

Maglev, introduced in Chrome M117 in 2023, sits between Sparkplug and TurboFan. V8 describes it as a fast optimizing JIT that uses feedback to make good-enough code quickly. TurboFan remains V8's top-tier optimizing compiler. Historically TurboFan used a Sea of Nodes intermediate representation; V8's 2025 “Land ahoy: leaving the Sea of Nodes” post describes the ongoing move toward the Turboshaft backend, a more control-flow-graph-shaped pipeline for the backend side.

Tiered compilation is not a V8-only idea. Mozilla's SpiderMonkey source docs describe a tiering engine that increments warmup counters when entering functions and reaching loop headers. Its documented tiers are the C++ interpreter, Baseline Interpreter, Baseline Compiler, and Ion optimizing compiler. The 2020 Warp project changed how Ion gets optimization data: WarpBuilder snapshots bytecode and inline-cache data, then a background thread builds MIR through the Warp pipeline.

JavaScriptCore uses LLInt, Baseline JIT, DFG, and FTL. WebKit's 2016 B3 post explains that FTL switched from LLVM to the B3 backend, and WebKit's 2020 speculation post explains how JavaScriptCore uses speculation to make dynamic JavaScript run quickly. Details differ, but the curve is familiar: cheap start, quick baseline, stronger optimizing tiers.

Engines need a signal that code is hot. A simple teaching model is an invocation counter: each function call increments a count, and thresholds request stronger tiers. Real engines combine invocation counts, loop back-edge or interrupt-budget counters, feedback vectors, inline-cache states, and heuristics. Optimizing compilation can happen on background threads so the main thread keeps running older code until the new code is ready.

1const thresholds = { baseline: 6, mid: 30, top: 90 };2let tier = "interpreter";3let invocationCount = 0;4 5function scoreCart(items) {6  invocationCount += 1;7  if (invocationCount === thresholds.baseline) tier = "baseline";8  if (invocationCount === thresholds.mid) tier = "mid";9  if (invocationCount === thresholds.top) tier = "top";10  return { tier, total: items.reduce((sum, item) => sum + item.price, 0) };11}12 13for (let call = 1; call <= 8; call += 1) {14  const report = scoreCart([{ price: call }, { price: 2 }]);15  console.log(call, report.tier, report.total);16}

The model starts in interpreter, increments invocationCount on every call, and switches to baseline on call six. Later thresholds stand in for mid-tier and top-tier compilers. The important point is not the number six; it is that tier-up is driven by evidence from running code.

1const thresholds = { baseline: 6, mid: 30, top: 90 };2let tier = "interpreter";Run3let invocationCount = 0;4 5function scoreCart(items) {6  invocationCount += 1;7  if (invocationCount === thresholds.baseline) tier = "baseline";8  if (invocationCount === thresholds.mid) tier = "mid";9  if (invocationCount === thresholds.top) tier = "top";10  return { tier, total: items.reduce((sum, item) => sum + item.price, 0) };11}12 13for (let call = 1; call <= 8; call += 1) {14  const report = scoreCart([{ price: call }, { price: 2 }]);15  console.log(call, report.tier, report.total);16}

1let tier = "interpreter";2let interruptBudget = 18;3 4function crunchLoop(limit) {5  let total = 0;6  for (let i = 1; i <= limit; i += 1) {7    interruptBudget -= 3;8    if (interruptBudget <= 0 && tier === "interpreter") {9      tier = "baseline"; // a real engine can OSR into compiled loop code10      interruptBudget = 18;11    }12    total += i;13  }14  return { tier, total };15}16 17console.log(crunchLoop(8));

Function calls are not enough. A single call can contain a long-running loop, so engines also check loop progress. On-stack replacement (OSR) lets a running loop switch into compiled code without starting the function over. This lesson shows the idea; a later optimization lesson covers the stack-frame mechanics.

1let tier = "interpreter";Run2let interruptBudget = 18;3 4function crunchLoop(limit) {5  let total = 0;6  for (let i = 1; i <= limit; i += 1) {7    interruptBudget -= 3;8    if (interruptBudget <= 0 && tier === "interpreter") {9      tier = "baseline"; // a real engine can OSR into compiled loop code10      interruptBudget = 18;11    }12    total += i;13  }14  return { tier, total };15}16 17console.log(crunchLoop(8));

The same compile-time curve looks different for a short script and a long session. Never optimizing wins when nothing runs enough to pay back compilation. Eager optimization wastes time compiling cold helpers. Tiering wins the common browser case: start quickly, then spend compiler work on the function that became hot.

1const costs = {2  interpreter: { compile: 0, call: 5 },3  baseline: { compile: 15, call: 2 },4  mid: { compile: 40, call: 1.2 },5  top: { compile: 120, call: 0.6 },6};7 8const program = [9  { name: "route", calls: 3 },10  { name: "format", calls: 160 },11  { name: "validate", calls: 3 },12  { name: "paint", calls: 3 },13  { name: "cleanup", calls: 3 },14];15 16// A real engine uses richer counters, feedback, and background compilation.17// This model only shows the compile-time vs run-time trade-off.18console.log("never optimize", 860);19console.log("optimize eagerly", 703.2);20console.log("tiered JIT", 422.6);

The model charges top-tier compile cost for every function in the eager strategy, while the tiered strategy only compiles functions that cross thresholds. Real engines use many more details, but this is the heart of tiered compilation: optimize what evidence says is worth it.

V8 exposes internal testing functions when Node runs with --allow-natives-syntax. They are not JavaScript language features, and a normal browser or Node process treats the % syntax as invalid. The lesson tests run child Node processes, remove NODE_TEST_* variables, and assert only stable facts: version strings, V8 option defaults, status bits from V8 12.4's runtime.h, and --trace-opt lines that mention TurboFan compilation.

1// Node 22.23.1 (V8 12.4). Run only in Node with --allow-natives-syntax.2function hotAdd(x) {3  let total = 0;4  for (let i = 0; i < 30; i += 1) total += (x + i) | 0;5  return total;6}7 8%PrepareFunctionForOptimization(hotAdd);9hotAdd(1);10hotAdd(2);11%OptimizeFunctionOnNextCall(hotAdd);12hotAdd(3);13console.log(%GetOptimizationStatus(hotAdd));

In V8 12.4, the status bits include kIsFunction = 1 << 0, kOptimized = 1 << 4, and kTurboFanned = 1 << 6. The forced optimization probe is deterministic enough for a lesson test, but it is still an engine-lab tool. Do not ship code that calls native syntax or relies on a particular tier.

node --allow-natives-syntax --trace-opt tier-up-probe.mjs

Node 22.23.1 (V8 12.4)
[manually marking ... hotAdd ... for optimization to TURBOFAN]
[compiling method ... hotAdd ... (target TURBOFAN)]
[completed compiling ... hotAdd ... (target TURBOFAN)]
status bits include kIsFunction, kOptimized, and kTurboFanned

Tiered compilation explains why benchmark warm-up matters and why short scripts often never reach a top tier. It does not mean you should write for Sparkplug, Maglev, TurboFan, Ion, or FTL directly. Engine teams change thresholds, tier names, and heuristics. Your job is to write clear code, measure the real interaction, warm up benchmarks, and understand why the first few runs may differ from the steady state.

If a benchmark changes after warm-up, connect that behavior to Measuring performance. If a hot function behaves differently after its inputs change, the next lessons on type feedback and inline caches explain the evidence optimizers consume.

Common misconceptions

Answer with the compile-time curve, tier names, and hotness counters in mind.

Key takeaways

• Interpreters start quickly; compilers can run faster after paying compile time; JITs choose at runtime what is worth compiling.
• V8's modern map is Ignition, Sparkplug, Maglev, and TurboFan, with Turboshaft work replacing the old Sea-of-Nodes backend path.
• SpiderMonkey and JavaScriptCore use different tier names but the same economic idea: spend more compiler effort on hotter code.
• Hotness comes from function entries, loop progress, feedback, and thresholds; OSR lets loops switch tiers while already running.
• Warm up benchmarks, expect short scripts to stay in cheap tiers, and never write production code for a specific engine tier.

Up next: Type feedback & feedback vectors.