Deep dive into the V8 JS Engine

Node.js architecture — the big picture

Before diving into V8’s internals, let’s recall the high-level architecture of Node.js:

The big picture — what sits inside Node.js

┌──────────────────────── NODE.JS RUNTIME ────────────────────────┐
│                                                                 │
│  ┌── V8 JS ENGINE (Google) ──┐     ┌── LIBUV (C Library) ──┐    │
│  │ Parsing → Ignition →      │     │ Event Loop · Thread    │    │
│  │ TurboFan                  │ →→  │ Pool                   │    │
│  │ Call Stack · Memory Heap  │     │ Async I/O · Timers ·   │    │
│  │ · GC                      │     │ OS access              │    │
│  │ Executes JavaScript code  │     │ Handles async ops      │    │
│  └───────────────────────────┘     └────────────────────────┘    │
│                                                                 │
│  ┌─── fs ───┐ ┌── http/https ──┐ ┌── crypto ──┐ ┌── zlib, os, path… ──┐ │
│  │file sys. │ │  networking    │ │ encryption │ │ other core modules  │ │
│  └──────────┘ └────────────────┘ └────────────┘ └─────────────────────┘ │
│                                                                 │
│   Core modules bridge JS code to C++ bindings → libuv → OS      │
└─────────────────────────────────────────────────────────────────┘

The complete V8 pipeline — how code becomes execution

This is the most important diagram to remember. It shows every component inside V8 and how they connect.

                    📄 YOUR SOURCE CODE (.js)
                   var a = 10; function sum(x,y){...}
                                │
                                ▼
              ┌─────────── A. PARSING ────────────┐
              │ ① Lexical Analysis  →  ② Syntax   │
              │  (Code → Tokens)       Analysis   │
              │                       (Tokens →   │
              │                        AST)       │
              └────────────────────┬──────────────┘
                                   │ ↓ AST
                                   ▼
  ┌─── GARBAGE ───┐   ┌──── B. IGNITION ────┐  HOT code   ┌──── C. TURBOFAN ────┐
  │  COLLECTOR    │   │   Interpreter       │ ──────────► │ Optimizing Compiler │
  │ (Mark &       │   │  AST → Bytecode     │             │ Makes type          │
  │  Sweep)       │   │  (line by line)     │ ◄────────── │ assumptions         │
  │               │   └──────────┬──────────┘ deoptimize  └──────────┬──────────┘
  │ · Orinoco     │              │            (assumptions            │
  │ · Oil Pan     │              ▼            wrong)                  ▼
  │ · Scavenger   │         BYTECODE                           OPTIMIZED
  │ · MCompact    │         (intermediate)                     MACHINE CODE
  │               │              │                                   │
  │ Runs through  │              └───────────────┬───────────────────┘
  │ the entire    │                              ▼
  │ pipeline      │                       D. EXECUTION
  │ behind the    │                    (Your code runs on
  │ scenes        │                         the CPU)
  └───────────────┘
 
  OPTIMIZATIONS: · Inline Caching · Copy Elision · Hidden Classes

Stage A: Parsing — from code to tokens to AST

When JavaScript code enters V8, the very first thing that happens is parsing. Parsing has two sub-stages: Lexical Analysis (Tokenization) and Syntax Analysis (AST generation).

For example, take this simple line of code:

var a = 10;

V8’s lexer scans this character by character and produces these tokens:

• var — keyword
• a — identifier
• = — operator
• 10 — literal
• ; — punctuation

JavaScript Code: var a = 10;
    ↓
Tokens: [ 'var', 'a', '=', '10', ';' ]

Why tokenization? It helps V8 read and understand the code by breaking it into smaller, structured pieces. Without tokenization, V8 would be staring at a wall of characters with no idea where one keyword ends and another begins. This step is crucial for the next stage — building the tree.

For var a = 10;, the AST looks like this:

VariableDeclaration
├── Identifier (a)
└── Literal (10)

Each node in the tree corresponds to a construct in the code: VariableDeclaration represents the statement, Identifier is the variable name a, and Literal is the value 10.

For more complex code like this:

var name = "Node JS";
function sayNamaste() {
  console.log("Namaste World");
}

The AST becomes a much larger tree with a Program root node containing a VariableDeclaration node and a FunctionDeclaration node, which itself contains an Identifier (sayNamaste), params (empty array), and a BlockStatement body with an ExpressionStatement inside it.

Stage B: Interpreted vs compiled — and why JS is both

Before understanding V8’s execution pipeline, you need to know the two fundamental types of programming languages:

The V8 execution pipeline — Ignition + TurboFan

This is the core of Episode 08. The whiteboard diagrams on PDF pages 2-3 show the complete V8 pipeline. Here it is as a flow:

• Source code (your .js file). Raw JavaScript text enters V8.

• A. Parsing. Lexical Analysis: Code → Tokens (tokenization). Syntax Analysis: Tokens → AST (Abstract Syntax Tree).

• B. Ignition (Interpreter). Converts AST → Bytecode (intermediate representation, lower-level than source code but not yet machine code). Ignition then executes this bytecode line by line — this gives you fast initial startup.

  ↘ While executing, Ignition monitors “hot” code — functions that are called repeatedly. When code is hot enough, it’s sent to TurboFan for optimization.

• C. TurboFan (Optimizing Compiler). Takes the hot bytecode and compiles it into optimized machine code — native CPU instructions. TurboFan makes assumptions about types (e.g., “this function always receives numbers”) and generates highly efficient code based on those assumptions.

  ↙ If assumptions are wrong (e.g., function was optimized for numbers but receives a string), TurboFan deoptimizes — the code is reverted back to Ignition bytecode for re-interpretation and possible re-optimization.

• D. Execution. Both bytecode (from Ignition) and optimized machine code (from TurboFan) feed into the execution stage. Your code runs.

Optimization techniques — inline caching & copy elision

V8 uses several clever optimization techniques during bytecode execution and TurboFan compilation:

Inline caching. Speeds up property access by caching the results of lookups. When you access obj.name, V8 remembers where name was found in the object’s hidden class. Next time, it skips the lookup and goes directly to the cached location. This makes repeated property access on same-shaped objects extremely fast.

Copy elision. An optimization that eliminates unnecessary copying of objects. When a function returns an object, instead of creating the object inside the function and then copying it to the caller, V8 can construct it directly in the caller’s memory — avoiding the copy entirely.

Garbage collection — memory cleanup behind the scenes

The whiteboard diagrams on PDF page 3 show that Garbage Collection runs throughout the entire V8 pipeline — alongside parsing, interpretation, and compilation. It uses the Mark and Sweep algorithm as its foundation.

V8’s garbage collector has several specialized sub-systems:

Other JS engines — V8 isn’t the only one

The PDF notes that all these processes (parsing, interpreting, compiling, GC) work differently in each JavaScript engine, but V8 is considered the best on the market. Here’s how other engines name their components:

The architecture is the same concept everywhere: parse → interpret → optimize hot code → deoptimize when assumptions fail. The names change, the core idea doesn’t.

Episode 08 — at a glance