Chromium Simple Cache Disk Eviction Algorithm

This article provides a quick overview and technical breakdown of the disk caching eviction algorithm used by the Simple Cache backend in the Chromium web browser. It explains how the browser manages local storage limits using a Least Recently Used (LRU) strategy, how the in-memory index tracks file usage without causing disk bottlenecks, and the exact process triggered when the cache reaches capacity.

The Core Algorithm: Least Recently Used (LRU)

The Simple Cache backend in Chromium uses the Least Recently Used (LRU) eviction algorithm to manage disk space.

Unlike Chromium's legacy "Blockfile" cache—which used a complex, multi-tiered ranking system that combined access frequency and recency—Simple Cache was designed to be lightweight. It relies directly on the host operating system's file system to manage individual cache files and uses a straightforward time-based LRU policy to decide which files to delete when storage runs low.

How Simple Cache Tracks Usage

To execute an LRU eviction strategy efficiently, the browser must know when every cached file was last accessed. Querying the operating system's file system for the "last accessed" timestamps of thousands of files would cause severe disk I/O bottlenecks.

Simple Cache solves this by maintaining an in-memory index (SimpleIndex). This index stores minimal metadata for every active entry in the cache:

  • A 64-bit hash of the cache key.
  • The size of the cached entry on the disk.
  • The last_used timestamp.

Whenever a cached resource is read or written, Chromium updates the last_used timestamp in the RAM-based SimpleIndex instantly. To ensure this data isn't lost when the browser closes, the in-memory index is periodically serialized and flushed to a single index file on the disk when the browser is idle.

The Eviction Process

Eviction in the Simple Cache backend is not a continuous process; it is triggered in batches based on storage thresholds (watermarks) to prevent constant disk thrashing.

The eviction lifecycle follows these exact steps:

  1. Monitoring Capacity: Every time a new file is written to the cache, the SimpleIndex adds the new file's size to the total tracked cache size.
  2. Reaching the High Watermark: Eviction is triggered only when the total size of all cached files exceeds the maximum allowed cache size (the high watermark), which is dynamically calculated based on available disk space.
  3. Sorting Entries: Once triggered, the browser collects all entries from the SimpleIndex and sorts them in ascending order based on their last_used timestamps.
  4. Batch Deletion: Chromium iterates through the sorted list, deleting the oldest files from the disk and removing their references from the SimpleIndex.
  5. Reaching the Low Watermark: The deletion process does not stop the moment the cache drops just below the maximum limit. Instead, it continues deleting the least recently used files until the total cache size drops to a "low watermark" (typically around 90% of the maximum limit). Clearing this extra buffer ensures that the eviction algorithm does not need to run again on the very next network request.

Why Simple Cache Uses Pure LRU

The decision to use a standard LRU algorithm in Simple Cache comes down to CPU and disk efficiency. Because Simple Cache stores entries as discrete files on the OS file system rather than inside a massive, custom-managed database file, the actual deletion of an entry requires an OS-level unlink (delete) operation.

By keeping the eviction math strictly tied to an in-memory timestamp sort, Chromium minimizes CPU overhead and reserves disk operations strictly for reading, writing, and batch-deleting the actual cached web assets.