How V8 Code Caching Stores Compiled Bytecode in Chromium

This article explains how the V8 JavaScript engine in the Chromium web browser optimizes page load times through code caching. By serializing and storing compiled bytecode directly to the user's disk, Chromium bypasses the expensive parsing and compilation phases for frequently visited websites. Below is a breakdown of the triggers for this caching mechanism, the serialization process, how the bytecode is written to disk, and the security protocols that keep this cached data isolated and valid.

The Heuristic Trigger: Cold vs. Warm Runs

Chromium does not cache bytecode on your very first visit to a website. Serializing and writing data to the disk takes time and system resources, and doing so for every single script on the web would degrade performance and bloat storage. Instead, Chromium uses a time-based heuristic divided into three phases:

  1. Cold Run (First Visit): Chromium downloads the JavaScript file, stores it in the standard HTTP cache, and records a timestamp. V8 parses the JavaScript and compiles it into Ignition bytecode in memory, then executes it. No bytecode is saved to the disk.
  2. Warm Run (Second Visit): If you revisit the website and request the exact same script within a 72-hour window, Chromium flags the script as "frequently used." V8 compiles the script into bytecode from scratch one more time, executes it, and then triggers the code caching mechanism.
  3. Hot Run (Third+ Visit): Chromium fetches the compiled bytecode directly from the disk, skipping the parsing and compilation steps entirely.

Bytecode Serialization

Once the Warm Run triggers the caching mechanism, V8 prepares the in-memory bytecode for storage. Because memory addresses and internal pointers change every time the browser restarts, V8 cannot simply dump its memory to the disk.

Instead, V8 uses an internal serializer to convert the compiled Ignition bytecode into a flat, raw binary blob. Along with the bytecode itself, V8 packs crucial metadata into the header of this binary blob:

  • The exact version of the V8 engine.
  • Current CPU architecture flags.
  • A cryptographic hash or checksum of the original JavaScript source code.

Because V8 uses lazy compilation—meaning it only compiles functions that are actually called during page load—the serialized cache primarily contains the top-level script execution and the functions that ran before the page finished loading.

Disk Storage Architecture

The V8 engine runs inside a heavily sandboxed Renderer Process, which does not have permission to write files directly to your hard drive. To store the serialized bytecode on disk, V8 relies on the broader Chromium architecture:

  1. Passing to Blink: V8 hands the serialized bytecode blob over to Blink, Chromium's rendering engine.
  2. IPC Transmission: Blink uses Mojo, Chromium's Inter-Process Communication (IPC) system, to send the bytecode blob out of the sandboxed Renderer Process and into the privileged Browser Process.
  3. The GeneratedCodeCache: The Browser Process receives the data and passes it to a dedicated storage subsystem called the GeneratedCodeCache.
  4. Disk Write: The GeneratedCodeCache writes the binary blob to a specific directory in the user's profile folder on the hard drive. This cache operates in parallel to the standard HTTP cache, using Chromium's disk_cache backend to manage file eviction, size limits, and disk read/write operations asynchronously.

Security and Cache Isolation

Storing executable code on disk introduces security risks, particularly regarding cross-site tracking and timing attacks. To prevent malicious websites from probing the disk cache to see what other websites a user has visited, Chromium enforces strict cache partitioning.

When the GeneratedCodeCache writes the bytecode to disk, it does not just use the script's URL as the lookup key. Instead, it uses a double-keying mechanism (often referred to as a Network Isolation Key). The disk storage entry is keyed using both:

  • The URL of the JavaScript resource.
  • The top-level site origin (the URL in the browser's address bar) that requested the script.

If Website A and Website B both load the exact same third-party script, Chromium will compile, serialize, and store that bytecode twice on the disk under two different keys. This guarantees complete isolation between different websites.

Retrieval and Deserialization

When you visit the website a third time (a Hot Run), the Renderer Process requests the JavaScript file. The Browser Process simultaneously queries the HTTP cache for the raw JavaScript text and the GeneratedCodeCache for the compiled bytecode on disk.

Both the raw source code and the cached binary blob are sent back to the V8 engine. Before V8 executes the cached bytecode, it performs strict sanity checks:

  • It verifies that the V8 version in the blob's header matches the currently running V8 version (if Chrome updated overnight, the cache is rejected).
  • It checks that the source code hash in the blob matches the actual JavaScript file fetched from the HTTP cache.

If the checks pass, V8 deserializes the binary blob, reconstructing the Ignition bytecode directly into memory. The engine immediately begins execution, successfully bypassing the CPU-intensive parsing and compilation phases.