Optimizing compilers

An optimizer rebuilds the function first

A JavaScript engine is the program inside a browser or Node that runs your code. A function that runs very often is called hot. For hot functions, the engine uses its strongest compilers. To compile means to turn code into another form before running it. Machine code is the form the computer's processor runs directly.

A strong compiler does not jump straight from your source text to machine code. First it rebuilds the function in its own private form. That form is called an intermediate representation, or IR. In the IR, the compiler can:

• give each value its own name,
• join up the two paths of an if,
• attach feedback: the notes the engine kept about the values each step has seen, such as "this was always a small whole number",
• choose the machine instructions.

None of this changes what your JavaScript means.

The Baseline compilers lesson covered quick compilers such as V8's Sparkplug. This lesson picks up from there. It shows the strongest compilers in three engines:

• V8, the engine in Chrome and Node: Maglev and TurboFan.
• SpiderMonkey, the engine in Firefox: WarpMonkey.
• JavaScriptCore, the engine in Safari: DFG and FTL.

The next lesson, Speculation & deoptimization, covers the checks that protect the compiler's guesses. This lesson covers IRs, SSA, graphs, the steps inside each engine, and compiling on a second thread.

In JavaScript, a variable can change many times. That makes it hard for a compiler to know which value a line reads. So many compilers use SSA, short for single static assignment. In SSA, each name in the IR gets a value exactly once. When your code changes a variable, the compiler makes a new name instead.

Your JavaScript variables still change as normal. Only the compiler's private copy uses the new names.

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));

In plain words, line by line:

1. Line 2 sets discount to 5.
2. Line 4 changes it to 20, but only for a member.
3. Line 6 subtracts whichever value discount holds now.
4. Lines 9 and 10 call the function both ways. They print 80 for a member and 95 for someone who is not a member.

In SSA, the compiler gives each value of discount its own name:

• discount0 = 5 is the first value.
• discount1 = 20 is the member value.
• discount2 is the value after the if.

After the if, the code can arrive by two paths. A phi node (say "fie") is a special IR step at the place where the paths join. It picks the value from the path that ran: discount1 for a member, and discount0 for anyone else.

The step-through below runs a small converter written in plain JavaScript. It is a model, not V8 itself. It really builds the SSA lines 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(" | "));

Maglev is one of V8's optimizing compilers. V8's Maglev article calls it a simple JIT compiler built on SSA. It arrived in Chrome version 117 (M117). It sits between two other V8 compilers:

• Sparkplug, the quick baseline compiler from the last lesson,
• TurboFan, V8's strongest and slowest compiler.

Maglev makes code that is faster than Sparkplug's. It makes that code much sooner than TurboFan can.

The model below shows how feedback changes the plan. Two words first. An object's shape is its layout: which property names it has, in which order. Smi is short for "small integer", a small whole number.

1const stableFeedback = { shape: "CartShape", priceType: "smi" };2const changedFeedback = { shape: "OtherShape", priceType: "mixed" };3 4function maglevPlan(feedback) {5  if (feedback.shape !== "CartShape" || feedback.priceType !== "smi") {6    return ["GenericPropertyLoad", "GenericAdd", "Return"];7  }8  const graph = [];9  graph.push("CheckShape " + feedback.shape);10  graph.push("CheckSmi price");11  graph.push("LoadField price");12  graph.push("Int32Add");13  graph.push("Return");14  return graph;15}16 17console.log("stable", maglevPlan(stableFeedback).join(" -> "));18console.log("changed", maglevPlan(changedFeedback).join(" -> "));

In plain words, line by line:

1. Lines 1 and 2 stand in for feedback from the earlier steps. stableFeedback says every cart had the same shape and every price was a smi. changedFeedback says other shapes and other kinds of values showed up.
2. Line 5 checks the feedback. If it is not the steady kind, line 6 returns a generic plan: steps that work for any value, but slowly.
3. Lines 9 to 13 build the special plan. Check the shape. Check that the price is a smi. Read the price straight from its known place. Add with a fast whole-number add. Return.
4. Line 16 prints stable and then the special plan: CheckShape CartShape -> CheckSmi price -> LoadField price -> Int32Add -> Return.
5. Line 17 prints changed and then the generic plan: GenericPropertyLoad -> GenericAdd -> Return.

A check step such as CheckShape is a guard. If the guess turns out wrong, the optimized code stops and hands the work back to slower code. The next lesson covers that. Real Maglev starts from bytecode and feedback, and builds a graph in SSA form. This model only teaches the words.

The table below places each optimizing compiler. Read each row as one compiler, its job, and how to think about it.

TurboFan is V8's strongest optimizing compiler. Like most compilers, it keeps its IR as a graph. The parts of the graph are called nodes, and the lines between them are called edges. There are two common shapes:

• A control-flow graph, or CFG, cuts the code into basic blocks. A basic block is a run of steps with no branch in the middle. Edges between blocks show which block can run next.
• A Sea of Nodes graph has no fixed blocks at first. Each node is one operation. Edges show which values a node needs, which effects (such as a property write) must happen first, and which branch it belongs to.

For years, TurboFan was known for using Sea of Nodes. In 2025, V8's article "Land ahoy: leaving the Sea of Nodes" said that TurboFan's JavaScript backend now uses Turboshaft. The backend is the last part of a compiler, the part that makes machine code. Turboshaft uses the more usual CFG shape.

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));

There is one catch. In JavaScript, a * 2 on line 2 can run your own code. For example, an object can have a valueOf method that JavaScript calls to turn the object into a number. Turning a value into another type like this is called coercion. So the compiler cannot move line 2 or line 3 around freely.

The playground's Sea of Nodes view starts after two checks. Feedback said a and b were numbers, and number checks proved it. Only then are the two multiplications free to move. A CFG view shows blocks and branches. A Sea of Nodes view shows which values depend on which.

The table compares the two shapes. Read each row as one shape, what it looks like, and why a compiler picks it.

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));

Line 2 doubles a. Line 3 doubles b. Line 4 uses flag to pick one of them. Line 5 adds 1. The program prints 7 (3 × 2 + 1) and then 9 (4 × 2 + 1).

SpiderMonkey is the engine in Firefox. Its optimizing compiler is WarpMonkey, or Warp for short. Warp starts from inline caches, or ICs: the small saved shortcuts from the Inline caches lesson. SpiderMonkey writes each IC in a simple format called CacheIR. One saved list of CacheIR steps is called a stub.

When Warp optimizes a function, three things happen, in order:

1. WarpOracle takes a snapshot: a frozen copy of the function's bytecode and its useful IC data.
2. WarpBuilder and the WarpCacheIRTranspiler turn that CacheIR into MIR. MIR is SpiderMonkey's middle-level IR. A transpiler turns code from one format into another.
3. Later, MIR becomes LIR, a lower-level IR close to machine code, and then machine code.

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(" -> "));

In plain words, line by line:

1. Line 1 is the IC's record. GuardShape checks the object's shape. LoadFixedSlotResult reads a property from a fixed place inside the object.
2. Lines 4 to 6 go through each step and swap in the matching MIR name. Line 7 handles any step the model does not know.
3. Line 11 prints MGuardShape -> MLoadFixedSlot.

Real Warp also uses what it saw about calls. Inlining means copying a called function's body into the caller, so no call is needed when the code runs. In trial inlining, Warp tries this for hot called functions before it builds the final code.

JavaScriptCore is the engine in Safari. It uses different names:

• The DFG (Data Flow Graph) JIT is an optimizing compiler.
• The FTL (Faster Than Light) JIT is the stronger top step.
• B3, the Bare Bones Backend, is the part of FTL that makes the final machine code. WebKit's B3 article says B3 replaced LLVM in that job. LLVM is a large, general-purpose compiler toolkit.

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

In plain words, line by line:

1. Line 1 lists the steps in order. LLInt is the low-level interpreter, where code starts. Baseline JIT is the quick compiler.
2. Line 4 joins the names with arrows.
3. Line 7 prints LLInt -> Baseline JIT -> DFG -> FTL (B3 backend).

B3 is written inside FTL's entry because it is part of FTL, not a step after it. When code moves from one step to the next is up to each engine. It never changes what your JavaScript means.

The table puts the three engines side by side. Read each row as one engine and its optimizing compilers.

A thread is one line of work that the computer runs. Your JavaScript runs on the main thread. Concurrent compilation means the engine builds optimized code on a background thread, a second line of work. Meanwhile, the main thread keeps running the older code.

The compiler works from:

• a snapshot, a frozen copy of the facts it needs,
• the feedback,
• a list of things that must stay true for the new code to be correct.

The engine switches to the new code only when it is ready and safe. This switch is called installing the code.

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

The table splits the work into three parts. Read each row as one part, its job, and why it matters.

Now the real thing. The lesson tests run the code below in Node with --trace-opt. That flag makes V8 print a line each time it starts optimizing a function.

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. Run: node --v8-options
// The lesson tests check only these settings:
// --maglev defaults to --no-maglev in Node 22 (V8 12.4).
// --turbofan and --concurrent-recompilation are on by default.

In the first block, line 1 defines hotSum. Line 3 gives it a loop of work. Line 7 calls it 20,000 times, so it becomes hot. In the trace lines:

• (target TURBOFAN) means TurboFan compiles the function.
• ConcurrencyMode::kConcurrent means it compiles on a background thread. This is the default.
• With --no-concurrent-recompilation, the mode becomes ConcurrencyMode::kSynchronous. The main thread waits while the function compiles.
• With --allow-natives-syntax --maglev, a test that asks for Maglev prints Maglev is not enabled.

The last block is a note, not code to run. It lists the V8 settings from node --v8-options that the tests check.

The tests check only these parts, because they are the same on every run. They do not check timings, memory addresses, or exact version numbers.

Use this knowledge safely

Optimizing compilers explain two things you may notice. Code often gets faster after it has run a while; this is called warm-up. And a small change to hot code can change its speed. But these compilers are not a set of hidden switches for you to flip. In your own code:

• Write clear JavaScript.
• Keep your objects the same shape when that is natural.
• Measure what the user waits for before you change code to make it faster.

When you measure speed:

• Warm up a small speed test (a microbenchmark) first. Then report many runs. Do not trust the first, slow run.
• Use the browser's performance tools to find the slow part of the page before you think about compilers.
• Choose simple, readable code over clever code written for one named compiler.
• When the optimizer surprises you, the next lesson on speculation and deoptimization often explains why.

Common misconceptions

The table below lists four terms. Read each row as a term, what it means, and what it does not mean.

Use the IR words, the engine names, and the two threads from this lesson.

Key takeaways

• An optimizing compiler first rebuilds a hot function as an IR, its own private form. Then it makes faster machine code.
• In SSA, each value gets a name exactly once. A phi node picks the value from the path that ran.
• V8 uses Maglev for quick optimizing and TurboFan, with its Turboshaft backend, for the strongest code. Node 22 (V8 12.4) keeps Maglev off by default.
• SpiderMonkey's Warp turns CacheIR into MIR. JavaScriptCore uses DFG, then FTL, with B3 as FTL's backend.
• Concurrent compilation builds optimized code on a background thread while the main thread keeps running the old code.

Up next: Speculation & deoptimization. You'll see the guards that check the compiler's guesses, and what happens when a guess is wrong.