On-stack replacement

Switch while a call is already running

A normal optimized function starts when you call it. But a loop can become hot inside a function that was called only once. If the engine waited for the next call, a data import, parser, image filter, or report generator might finish before optimized code ever gets a chance to run.

The “stack” is the engine's record of active function calls. A frame is one call's portion of that stack: its parameters, local variables, return point, and bookkeeping. OSR replaces the code used by that live frame without asking JavaScript to start the function again.

1function sumOnce(limit) {2  let sum = 0;3  for (let i = 1; i <= limit; i += 1) {4    sum += i;5  }6  return "sum=" + sum;7}8 9console.log(sumOnce(5));

Line 9 calls sumOnce once. Lines 3 and 4 can still run many times. That difference is why this lesson links back to tiered compilation for hotness counters, then zooms in on the special loop handoff. The previous lesson, What optimizing compilers do, explains transformations such as loop-invariant code motion. The next lesson, Tagged values, Smis & heap numbers, explains the values those optimized frames move around.

Hot loops in cold functions

A function is cold when it has not been called enough to justify expensive compilation. A loop is hot when its back edge runs many times. Those facts can disagree: one call can contain ten million loop iterations.

Engines already use hotness counters, but function-entry counters are not enough for this shape. V8 also tracks loop progress. The bytecode for a loop has a back-edge instruction named JumpLoop. Around that back edge, V8 can update OSR urgency and decide whether an optimized loop entry should be compiled.

1function longOsrLoop(limit) {2  let sum = 0;3  for (let i = 0; i < limit; i += 1) {4    sum += i & 7;5  }6  return sum;7}8 9longOsrLoop(10000000);

This is not JavaScript syntax. It is V8 evidence. Your application should never depend on the exact threshold or on OSR happening at all.

OSR entry points start at loop headers

Optimized code normally expects to start with a fresh call: parameters arrive, locals are initialized, then line 1 runs. OSR needs a different doorway. The loop is already partway through the function, so the optimized code is compiled with a special entry point at a loop header. A loop header is the place where the next iteration begins.

1$ node --print-bytecode --print-bytecode-filter=longOsrLoop probe.js2[generated bytecode for function: longOsrLoop]3... JumpLoop ..., [0], ...

V8's full printed bytecode includes offsets and addresses that change between runs, so the test does not pin them. The stable clue is the word JumpLoop. That back edge is the loop's “next lap” point, and it is a natural place to ask whether the loop should continue in optimized code.

Carry live values across the handoff

The hard part is not deciding that a loop is hot. The hard part is entering compiled code with the right live values. If the interpreter has already computed i = 5 and sum = 10, the optimized loop must receive exactly those values. Otherwise the language result would change.

1const osrBudget = 5;Run2function sumWithOsrModel(limit) {3  let tier = "interpreter";4  let sum = 0;5  for (let i = 1; i <= limit; i += 1) {6    if (tier === "interpreter" && i === osrBudget) {7      tier = "optimized";8      console.log("OSR carries i=" + i + ", sum=" + sum);9    }10    sum += i;11  }12  return { tier, sum };13}14 15const report = sumWithOsrModel(8);16console.log(report.tier);17console.log(report.sum);

Step through the model. Line 15 makes one call. The first four iterations build sum = 10. Line 6 is the budget check at the loop header. Line 7 switches the tier, and line 8 prints the values that must be carried into the optimized loop.

1function runTeachingOsr(iterations, budget) {2  let tier = "interpreter";3  let sum = 0;4  let switchIteration = null;5  for (let i = 1; i <= iterations; i += 1) {6    if (tier === "interpreter" && i === budget) {7      switchIteration = i;8      tier = "optimized";9    }10    sum += i;11  }12  return { switchIteration, tier, sum };13}

Change the budget and the iteration count. When the budget is 6 and the limit is 12, the interpreter runs five trips, then optimized code runs seven trips. When the budget is larger than the loop, there is no handoff.

Deoptimizing mid-function goes the other way

OSR moves from a less specialized tier into optimized code. Deoptimization moves the other way: optimized code gives up an assumption and rebuilds an interpreter-compatible frame at the right bytecode offset. The wider deoptimization story belongs to the speculation and deoptimization lesson; here we focus on the mid-function handoff.

1function sumWithDeoptModel(values) {2  let mode = "optimized-number-loop";3  let total = 0;4  for (let i = 0; i < values.length; i += 1) {5    const value = values[i];6    if (mode === "optimized-number-loop" && typeof value !== "number") {7      mode = "interpreter";8      console.log("deopt carries i=" + i + ", total=" + total);9    }10    total += value;11  }12  return total;13}14 15console.log(sumWithDeoptModel([2, 3, null, 5]));Run

The teaching model starts with a number-only loop. The value null fails the guard on line 6. Line 7 switches to the interpreter model, line 8 carries the live values, and line 10 finishes with JavaScript's ordinary addition rules. The answer is still 10.

1function sumNumbers(values) {2  let total = 0;3  for (let i = 0; i < values.length; i += 1) {4    total += values[i];5  }6  return total;7}8 9const numbers = [1, 2, 3, 4];10for (let i = 0; i < 100000; i += 1) sumNumbers(numbers);11%OptimizeFunctionOnNextCall(sumNumbers);12sumNumbers(numbers);13sumNumbers([1, "2", 3, 4]);

1[bailout (kind: deopt-eager, reason: ...): begin. deoptimizing ... <JSFunction sumNumbers ...>, ... bytecode offset ...]

The real trace is noisy, so the test only checks stable substrings: deoptimizing, sumNumbers, and bytecode offset. Addresses, optimization IDs, and exact timing are intentionally ignored.

Real V8 evidence, carefully stated

The tests for this lesson run on Node 22, which embeds V8 12.4. They check process.version with a v22. prefix and process.versions.v8 with a 12.4. prefix. They do not pin patch versions, memory addresses, instruction offsets, or timing numbers.

Those are V8 12.4 implementation facts, not ECMAScript rules. Other engines have their own tiering and OSR machinery. The JavaScript specification only requires the same observable result.

Why loop benchmarks mislead

A tiny loop benchmark often measures tiering artifacts. Early iterations may be interpreter code. Later iterations may enter through an OSR path that normal calls do not use. Fixed inputs may make the work easier than production. If the result is unused, the optimizer may remove or reshape the work. Garbage collection and timer resolution can drown out the signal.

1function cartTotal(items) {2  let total = 0;3  for (let i = 0; i < items.length; i += 1) {4    total += items[i];5  }6  return total;7}8 9const basket = [10, 20, 30];10for (let sample = 0; sample < 1000; sample += 1) {11  cartTotal(basket);12}13console.log("bad benchmark kept result:", false);

This bad sample prints a stable warning value, not a timing number, because timing is not portable enough for a lesson test. The important bug is line 10: the returned total is thrown away.

1function cartTotal(items) {2  let total = 0;3  for (let i = 0; i < items.length; i += 1) {4    total += items[i];5  }6  return total;7}8 9const baskets = [[10, 20, 30], [5, 15, 25], [7, 11, 13]];10let sink = 0;11for (let warmup = 0; warmup < 100; warmup += 1) {12  sink += cartTotal(baskets[warmup % baskets.length]);13}14for (let sample = 0; sample < 1000; sample += 1) {15  sink += cartTotal(baskets[sample % baskets.length]);16}17console.log("better benchmark kept result:", sink > 0);18console.log("sample total:", cartTotal(baskets[1]));

This is still only a skeleton. A real benchmark would add a timer, many samples, medians or distributions, and allocation checks. For the full workflow, use Measuring performance.

What working developers should do

You usually do not need to force or detect OSR. You need to know why warm-up exists, why a single long loop can change behavior during a run, and why a profile beats folklore. If a measured hot loop matters, keep the code readable first, then test realistic inputs and watch allocations.

• Warm up benchmarks with the same kinds of values the measured run will use.
• Use the computed result so the engine must preserve the work you meant to measure.
• Vary inputs enough to resemble the real workload, especially limits and data shapes.
• Report repeated samples, not one dramatic timing number.
• Do not ship V8 flags, native syntax, or code that depends on OSR thresholds.

The practical rule is simple: measure the user-visible path first. Engine internals help you explain a profile; they should not become a style guide on their own.

Common misconceptions

• “OSR is a JavaScript feature.” It is an engine implementation detail. Your code cannot call it directly.
• “A function must be called many times to optimize.” A loop can be hot inside one call, which is the OSR case.
• “OSR means the loop starts over.” It continues from a loop header with live values carried across.
• “Deopt is a crash.” It is a safe recovery path that preserves JavaScript semantics.
• “A loop microbenchmark proves production speed.” It may mostly prove warm-up, OSR, timer, or dead-result behavior.

Practice exercises

function sumOnce(limit) {
  let sum = 0;
  for (let i = 1; i <= limit; i += 1) sum += i;
  return sum;
}
console.log(sumOnce(6));

function countTiered(iterations, switchAt) {
  let tier = "interpreter";
  let optimized = 0;
  for (let i = 1; i <= iterations; i += 1) {
    if (i === switchAt) tier = "optimized";
    if (tier === "optimized") optimized += 1;
  }
  return optimized;
}
console.log(countTiered(8, 5));

function countTiered(iterations, switchAt) {
  let tier = "interpreter";
  let optimized = 0;
  for (let i = 1; i <= iterations; i += 1) {
    if (i === switchAt) tier = "optimized";
    if (tier === "optimized") optimized += 1;
  }
  return optimized;
}
console.log(countTiered(8, 5));

Check your understanding

Key takeaways

• OSR lets a currently running loop enter optimized code without waiting for the next function call.
• The special entry point is usually at a loop header, where live values such as i and sum can be carried across.
• Deoptimization can rebuild interpreter-compatible state at a bytecode offset when optimized assumptions fail mid-function.
• Loop microbenchmarks are fragile because warm-up, OSR entry paths, unused results, fixed inputs, GC, and timers can dominate.
• Use OSR knowledge to interpret measurements, not to write code that depends on one engine's thresholds.

Up next: Tagged values, Smis & heap numbers, where you will see how engines fit JavaScript values into machine words.