Speculation & deoptimization

Optimize the likely case, keep an exit

JavaScript engines want hot code to run like carefully planned machine code, but JavaScript values can change shape and type at runtime. The compromise is speculation: compile the case that has happened so far, then keep a safe exit for the case that happens next.

This lesson builds on type feedback and inline caches. Those lessons explain how engines collect evidence; here you use that evidence to understand why optimized code needs guards, watchpoints, and deopt metadata. The previous lesson, Optimizing compilers, explains the compilers that emit the optimized code.

Speculative optimization

A speculative plan has three parts. First, feedback says what values arrived at one site. Second, optimized code uses that pattern. Third, guards check that the next value still fits. A guard is a runtime test that protects an optimization.

1const feedback = createFeedback("total + fee");Run2observe(feedback, 10, 2);3const optimized = compileWithGuards(feedback);4optimized(12, 3);5optimized("12", "3");

In the replay, line 2 warms the add site with numbers. Line 3 compiles a guarded plan. Line 4 passes the guard, but line 5 sends strings. The optimized path bails out, the generic path concatenates, and the result is still "123".

1function totalCents(price, tax) {2  return price + tax;3}4 5console.log(totalCents(100, 8));6console.log(totalCents(250, 20));

Line 2 always performs numeric addition. The lesson is not “never use strings.” It is “avoid making one hot operation alternate between two meanings unless that is the behavior you really need.”

The feedback lattice

A lattice is an ordered set of states where new evidence can move a site toward a more general state. For the binary add operation, V8 12.4 names hints such as None, SignedSmall, Number, NumberOrOddball, and Any. The exact compiler may split more cases, but the safe teaching model is that a site widens when broader values appear.

1function onlySmi(a, b) { return a + b; }2for (let i = 0; i < 30; i += 1) onlySmi(i, i + 1);3console.log("ONLY_SMI");4%DebugPrint(onlySmi);5 6function smiThenDouble(a, b) { return a + b; }7for (let i = 0; i < 30; i += 1) smiThenDouble(i, i + 1);8smiThenDouble(1.5, 2.25);9console.log("SMI_DOUBLE");10%DebugPrint(smiThenDouble);11 12function numberOddball(a, b) { return a + b; }13for (let i = 0; i < 30; i += 1) numberOddball(undefined, i);14console.log("ODDBALL");15%DebugPrint(numberOddball);

1const slot = createSlot("BinaryOp slot #0");2feed(slot, 1, 2);          // SignedSmall3feed(slot, 1.5, 2.25);     // Number4feed(slot, undefined, 1);  // NumberOrOddball5feed(slot, "7", "8");     // Any

Try the scripted sequence, then reset and feed strings first. A fresh string-only site can specialize differently, but mixing number addition and string concatenation at the same site pushes this model to Any.

Guards, checks, and watchpoints

Inline checks protect facts about values in the current optimized frame. A Smi check protects small-integer math. A map check protects an object layout. A bounds check protects an array access. A watchpoint, also called a code dependency in V8 traces, protects a fact that can be invalidated from elsewhere, such as a stable prototype or constant field.

Eager vs lazy deoptimization

Eager deoptimization happens at the failing check. The optimized frame cannot continue because the current value violates a guard. Lazy deoptimization is delayed until a safe point after optimized code was marked invalid by a dependency or watchpoint. Both paths need metadata that maps optimized machine state back to interpreter-level variables.

1const menu = makeMenu({ taxRate: 0.05 });Run2const plan = compilePriceReader(menu);3plan({ subtotal: 100 });4changeTaxRate(menu, 0.12);5plan({ subtotal: 100 });

The watchpoint replay is a teaching model. It does not inspect your browser engine. It shows why code can be invalidated by a change outside the exact instruction that later falls back.

Deopt loops

A deopt loop is a pattern where code optimizes for one case, quickly sees another case, deopts, gathers feedback, and then repeats. Engines track this kind of churn and can delay or stop re-optimizing. Your practical fix is usually simpler: keep the hot operation's inputs stable, or split truly different cases into different paths.

1function addOne(value) {2  return value + 1;3}4 5const values = [1, "1", 2, "2"];6console.log(values.map(addOne).join("|"));

Line 6 calls the same addOne site with numbers and strings. JavaScript prints 2|11|3|21. A real optimizer may learn from that, but if the hot path keeps alternating, repeated specialization attempts can become wasted work.

• Normalize API data once, before it enters a hot loop.
• Keep one hot call site from mixing many unrelated shapes or type meanings.
• Split rare cases out when it improves clarity and measurements say the path matters.
• Prefer readable code; do not contort code for a trace line that is not on a hot path.

Tracing deopts with Node

V8 exposes diagnostic flags in Node. These examples are marked non-runnable in the browser editor because they require Node flags and V8 native syntax. The tests run them in child processes and assert stable facts only: Node starts with v22., V8 starts with 12.4., eager deopt traces include a kind and reason, and dependency invalidation traces mention code dependencies.

1function add(a, b) {2  return a + b;3}4 5%PrepareFunctionForOptimization(add);6for (let i = 0; i < 100000; i += 1) {7  add(i, i + 1);8}9%OptimizeFunctionOnNextCall(add);10add(1, 2);11add("x", "y");

$ node --allow-natives-syntax --no-concurrent-recompilation --trace-deopt probe.js
[bailout (kind: deopt-eager, reason: not a Smi): begin. deoptimizing ...]

1const proto = { taxRate: 0.05 };2const menu = Object.create(proto);3menu.subtotal = 100;4function price(row) {5  return row.subtotal * (1 + row.taxRate);6}7%PrepareFunctionForOptimization(price);8for (let i = 0; i < 100000; i += 1) price(menu);9%OptimizeFunctionOnNextCall(price);10price(menu);11proto.taxRate = 0.12;12price(menu);

$ node --allow-natives-syntax --trace-deopt probe.js
[marking dependent code ... for deoptimization, reason: code dependencies]

1function add(a, b) { return a + b; }2%PrepareFunctionForOptimization(add);3add(1, 2);4%OptimizeFunctionOnNextCall(add);5add(3, 4);6const status = %GetOptimizationStatus(add);7console.log("status is number", typeof status === "number");

Practical habits

Most frontend developers should not chase every deopt. Use this knowledge when a measured hot path matters: a parser, a chart reducer, a data-grid formatter, or an animation loop. Then make the values boring in the best way.

1function toCents(value) {2  return Number(value);3}4const inputs = ["100", "50", "25"];5console.log(inputs.map(toCents).reduce((sum, value) => sum + value, 0));

Line 1 converts each API value once. Line 5 then reduces numbers, not a mixture of strings and numbers. Measure before and after in the application path you care about.

Common misconceptions

• “Deopt means my code is wrong.” No. It means an optimized assumption stopped matching; JavaScript still runs correctly.
• “The feedback lattice narrows after a clean call.” Usually no. Feedback tends to widen so the next plan stays safe.
• “Watchpoints run my JavaScript callback.” No. They are engine dependencies that invalidate compiled code internally.
• “Every trace line must be fixed.” No. Fix measured hot paths, not diagnostic noise.

Practice exercises

function totalCents(price, tax) {
  return price + tax;
}

console.log(totalCents(100, 8));
console.log(totalCents(250, 20));

function totalCents(price, tax) {
  return price + tax;
}

console.log(totalCents(100, 8));
console.log(totalCents(250, 20));

let state = "None";
function merge(previous, observed) {
  if (previous === "None") return observed;
  if (previous === observed) return previous;
  if (previous === "SignedSmall" && observed === "Number") return "Number";
  if (previous === "Number" && observed === "NumberOrOddball") return "NumberOrOddball";
  return "Any";
}
state = merge(state, "SignedSmall");
state = merge(state, "Number");
state = merge(state, "NumberOrOddball");
console.log(state);

let state = "None";
function merge(previous, observed) {
  if (previous === "None") return observed;
  if (previous === observed) return previous;
  if (previous === "SignedSmall" && observed === "Number") return "Number";
  if (previous === "Number" && observed === "NumberOrOddball") return "NumberOrOddball";
  return "Any";
}
state = merge(state, "SignedSmall");
state = merge(state, "Number");
state = merge(state, "NumberOrOddball");
console.log(state);

function addFee(value) {
  return value + 1;
}

console.log(addFee(4));
console.log(addFee("4"));

function addFee(value) {
  return value + 1;
}

console.log(addFee(4));
console.log(addFee("4"));

function normalizePrice(value) {
  // return a number here
}

const raw = ["100", "50", "25"];

function toCents(value) {
  return Number(value);
}
const inputs = ["100", "50", "25"];
console.log(inputs.map(toCents).reduce((sum, value) => sum + value, 0));

Quiz

Key takeaways

• Optimized JavaScript is often speculative: fast for the observed case, guarded for correctness.
• Feedback usually widens through a lattice. One surprising value can make a site more general.
• Inline guards tend to cause eager deopts; watchpoints and code dependencies can invalidate code lazily.
• Trace deopts to investigate measured hot paths, then keep types and shapes stable where it improves real work.

One-line summary: speculation makes the common path fast, and deoptimization keeps the uncommon path correct.

Next, What optimizing compilers do shows the classic transformations, such as inlining, constant folding, and bounds-check elimination, that speculation makes possible.