How V8 represents a value

One word to hold every value

A variable, an array element, an object property slot, a register inside the interpreter — all of these are exactly one machine word wide, 64 bits on a modern CPU. That uniformity is not an accident; it is what makes the engine simple and fast. A load from an array element is the same instruction whether the element is a number or an object, because the thing being loaded is always one word. The engine never has to ask “how big is this value” before moving it around.

But JavaScript values are not all the same size in principle. A small integer fits in a word trivially. An object, a string, a closure — those are arbitrarily large. So V8 plays the classic systems trick: the word is a tagged union. It holds either a value inline or a pointer to where the real value lives, and a tag tells you which interpretation applies.

There are exactly two cases:

• Smi (“Small Integer”) — a small signed integer stored directly in the word. No heap object exists; the bits of the word are the number. Reading it is free.
• HeapObject pointer — the word is the address of an object on the heap. The real value (the object’s fields, the string’s characters, the double’s 64 bits) lives at that address. Reading it costs a dereference.

The tag bit: how the engine tells them apart

The trick is alignment. Every HeapObject is allocated on an even address (aligned to at least 2 bytes, in practice 4 or 8), so a genuine pointer always has its lowest bit equal to 0. V8 exploits this: it sets the low bit of a pointer to 1 to mark “this word is a pointer”, and leaves the low bit 0 to mark “this word is a Smi”. (We will see the exact bit layout in the next two lessons — the point here is that one bit is enough to discriminate.)

So every time the engine looks at a value word, the very first thing it does is a single bit test on the low bit:

// Conceptually, every value access starts with this branch:
if ((word & 1) === 0) {
  // Smi: the integer is encoded in the upper bits — use it directly
} else {
  // HeapObject: mask off the tag and dereference to reach the object
}

That branch is one CPU instruction. It is the price of admission for dynamic typing, and V8 has spent two decades making it cheap and predictable.

HeapObjects all start with a Map pointer

When the word is a pointer, what does it point at? Every HeapObject — an object, an array, a string, a function, a boxed number — begins its memory layout with a single word: a pointer to its Map. The Map is V8’s term for the hidden class: it describes what kind of HeapObject this is and, for plain objects, the layout of its properties (which names live at which offsets).

This is why the engine can dereference any HeapObject pointer and immediately learn its type and shape: the answer is always at offset 0.

HeapObject memory layout:
  [ Map pointer    ]  <- offset 0: "what am I, and what's my layout"
  [ field / data   ]  <- next word: depends on the kind
  [ field / data   ]
  ...

The Map is the linchpin of the whole performance story — hidden classes, inline caches, and deopt all hang off it. We cover Maps in depth in the hidden-classes unit; here, just fix the structural fact: a value is a word; if its tag says pointer, it points at a HeapObject; and a HeapObject’s first word is its Map.

Oddballs: true, false, null, undefined, and the hole

So where do true, false, null, and undefined live? They are not Smis (they are not integers) and they are not “objects” in the JS sense. V8 represents them as Oddballs — special singleton HeapObjects. There is exactly one undefined Oddball in the whole isolate, one null, one true, one false. A variable holding undefined holds a pointer to that one shared Oddball.

There is also a hidden Oddball you never see directly: the hole (TheHole). V8 uses it as a sentinel to mark an empty array slot or an uninitialised let binding (the temporal dead zone is literally “this slot still contains the hole”). Reading the hole is what triggers a ReferenceError for a TDZ access, or a sparse-array hole check.