How V8 Works

What is a JavaScript Engine?

A JavaScript engine takes your source code and executes it. Major engines:

All modern engines follow similar architecture, but V8 is the most studied.

V8's Pipeline: Code to Execution

Step 1: Parsing

The parser reads your source text and builds an Abstract Syntax Tree (AST):

const x = 1 + 2;

Becomes roughly:

The parser has two phases:

• Eager parsing — parses code that will run immediately (top-level code)
• Lazy parsing — does a shallow parse of function bodies (avoids parsing unused functions upfront)

Step 2: Ignition — The Interpreter

Ignition compiles the AST to bytecode — a compact, platform-independent instruction set. Then it executes the bytecode directly.

Bytecode is much faster to generate than machine code, which is why startup time is fast. But bytecode is slower to execute than optimized machine code.

Step 3: TurboFan — The JIT Compiler

While Ignition runs, the profiler watches for "hot" functions — those called many times. When a function is hot, TurboFan compiles it to optimized native machine code using a technique called Just-In-Time (JIT) compilation.

This optimized code runs at near-native speed.

Speculative Optimization

TurboFan makes assumptions based on observed types. If add is always called with numbers:

function add(a, b) { return a + b; }
add(1, 2);  // V8 notes: both args are numbers
add(3, 4);
add(5, 6);

TurboFan generates optimized code assuming a and b are always numbers (integer addition is faster than generic addition).

Deoptimization

If an assumption is violated, V8 deoptimizes — throws away the optimized code and falls back to the interpreter:

function add(a, b) { return a + b; }

add(1, 2);      // ✓ number + number
add(3, 4);      // ✓ number + number
add("hello", 5); // ✗ string + number — deoptimization!

Deoptimization is expensive. Consistent types = faster code.

Hidden Classes

V8 tracks the "shape" of objects using hidden classes (similar to compiled class shapes). Objects with the same shape share a hidden class:

// ✓ Efficient — same shape, same hidden class
function makePoint(x, y) {
  const p = {};
  p.x = x;  // shape: {x}
  p.y = y;  // shape: {x, y}
  return p;
}
const p1 = makePoint(1, 2); // hidden class C1
const p2 = makePoint(3, 4); // reuses hidden class C1

// ✗ Inefficient — different property order creates different hidden classes
const a = {};
a.x = 1; a.y = 2; // hidden class: {x, y}

const b = {};
b.y = 1; b.x = 2; // different hidden class: {y, x}!

Inline Caching

V8 uses inline caches (ICs) to speed up property lookups. The first time a property is accessed, V8 looks up the hidden class. Subsequent accesses on objects with the same hidden class are almost free.

function getX(point) {
  return point.x; // IC: "for hidden class C1, x is at offset 0"
}

// Fast (all same hidden class):
getX({ x: 1, y: 2 });
getX({ x: 3, y: 4 });
getX({ x: 5, y: 6 });

eval and with — JIT Killers

Certain constructs prevent optimization:

// ✗ eval creates new scope dynamically — V8 can't optimize the enclosing function
function bad(str) {
  eval(str); // V8 can't know what this will do
  return x + y;
}

// ✗ with statement — prevents scope resolution optimization
with (obj) {
  console.log(name); // is 'name' from obj or outer scope?
}

Both prevent V8 from knowing the scope structure at compile time.

Practical Performance Tips

// ✓ Monomorphic functions — single type per argument
function addNums(a, b) { return a + b; } // always numbers

// ✗ Polymorphic — multiple types deoptimize
function add(a, b) { return a + b; } // sometimes string, sometimes number

// ✓ Consistent object shapes
class Vector {
  constructor(x, y) {
    this.x = x; // always defined in constructor
    this.y = y;
  }
}

// ✗ Dynamic property addition
const v = new Vector(1, 2);
v.z = 3; // changes hidden class!

// ✓ Avoid delete
delete obj.property; // changes hidden class!

V8's Garbage Collector

V8 uses a generational garbage collector:

• Young generation (Nursery) — small, collected frequently using a fast Scavenger
• Old generation — objects that survive young GC, collected with full GC (Mark-Compact)

Most objects die young (short-lived temporaries). Long-lived objects get promoted to old generation.

The GC runs concurrently and incrementally to minimize pauses.

Key Takeaways

• V8 pipeline: Source → AST → Bytecode (Ignition) → Optimized Machine Code (TurboFan)
• JIT optimization is speculative — V8 assumes types based on what it's seen
• Changing types on hot functions causes deoptimization (expensive)
• Keep object shapes consistent — add properties in the same order, always in constructors
• Avoid eval, with, and dynamic property deletion on hot objects
• V8's generational GC is highly optimized for short-lived objects