V8 Internals — Hidden Classes, Inline Caches, and GC Optimisation

The V8 JavaScript engine compiles JavaScript to machine code using an optimising JIT compiler. The quality of that machine code — and how fast your application runs — depends on patterns in your code that V8 can and cannot optimise. Understanding hidden classes, inline caches, deoptimisation triggers, and the garbage collector’s behaviour allows you to write JavaScript that V8 compiles to near-native speed rather than interpreted fallback paths. This is not micro-optimisation folklore — these patterns have measurable impact on hot code paths in production Node.js servers.

V8 Optimisation Concepts #

Complete V8 Optimisation Examples #

// ── Hidden classes — always initialise in the same order ──────────────────

// ❌ Creates two different hidden classes — polymorphic, harder to optimise
function createTaskBad(title, withDueDate) {
    const task = { title };
    if (withDueDate) {
        task.dueDate = new Date();  // added conditionally — different shape!
    }
    task.status = 'pending';
    return task;
}

// ✅ All tasks have the same hidden class — monomorphic, fast
function createTask(title, dueDate = null) {
    return {
        title,        // always present
        dueDate,      // always present (null if absent)
        status: 'pending',
        priority: 'medium',
    };
}

// ── Avoid delete — use null instead ──────────────────────────────────────
const task = createTask('Write tests');

// ❌ Degrades to dictionary mode
delete task.dueDate;

// ✅ Preserves hidden class
task.dueDate = null;

// ── Typed arrays for numeric data — much faster than JS arrays ────────────
// For operations on large numeric datasets (coordinates, timestamps, scores):

// ❌ Regular JS array — each element is a heap-allocated boxed double
const timestamps = new Array(100000).fill(Date.now());

// ✅ Float64Array — dense, unboxed, CPU-cacheable
const timestampsTyped = new Float64Array(100000);
for (let i = 0; i < 100000; i++) timestampsTyped[i] = Date.now();

// ✅ Int32Array for counters
const counters = new Int32Array(1024);  // 1024 int32 values in contiguous memory

// ── Avoiding deoptimisation in hot paths ─────────────────────────────────

// ❌ 'arguments' object prevents optimisation in older V8
function sumBad() {
    let total = 0;
    for (let i = 0; i < arguments.length; i++) total += arguments[i];
    return total;
}

// ✅ Rest parameters — optimisable
function sumGood(...nums) {
    return nums.reduce((a, b) => a + b, 0);
}

// ❌ try/catch blocks in hot functions prevent TurboFan optimisation
function parseJSONHot(str) {
    try {
        return JSON.parse(str);  // try/catch here prevents optimisation of whole function
    } catch {
        return null;
    }
}

// ✅ Isolate try/catch to a separate helper function
function safeParseJSON(str) {
    return tryParseJSON(str);  // hot caller stays optimisable
}
function tryParseJSON(str) {   // only this function is deoptimised — cold path
    try { return JSON.parse(str); } catch { return null; }
}

// ── Object pooling to reduce GC pressure ─────────────────────────────────
// For high-frequency short-lived objects (e.g. per-request context objects)
class ObjectPool {
    constructor(factory, resetFn, size = 100) {
        this._factory = factory;
        this._reset   = resetFn;
        this._pool    = Array.from({ length: size }, factory);
    }

    acquire() {
        return this._pool.pop() ?? this._factory();
    }

    release(obj) {
        this._reset(obj);
        this._pool.push(obj);
    }
}

const bufferPool = new ObjectPool(
    () => Buffer.allocUnsafe(1024),
    buf => buf.fill(0),
    50
);

// Use pooled buffer
const buf = bufferPool.acquire();
try {
    // use buf...
} finally {
    bufferPool.release(buf);
}

// ── Monomorphic call sites ─────────────────────────────────────────────────
// ❌ Polymorphic — different types passed to same function (3 shapes → megamorphic)
function getTitle(item) { return item.title; }
getTitle({ title: 'a', status: 'pending' });        // shape 1
getTitle({ title: 'b', user: '123', tags: [] });    // shape 2
getTitle({ title: 'c', priority: 'high' });          // shape 3
// V8 cannot cache — every call does property lookup

// ✅ Monomorphic — always called with same shape
class TaskView {
    constructor(title, status, priority) {
        this.title    = title;
        this.status   = status;
        this.priority = priority;
    }
}
function getTaskTitle(task) { return task.title; }
// All TaskView instances have same hidden class — IC always hits

How It Works #

Step 1 — Hidden Classes Turn Property Access into Offset Arithmetic #

V8 assigns a hidden class (internal “shape”) to each object based on which properties were added and in what order. Objects with the same hidden class store their properties at the same memory offsets. When V8 JIT-compiles a property access like task.title, it can compile it as a direct memory offset read — one instruction — rather than a hash map lookup. This only works if the object consistently has the same hidden class at that call site (monomorphic).

Step 2 — Inline Caches Cache the Last Seen Shape #

An inline cache (IC) is a small piece of machine code patched into each property access site by the JIT compiler. On first access, V8 records the hidden class and the offset. On subsequent accesses with the same hidden class, the cache hits and the access is a direct offset load. If the call site sees multiple shapes (polymorphic), V8 tries a few shapes; beyond ~4 shapes (megamorphic), it falls back to a general hash map lookup and stops trying to cache.

Step 3 — TurboFan Compiles Hot Functions to Machine Code #

Functions executed frequently (“hot”) are optimised by TurboFan, V8’s optimising JIT compiler. TurboFan produces highly optimised machine code based on type feedback — if a function has always received integers, it compiles integer-specific machine code. If a call later arrives with a float, V8 “deoptimises” back to the interpreter and collects new type feedback. Deoptimisation is expensive; avoid it by keeping argument types consistent across all calls to hot functions.

Step 4 — TypedArrays Use Unboxed Storage #

JavaScript numbers in regular arrays are “boxed” — each is a heap-allocated object with a pointer. TypedArrays (Float64Array, Int32Array) store values as raw unboxed memory — a Float64Array of 1000 elements is a contiguous 8000-byte block. Operations on TypedArrays are more CPU-cache-friendly (linear memory layout) and SIMD-optimisable. For numeric-heavy code (statistics, signal processing, physics simulations), TypedArrays provide 2–10x speedups.

Step 5 — Object Pooling Reduces GC Pause Frequency #

Creating and discarding many objects per request generates “garbage” that the GC must collect. Even Node.js’s incremental GC pauses event loop processing during major GCs. Pooling reusable objects (Buffers, context objects, temporary data structures) means fewer allocations — fewer GC cycles. The tradeoff is code complexity; pools are worth it for objects that are: frequently allocated, short-lived, and expensive to allocate (like Buffers).

Quick Reference #