TurboFan Compiler and JS Optimization Guide

// TurboFan represents code as a Sea-of-Nodes graph
// Unlike traditional compilers that use linear IR (three-address code),
// Sea-of-Nodes eliminates explicit control flow ordering where possible
 
// THREE TYPES OF EDGES IN SEA-OF-NODES:
// 1. Value edges:   Data dependencies (a needs the value of b)
// 2. Control edges: Control flow (branch taken/not-taken)
// 3. Effect edges:  Memory ordering (reads/writes must happen in order)
 
// EXAMPLE: Simple function to graph
function add(a, b) {
  const x = a + 1;
  const y = b * 2;
  return x + y;
}
 
// Sea-of-Nodes graph:
//
//  [Parameter a]  [Constant 1]    [Parameter b]  [Constant 2]
//       |              |               |              |
//       +----value-----+               +----value-----+
//             |                              |
//        [NumberAdd]                    [NumberMultiply]
//             |                              |
//             +------------value-------------+
//                          |
//                     [NumberAdd]
//                          |
//                      [Return]
//
// KEY INSIGHT: x = a+1 and y = b*2 have NO dependency between them
// They can be evaluated in any order, or even in parallel
// The scheduler decides actual placement during code generation
// This freedom enables powerful optimizations
 
// EFFECT CHAIN EXAMPLE
function effectful(arr, i) {
  const len = arr.length;     // Effect: memory read
  arr[i] = 42;                // Effect: memory write
  return len;                 // Value: uses result of first read
}
 
// Graph with effect edges:
//
// [Start] --effect--> [LoadField arr.length] --effect--> [StoreElement arr[i]=42] --effect--> [Return]
//                            |                                                                   |
//                            +-----------------------------value---------------------------------+
//
// Effect edges force memory operations to execute in source order
// Without them, V8 might reorder the store before the load

// TurboFan runs a series of optimization phases on the graph
// Each phase transforms the graph, typically reducing node count
 
// PHASE ORDER (simplified):
//
// 1. Graph Building      - Create Sea-of-Nodes from bytecodes + feedback
// 2. Inlining            - Replace call nodes with callee's graph
// 3. JSTyped Lowering    - Replace JS operations with typed operations
// 4. Simplified Lowering - Replace typed ops with machine-level ops
// 5. Escape Analysis     - Eliminate unnecessary heap allocations
// 6. Loop Peeling        - Extract first iteration of loops
// 7. Load Elimination    - Remove redundant loads from memory
// 8. Dead Code Elim.     - Remove unreachable or unused nodes
// 9. Effect Linearization - Fix effect ordering for code generation
// 10. Branch Elimination  - Remove provably-true/false branches
// 11. Scheduling          - Assign nodes to basic blocks
// 12. Register Allocation - Map virtual registers to CPU registers
// 13. Code Generation     - Emit machine code
 
// EXAMPLE: Typed lowering transforms JS ops to machine ops
function typedLowering(a, b) {
  return a + b; // JS semantics: could be string concat or number add
}
 
// BEFORE typed lowering (feedback says: always numbers):
//   [JSAdd] a, b  (full JS semantics with ToPrimitive, etc.)
//
// AFTER typed lowering:
//   [CheckNumber] a    (guard: a is a number)
//   [CheckNumber] b    (guard: b is a number)
//   [Float64Add] a, b  (raw CPU floating-point addition)
//
// If feedback says always Smi:
//   [CheckSmi] a
//   [CheckSmi] b
//   [Int32Add] a, b    (raw CPU integer addition)
//   [CheckNoOverflow]  (deopt if overflow)
 
// INLINING EXAMPLE
function Vector2D(x, y) { this.x = x; this.y = y; }
Vector2D.prototype.magnitude = function() {
  return Math.sqrt(this.x * this.x + this.y * this.y);
};
 
function totalMagnitude(vectors) {
  let sum = 0;
  for (const v of vectors) {
    sum += v.magnitude(); // Hot call site
  }
  return sum;
}
 
// TurboFan inlines magnitude() into totalMagnitude():
// Before: [Call magnitude, v]
// After:  [LoadField v.x]
//         [Float64Mul x, x]
//         [LoadField v.y]
//         [Float64Mul y, y]
//         [Float64Add xx, yy]
//         [Float64Sqrt sum]
//
// Benefits: No call overhead, enables further optimizations
// (e.g., x*x + y*y might use FMA instructions on some CPUs)

// Escape analysis determines if an object can be "scalar replaced"
// (stored in registers instead of heap-allocated)
 
// AN OBJECT "ESCAPES" IF:
// 1. It's stored in a global/outer variable
// 2. It's passed to a non-inlined function
// 3. It's returned from the function
// 4. It's stored in an array or another object that escapes
 
function escapeAnalysisDemo() {
  // Case 1: Object does NOT escape
  function distanceNotEscaping(x1, y1, x2, y2) {
    const diff = { dx: x2 - x1, dy: y2 - y1 }; // Allocated on heap?
    return Math.sqrt(diff.dx * diff.dx + diff.dy * diff.dy);
  }
  // TurboFan sees that 'diff' never escapes this function
  // It "scalar replaces" the object:
  //   const dx = x2 - x1;  // Just a register value
  //   const dy = y2 - y1;  // Just a register value
  //   return Math.sqrt(dx * dx + dy * dy);
  // No heap allocation occurs at all
 
  // Case 2: Object DOES escape
  function createPoint(x, y) {
    return { x, y }; // Object is returned, so it escapes
  }
  // TurboFan MUST allocate on the heap because the caller
  // receives a reference to the object
 
  // Case 3: Object escapes due to non-inlined call
  function processWithExternalCall(x, y) {
    const point = { x, y };
    externalFunction(point); // Not inlined -> point escapes
    return point.x + point.y;
  }
  // If externalFunction is inlined, TurboFan can re-analyze
  // and potentially scalar-replace point
 
  // Case 4: Partial escape analysis
  function conditionalEscape(x, y, shouldStore) {
    const point = { x, y };
    if (shouldStore) {
      globalStore.push(point); // Escapes on this path
    }
    return point.x + point.y;
  }
  // TurboFan can "dematerialize" point on the non-escaping path
  // and only allocate it when shouldStore is true
}
 
// ESCAPE ANALYSIS IMPACT ON PERFORMANCE
// Before EA: Each function call allocates a temporary object
//   function compute(items) {
//     for (const item of items) {
//       const result = { sum: 0, count: 0 };  // HEAP ALLOC per iteration
//       result.sum = item.a + item.b;
//       result.count = 1;
//       total += result.sum / result.count;
//     }
//   }
//
// After EA: No allocation
//   function compute_optimized(items) {
//     for (const item of items) {
//       const sum = item.a + item.b;  // register
//       const count = 1;              // register
//       total += sum / count;
//     }
//   }

// TurboFan applies several loop optimizations
 
// LOOP-INVARIANT CODE MOTION (LICM)
function licmExample(arr, config) {
  const results = [];
  for (let i = 0; i < arr.length; i++) {
    // config.multiplier does not change inside the loop
    // TurboFan moves this load ABOVE the loop
    results.push(arr[i] * config.multiplier);
  }
  return results;
}
 
// Optimized by TurboFan:
//   const multiplier = config.multiplier;  // Hoisted
//   const length = arr.length;             // Hoisted
//   for (let i = 0; i < length; i++) {
//     results.push(arr[i] * multiplier);
//   }
 
// LOOP PEELING
// Extracts the first iteration to simplify type guards
function loopPeeling(arr) {
  let sum = 0;
  for (let i = 0; i < arr.length; i++) {
    sum += arr[i]; // Guard: arr[i] is Smi
  }
  return sum;
}
 
// After peeling:
//   if (arr.length > 0) {
//     sum += arr[0];  // Type guard here (first iteration)
//     for (let i = 1; i < arr.length; i++) {
//       sum += arr[i]; // Guard eliminated (proven by peeled iteration)
//     }
//   }
 
// BOUNDS CHECK ELIMINATION
function boundsCheckElimination(arr) {
  let sum = 0;
  for (let i = 0; i < arr.length; i++) {
    // Without optimization: bounds check (0 <= i < arr.length) at each access
    // TurboFan proves: i starts at 0, increments by 1, exits at arr.length
    // Therefore: i is always in bounds. Remove the check.
    sum += arr[i];
  }
  return sum;
}
 
// When bounds checks CANNOT be eliminated:
function cannotEliminate(arr, indices) {
  let sum = 0;
  for (const idx of indices) {
    // idx comes from external input: cannot prove in-bounds
    // Bounds check is kept, but moved to a CheckBounds node
    sum += arr[idx];
  }
  return sum;
}

// After optimization, TurboFan must schedule nodes into a linear order
// and assign CPU registers
 
// SCHEDULING
// The scheduler places each node in a basic block, respecting:
// 1. Data dependencies (producer before consumer)
// 2. Effect dependencies (memory order)
// 3. Control dependencies (branch targets)
// 4. Schedule early / schedule late heuristics
 
// "SCHEDULE LATE" - Place computations as late as possible
// This reduces register pressure (values live for shorter time)
function scheduleLate(a, b, cond) {
  const expensive = a * a + b * b; // Compute sqrt only if needed
  if (cond) {
    return Math.sqrt(expensive);
  }
  return 0;
}
 
// Schedule-late moves the multiply/add into the true branch:
//   if (cond) {
//     const expensive = a * a + b * b;  // Only computed when needed
//     return Math.sqrt(expensive);
//   }
//   return 0;
 
// REGISTER ALLOCATION
// TurboFan uses a linear scan register allocator
// (similar to what the Go compiler uses)
//
// PROCESS:
// 1. Compute live ranges for each virtual register
// 2. Sort ranges by start position
// 3. Scan through, assigning CPU registers
// 4. When no register is available, "spill" to stack
//
// EXAMPLE:
// function registers(a, b, c, d) {
//   const x = a + b;    // x lives from here...
//   const y = c + d;    // y lives from here...
//   const z = x * y;    //              ...to here
//   return z;
// }
//
// x86-64 assignment (8 general purpose registers):
//   rax = a + b (x)
//   rbx = c + d (y)
//   rax = rax * rbx (z)  // Reuse rax since x is dead after this
//   return rax
//
// If we had more live values than registers, some would be
// "spilled" to the stack (saved to memory, reloaded when needed)
 
// REGISTER ALLOCATION FRIENDLY CODE
// Fewer live variables at any point = better register usage
 
// BAD: Many live variables
function manyLiveVars(data) {
  const a = data.field1;
  const b = data.field2;
  const c = data.field3;
  const d = data.field4;
  const e = data.field5;
  const f = data.field6;
  // All 6 values live simultaneously
  return a + b + c + d + e + f;
}
 
// BETTER: Partial sums reduce live variables
function fewerLiveVars(data) {
  let sum = data.field1 + data.field2; // Only sum is live
  sum += data.field3 + data.field4;    // Still just sum
  sum += data.field5 + data.field6;    // Still just sum
  return sum;
}

// PATTERN 1: Monomorphic operations (one shape)
// GOOD - always same object shape
class Point {
  constructor(x, y) {
    this.x = x; // Always in this order
    this.y = y; // Same hidden class every time
  }
}
 
// BAD - conditional properties create multiple shapes
function makePoint(x, y, z) {
  const p = { x, y };
  if (z !== undefined) p.z = z; // Different hidden class
  return p;
}
 
// PATTERN 2: Avoid megamorphic property access
// GOOD - consistent object shapes at each call site
function processUser(user) {
  return user.name + " " + user.email;
}
// Always call with same-shaped objects
 
// BAD - many different shapes at one call site
function processAnything(obj) {
  return obj.name; // Could be User, Company, Product...
  // Megamorphic IC = slow hash table lookup
}
 
// PATTERN 3: Typed arrays for numeric work
// GOOD - elements kind remains PACKED_DOUBLE_ELEMENTS
const numbers = new Float64Array(1000);
for (let i = 0; i < 1000; i++) {
  numbers[i] = Math.random();
}
 
// BAD - generic array can change elements kind
const mixed = [];
for (let i = 0; i < 1000; i++) {
  mixed.push(Math.random());
  mixed.push("string"); // Transitions to PACKED_ELEMENTS
}
 
// PATTERN 4: Prefer for loops over complex iterators
// GOOD - simple counted loop, easy to optimize
function sumArray(arr) {
  let sum = 0;
  for (let i = 0; i < arr.length; i++) {
    sum += arr[i];
  }
  return sum;
}
 
// LESS OPTIMAL - iterator protocol adds overhead
function sumWithReduce(arr) {
  return arr.reduce((sum, val) => sum + val, 0);
  // Callback creates a closure, harder to inline
  // TurboFan CAN optimize this, but it's more work
}