Ignition and the bytecode

Bytecode: compact by design, and the reason was memory

After the parser builds the AST (and only when a function is actually called — recall lazy parsing), the bytecode generator lowers that tree into Ignition bytecode: a flat sequence of small instructions for a virtual machine. Bytecode sits between source and machine code. It is slower to execute than native machine code, but it is dramatically more compact — one bytecode is typically one or two bytes, versus dozens of bytes of machine code for the same operation.

That compactness was the point. Before Ignition, V8’s baseline compiler generated machine code for every function eagerly, and on memory-constrained mobile devices the accumulated code blew the RAM budget. Ignition replaced eager machine code with bytecode that V8 interprets, roughly halving V8’s code memory while keeping startup snappy. Speed came later, from the JIT tiers compiling the hot bytecode; the founding motivation was footprint.

Register machine, not stack machine

When you read bytecode output from d8 --print-bytecode and see unfamiliar operand patterns, the register model is the key to decoding them. There are two classic ways to build a bytecode VM. A stack machine (the JVM, CPython) keeps operands on an implicit operand stack: PUSH a; PUSH b; ADD pops two, pushes the sum. A register machine keeps operands in named registers and operations reference them directly: ADD r1, r2. Ignition is a register machine.

Register bytecode is a little harder to generate but yields fewer, denser instructions — there is no constant push/pop churn for every operand — which means fewer dispatches in the interpreter loop per unit of work. That density is part of why a register design suits a JIT-backed engine: fewer bytecodes to interpret while cold, and a cleaner stream to compile when hot.

Ignition’s register model is specifically an accumulator + register file:

• The accumulator is a single implicit register that most bytecodes read from and write to. It threads intermediate values from one instruction to the next, so operands do not all need an explicit name. Many ops take one explicit operand and implicitly use the accumulator as the other input and as the output.
• The register file is the set of named local registers — r0, r1, r2, … — holding the function’s locals and temporaries, allocated per function frame.

Reading real bytecode

Take the simplest function and look at what Ignition runs. Run d8 --print-bytecode add.js on:

function add(a, b) { return a + b; }
add(1, 2);

You get something close to this (operands and slot indices abbreviated):

Ldar a1          // load argument b into the accumulator
Add a0, [0]      // accumulator = a0 (a) + accumulator (b); feedback slot 0
Return           // return the accumulator

Notice the accumulator-centric shape: Ldar (Load Accumulator from Register) puts b in the accumulator; Add a0, [0] adds register a0 (the argument a) to the accumulator and leaves the sum in the accumulator; Return returns the accumulator. There is no Push/Pop — the accumulator is the shared workspace.

The [slot] is where the JIT gets its type information

Look again at Add a0, [0]. That [0] is a feedback-vector slot index. Every bytecode whose behaviour depends on runtime types — arithmetic, property loads/stores, calls, comparisons — carries a slot index into the function’s feedback vector, a per-function array allocated alongside the bytecode. As the interpreter executes that bytecode, it records what it actually saw into that slot: the operands of Add were Smis, or the object at a property load had a particular hidden class, or this call site always hit one function.

This is the bridge to the optimiser. The interpreter is, in effect, profiling the program for free while it runs it. When a function gets hot, the JIT (Maglev, TurboFan — covered in unit 04) reads the feedback vector to make speculative assumptions: “this Add only ever sees integers, so emit an integer add.” Type feedback is collected here, in Ignition, one slot per type-sensitive bytecode — which is why this lesson sits directly upstream of the JIT and of type feedback.

Shared handlers, written in Torque

You might expect each bytecode to be hand-written assembly per CPU. Instead, V8 writes each bytecode’s handler — the routine that performs that opcode’s work — once, in a portable low-level DSL: originally CodeStubAssembler (CSA), now mostly Torque, which compiles down to CSA. These handlers are generated into machine code at build time and shared across all functions: there is one Add handler, one LdaNamedProperty handler, and so on. The interpreter is essentially a table of these shared handlers, and running a function means dispatching through them — the subject of the next lesson, the interpreter loop.