Inside the interpreter loop

The dispatch loop

The previous lesson left us with a function’s bytecode and a set of shared handlers (one per opcode, written in Torque). Execution is the act of running those handlers in sequence. Conceptually:

loop:
  opcode  = bytecode[pc]        // fetch the current opcode
  handler = handlerTable[opcode] // look up its handler
  jump handler                   // do the work; handler advances pc, then dispatches the next

Each iteration fetches the opcode at the current bytecode pointer (pc), looks up the handler for that opcode in a table, and jumps to it. The handler reads its operands (from the register file and the accumulator), does the operation, writes the result (usually back to the accumulator), advances the pc past this instruction’s operands, and then dispatches the next instruction. Run that loop until Return, and you have executed the function.

How the jump is made fast: threaded dispatch

A naive interpreter would write this as a giant switch (opcode) inside a while loop. That works, but it has a hidden cost: after every handler the control flow returns to the top of the loop and re-enters the switch, and the CPU’s branch predictor sees one single indirect branch shared by all opcodes — so it predicts poorly and stalls.

Ignition uses threaded dispatch instead: each handler ends by directly dispatching to the next handler — historically via a computed goto (one indirect jump per handler), and in Ignition specifically via a tail call from one handler’s machine code straight into the next handler’s. The win is for branch prediction: each opcode’s dispatch site is its own indirect branch, so the predictor can learn the common successor of each opcode (e.g. a comparison is usually followed by a branch), instead of muddling one shared branch. Fewer mispredicts means a tighter, faster interpreter loop.

The accumulator is what makes the handoff between handlers clean: rather than passing operands explicitly, most handlers read and write the one shared accumulator register, so a value produced by one bytecode is sitting right where the next bytecode expects it. The dispatch loop and the accumulator are two halves of the same design.

Profiling while interpreting: feedback fills in

The loop is not just executing — it is learning. Recall that every type-sensitive bytecode carries a feedback-vector slot. As those handlers run, they fill in the slots with the maps (hidden classes) and types they actually observe: this LdaNamedProperty saw an object with map M; this Add saw two Smis; this Call always targeted function F. By the time a function has run a while, its feedback vector is a compact profile of how it is really used — exactly the information the optimiser needs. The interpreter is priming the JIT as a side effect of running the program.

The interrupt budget: how the loop decides to tier up

How does V8 know a function is hot enough to compile? It does not literally count every instruction. Each function carries an interrupt budget (a “feedback cell budget” / invocation-and-loop counter). The loop decrements that budget on the events that correlate with heat:

• Back-edges — every time control jumps backward to the top of a loop (one iteration of a for/while). A tight loop chews through the budget fast.
• Function calls / invocations — entering the function again.

When the budget hits zero, the loop raises a tier-up request: compile this function with the next tier (Sparkplug, then Maglev, then TurboFan — unit 04). For a loop that is still running when it goes hot, V8 can even swap the running code mid-loop via on-stack replacement (OSR), jumping from the interpreter into freshly compiled code without waiting for the loop to finish. Back-edges are the key signal: a long-running loop is the canonical “this is hot, optimise it now” trigger.

Why interpreting first is the safe default

When you profile a function and see it spending time in the interpreter, that is not a bug — it is the engine doing exactly what it is supposed to do before it has enough data to speculate. Interpretation is slower per instruction than optimised machine code — there is a fetch-and-dispatch overhead on every bytecode. But it is predictable: there is no compile pause (the bytecode is ready immediately), and there is no deopt — the interpreter makes no speculative type assumptions, so it cannot be wrong about types and forced to bail out. Optimised code is faster but can deopt back to this loop when an assumption breaks (a deopt always lands you back in the interpreter). So Ignition is both the cheap starting point and the safety net the JIT falls back to. That is why every function begins its life right here, in the dispatch loop, and why this lesson sits at the seam between “how JS runs” and the JIT machinery of unit 04.