How the Google V8 Engine Compiles JavaScript

// Consider this function:
function multiply(a, b) {
  return a * b;
}
 
// Ignition generates bytecode like this (simplified):
//
// Bytecode for multiply(a, b):
//   0: Ldar a1          // Load register a1 (parameter 'b') into accumulator
//   1: Mul a0, [0]      // Multiply accumulator by register a0 (parameter 'a')
//                        // [0] references feedback slot for type profiling
//   2: Return            // Return the value in the accumulator
//
// Key Ignition features:
// - Register-based VM (not stack-based)
// - Accumulator register used implicitly by most operations
// - Feedback slots collect runtime type information
 
// More complex bytecode example:
function fibonacci(n) {
  if (n <= 1) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}
 
// Ignition bytecode (simplified):
//   0: LdaSmi [1]           // Load small integer 1 into accumulator
//   1: TestLessThanOrEqual a0, [0]  // Compare a0 (n) <= accumulator
//   2: JumpIfFalse [7]      // Jump to bytecode offset 7 if false
//   3: Ldar a0              // Load n into accumulator
//   4: Return               // Return n (base case)
//   5: ...                  // Recursive calls and addition
//
// Each operation also records type feedback:
// - Slot [0] learns that 'n' is always a Smi (small integer)
// - This feedback guides TurboFan optimization later
 
// BYTECODE SIZE MATTERS: Ignition bytecodes are compact
// A typical function compiles to 50-200 bytes of bytecode
// vs 500-5000 bytes of optimized machine code
// This reduces memory pressure for rarely-called functions

// Every function has a feedback vector that collects type information
// This data drives TurboFan's optimization decisions
 
// Type feedback for arithmetic operations
function compute(x, y) {
  const sum = x + y;    // Feedback slot 0: records operand types
  const product = x * y; // Feedback slot 1: records operand types
  return sum + product;  // Feedback slot 2: records operand types
}
 
// Call 1: V8 records that x=5 (Smi), y=3 (Smi)
compute(5, 3);
// Feedback slot 0: Smi + Smi -> Smi
// Feedback slot 1: Smi * Smi -> Smi
 
// Call 1000: Same types - feedback is stable
for (let i = 0; i < 1000; i++) {
  compute(i, i + 1);
}
// All slots consistently see Smi - TurboFan can optimize
 
// Then this happens:
compute(1.5, 2.7);
// Feedback slot 0 now shows: Smi + Smi -> Smi AND Number + Number -> Number
// IC transitions from monomorphic to polymorphic
 
// PROPERTY ACCESS FEEDBACK
function processUser(user) {
  return user.name.toUpperCase(); // Two feedback slots:
  // Slot A: property 'name' on shape {name, age, email}
  // Slot B: method 'toUpperCase' on String prototype
}
 
// Consistent shapes keep feedback monomorphic
const users = [
  { name: "Alice", age: 30, email: "a@test.com" },
  { name: "Bob", age: 25, email: "b@test.com" },
];
users.forEach(processUser); // Monomorphic: all same shape
 
// Different shape breaks monomorphic feedback
processUser({ name: "Charlie", role: "admin" }); // Different shape
// Slot A is now polymorphic - TurboFan must handle multiple shapes

// TurboFan compiles hot functions to optimized machine code
// using type feedback from Ignition
 
// SPECULATIVE OPTIMIZATION: TurboFan assumes types stay constant
function dotProduct(a, b) {
  let sum = 0;
  for (let i = 0; i < a.length; i++) {
    sum += a[i] * b[i];
  }
  return sum;
}
 
// After enough calls with Float64Arrays, TurboFan generates
// machine code that:
// 1. Skips type checks (assumes Float64Array)
// 2. Uses CPU SIMD instructions for multiplication
// 3. Unrolls the loop partially
// 4. Eliminates bounds checks when safe
 
const vec1 = new Float64Array([1.0, 2.0, 3.0, 4.0]);
const vec2 = new Float64Array([5.0, 6.0, 7.0, 8.0]);
 
// First calls: Ignition interprets, collects feedback
for (let i = 0; i < 1000; i++) {
  dotProduct(vec1, vec2);
}
// TurboFan sees stable types -> compiles optimized version
 
// OPTIMIZATION PIPELINE:
// 1. Build Sea-of-Nodes IR (intermediate representation)
// 2. Type narrowing based on feedback
// 3. Inlining of small functions
// 4. Escape analysis (avoid heap allocation)
// 5. Loop optimizations (unrolling, invariant hoisting)
// 6. Dead code elimination
// 7. Register allocation
// 8. Machine code generation
 
// INLINING: TurboFan copies function bodies into callers
function square(n) {
  return n * n;
}
 
function sumOfSquares(arr) {
  let total = 0;
  for (let i = 0; i < arr.length; i++) {
    total += square(arr[i]); // TurboFan inlines square() here
  }
  return total;
}
// After inlining, the loop body becomes: total += arr[i] * arr[i]
// No function call overhead
 
// ESCAPE ANALYSIS: Avoids unnecessary heap allocation
function createVector(x, y) {
  return { x, y }; // Normally allocates on heap
}
 
function vectorLength(x, y) {
  const v = createVector(x, y); // Escape analysis detects
  return Math.sqrt(v.x * v.x + v.y * v.y); // v never escapes
}
// TurboFan eliminates the object allocation entirely
// Treats v.x and v.y as local variables (scalar replacement)

// When runtime types violate TurboFan's assumptions,
// V8 "deoptimizes" - falls back to Ignition bytecode
 
// DEOPTIMIZATION EXAMPLE
function processItems(items) {
  let sum = 0;
  for (let i = 0; i < items.length; i++) {
    sum += items[i].value; // Optimized for shape {value: Smi}
  }
  return sum;
}
 
// Warm up - TurboFan optimizes for {value: number}
const data = Array.from({ length: 10000 }, (_, i) => ({ value: i }));
processItems(data); // Optimized machine code generated
 
// Trigger deoptimization
data.push({ value: "not a number" }); // String breaks the assumption
processItems(data);
// V8 hits the type guard, triggers "eager deoptimization"
// Steps:
// 1. Discard optimized machine code
// 2. Reconstruct Ignition stack frame from machine state
// 3. Continue execution in interpreter
// 4. Collect new (broader) type feedback
// 5. May re-optimize with polymorphic type handling
 
// COMMON DEOPTIMIZATION TRIGGERS
 
// 1. Type instability
function add(a, b) { return a + b; }
add(1, 2);       // Smi + Smi
add(1.5, 2.5);   // HeapNumber + HeapNumber (deopt if only Smi expected)
 
// 2. Hidden class mismatch
function getName(obj) { return obj.name; }
getName({ name: "A", age: 1 });     // Shape 1
getName({ name: "B", role: "admin" }); // Shape 2 (deopt from monomorphic)
 
// 3. Out-of-bounds array access
function getFirst(arr) { return arr[0]; }
getFirst([1, 2, 3]);  // Packed SMI array
getFirst([]);          // Out of bounds (deopt)
 
// 4. Map/prototype changes
const proto = { greet() { return "hello"; } };
const obj = Object.create(proto);
obj.greet(); // Optimized based on prototype chain
 
// Later, modifying the prototype invalidates optimization
proto.greet = function () { return "hi"; }; // Deopt all dependents
 
// TRACKING DEOPTIMIZATIONS (Node.js)
// Run with: node --trace-deopt script.js
// Output shows:
//   [deoptimizing (DEOPT eager): begin ... ]
//   [deoptimizing: reason: wrong map]
//   [deoptimizing: end ... ]

// V8's Just-In-Time compilation follows a tiered approach
// Each tier trades compilation time for execution speed
 
// TIER 1: Ignition (Interpreter)
// - Compiles AST to bytecode in a single pass
// - Fast startup, slow execution
// - Collects type feedback for higher tiers
 
// TIER 2: Sparkplug (Baseline compiler, V8 v9.1+)
// - Non-optimizing compiler, faster than Ignition
// - Translates bytecode to machine code without optimization
// - Very fast compilation (no IR, no register allocation)
// - 1.5-2x faster than Ignition interpretation
 
// TIER 3: Maglev (Mid-tier compiler, V8 v11.3+)
// - SSA-based IR with simple optimizations
// - Faster compilation than TurboFan
// - Generates code 2-5x faster than Sparkplug
// - Fills the gap between Sparkplug and TurboFan
 
// TIER 4: TurboFan (Optimizing compiler)
// - Full Sea-of-Nodes IR
// - Speculative/adaptive optimization
// - Generates the fastest possible machine code
// - Expensive compilation (done on background thread)
 
// COMPILATION CONCURRENCY
// TurboFan compiles on a background thread while the main
// thread continues executing Ignition bytecode
 
function hotLoop() {
  let sum = 0;
  for (let i = 0; i < 1000000; i++) {
    sum += i;
  }
  return sum;
}
 
// Timeline:
// Main thread: [Ignition executing hotLoop...]
// Background:  [TurboFan compiling hotLoop...]
// Main thread: [Ignition... -> Switch to TurboFan code]
//
// The switch happens via "on-stack replacement" (OSR)
// V8 replaces the Ignition stack frame with a TurboFan frame
// mid-execution (even inside the loop)
 
// OSR COMPILATION
// When V8 detects a long-running loop in Ignition,
// it compiles the function while the loop is still running
// and replaces the interpreter frame with optimized code
 
function searchLargeArray(arr, target) {
  for (let i = 0; i < arr.length; i++) {
    // If this loop runs long enough, V8 triggers OSR
    // It compiles this function in the background
    // Then replaces the current stack frame with optimized code
    // Execution continues from the current loop iteration
    if (arr[i] === target) return i;
  }
  return -1;
}

// These patterns help V8 produce the best possible machine code
 
// 1. STABLE CONSTRUCTORS: Define all properties up front
class User {
  constructor(name, email, age) {
    // Always define all properties in the same order
    this.name = name;
    this.email = email;
    this.age = age;
    this.active = true;    // Even defaults
    this.loginCount = 0;   // Always present
  }
}
 
// 2. AVOID POLYMORPHIC CALL SITES
// BAD: Process accepts different shapes
function processAnything(item) {
  return item.getValue(); // Megamorphic: many different prototypes
}
 
// GOOD: Separate functions for separate types
function processOrder(order) { return order.getValue(); }
function processPayment(payment) { return payment.getValue(); }
 
// 3. KEEP ARRAYS HOMOGENEOUS
// BAD: Mixed types in array
const mixed = [1, "two", { three: 3 }, [4]];
// V8 uses generic PACKED_ELEMENTS mode (slow)
 
// GOOD: Uniform types
const numbers = [1, 2, 3, 4, 5];
// V8 uses PACKED_SMI_ELEMENTS mode (fast)
 
const objects = [
  { id: 1, name: "a" },
  { id: 2, name: "b" },
]; // All same shape
 
// ARRAY ELEMENT KINDS (from fastest to slowest):
// PACKED_SMI_ELEMENTS    -> small integers only
// PACKED_DOUBLE_ELEMENTS -> doubles only
// PACKED_ELEMENTS        -> any type
// HOLEY_SMI_ELEMENTS     -> small integers with holes
// HOLEY_DOUBLE_ELEMENTS  -> doubles with holes
// HOLEY_ELEMENTS         -> any type with holes
// DICTIONARY_ELEMENTS    -> sparse (hash table)
 
// Transitions go one direction: specific -> generic
const arr = [1, 2, 3];     // PACKED_SMI_ELEMENTS
arr.push(4.5);              // PACKED_DOUBLE_ELEMENTS (can't go back)
arr.push("string");         // PACKED_ELEMENTS (can't go back)
 
// 4. PREFER for LOOPS OVER forEach FOR HOT CODE
// V8 can optimize traditional for loops more aggressively
const data = new Float64Array(100000);
 
// GOOD: Traditional loop - fully optimizable
let sum1 = 0;
for (let i = 0; i < data.length; i++) {
  sum1 += data[i];
}
 
// ACCEPTABLE: for-of is well optimized in modern V8
let sum2 = 0;
for (const val of data) {
  sum2 += val;
}