JavaScript JIT Compilation Advanced Tutorial

// V8's compilation tiers (as of 2024+):
//
// Tier 0: IGNITION (Interpreter)
//   - Compiles source to bytecode (~1ms per function)
//   - Executes via dispatch loop
//   - Collects type feedback in feedback vectors
//
// Tier 1: SPARKPLUG (Baseline Compiler) [optional]
//   - Non-optimizing compiler
//   - Generates machine code directly from bytecodes
//   - 1-to-1 mapping: each bytecode -> fixed machine code sequence
//   - ~10x faster compilation than TurboFan
//   - ~2x faster execution than Ignition
//   - No speculative optimizations (safe, never deoptimizes)
//
// Tier 2: MAGLEV (Mid-tier Compiler) [optional]
//   - SSA-based IR (Static Single Assignment)
//   - Uses feedback vector for speculative type guards
//   - Simpler optimization passes than TurboFan
//   - ~5x faster execution than Sparkplug
//
// Tier 3: TURBOFAN (Optimizing Compiler)
//   - Sea-of-Nodes IR with full optimization suite
//   - Maximum optimization: inlining, escape analysis, etc.
//   - ~10-100x faster execution than Ignition
 
// Promotion through tiers:
function processItems(items) {
  let total = 0;
  for (const item of items) {
    total += item.value * item.weight;
  }
  return total;
}
 
// Timeline:
// Call 1:     Ignition interprets bytecode
//             Feedback: item.value = Smi, item.weight = Smi
// Call ~10:   Sparkplug generates baseline machine code
//             No speculation, just faster dispatch
// Call ~100:  Maglev generates mid-tier code
//             Speculates on Smi types, inserts type guards
// Call ~1000: TurboFan generates fully optimized code
//             Inlines property access, removes bounds checks
//             Generates CPU-specific SIMD instructions

// TurboFan optimizes based on assumptions drawn from runtime feedback
// If assumptions are wrong, it "deoptimizes" back to interpreted code
 
// SPECULATIVE TYPE SPECIALIZATION
function multiply(a, b) {
  return a * b;
}
 
// If Ignition always sees multiply(int, int):
//   TurboFan generates integer multiplication (imul instruction)
//   No boxing, no type checks in the hot path
//   A single type guard at function entry verifies the assumption
 
// TurboFan's speculative pipeline:
//
// 1. Read feedback vector for each bytecode operation
// 2. For each operation, insert:
//    a. A type guard (check the assumption)
//    b. The specialized operation (e.g., integer multiply)
//    c. A deopt point (what to do if guard fails)
// 3. Later optimization passes may remove redundant guards
 
// EXAMPLE: How speculation works
function sumArray(arr) {
  let sum = 0;
  for (let i = 0; i < arr.length; i++) {
    sum += arr[i]; // Feedback says: Smi + Smi -> Smi
  }
  return sum;
}
 
// TurboFan-optimized pseudocode:
//
// function sumArray_optimized(arr) {
//   // Guard: arr is a JSArray
//   if (!isJSArray(arr)) DEOPT("not an array");
//   // Guard: arr has PACKED_SMI_ELEMENTS
//   if (arr.elementsKind !== PACKED_SMI_ELEMENTS) DEOPT("wrong elements");
//
//   let sum = 0;  // Unboxed integer
//   const len = arr.length;  // Direct field read (no IC lookup)
//
//   for (let i = 0; i < len; i++) {
//     // Direct memory read (no bounds check if proven safe)
//     const element = arr.elements[i];
//     // Unboxed integer add (no overflow check if range proven)
//     sum = sum + element;
//   }
//   return sum;  // Box result for return
// }

// When a speculation fails, V8 "deoptimizes": replaces the optimized
// frame with an interpreter frame and continues in Ignition
 
function deoptExample(input) {
  return input.x + input.y;
}
 
// Call pattern:
// Calls 1-1000:  deoptExample({ x: 1, y: 2 })
//   -> TurboFan optimizes for objects with shape { x: Smi, y: Smi }
//
// Call 1001:     deoptExample({ x: "hello", y: "world" })
//   -> Type guard fails: x is not Smi
//   -> DEOPTIMIZATION triggered
//   -> V8 reconstructs Ignition stack frame
//   -> Ignition continues from the deopt point
//   -> Feedback vector updated with new type info
//
// Later:         V8 may re-optimize with a wider type assumption
//                (e.g., x can be Smi OR String)
 
// DEOPTIMIZATION REASONS (common ones)
const deoptReasons = {
  wrongMap:          "Object shape (hidden class) changed",
  wrongType:         "Operand type does not match speculation",
  smiOverflow:       "Integer result exceeded Smi range",
  outOfBounds:       "Array index exceeded bounds check",
  divisionByZero:    "Divisor was zero in optimized int division",
  wrongCallTarget:   "Inlined function was replaced",
  changedPrototype:  "Prototype chain was modified",
  insufficientFeedback: "Not enough type information to speculate",
  osrOffset:         "On-Stack Replacement at unexpected offset"
};
 
// TRACKING DEOPTS
// Run with: node --trace-deopt script.js
//
// Output format:
// [deoptimizing (DEOPT eager): begin ...]
// [deoptimize: reason = wrong map, at bytecode offset 12]
//
// DEOPT TYPES:
// - Eager: Guard check fails (type guard, map check)
// - Lazy:  External change invalidated assumptions (prototype modified)
// - Soft:  V8 decides code is not worth keeping optimized
 
// DEOPT LOOPS (pathological case)
// If a function repeatedly deopts, V8 may stop optimizing it entirely
function deoptLoop(arr) {
  let sum = 0;
  for (const item of arr) {
    // If arr alternates between [1,2,3] and ["a","b","c"]
    // V8 will optimize, deopt, re-optimize, deopt...
    // After a threshold, V8 marks this function as "don't optimize"
    sum += item;
  }
  return sum;
}
 
// HOW TO AVOID DEOPTS:
// 1. Keep types consistent (always pass same shapes)
// 2. Initialize all object properties in constructor
// 3. Don't change __proto__ after creation
// 4. Don't delete properties from objects
// 5. Don't mix element types in arrays

// OSR replaces an Ignition frame with a TurboFan frame mid-execution
// This is critical for long-running loops in cold functions
 
function computeOnce() {
  // This function is called only once, so call-count thresholds
  // would never trigger TurboFan. But the inner loop is hot.
 
  let result = 0;
  for (let i = 0; i < 100_000_000; i++) {
    result += Math.sqrt(i) * Math.sin(i);
    // Back-edge counter incremented each iteration
    // After ~10,000 iterations, V8 triggers OSR compilation
 
    // OSR entry point is at the JumpLoop bytecode (loop back-edge)
    // TurboFan compiles the function from that specific bytecode offset
    // V8 copies register values from the Ignition frame to the
    // TurboFan frame and continues in optimized code
  }
  return result;
}
 
// OSR CONSIDERATIONS:
//
// 1. OSR code is specific to the entry offset
//    - It can only be entered at the OSR entry point
//    - Normal calls still use Ignition until regular optimization
//
// 2. Register mapping must be exact
//    - Ignition registers -> TurboFan virtual registers
//    - Values are live at the OSR entry point
//    - TurboFan generates code that starts with these values
//
// 3. OSR code may be less optimal than regular TurboFan code
//    - Cannot optimize the function prologue
//    - Loop-independent code above the loop is not optimized
//    - V8 may later compile a fully optimized version
 
// OSR TIMELINE:
// Iteration 0:        Enter loop in Ignition
// Iteration 10,000:   OSR threshold reached
//                     V8 starts TurboFan compilation (background)
//                     Ignition continues interpreting
// Iteration ~12,000:  TurboFan compilation complete
//                     V8 replaces stack frame at next JumpLoop
//                     Execution continues in TurboFan code
// Iteration 100M:     Loop ends, return result

// TurboFan compiles on background threads to avoid blocking the main thread
 
// COMPILATION PIPELINE:
//
// Main Thread:
//   1. Detect hot function (ticks threshold)
//   2. Create CompilationJob with bytecodes + feedback vector
//   3. Post job to background compiler thread
//   4. Continue executing Ignition/Sparkplug code
//   ... (later, when compilation finishes) ...
//   5. Install optimized code on the function
//   6. Next call uses optimized code
//
// Background Thread:
//   1. Receive CompilationJob
//   2. Build TurboFan graph (Sea-of-Nodes IR)
//   3. Run optimization passes (inlining, DCE, etc.)
//   4. Generate machine code
//   5. Signal main thread that code is ready
 
// CONCURRENT DATA ACCESS
// Feedback is read by the background thread but written by the main thread
// V8 handles this with:
// - Atomic reads of feedback slots
// - Snapshot-based approach (feedback is stable during compilation)
// - If feedback changes, optimized code may deopt on first run
 
// EXAMPLE: Background compilation with node --trace-turbo
class DataProcessor {
  #buffer = [];
 
  process(item) {
    const normalized = this.#normalize(item);
    this.#buffer.push(normalized);
    if (this.#buffer.length > 1000) {
      this.#flush();
    }
  }
 
  #normalize(item) {
    return {
      id: item.id | 0,           // Force integer
      value: +item.value,         // Force number
      label: String(item.label)   // Force string
    };
  }
 
  #flush() {
    const batch = this.#buffer.splice(0);
    // ... process batch ...
    return batch.length;
  }
}
 
// Call process() 10,000 times:
// - process() hits threshold first -> compiled by TurboFan
// - normalize() is inlined into process() -> no separate compilation
// - flush() called <10 times -> stays in Ignition (cold function)
 
// FLAGS FOR DEBUGGING:
// --trace-turbo-graph    Print TurboFan graph at each phase
// --trace-turbo-inlining Show inlining decisions
// --trace-turbo-reduction Show optimization passes
// --turbo-stats          Print compilation timing statistics

// V8 FLAGS for JIT profiling:
//
// node --print-opt-code script.js       # Print optimized code
// node --trace-opt script.js            # Log optimization events
// node --trace-deopt script.js          # Log deoptimizations
// node --trace-ic script.js             # Log inline cache events
// node --trace-turbo script.js          # Dump TurboFan graph files
 
// PROGRAMMATIC DETECTION (using V8 native syntax)
// Only available with --allow-natives-syntax
 
// %OptimizeFunctionOnNextCall(fn) - Force optimization
// %DeoptimizeFunction(fn) - Force deoptimization
// %GetOptimizationStatus(fn) - Check optimization state
// %NeverOptimizeFunction(fn) - Prevent optimization
 
// PRACTICAL PROFILING: Use Chrome DevTools or node --prof
 
// Example: Benchmarking with stable optimization
function benchmark(fn, iterations) {
  // Warm up: ensure function is optimized
  for (let i = 0; i < 10000; i++) {
    fn(i);
  }
 
  // Measure: optimized code is running
  const start = performance.now();
  for (let i = 0; i < iterations; i++) {
    fn(i);
  }
  const end = performance.now();
 
  return {
    iterations,
    totalMs: end - start,
    avgNs: ((end - start) / iterations) * 1_000_000
  };
}
 
// PATTERNS THAT PREVENT OPTIMIZATION
// (Some historical; V8 improves over time)
 
// 1. Arguments leaking
function leaksArguments() {
  const args = arguments; // Prevents optimization of arguments
  return args[0];
}
 
// 2. Eval or with statements
function usesEval(code) {
  return eval(code); // Makes variable lookup dynamic
}
 
// 3. For-in on non-simple objects
function complexForIn(obj) {
  const result = [];
  for (const key in obj) { // If obj has prototype chain props
    result.push(key);
  }
  return result;
}
 
// 4. try-catch in hot loops (mostly fixed in modern V8)
function tryCatchLoop(arr) {
  let sum = 0;
  for (let i = 0; i < arr.length; i++) {
    try {
      sum += arr[i];
    } catch (e) {
      // Historically prevented loop optimization
      // Modern V8 handles this correctly
    }
  }
  return sum;
}