V8's Turbocharging Trick: How Mutable Heap Numbers Boosted a Benchmark by 2.5x

Introduction

In the relentless pursuit of JavaScript performance, the V8 team recently turned its attention to an unexpected performance bottleneck hiding inside the JetStream2 benchmark suite. By rethinking how numeric values are stored and updated in script contexts, engineers achieved a remarkable 2.5x speedup in the async-fs benchmark, contributing to a noticeable overall score boost. This optimization, inspired by a benchmark quirk, has real-world implications for code that frequently mutates numeric variables stored outside local function scopes.

V8's Turbocharging Trick: How Mutable Heap Numbers Boosted a Benchmark by 2.5x — Source: v8.dev

The Bottleneck: Immutable Heap Numbers

The async-fs benchmark simulates a JavaScript-based file system with heavy asynchronous operations. Surprisingly, its performance bottleneck lay in an unlikely place: the custom implementation of Math.random. To ensure deterministic behavior across runs, the benchmark uses its own pseudo–random number generator driven by a seed variable:

let seed;
Math.random = (function() {
  return function () {
    seed = ((seed + 0x7ed55d16) + (seed << 12))  & 0xffffffff;
    seed = ((seed ^ 0xc761c23c) ^ (seed >>> 19)) & 0xffffffff;
    seed = ((seed + 0x165667b1) + (seed << 5))   & 0xffffffff;
    seed = ((seed + 0xd3a2646c) ^ (seed << 9))   & 0xffffffff;
    seed = ((seed + 0xfd7046c5) + (seed << 3))   & 0xffffffff;
    seed = ((seed ^ 0xb55a4f09) ^ (seed >>> 16)) & 0xffffffff;
    return (seed & 0xfffffff) / 0x10000000;
  };
})();

The seed variable lives in a ScriptContext—a storage area for values accessible throughout a script. Internally, V8 represents the ScriptContext as an array of tagged values. On 64-bit systems with default configuration, each tagged value occupies 32 bits. The least significant bit acts as a tag:

0 → a 31-bit Small Integer (SMI), stored directly
1 → a compressed pointer to a heap object

Because seed is updated on every call and eventually grows beyond 31 bits (and includes a division), it cannot remain an SMI. Instead, V8 stores it as a HeapNumber—a full 64-bit double-precision floating‑point value allocated on the garbage‑collected heap. The ScriptContext slot then holds a compressed pointer to that HeapNumber.

The problem: HeapNumbers are immutable. Each time Math.random computes a new seed, V8 must allocate a brand new HeapNumber, copy the value into it, and update the pointer in the ScriptContext. This allocation happens on every single call, creating significant overhead—especially when Math.random is invoked thousands of times per benchmark run.

HeapNumber Allocation Overhead

Profiling revealed two major sources of slowdown:

Allocation costs: Allocating a new HeapNumber object on the heap for each update consumes CPU cycles and stresses the garbage collector.
Memory traffic: Constant pointer updates from the ScriptContext to newly allocated objects generate additional memory bus activity.

In the hot path of Math.random, these micro‑operations accumulated into a measurable performance penalty.

The Optimization: Mutable Heap Numbers

V8 engineers realized that the seed variable’s storage pattern—an SMI‑incompatible number being updated inside a loop—could benefit from a specialized representation. Instead of creating a new immutable HeapNumber on every write, they introduced the concept of a mutable HeapNumber.

A mutable HeapNumber keeps its value in a fixed heap location and allows in‑place updates. When the ScriptContext slot points to a mutable HeapNumber, the engine can directly modify the underlying 64‑bit double without allocating new objects. This eliminates allocation overhead and reduces GC pressure.

The change is transparent to JavaScript code: it only affects V8’s internal handling of certain numeric variables stored in non‑local contexts (such as ScriptContexts). The engine detects variables like seed—those repeatedly written with non‑SMI values inside a tight loop—and automatically promotes them to mutable HeapNumbers.

Trade‑offs and Applicability

Mutable HeapNumbers are not a universal solution. They consume a fixed heap slot even if the variable is later read only, and they can complicate escape analysis. However, for patterns where the same numeric variable is mutated many times (as in this custom PRNG), the benefits far outweigh the costs.

Results: 2.5x Speedup in async-fs

After implementing mutable HeapNumbers, V8 measured a 2.5x performance improvement in the async-fs benchmark. The overall JetStream2 score also saw a noticeable uplift, confirming that this targeted optimization had a meaningful impact on the suite’s final result.

While the async-fs benchmark is synthetic, the underlying pattern—repeated mutation of a non‑SMI numeric variable in a persistent scope—does appear in real‑world JavaScript. Libraries that implement custom random number generators, physics simulations, or any code that aggressively updates a number stored in a closure or module scope can benefit from this change.

Conclusion

V8’s introduction of mutable HeapNumbers demonstrates that even low‑level representation decisions can unlock significant performance gains. By replacing immutable heap allocations with in‑place mutability for frequently updated numeric variables, the engine reduced GC load and sped up a benchmark by 2.5x. This optimization is a reminder that the best performance improvements often come from scrutinizing how the engine handles everyday data patterns—not just exotic code.

For developers, the lesson is subtle but valuable: if your code frequently updates a numeric variable that falls outside SMI range, consider whether a loop‑hoisting or local‑caching refactor could help. And rest assured that V8 continues to evolve to make even the trickiest patterns faster.

Tags: