Optimizing compilers

Optimizers build a second program

A fast JavaScript engine does not turn hot code straight from source text into final machine code. It first builds an intermediate representation, or IR: a compiler-friendly version of the program. The IR lets the compiler name values, connect branches, attach feedback, and choose machine instructions without losing JavaScript's meaning.

The Baseline compilers lesson explains quick tiers such as Sparkplug. This lesson starts after that point: how V8's Maglev and TurboFan, SpiderMonkey's WarpMonkey, and JavaScriptCore's DFG and FTL build optimizer pipelines. The next lesson, Speculation & deoptimization, zooms in on guards and bailouts, so here we focus on IRs, SSA, graphs, pipeline stages, and compiler threads.

Single static assignment, or SSA, means each value name in the compiler IR is assigned exactly once. JavaScript variables can still change. The compiler simply rewrites those changes into new internal names so later passes can ask “which exact value does this use?”

1function finalPrice(isMember) {2  let discount = 5;3  if (isMember) {4    discount = 20;5  }6  return 100 - discount;7}8 9console.log(finalPrice(true));10console.log(finalPrice(false));

Line 2 gives discount a regular value of 5. Line 4 may replace it with 20. Line 6 reads whichever value is current for the path that ran. The program prints 80 for a member and 95 for a non-member.

Step through the converter. It is a small teaching model, but it really creates the SSA strings shown beside the code.

1function convertDiscountToSsa() {2  const ssa = [];Run3  const nextVersion = {};4  function name(base) {5    const version = nextVersion[base] ?? 0;6    nextVersion[base] = version + 1;7    return base + version;8  }9  const total = name("total");10  ssa.push(total + " = parameter total");11  const regularDiscount = name("discount");12  ssa.push(regularDiscount + " = 5");13  const memberDiscount = name("discount");14  ssa.push(memberDiscount + " = 20");15  const mergedDiscount = name("discount");16  ssa.push(mergedDiscount + " = phi(" + memberDiscount + ", " + regularDiscount + ")");17  const payable = name("payable");18  ssa.push(payable + " = " + total + " - " + mergedDiscount);19  return ssa;20}21 22console.log(convertDiscountToSsa().join(" | "));

V8's Maglev post describes Maglev as a simple SSA-based JIT compiler introduced in Chrome M117. It sits between Sparkplug and TurboFan: stronger than the baseline compiler, but designed to build good-enough optimized code faster than the top tier.

1const feedback = { shape: "CartShape", priceType: "smi" };2 3function maglevPlan(feedback) {4  const graph = [];5  graph.push("CheckShape " + feedback.shape);6  graph.push("LoadField price");7  graph.push("Int32Add");8  graph.push("Return");9  return graph;10}11 12console.log(maglevPlan(feedback).join(" -> "));

Line 1 stands in for runtime feedback gathered by earlier tiers. Lines 5 and 6 model a shape check followed by a field load. Real Maglev uses bytecode, feedback, liveness information, and a CFG-shaped SSA graph. The model only gives you the vocabulary.

TurboFan is V8's top-tier optimizing compiler. Historically it was famous for using a Sea of Nodes IR, where nodes are connected by value, effect, and control dependencies instead of being fixed inside blocks from the start. V8's 2025 “Land ahoy: leaving the Sea of Nodes” post says the JavaScript backend now uses Turboshaft, a more traditional control-flow-graph-shaped IR.

1function chooseBonus(a, b, flag) {2  const left = a * 2;3  const right = b * 2;4  const picked = flag ? left : right;5  return picked + 1;6}7 8console.log(chooseBonus(3, 4, true));9console.log(chooseBonus(3, 4, false));

In the playground, line 2 and line 3 can be reasoned about independently because neither changes JavaScript-visible state. A CFG view shows basic blocks and branches. A Sea-of-Nodes view shows the value dependencies that let pure work float until scheduling.

1function chooseBonus(a, b, flag) {2  const left = a * 2;3  const right = b * 2;4  const picked = flag ? left : right;5  return picked + 1;6}7 8console.log(chooseBonus(3, 4, true));9console.log(chooseBonus(3, 4, false));

SpiderMonkey's optimizer is WarpMonkey. Mozilla's source docs say Baseline tiers attach inline caches, and CacheIR is the core format for those speculative cache stubs. When Warp optimizes, WarpOracle snapshots bytecode and relevant IC data. WarpBuilder and the WarpCacheIRTranspiler turn that CacheIR into MIR, SpiderMonkey's middle-level IR.

1const cacheIR = ["GuardShape", "LoadFixedSlotResult"];2 3function warpToMir(cacheIR) {4  return cacheIR.map((op) => {5    if (op === "GuardShape") return "MGuardShape";6    if (op === "LoadFixedSlotResult") return "MLoadFixedSlot";7    return "MUnsupported";8  });9}10 11console.log(warpToMir(cacheIR).join(" -> "));

Line 1 is the inline-cache evidence: guard the shape, then load a fixed slot. Lines 4 through 6 translate those cache operations into MIR-shaped names. Real Warp also uses call information for trial inlining, where hot callees are tried inside the caller before the optimizer commits to final code.

JavaScriptCore uses different names. The DFG JIT is a high-level optimizing compiler. The FTL JIT is a stronger top tier. WebKit's B3 post explains that FTL replaced LLVM with the Bare Bones Backend, or B3, as its low-level optimizing backend.

1const jscTiers = ["Baseline JIT", "DFG", "FTL", "B3"];2 3function describeJscPipeline(tiers) {4  return tiers.join(" -> ");5}6 7console.log(describeJscPipeline(jscTiers));

This code only prints names, but it keeps the stack straight: Baseline JIT feeds hot code to DFG, FTL is the top tier, and B3 is the low-level backend used by FTL. The exact heuristics are engine details, not JavaScript semantics.

Concurrent compilation means the engine can build optimized code on a background thread while the main thread keeps executing older code. The compiler works from snapshots, feedback, and dependencies; the runtime installs the new code only when it is ready and safe.

1function buildConcurrentTimeline(callsBeforeReady = 3) {2  const events = [];3  events.push("main: run baseline call 1");4  events.push("background: compile optimized graph");5  for (let call = 2; call <= callsBeforeReady; call += 1) {6    events.push("main: run baseline call " + call);7  }8  events.push("main: install optimized code when it is ready");9  events.push("main: run optimized call " + (callsBeforeReady + 1));10  return events;11}12 13console.log(buildConcurrentTimeline(3).join(" | "));Run

1function hotSum(x) {2  let total = 0;3  for (let i = 0; i < 200; i += 1) total = (total + x + i) | 0;4  return total;5}6 7for (let n = 0; n < 20000; n += 1) hotSum(n);

Default:
[compiling method ... hotSum ... (target TURBOFAN), mode: ConcurrencyMode::kConcurrent]

With --no-concurrent-recompilation:
[compiling method ... hotSum ... (target TURBOFAN), mode: ConcurrencyMode::kSynchronous]

With --allow-natives-syntax --maglev:
Maglev is not enabled.

// Node-only probe. Run with: node --v8-options
// The lesson tests assert stable substrings only:
// --maglev defaults to --no-maglev in Node 22's V8 12.4 build.
// --turbofan and --concurrent-recompilation are enabled by default.

The tests assert stable substrings only: (target TURBOFAN), ConcurrencyMode::kConcurrent by default, and ConcurrencyMode::kSynchronous when Node runs with --no-concurrent-recompilation. They do not assert timings, memory addresses, or exact patch versions.

Use this knowledge safely

Optimizing compilers explain why warm-up exists and why a small source change can affect hot-code performance. They are not a checklist of private knobs to force. In application code, write clear JavaScript, keep data shapes consistent where it is natural, and measure the user-visible path before changing code for performance.

• Warm up microbenchmarks, then report repeated samples instead of trusting the first cold run.
• Use browser performance tools to find the hot interaction before thinking about compiler internals.
• Prefer stable, readable data flow over clever code written for one named tier.
• Link optimizer surprises to the next lesson on speculation and deoptimization.

Common misconceptions

Use the IR vocabulary, engine pipeline names, and thread model from the lesson.

Key takeaways

• Optimizing compilers build internal IRs so they can reason about values, control flow, effects, feedback, and machine code.
• SSA assigns each compiler value name once; phi nodes merge values from different control-flow paths.
• V8 uses Maglev for fast SSA optimization and TurboFan/Turboshaft for top-tier backend work; Node 22's V8 12.4 build keeps Maglev off by default.
• SpiderMonkey's Warp uses CacheIR and MIR; JavaScriptCore uses DFG, FTL, and the B3 backend.
• Concurrent compilation lets optimized code be built off-thread while older code keeps running on the main thread.

Up next: Speculation & deoptimization, where those protected assumptions become guards and deopt exits.