Discardable memory (Chrome)

Discardable memory (Chrome)
Name	Discardable memory (Chrome)
Developer	Google
Released	2013
Programming language	C++
Operating system	Windows, macOS, Linux, Android, ChromeOS
License	BSD-style

Discardable memory (Chrome)

Discardable memory in Chrome is a memory management mechanism designed to allow the browser to mark portions of its heap as reclaimable under memory pressure, enabling the operating system to reclaim those pages without explicit free by the process. It is integrated into Chromium-based projects and interacts with platform allocators and kernel memory management to reduce resident set size while preserving in-process caches and data structures when possible.

Overview

Discardable memory provides a facility for Chromium to tag allocated memory as discardable so that the underlying operating system can reclaim the physical backing when required, while the process retains logical ownership of the virtual address range. The feature sits between the browser's internal allocators and platform primitives such as mmap on Linux, VirtualAlloc on Windows, and madvise/mmap semantics on Android and ChromeOS. Primary goals include lowering memory footprint for large caches in Google Chrome and related projects like Chromium, Microsoft Edge (Chromium-based), and embedded variants used by Electron-based applications.

History and development

Work on discardable memory emerged from efforts inside Google to optimize memory use in resource-constrained environments and during heavy multitasking on desktop systems. Early experiments referenced techniques used in operating systems research and in projects like WebKit and Firefox memory optimizations; subsequent implementation efforts were coordinated with contributors from projects such as Chromium OS and partners at Intel and ARM to ensure compatibility across architectures. Formal commits and API stabilization occurred across multiple repository milestones around 2013–2016 as part of broader memory footprint reduction initiatives alongside features like tab discarding and process consolidation in Chromium.

Implementation details

The implementation layers a discardable allocator on top of platform-specific APIs: on Linux and ChromeOS it uses anonymous mmap with MADV_DONTNEED/madvise to drop physical pages; on Windows it employs VirtualAlloc with decommit semantics; on macOS it integrates with vm_deallocate and madvise equivalents. The allocator exposes RAII-style objects in C++ that allow callers within subsystems such as the renderer process, GPU process, and browser process to lock and unlock ranges. The design tracks generation identifiers and maintains a discardable map so that when a lock fails (indicating the memory was reclaimed), callers can detect staleness via versioning and regenerate data. Integration points include Chromium subsystems like Skia for graphics caches, Blink for layout caches, and the Network Service for buffer reuse.

Use cases and behavior

Common use cases are bitmap caches for Skia and Vulkan-backed surfaces, decoded image caches in the renderer process, transient framebuffers in GPU accelerated compositing, and large lookup tables used by subsystems such as spellchecker or PDFium in the PDF Viewer. Behaviorally, code marks buffers as discardable when they are recomputable from persisted resources (e.g., disk-backed images, compressed assets, or network-fetched content) so that a reclaim simply triggers a lazy recompute. When memory is later accessed, the lock operation may succeed (memory intact) or fail (pages reclaimed); frameworks then decide whether to reconstruct content synchronously or schedule recreation. Interaction with features like tab freezing and automatic tab discarding influences when subsystems proactively release discardable allocations.

Performance and resource impact

When used judiciously, discardable memory reduces the browser's resident set size, which can improve system responsiveness on systems with limited physical RAM and reduce swapping on platforms like Windows 10, Ubuntu, and Android. However, excessive reliance on discardable allocations can increase CPU load and latency due to recomputation costs, affecting metrics such as time to interactive and frame latency in the compositor. Real-world measurements in Chromium telemetry suites demonstrated trade-offs: reductions in steady-state RSS and working set size versus spikes in CPU and network I/O for content regeneration. Platform-specific behaviors, such as kernel page reclaim aggressiveness in Linux kernel versions and memory pressure signaling on Android levels, modulate the effectiveness of discardable strategies.

Security and privacy considerations

Implementations must ensure no sensitive residual data is exposed after pages are reclaimed and subsequently reused; this requires zeroing or scrubbing policies aligned with platform semantics like VirtualAlloc decommit zeroing on Windows and explicit memory clearing after madvise operations on Linux. Care is taken to avoid use-after-free scenarios in multithreaded subsystems such as the renderer process, GPU process, and service workers; versioning and lock semantics mitigate race conditions. Privacy-sensitive caches tied to user data, such as decoded content from Google Drive or authenticated resources from OAuth 2.0 flows, are typically excluded from discardable tagging or guarded by additional encryption and access checks.

Adoption and platform support

Discardable memory is adopted across Chromium-derived browsers like Google Chrome, Microsoft Edge (Chromium) and used in operating environments from desktop Windows and macOS to mobile Android and embedded ChromeOS builds. Support varies by kernel and runtime: full reclaim semantics rely on features present in modern Linux kernel releases, recent Windows versions, and current Android releases; on older platforms fallback behaviors reduce benefits. Upstream contributions and platform-specific patches from organizations like Google, Intel Corporation, and community contributors in the Chromium project continue to evolve portability and robustness.

Category:Memory management