arthrop0d

Brief articles on varied topics.

V8 Hidden Classes and Inline Caches

javascriptperformance

V8, the JavaScript engine used by Chrome and Node.js, gives objects internal hidden classes that describe their property layout, and uses inline caches to make repeated property access fast. Together, they let V8 turn a dynamic operation such as user.name into a short, specialized machine-code path—provided the objects involved continue to have the shape the generated code expects.

The problem: dynamic objects are expensive

In JavaScript, an object can acquire or lose properties at runtime:

const user = {};
user.name = "Ada";
user.id = 42;

A straightforward implementation could store properties in a general-purpose dictionary and look up name every time. That is flexible, but repeated property reads would involve hashing or searching, checking prototypes, handling accessors, and performing other dynamic-language work.

V8 instead tries to discover regularity. If many objects are created with the same properties in the same order, their layout is predictable. V8 can then remember that pattern and optimize future accesses.

The important distinction is between an object's shape—which properties it has and where they are stored—and the values currently held in those properties.

Two objects can have different values but the same shape. That is the useful case for optimization.

Hidden classes: a map of an object's shape

A hidden class is V8's internal description of an object's structure. V8 also calls this structure a Map in its implementation and diagnostic output; it is not a JavaScript class and is unrelated to the class syntax used to create instances.

Conceptually, a hidden class records facts such as:

V8 commonly builds these classes as a transition tree. Start with an empty object. Adding name produces one hidden class; adding id after that produces another:

const first = {};
first.name = "Ada";
first.id = 1;

const second = {};
second.name = "Grace";
second.id = 2;

Because both objects follow the same sequence, V8 can usually give them the same final hidden class. Their values differ, but their property layout does not.

Property order therefore matters. This produces the same names but typically a different transition path:

const third = {};
third.id = 3;
third.name = "Katherine";

third may have a different hidden class from first and second. The objects are semantically similar to JavaScript code, but they are not necessarily structurally identical to V8.

Object constructors and factory functions make a stable order easier to maintain:

function makeUser(name, id) {
  return { name, id };
}

Every result has the same literal property order. This is not a rule that makes code automatically fast, but consistency gives V8 a pattern it can exploit.

Inline caches: remembering successful lookups

An inline cache (IC) is a small piece of information attached to an operation in the generated code. It records what happened at that particular source location before, so V8 does not have to rediscover it on every execution.

Suppose this function is called repeatedly:

function getName(user) {
  return user.name;
}

Initially, V8 may use a general lookup. After observing that user has a particular hidden class, it can specialize the access roughly like this:

  1. Check whether user has the expected hidden class.
  2. If it does, read name from its known location.
  3. Otherwise, take a slower fallback path.

The real generated code is more sophisticated than this pseudocode, but the principle is accurate. The hidden-class check protects the assumption; the cached property location avoids a full dynamic lookup.

An IC that has seen one hidden class is monomorphic. If the same operation sees a small number of different hidden classes, it can become polymorphic—the generated code checks several known shapes. With many unrelated shapes, it may become megamorphic, where maintaining a growing list of special cases is no longer worthwhile and lookups become more generic.

The cache belongs to an operation location, not globally to the property name. Two user.name expressions in different functions can develop different histories.

How shape changes affect generated code

Optimizing compilers use runtime observations to produce faster machine code. A compiled version of getName might assume that its argument has the hidden class seen during warm-up. That assumption is called a guard: a check that must remain true for the optimized code to be valid.

This pattern can invalidate the assumption:

function getName(user) {
  return user.name;
}

const user = { name: "Ada" };
getName(user);

user.age = 36; // changes the object's shape
getName(user);

Adding age changes user's hidden class, even though the name value and property still exist. The optimized code may no longer be able to use its original guard. V8 can fall back to less specialized code, or it can deoptimize—discard the optimized version and return execution to a more general version that is known to be correct. Later, V8 may optimize again using the new observations.

A deoptimization is not a correctness failure. It is a performance recovery mechanism. It becomes a problem when code repeatedly switches between shapes, causing repeated invalidation, recompilation, or megamorphic property access.

Patterns that look harmless

Adding fields conditionally

function makeUser(name, admin) {
  const user = { name };
  if (admin) user.role = "admin";
  return user;
}

This creates at least two shapes: users with only name, and users with name followed by role. If a hot function processes both kinds, its property ICs may become polymorphic. Initializing the field consistently can preserve one shape, although the best representation depends on the workload:

function makeUser(name, admin) {
  return { name, role: admin ? "admin" : null };
}

Deleting properties

delete user.role changes the object's structure and can force V8 away from its fastest property representation toward a dictionary-style representation designed for more dynamic changes. If a field is optional, assigning null or undefined is often more shape-stable than deleting it.

Mixing construction styles

Objects made by a constructor, object literal, and several ad hoc mutation sequences can represent the same conceptual record while having different hidden classes. Code that feeds all of them into one hot operation gives its inline caches more cases to handle.

What to take from this

Do not treat hidden classes as a reason to freeze every object or avoid all mutation. V8 handles ordinary JavaScript well, and a single shape change is rarely important. The practical rule is narrower: for objects flowing through performance-sensitive, repeated code, construct them consistently, add properties in a consistent order, avoid unnecessary delete, and be cautious about mixing radically different object layouts.

If a profile, trace, or optimization log mentions ICs, maps, wrong map, or deoptimization, it is often describing this mechanism. V8 observed one object shape, generated code around it, and then encountered a shape that no longer matched the assumption.

← All articles