Bytecode & interpreters

Bytecode in one sentence

After scanning, parsing, and scope analysis, a JavaScript engine needs something it can run quickly. Bytecode is that compact middle form: lower-level than an AST, higher-level than CPU machine code, and structured enough for an interpreter and later JIT tiers to share.

We will use V8's Ignition as the main concrete example, then compare SpiderMonkey's Baseline Interpreter and JavaScriptCore's LLInt. Keep the nearby lessons in mind: bytecode sits after lazy parsing and before startup snapshots and code caching, while hot code continues into tiered compilation.

Engines could walk the AST directly. That is easy to imagine, but syntax trees are built for grammar: many object nodes, many pointers, and many cases that do not map cleanly to the next executable operation. Rewalking those nodes is unfriendly to caches and keeps parser data alive longer than necessary.

Engines could also compile every function straight to machine code. That can be fast once it runs, but first-run code often executes once during startup. Compiling all of it spends CPU and memory before the engine knows what becomes hot. V8's 2016 Firing up the Ignition interpreter post described Ignition bytecode as roughly 25% to 50% the size of equivalent baseline machine code and first enabled it for low-RAM Android devices.

Ignition is a register machine with a special implicit accumulator. "Register" here means a virtual slot in the interpreter frame, not necessarily a hardware register. Function parameters print as a0, a1, and so on. Locals and temporaries print as r0, r1, and so on. The accumulator is not printed as an operand on most lines because many bytecodes read or write it implicitly.

That implicit accumulator keeps bytecodes compact. Ldar a0 means "load parameter a0 into the accumulator." Star0 means "store the accumulator into r0." Add r0, [1] means "add r0 to the accumulator and use feedback slot 1 for runtime feedback."

You can ask Node to print V8 bytecode for a named function. The lesson tests write the source below to a child Node process, delete the Node test environment variables, and compare each stored opcode sequence with the live output. The addresses are normalized to <addr>.

1node --print-bytecode --print-bytecode-filter=loopSum bytecode-demo.js

1function arithmetic(a, b) {2  const total = a + b;3  return total * 2;4}5 6function propertyCall(user) {7  user.count = user.count + 1;8  return user.label(user.count);9}10 11function loopSum(n) {12  let total = 0;13  let i = 1;14  while (i < n) {15    total = total + i;16    i = i + 1;17  }18  return total;19}20 21function makeAdder(x) {22  return function add(y) {23    return x + y;24  };25}26 27function callFree(fn) {28  return fn(1, 2);29}30 31const user = { count: 1, label(value) { return "#" + value; } };32console.log(arithmetic(2, 3));33console.log(propertyCall(user));34console.log(loopSum(5));35console.log(makeAdder(4)(6));36console.log(callFree((a, b) => a + b));

Line by line: a loop

The loop listing starts with metadata. Parameter count 2 means receiver plus one user parameter. Register count 2 reserves r0 and r1 for total and i. The number after @ is the bytecode offset. Jumps target offsets, not source lines.

1[generated bytecode for function: loopSum (<addr> <SharedFunctionInfo loopSum>)]2Bytecode length: 313Parameter count 24Register count 25Frame size 166  207 S> <addr> @    0 : 0c                LdaZero7         <addr> @    1 : c9                Star08  220 S> <addr> @    2 : 0d 01             LdaSmi [1]9         <addr> @    4 : c8                Star110  234 S> <addr> @    5 : 0b 03             Ldar a011  234 E> <addr> @    7 : 71 f8 00          TestLessThan r1, [0]12         <addr> @   10 : 9e 12             JumpIfFalse [18] (<addr> @ 28)13  245 S> <addr> @   12 : 0b f8             Ldar r114  259 E> <addr> @   14 : 3b f9 01          Add r0, [1]15         <addr> @   17 : c9                Star016  268 S> <addr> @   18 : 0b f8             Ldar r117  274 E> <addr> @   20 : 47 01 02          AddSmi [1], [2]18         <addr> @   23 : c8                Star119  225 E> <addr> @   24 : 8e 13 00 03       JumpLoop [19], [0], [3] (<addr> @ 5)20  285 S> <addr> @   28 : 0b f9             Ldar r021  298 S> <addr> @   30 : ae                Return22Constant pool (size = 0)23Handler Table (size = 0)24Source Position Table (size = 27)25<addr> <Other heap object (TRUSTED_BYTE_ARRAY_TYPE)>

Read the loop body as a sequence of accumulator moves: load n, test whether i < n, jump out if false, load i, add total, store the accumulator back to r0, increment i, then JumpLoop back to offset 5.

Properties, calls, and closures

Property operations have current names in V8 12.4: GetNamedProperty and SetNamedProperty. A method call such as user.label(user.count) becomes a CallProperty1 with the function, receiver, one argument, and a feedback slot.

1[generated bytecode for function: propertyCall (<addr> <SharedFunctionInfo propertyCall>)]2Bytecode length: 273Parameter count 24Register count 35Frame size 246  124 S> <addr> @    0 : 2f 03 00 01       GetNamedProperty a0, [0], [1]7  130 E> <addr> @    4 : 47 01 00          AddSmi [1], [0]8  117 E> <addr> @    7 : 35 03 00 03       SetNamedProperty a0, [0], [3]9  149 S> <addr> @   11 : 2f 03 01 05       GetNamedProperty a0, [1], [5]10         <addr> @   15 : c9                Star011  160 E> <addr> @   16 : 2f 03 00 01       GetNamedProperty a0, [0], [1]12         <addr> @   20 : c7                Star213  149 E> <addr> @   21 : 61 f9 03 f7 07    CallProperty1 r0, a0, r2, [7]14  167 S> <addr> @   26 : ae                Return15Constant pool (size = 2)16<addr>: [TrustedFixedArray]17 - map: <addr> <Map(TRUSTED_FIXED_ARRAY_TYPE)>18 - length: 219           0: <addr> <String[5]: #count>20           1: <addr> <String[5]: #label>21Handler Table (size = 0)22Source Position Table (size = 18)23<addr> <Other heap object (TRUSTED_BYTE_ARRAY_TYPE)>

Closures connect this lesson back to scope analysis. The outer function creates a function context and stores x in a context slot. The inner function later loads that slot before adding its own parameter.

1[generated bytecode for function: makeAdder (<addr> <SharedFunctionInfo makeAdder>)]2Bytecode length: 143Parameter count 24Register count 15Frame size 86  320 E> <addr> @    0 : 88 00 01          CreateFunctionContext [0], [1]7         <addr> @    3 : 1a f9             PushContext r08         <addr> @    5 : 0b 03             Ldar a09         <addr> @    7 : 25 02             StaCurrentContextSlot [2]10  328 S> <addr> @    9 : 85 01 00 02       CreateClosure [1], [0], #211  375 S> <addr> @   13 : ae                Return12Constant pool (size = 2)13<addr>: [TrustedFixedArray]14 - map: <addr> <Map(TRUSTED_FIXED_ARRAY_TYPE)>15 - length: 216           0: <addr> <ScopeInfo FUNCTION_SCOPE>17           1: <addr> <SharedFunctionInfo add>18Handler Table (size = 0)19Source Position Table (size = 10)20<addr> <Other heap object (TRUSTED_BYTE_ARRAY_TYPE)>

1[generated bytecode for function: add (<addr> <SharedFunctionInfo add>)]2Bytecode length: 93Parameter count 24Register count 15Frame size 86  357 S> <addr> @    0 : 17 02             LdaImmutableCurrentContextSlot [2]7         <addr> @    2 : c9                Star08         <addr> @    3 : 0b 03             Ldar a09  366 E> <addr> @    5 : 3b f9 00          Add r0, [0]10  370 S> <addr> @    8 : ae                Return11Constant pool (size = 0)12Handler Table (size = 0)13Source Position Table (size = 9)14<addr> <Other heap object (TRUSTED_BYTE_ARRAY_TYPE)>

A free function call has no method receiver, so V8 prints CallUndefinedReceiver2 for two arguments in this example.

1[generated bytecode for function: callFree (<addr> <SharedFunctionInfo callFree>)]2Bytecode length: 123Parameter count 24Register count 35Frame size 246   26 S> <addr> @    0 : 0d 01             LdaSmi [1]7         <addr> @    2 : c8                Star18         <addr> @    3 : 0d 02             LdaSmi [2]9         <addr> @    5 : c7                Star210   33 E> <addr> @    6 : 66 03 f8 f7 00    CallUndefinedReceiver2 a0, r1, r2, [0]11   42 S> <addr> @   11 : ae                Return12Constant pool (size = 0)13Handler Table (size = 0)14Source Position Table (size = 8)15<addr> <Other heap object (TRUSTED_BYTE_ARRAY_TYPE)>

The browser experiment below compiles a tiny JavaScript subset with acorn, lowers it to a toy accumulator/register bytecode, and interprets it with a dispatch table. It is a teaching model inspired by Ignition; it does not implement JavaScript semantics, hidden classes, inline caches, exceptions, or real V8 bytecode.

1const program = [2  ["LdaSmi",0],Run3  ["Star","r0"],4  ["LdaSmi",1],5  ["Star","r1"],6  ["Ldar","r1"],7  ["Star","r2"],8  ["Ldar","a0"],9  ["Star","r3"],10  ["LdaSmi",1],11  ["Add","r3"],12  ["TestLessThan","r2"],13  ["JumpIfFalse",23],14  ["Ldar","r0"],15  ["Star","r4"],16  ["Ldar","r1"],17  ["Add","r4"],18  ["Star","r0"],19  ["Ldar","r1"],20  ["Star","r5"],21  ["LdaSmi",1],22  ["Add","r5"],23  ["Star","r1"],24  ["Jump",4],25  ["Ldar","r0"],26  ["Return"],27];28 29function run(bytecode, a0) {30  const registers = { a0: a0, r0: undefined, r1: undefined };31  let pc = 0;32  let acc;33  const dispatch = {34    LdaSmi(value) { acc = value; pc += 1; },35    Ldar(register) { acc = registers[register]; pc += 1; },36    Star(register) { registers[register] = acc; pc += 1; },37    Add(register) { acc = registers[register] + acc; pc += 1; },38    Mul(register) { acc = registers[register] * acc; pc += 1; },39    TestLessThan(register) { acc = registers[register] < acc; pc += 1; },40    JumpIfFalse(target) { pc = acc ? pc + 1 : target; },41    Jump(target) { pc = target; },42    Return() { pc = bytecode.length; },43  };44  while (pc < bytecode.length) {45    const [op, operand] = bytecode[pc];46    dispatch[op](operand);47  }48  return acc;49}50 51console.log(run(program, 4));

The loop shows why a program counter matters. JumpIfFalse leaves the loop when the accumulator holds false; Jump returns to the condition. Back and Reset replay recorded snapshots from the real toy interpreter run.

1const program = [2  ["Ldar","a0"],Run3  ["Star","r1"],4  ["LdaSmi",2],5  ["Mul","r1"],6  ["Star","r0"],7  ["Ldar","r0"],8  ["Star","r2"],9  ["LdaSmi",1],10  ["Add","r2"],11  ["Return"],12];13 14function run(bytecode, a0) {15  const registers = { a0: a0, r0: undefined };16  let pc = 0;17  let acc;18  const dispatch = {19    LdaSmi(value) { acc = value; pc += 1; },20    Ldar(register) { acc = registers[register]; pc += 1; },21    Star(register) { registers[register] = acc; pc += 1; },22    Add(register) { acc = registers[register] + acc; pc += 1; },23    Mul(register) { acc = registers[register] * acc; pc += 1; },24    TestLessThan(register) { acc = registers[register] < acc; pc += 1; },25    JumpIfFalse(target) { pc = acc ? pc + 1 : target; },26    Jump(target) { pc = target; },27    Return() { pc = bytecode.length; },28  };29  while (pc < bytecode.length) {30    const [op, operand] = bytecode[pc];31    dispatch[op](operand);32  }33  return acc;34}35 36console.log(run(program, 5));

A short expression makes the accumulator easier to see: load a value, store a temporary, load the next value, combine, then return. The real V8 listing uses more specialized bytecodes, but the mental model is the same: one current value plus named storage.

0000 LdaSmi 0
0001 Star r0
0002 LdaSmi 1
0003 Star r1
0004 Ldar r1
0005 Star r2
0006 Ldar a0
0007 Star r3
0008 LdaSmi 1
0009 Add r3
0010 TestLessThan r2
0011 JumpIfFalse 23
0012 Ldar r0
0013 Star r4
0014 Ldar r1
0015 Add r4
0016 Star r0
0017 Ldar r1
0018 Star r5
0019 LdaSmi 1
0020 Add r5
0021 Star r1
0022 Jump 4
0023 Ldar r0
0024 Return

[generated bytecode for function: loopSum (<addr> <SharedFunctionInfo loopSum>)]
Bytecode length: 31
Parameter count 2
Register count 2
Frame size 16
  207 S> <addr> @    0 : 0c                LdaZero
         <addr> @    1 : c9                Star0
  220 S> <addr> @    2 : 0d 01             LdaSmi [1]
         <addr> @    4 : c8                Star1
  234 S> <addr> @    5 : 0b 03             Ldar a0
  234 E> <addr> @    7 : 71 f8 00          TestLessThan r1, [0]
         <addr> @   10 : 9e 12             JumpIfFalse [18] (<addr> @ 28)
  245 S> <addr> @   12 : 0b f8             Ldar r1
  259 E> <addr> @   14 : 3b f9 01          Add r0, [1]
         <addr> @   17 : c9                Star0
  268 S> <addr> @   18 : 0b f8             Ldar r1
  274 E> <addr> @   20 : 47 01 02          AddSmi [1], [2]
         <addr> @   23 : c8                Star1
  225 E> <addr> @   24 : 8e 13 00 03       JumpLoop [19], [0], [3] (<addr> @ 5)
  285 S> <addr> @   28 : 0b f9             Ldar r0
  298 S> <addr> @   30 : ae                Return
Constant pool (size = 0)
Handler Table (size = 0)
Source Position Table (size = 27)
<addr> <Other heap object (TRUSTED_BYTE_ARRAY_TYPE)>

A bytecode interpreter is not a magical loop that understands every instruction by name. Each bytecode has handler code. Dispatch reads the opcode at the current bytecode offset, jumps to the handler, and the handler updates state before dispatching the next bytecode.

1const handlers = {2  LdaSmi(state, value) {3    state.acc = value;4    state.pc += 1;5  },6  Add(state, register) {7    state.acc = state.registers[register] + state.acc;8    state.pc += 1;9  },10  JumpIfFalse(state, target) {11    state.pc = state.acc ? state.pc + 1 : target;12  },13};14 15function dispatch(bytecode, state) {16  const [op, operand] = bytecode[state.pc];17  return handlers[op](state, operand);18}

V8's Ignition documentation describes threaded dispatch: every handler is a standalone chunk of machine code, and the end of a handler fetches the next bytecode and jumps through a dispatch table. V8's original Ignition post says those handlers were generated with TurboFan's low-level backend rather than handwritten for every architecture; later V8 infrastructure such as the CodeStubAssembler uses TurboFan's backend for portable low-level builtins.

Size matters inside the bytecode stream too. Stores to low-numbered registers use short forms such as Star0, Star1, and Star2; Node 22's listings above show them directly. These short stores are part of the same compactness story as the accumulator.

Bytecode saves memory, but it still occupies heap space. V8's V8 Lite work identified bytecode and feedback data as important memory contributors on real pages. The result was not just a separate lite mode; several ideas moved into regular V8.

The flag names are visible in current Node: --flush-bytecode is enabled by default, --lazy-feedback-allocation is enabled by default, and --invocation-count-for-feedback-allocation controls one threshold. These are engine implementation details, not knobs application code should casually depend on.

V8's names are useful because Node is easy to run, but the web does not standardize bytecode. Firefox's SpiderMonkey and Safari's JavaScriptCore also execute bytecode first, with their own formats, metadata, and tiering decisions.

Firefox source docs describe SpiderMonkey's Baseline Interpreter as a hybrid interpreter/JIT: it interprets bytecode one opcode at a time while attaching Inline Caches. SpiderMonkey's opcode definitions describe stack uses and definitions for bytecode instructions. WebKit's JSC bytecode post shows bytecode with operands such as loc7 and arg1, and WebKit docs describe the LLInt as the Low Level Interpreter written in offlineasm.

You do not need bytecode for every performance investigation. Start with the Performance panel, real-user metrics, bundle analysis, and the call stack. Bytecode becomes useful when you are checking first-run costs, investigating a small benchmark, learning how closures and property operations are represented, or verifying a claim about what the engine does before optimization.

Common misconceptions

• “Bytecode is JavaScript source with shorter names.” It is an engine-specific instruction format after parsing, scope work, and lowering.
• “Bytecode is machine code.” The CPU does not execute Ignition bytecode directly; handlers interpret it or compilers translate from it.
• “One V8 listing teaches every browser.” SpiderMonkey and JavaScriptCore have different bytecode formats and names.
• “Feedback slots are constants.” Bracketed operands on many V8 bytecodes name feedback vector slots, not literal values.
• “Flushing bytecode changes program behavior.” It is an internal memory optimization; if the function runs again, bytecode is regenerated.

Key takeaways

• Bytecode is a compact execution format between source ASTs and CPU machine code.
• Ignition uses virtual registers plus an implicit accumulator; many operands are omitted because the accumulator is assumed.
• --print-bytecode listings show bytecode offsets, registers, constants, feedback slots, and metadata for one V8 version.
• Handlers and dispatch are the interpreter's core: read an opcode, jump to its handler, update state, repeat.
• Engines can flush cold bytecode and allocate feedback lazily to reduce memory without changing JavaScript behavior.
• SpiderMonkey and JavaScriptCore share the bytecode-first strategy but use different formats and first-tier interpreters.

Next: Startup: snapshots & code caching. Then return to Tiered compilation to see how hot bytecode graduates beyond the interpreter.