How Chromium Deduplicates Fonts and Shared Memory

This article provides an overview of the specific architectural techniques the Chromium web browser uses to prevent memory bloat across dozens of open tabs. By leveraging operating system page caches, centralized font brokering, Mojo Inter-Process Communication (IPC), and read-only shared memory regions, Chromium ensures that identical font tables, rasterized glyphs, and static engine assets are loaded into physical RAM only once, regardless of how many isolated renderer processes are active.

The Sandbox Challenge

Chromium uses a multi-process architecture where almost every tab runs in its own isolated "renderer" process. For security reasons, these renderer processes are strictly sandboxed and forbidden from directly accessing the operating system’s file system, meaning they cannot simply read system font files from the hard drive.

If Chromium copied the necessary font files into each tab's private memory space to bypass this restriction, opening thirty tabs would duplicate megabytes of identical font data thirty times. Chromium solves this through handle passing and shared memory.

OS-Level Memory Mapping for System Fonts

When a tab needs to render text using a system font (like Arial or Roboto), it does not receive a copy of the font. Instead, Chromium relies on the operating system's virtual memory manager.

  1. Broker Request: The sandboxed renderer asks the privileged main Browser process for the font via Mojo, Chromium's IPC system.
  2. File Descriptor Passing: The Browser process locates the font file on the disk, opens it in read-only mode, and passes a file handle (or file descriptor on POSIX systems) back to the renderer.
  3. Memory Mapping (mmap): The renderer uses this handle to memory-map the font file into its own virtual address space.

Because the mapping is strictly read-only, the operating system kernel recognizes that multiple processes are reading the exact same underlying file on the disk. The OS loads the font file into physical RAM (the OS page cache) only once, and simply points the virtual memory addresses of all thirty tabs to that single physical RAM location.

Deduplicating Font Tables via the Font Proxy

Font files (like TrueType and OpenType) are actually databases containing multiple distinct tables—such as cmap (character-to-glyph mapping), glyf (glyph shapes), and GPOS (glyph positioning). Often, a tab only needs specific tables rather than the entire font file.

On Windows, Chromium uses a DirectWrite Font Proxy. When a renderer process requests a specific font table to calculate text layout (via the HarfBuzz shaping engine), the proxy intercepts the call and routes it to the Browser process. The Browser process loads the requested table into a Read-Only Shared Memory Region (base::ReadOnlySharedMemoryRegion) and caches the handle.

When a second or third tab requests the exact same font table, the Browser process does not reload the table. It simply duplicates the lightweight shared memory handle and sends it to the new tabs, granting them immediate read-only access to the already-allocated RAM.

Centralizing Rasterized Glyphs in the GPU Process

Parsing font tables is only half the battle; the browser also has to rasterize (draw) the vector font shapes into pixel bitmaps. Chromium prevents tabs from duplicating these bitmaps by offloading the work to a single, centralized GPU Process.

  • Skia Glyph Atlases: Chromium’s graphics engine, Skia, maintains a centralized texture atlas (a large composite image of individual characters) inside the GPU process.
  • Cross-Tab Reuse: If Tab 1 renders a 16-pixel "E" in Times New Roman, the GPU process rasterizes that glyph and stores it in the atlas. If Tab 2 through Tab 20 also need a 16-pixel "E" in Times New Roman, they do not rasterize it themselves. They issue drawing commands to the GPU process, which reuses the single cached glyph from the shared atlas.

Discardable Shared Memory for Web Fonts and Caches

Unlike system fonts, downloadable web fonts (like WOFF2 files fetched via CSS @font-face) do not exist permanently on the user's hard drive. To prevent duplication of these dynamic resources, Chromium uses two mechanisms:

  1. The Blink Memory Cache: If multiple tabs are running within the same renderer process (which happens when tabs share the same website domain or when the user exceeds the process limit), Blink’s internal FontCache shares the decoded SkTypeface objects directly via C++ pointers.
  2. Discardable Shared Memory: For decoded resources that must cross process boundaries, Chromium uses base::DiscardableSharedMemory. The Browser process allocates a block of shared memory and hands it to the renderers. When a tab isn't actively looking at the data, it "unlocks" the memory. If the system runs low on RAM, the Browser process can instantly purge this unlocked memory without crashing the tab, regenerating the font data only if the user switches back to that tab.

V8 Snapshots and Static Engine Data

Beyond fonts, Chromium uses the exact same read-only shared memory techniques to deduplicate its own internal engine resources across tabs:

  • V8 Context Snapshots: Every tab needs a JavaScript engine (V8) initialized with built-in objects (like Array, Math, and Promise). Instead of building these from scratch in every tab, Chromium maps a pre-compiled v8_context_snapshot.bin file into read-only shared memory. Every tab reads the exact same physical RAM for its baseline JavaScript environment.
  • Data Pack (.pak) Files: Default browser stylesheets (user-agent CSS), localized strings, and UI icons are bundled into .pak files. These are memory-mapped at browser startup, allowing dozens of processes to read default browser assets with zero memory duplication.