How Chromium Compresses Memory Under Critical Pressure

This article provides an overview of the mechanisms the Chromium web browser uses to reduce memory consumption when a system experiences critical memory pressure. Specifically, it covers how Chromium identifies and compresses inactive foreground memory strings using the ParkableStrings API, and how the rendering engine manages, compresses, and purges decoded image caches in the active tab to prevent browser crashes and maintain system stability.

Detecting Critical Memory Pressure

Chromium relies on a cross-platform component called the MemoryPressureListener to monitor the host operating system's RAM usage. When available memory drops below a critical threshold, the OS broadcasts a critical memory pressure signal. Upon receiving this alert, Chromium bypasses standard, passive garbage collection routines and immediately executes aggressive memory-saving interventions, even within the currently active foreground tab.

Compressing Inactive Foreground Strings

Web pages often load massive strings into memory, such as large JavaScript bundles, JSON payloads, or HTML source code. Once parsed or executed, many of these strings sit idle in the foreground tab. Chromium manages these using a mechanism in its Blink rendering engine called ParkableString.

When a string exceeds a specific size threshold (typically 10KB) and is allocated on the main thread, Blink wraps it as a ParkableString. Chromium tracks whether this string is actively being read or referenced by the V8 JavaScript engine or the DOM.

Under normal conditions, Chromium uses a background timer to "age" these strings, eventually compressing them if they remain unused. However, when critical memory pressure hits, Chromium takes immediate action:

  1. Immediate Parking: Chromium scans for any foreground ParkableString that does not have an active lock (meaning it is not currently being read by an active process).
  2. In-Memory Compression: A background worker thread compresses the raw string data in place using fast compression algorithms like Zlib or Snappy.
  3. Purging the Original: Once the compressed copy is generated, the original uncompressed string is immediately purged from RAM, reducing its memory footprint by up to 80%.
  4. Disk Eviction: If memory pressure remains critical after compression, Chromium can write the compressed string to disk (if swap space allows) and drop it from physical RAM entirely.

If the foreground tab suddenly requires the string again, Chromium pauses the requesting operation for a fraction of a millisecond, decompresses the string back into memory on the fly, and resumes execution seamlessly.

Managing Decoded Image Caches

Images represent one of the largest memory consumers in a foreground tab. When an image (like a JPEG or WebP) is downloaded, it is small because it is encoded. To display it on the screen, Chromium's graphics engine (Skia) and the Chrome Compositor must decode the image into a raw, uncompressed bitmap, which takes up a massive amount of RAM.

In an active foreground tab, many images are "inactive" because the user has scrolled past them, placing them outside the current viewport. Chromium manages these through the ImageDecodeCache and DiscardableMemory systems.

When critical memory pressure is triggered, Chromium handles decoded image caches through the following steps:

  1. Shrinking Cache Limits: The Chrome Compositor drastically reduces the maximum allowed size of the ImageDecodeCache, often setting the limit for off-screen images to zero.
  2. Discarding Decoded Bitmaps: Chromium identifies all decoded image bitmaps in the foreground tab that are not currently visible inside the active viewport. Rather than running a CPU-heavy compression algorithm on the raw bitmap, Chromium simply deletes the decoded bitmap from DiscardableMemory.
  3. Falling Back to Encoded Data: By deleting the raw bitmap, Chromium effectively reverts the image back to its original, heavily compressed source format (e.g., PNG, JPEG, WebP) which is still held in the browser's MemoryCache.
  4. Parking Encoded Images: To save even more RAM under critical conditions, Chromium utilizes ParkableImage—a system identical to ParkableString. It takes the already-compressed source image data of off-screen foreground images and writes it to disk, freeing both the decoded bitmap and the encoded file from physical RAM.

If the user scrolls back up to view the image, the compositor fetches the encoded data, re-decodes it into a bitmap just before it enters the viewport, and renders it to the screen.