Under the Hood of JavaScript: How V8, Ignition, and TurboFan Execute Code

1. The Myth of Interpreted JavaScript

For years, computer science textbooks labeled JavaScript as a 'slow, interpreted scripting language'. While that was true in 1995 when Brendan Eich created JS in 10 days for Netscape Navigator, modern JavaScript engines like Google V8 operate closer to C++ compilers than line-by-line interpreters.

When Chrome launched in 2008 powered by Lars Bak's V8 engine, it revolutionized web performance by introducing Just-In-Time (JIT) compilation directly inside the browser process.

Today, V8 does not simply interpret your text files line by line. It compiles JavaScript dynamically into machine code instructions executed directly on your host CPU's hardware registers.

"V8 treats JavaScript dynamically like Python, but optimizes it internally until it executes at speeds approaching native C binary code."

2. The Pipeline: Streaming Parser, AST, and Ignition Bytecode

When your web app loads a JavaScript file over the network, V8 begins executing code before the file has even finished downloading using its scanner and streaming parser:

1. Scanner & Parser: Converted raw UTF-8 text into tokens, building an Abstract Syntax Tree (AST).

2. Ignition Interpreter: AST is fed into Ignition, V8's fast register-based bytecode interpreter. Ignition generates compact bytecode instructions within milliseconds, allowing instantaneous application boot times.

3. Type Feedback Collection: As Ignition executes bytecode, it records runtime type information into a data structure called the Feedback Vector. It notes: 'Function add(a, b) has been called 10,000 times, and a and b have ALWAYS been integers!'

// Monomorphic function: V8 easily optimizes this to 1 CPU assembly instruction
function add(a, b) {
  return a + b;
}

// Ignition collects type feedback: (number, number) -> number
for (let i = 0; i < 100000; i++) {
  add(i, 2); 
}

3. TurboFan: The Hot Code JIT Optimizer

When Ignition notices a function running frequently (a 'hot function'), it passes the bytecode along with its collected Feedback Vector to TurboFan—V8's optimizing JIT compiler.

TurboFan makes bold speculative optimizations. It assumes: 'If add(a, b) was called with numbers 100,000 times, it will probably be numbers next time too.' It strips away all dynamic JS type checks and compiles the function directly into raw machine code (x86-64 or ARM64 assembly).

What happens if you suddenly pass a string add('hello', 5) to your optimized function? TurboFan triggers a Deoptimization ('Deopt'). It instantly discards the optimized machine code, safely rewinds execution back to Ignition bytecode, and continues interpreting safely.

4. Hidden Classes (Maps) and Inline Caching: Why Object Shape Matters

In C++, objects have fixed memory offsets determined at compile time (point.x is always at offset 0, point.y at offset 8). In JavaScript, objects are dynamic hash maps where properties can be added or deleted at runtime.

To achieve near-C++ property access speeds, V8 generates hidden internal classes called 'Maps' (or Shapes):

• When you create { x: 1, y: 2 }, V8 assigns it a Map transition graph.
• If two objects share the exact same property key addition order, they share the exact same hidden Map.
• If you delete a property (delete obj.x) or mutate shapes dynamically, V8 forces a Map split, degrading property access from Inline Cache (IC) hit to slow hash table lookup.

// FAST: Identical hidden class layout (Monomorphic)
class Point {
  constructor(x, y) {
    this.x = x; // Map0 -> Map1 (+x)
    this.y = y; // Map1 -> Map2 (+y)
  }
}
const p1 = new Point(10, 20);
const p2 = new Point(30, 40);

// SLOW: Dynamic property addition breaks Map sharing (Polymorphic/Megamorphic)
const p3 = {};
p3.x = 10;
p3.y = 20;

delete p3.x; // DEOPT BAD PRACTICE: Destroys hidden class optimization!

5. Garbage Collection: Orinoco Scavenger vs. Parallel Mark-Sweep

V8 manages memory using Orinoco, a garbage collector built on the Generational Hypothesis: 'Most objects die young.'

Memory is split into two main spaces:

• New Space (Young Generation): Small buffer (1-8 MB) where new objects are allocated. Cleaned ultra-fast using the Cheney Scavenge algorithm in parallel without freezing the main UI thread.
• Old Space (Tenured Generation): Objects that survive multiple scavenge cycles are promoted to Old Space, managed by a concurrent Mark-Sweep-Compact algorithm.

Writing predictable object shapes and avoiding long-lived global garbage ensures your web application maintains butter-smooth 120 FPS performance.