Baseline compilers

A quick compiler between tiers

After inline caches, the engine has useful feedback at many operation sites. The next question is economic: how much compiler work should the engine spend before a function has proved it is very hot?

A baseline compiler answers “a little.” It turns already-created bytecode into simple machine code quickly. The code is not the engine's best possible code, but it removes interpreter overhead: repeated bytecode decoding, dispatch to the next bytecode handler, and some stack shuffling.

This lesson stays in the baseline layer. Tiered compilation introduced the whole ladder. Optimizing compilers covers Maglev, TurboFan, Warp, DFG, and FTL in depth. A later speculation and deoptimization lesson covers what happens when optimized assumptions fail.

In V8, Ignition is the bytecode interpreter. Sparkplug is V8's baseline compiler. The public V8 article describes Sparkplug as compiling Ignition bytecode directly to machine code, without building a large intermediate representation, or IR. An IR is a compiler's private form of the program used for analysis and rewrites.

1function stamp(total) {2  const fee = 2;3  return total + fee;4}5 6console.log(stamp(40));

Line 1 defines stamp. Line 2 creates fee. Line 3 adds the argument total to that local value. Line 6 calls the function and prints 42. Ignition first lowers the function to bytecode; Sparkplug can then walk that bytecode instead of reparsing the JavaScript source.

[generated bytecode for function: stamp]
LdaSmi [2]
Star0
Ldar r0
Add a0, [0]
Return

Read the bytecode in plain language: LdaSmi [2] loads the small integer 2, Star0 stores it in virtual register 0, Ldar r0 loads that register, Add a0, [0] adds the first argument with feedback slot 0, and Return returns the accumulator.

The next walkthrough is a teaching model. It does not inspect your browser's engine. It shows the same shape of work Sparkplug is famous for: one bytecode instruction comes in, one simple machine-code-like template goes out.

1const bytecode = [2  ["LdaSmi", 2],3  ["Star", "fee"],4  ["Ldar", "fee"],5  ["Add", "total"],6  ["Return"],7];8 9function compileTemplates(bytecodes) {10  const machine = [];11  for (const instruction of bytecodes) {12    const [op, operand] = instruction;13    if (op === "LdaSmi") machine.push(`load_smi ${operand}`);14    if (op === "Star") machine.push(`store ${operand}`);15    if (op === "Ldar") machine.push(`load ${operand}`);16    if (op === "Add") machine.push(`add ${operand}`);17    if (op === "Return") machine.push("return accumulator");18  }19  return machine;20}21 22console.log(compileTemplates(bytecode).join(" | "));

Line 1 holds toy bytecode. Line 9 starts a compiler function. Line 11 walks the list in order. Lines 13 through 17 append fixed templates. Line 19 returns the templates, and line 22 prints them as one trace.

1const bytecode = [Run2  ["LdaSmi", 2],3  ["Star", "fee"],4  ["Ldar", "fee"],5  ["Add", "total"],6  ["Return"],7];8 9function compileTemplates(bytecodes) {10  const machine = [];11  for (const instruction of bytecodes) {12    const [op, operand] = instruction;13    if (op === "LdaSmi") machine.push(`load_smi ${operand}`);14    if (op === "Star") machine.push(`store ${operand}`);15    if (op === "Ldar") machine.push(`load ${operand}`);16    if (op === "Add") machine.push(`add ${operand}`);17    if (op === "Return") machine.push("return accumulator");18  }19  return machine;20}21 22console.log(compileTemplates(bytecode).join(" | "));

Notice what is missing: there is no whole-program graph, no inlining decision, and no speculative rewrite. That is why the compiler is fast. It is also why this tier leaves peak performance to later optimizers.

A stack frame is the runtime storage for one active function call: its arguments, local slots, metadata, and return path. Sparkplug deliberately keeps frames compatible with Ignition. That means the debugger, profiler, stack traces, and on-stack replacement can keep using interpreter-shaped knowledge.

1const frame = {2  functionName: "stamp",3  context: "checkout",4  argument0: 40,5  bytecodeArray: "stamp bytecode",6  offsetOrFeedback: "bytecode offset 0",7  register0: undefined,8};9 10function runInIgnition(total) {11  frame.argument0 = total;12  frame.offsetOrFeedback = "bytecode offset 0";13  frame.register0 = 2;14  return frame.argument0 + frame.register0;15}16 17function runInSparkplug(total) {18  frame.argument0 = total;19  frame.offsetOrFeedback = "feedback vector";20  frame.register0 = 2;21  return frame.argument0 + frame.register0;22}23 24console.log(runInIgnition(40));25console.log(runInSparkplug(40));26console.log(frame.register0);

1const frame = {Run2  functionName: "stamp",3  context: "checkout",4  argument0: 40,5  bytecodeArray: "stamp bytecode",6  offsetOrFeedback: "bytecode offset 0",7  register0: undefined,8};9 10function runInIgnition(total) {11  frame.argument0 = total;12  frame.offsetOrFeedback = "bytecode offset 0";13  frame.register0 = 2;14  return frame.argument0 + frame.register0;15}16 17function runInSparkplug(total) {18  frame.argument0 = total;19  frame.offsetOrFeedback = "feedback vector";20  frame.register0 = 2;21  return frame.argument0 + frame.register0;22}23 24console.log(runInIgnition(40));25console.log(runInSparkplug(40));26console.log(frame.register0);

Baseline compilation is not only a V8 idea. SpiderMonkey, Firefox's engine, documents a C++ interpreter, a Baseline Interpreter, a Baseline Compiler, and then Ion through Warp. Its Baseline Interpreter is a JIT-compiled interpreter that can use inline caches. Its Baseline Compiler is a simple template JIT that emits per-script native code and uses the same ICs.

JavaScriptCore, Safari's engine, publicly describes a tier sequence of LLInt, Baseline JIT, DFG, and FTL. LLInt is the low-level interpreter. Baseline JIT is the quick native tier. DFG and FTL are the optimizing tiers, linked forward to the next lesson.

A baseline compiler chooses compile speed over code quality. That does not mean it creates bad code. It means it refuses expensive analysis until the function has earned it. The code is better than interpretation for repeated execution, but it usually does not inline many functions, rebuild the program as SSA, or specialize every representation.

This is why baseline compilers are perfect for the middle: code that is too active for interpretation to be ideal, but not proven hot enough for a top-tier optimizer. If a function becomes very hot, the next lesson explains the optimizing compilers that spend more time for better machine code.

Use this model to change one input: how many times a function runs. The numbers are not V8 thresholds. They are a small model for the curve: interpreter has no compile cost, baseline has a small compile cost and lower call cost, and optimizing has a large compile cost with the lowest call cost.

1function total(compileCost, callCost, calls) {2  return compileCost + callCost * calls;3}4 5for (const calls of [3, 20, 200]) {6  console.log(7    calls,8    total(0, 5, calls),9    total(12, 2, calls),10    total(80, 0.7, calls).toFixed(1),11  );12}

For three calls, the interpreter's zero compile cost can win. Around twenty calls in this model, baseline wins. At two hundred calls, the optimizing tier finally repays its big compile bill. Real engines use richer counters, inline caches, type feedback, memory budgets, and background compilation.

The lesson tests probe Node 22 on V8 12.4 without depending on exact patch numbers, addresses, or timings. They check that Sparkplug flags exist, that --print-bytecode shows the bytecode above, that %CompileBaseline exists, and that the V8 status mask includes kBaseline after forced baseline compilation.

1// Run in Node with --allow-natives-syntax.2const bits = { kIsFunction: 1 << 0, kBaseline: 1 << 15 };3function stamp(total) {4  const fee = 2;5  return total + fee;6}7 8%CompileBaseline(stamp);9console.log(stamp(40));10const status = %GetOptimizationStatus(stamp);11console.log(Boolean(status & bits.kIsFunction));12console.log(Boolean(status & bits.kBaseline));

node --v8-options | grep -E -- "--sparkplug|--always-sparkplug|--trace-baseline-batch-compilation|--print-bytecode"
node --print-bytecode --print-bytecode-filter=stamp stamp-probe.mjs
node --allow-natives-syntax --always-sparkplug baseline-status.mjs
node --allow-natives-syntax --no-sparkplug baseline-status.mjs

A working developer rarely needs to know whether a function is in Sparkplug, Baseline JIT, or another baseline tier. The useful habit is to understand why early runs can differ from warm runs, why medium-hot helpers can speed up without becoming top-tier optimized, and why stable shapes from the previous lesson still help later tiers.

Measure first. If a user-visible path is slow, profile the path in the browser or Node process that runs it. Keep the code readable, keep hot data reasonably consistent, and treat V8 native syntax as a lab tool only.

Common misconceptions

Check your understanding

Answer these without guessing from tier names. For code questions, compute the JavaScript output first, then connect it back to the engine idea.

Key takeaways

• Sparkplug is V8's fast baseline compiler: it compiles Ignition bytecode directly and avoids a heavy IR.
• Interpreter-compatible frames let baseline code switch tiers, support OSR, and keep debugging machinery simple.
• SpiderMonkey and JavaScriptCore have their own baseline tiers with similar roles but different names and internals.
• Baseline compilation trades peak code quality for compile speed; measure real code before acting on any JIT theory.

Next, Optimizing compilers shows what engines do when a function becomes hot enough for Maglev, TurboFan, Warp, DFG, or FTL to spend more time chasing better machine code.