node_06 - The V8 Engine¶

V8 is the C++ engine that makes JavaScript fast enough to run servers
Before V8 , JavaScript was interpreted (slow) and nobody considered it a serious language for backend development. Then Google built V8 for Chrome in 2008 , introduced JIT compilation to JavaScript , and suddenly JS ran as fast as Java. Ryan Dahl grabbed V8 , wrapped it in libuv , and Node was born. Every Node process has V8 embedded - it's the brain. Understanding V8 means understanding how your code executes (or doesn't)

what V8 is¶

V8 is Google's open-source JavaScript engine , written in C++ , that compiles JavaScript to native machine code. It's embedded in Chrome , Node.js , Deno , Electron , and various other runtimes. It does NOT include DOM APIs , browser APIs , or any I/O capabilities - those are provided by the host environment

V8's job: 1. Parse JavaScript source code into an Abstract Syntax Tree (AST) 2. Compile it to bytecode (Ignition interpreter) 3. Profile execution and optimize hot paths (TurboFan compiler) 4. Manage memory with garbage collection (Orinoco) 5. Keep everything fast enough that you don't notice any of this happening

parsing and compilation pipeline¶

// Your source code
function add(a , b) {
  return a + b
}

// 1. Scanner - tokenizes the source into tokens
// 'function', 'add', '(', 'a', ',', 'b', ')', '{', 'return', 'a', '+', 'b', ';', '}'

// 2. Parser - builds AST from tokens
// FunctionDeclaration -> id , params , body

flowchart TD
    FD["FunctionDeclaration"] --> ID["id: Identifier('add')"]
    FD --> P["params"]
    P --> IA["Identifier('a')"]
    P --> IB["Identifier('b')"]
    FD --> RS["body: ReturnStatement"]
    RS --> BE["BinaryExpression(+)"]
    BE --> EXA["Identifier('a')"]
    BE --> EXB["Identifier('b')"]

// 3. Ignition - generates bytecode from AST
// Ldar a1        // Load accumulator with a
// Add a2         // Add b to accumulator
// Return         // Return accumulator

// 4. TurboFan - optimizes hot functions to machine code
// mov eax, [rdi+0x8]    // Load a from object
// add eax, [rsi+0x8]    // Add b
// ret                    // Return

The key insight: V8 starts executing bytecode immediately (no waiting for optimization) while TurboFan profiles and optimizes in the background. This means cold code runs slower than hot code - a property that affects both performance and security

JIT compilation - speed at a cost¶

The Just-In-Time compiler (TurboFan) observes how your code runs and makes assumptions to optimize. If your add(a , b) function is always called with numbers , TurboFan generates optimized machine code assuming both arguments are numbers. If someone later calls add('hello' , 5) , V8 deoptimizes back to bytecode and recompiles with the new type information

// This gets HOT - called thousands of times with numbers
function sumArray(arr) {
  let total = 0
  for (let i = 0; i < arr.length; i++) {
    total += arr[i]  // TurboFan assumes this is always number + number
  }
  return total
}

// Called 1000 times with [1, 2, 3] - TurboFan optimizes
// Then called with ['a', 'b', 'c'] - full deoptimization
// The deoptimization costs more than the original optimization saved

This is why type stability matters. V8 optimizes based on observed types. If your function parameters change types unpredictably , V8's optimizations break down and performance degrades to interpreted levels

memory management - the Orinoco garbage collector¶

V8 uses a generational garbage collector. The heap is divided into two spaces:

Young space (new-space) - where new objects are allocated. Small (1-8 MB default) and collected frequently. Objects that survive two GC cycles get promoted to old space

Old space (old-space) - where long-lived objects live. Collected less frequently using mark-sweep and mark-compact algorithms

// Objects in the young generation
function processRequest() {
  const data = { timestamp: Date.now() , userId: 'abc' }
  // data is allocated in young space
  // After this function returns, data is unreachable
  // Next young GC will collect it
  return data.userId
}

// Objects that survive stay in the old generation
const cache = new Map()
function addToCache(key , value) {
  cache.set(key , value)  // cache lives in old space
  // Survives multiple GC cycles
  // Only collected during major GC (mark-sweep)
}

Memory leaks happen when references to objects persist unintentionally. A Map that grows unbounded , event listeners that are never removed , closures that capture large objects - these keep references alive and prevent garbage collection

// Memory leak - the Map grows forever
const requestCache = new Map()

app.get('/api/data' , (req , res) => {
  const result = expensiveOperation()
  requestCache.set(req.ip , result)  // Never cleaned up
  // Every unique IP adds an entry that lives FOREVER
  // Eventually: process runs out of memory, crashes
  res.json(result)
})

// Fix - use a TTL cache or limit the size
const LRU = require('lru-cache')
const cache = new LRU({ max: 500 , ttl: 1000 * 60 * 5 })

hidden classes and inline caching¶

V8 optimizes property access by creating hidden classes (maps) for objects with the same property layout:

function Point(x , y) {
  this.x = x  // Creates hidden class C0
  this.y = y  // Transitions to hidden class C1
}

// Both objects share the same hidden class
const p1 = new Point(1 , 2)  // Hidden class: C0 -> C1
const p2 = new Point(3 , 4)  // Hidden class: C0 -> C1

// Accessing p1.x is optimized - V8 knows the property offset
// Because p1 and p2 share the same hidden class

// BREAKING the hidden class:
p2.z = 5  // Now p2 has a different hidden class than p1
// V8 can no longer optimize access to these objects uniformly

Adding properties to objects outside the constructor forces V8 to create new hidden class transitions. This is why TypeScript interfaces and consistent object shapes matter for performance - V8 optimizes predictability

V8 security - why it matters¶

V8 is a massive C++ codebase that processes attacker-controlled input (JavaScript). That's a recipe for CVEs. V8 vulnerabilities (type confusion , out-of-bounds access , JIT bugs) are the most common Chrome exploits and they affect Node too

# Disable JIT to mitigate JIT-related vulnerabilities
# This prevents JIT spraying and type confusion exploits
node --jitless app.js

# Limits V8 heap size - prevents OOM exhaustion
node --max-old-space-size=512 app.js  # limit to 512MB
# If your app leaks memory , it crashes at 512MB instead of
# consuming all system memory and triggering the OOM killer

JIT spraying - attackers craft JavaScript that , when JIT-compiled , produces machine code that can be executed as shellcode. Disabling JIT (--jitless) prevents this entirely at the cost of performance

Out-of-memory attacks - attackers send requests that trigger excessive object allocation (JSON bombs , deeply nested objects). V8's GC can't keep up and the process OOMs. Setting --max-old-space-size limits the damage

V8 flags for debugging¶

# Trace GC activity
node --trace-gc app.js

# Print optimized code
node --print-opt-code app.js

# Trace deoptimizations
node --trace-deopt app.js

# Print bytecode
node --print-bytecode app.js

# Get V8 version
node -e "console.log(process.versions.v8)"

These are for debugging , not production. Running with --trace-gc in production will flood your logs and degrade performance

prerequisites¶

node_05 - Node.js Command Line

next -> node_07_architecture.md