---
slug: process-consolidation-memory
type: pattern
summary: "Chromium merges multiple sites into one renderer process when available memory falls below a platform-specific threshold, releasing the Site Isolation boundary while preserving the browser-renderer privilege split."
created: 2026-05-12
updated: 2026-05-16
last_link_verified: 2026-05-13
related:
  memory-pressure-response:
    relation: complements
    note: "Memory Pressure Response is the performance-axis framing of the same renderer-merging move; this entry names the trust-model release the merge performs and what the per-site Spectre-class boundary loses when it fires."
  site-isolation:
    relation: relaxes
    note: "Site Isolation is the per-site renderer-process boundary this pattern conditionally releases; the relaxation is the documented Android Chrome 77 fallback to password-handling sites only, and the runtime consolidation that fires above it under sustained pressure."
  multi-process-architecture:
    relation: refines
    note: "Multi-Process Architecture established the per-renderer OS boundary; consolidation is the documented contraction of that boundary on devices whose memory budget cannot honor it without OOM-kill."
  browser-renderer-split:
    relation: preserves
    note: "Renderer-to-renderer merges happen; renderer-to-browser merges do not. The Browser-Renderer Privilege Split is the one invariant the pattern never releases, by deliberate design."
  untrusted-renderer-axiom:
    relation: stresses
    note: "When two cross-site renderers merge, the Untrusted Renderer Axiom widens its scope: one compromised renderer can now read both sites' data through the speculation channel Site Isolation was built to close."
  escape-chain:
    relation: shortens
    note: "Under consolidation a first-link memory-corruption primitive in a renderer can read cross-site data without the V8-heap-sandbox-bypass link the chain otherwise requires; the chain shortens by one link for the merged group."
  exploit-chain:
    relation: stresses
    note: "Exploit chain severity calibration assumes per-site renderer boundaries; consolidation is the documented condition under which a first-link bug's severity rating is conservative rather than accurate."
  v8-heap-sandbox:
    relation: complements
    note: "The V8 heap sandbox contains in-process attacks within one renderer; consolidation widens what 'one renderer' contains, raising the stakes of the heap-sandbox boundary specifically on consolidated groups."
  main-thread-starvation:
    relation: co-occurs-with
    note: "When two or more renderers merge into one process, their main threads share time; a Response-budget breach in one cross-site frame registers as a freeze on another, and Main Thread Starvation becomes more frequent on the same hardware."
  finch-variations:
    relation: tuned-by
    note: "The memory threshold below which Site Isolation defaults to password-sites-only is Finch-tunable; the canonical 1.4 GB Android breakpoint is the project's current setting, not an immutable constant."
---

# Process Consolidation Under Memory Pressure

> **Pattern**
>
> A named solution to a recurring problem.

*Chromium merges multiple sites into a single renderer process when available memory falls below a platform-specific threshold. The merge releases the OS-enforced Site Isolation boundary that defends against Spectre-class speculative-execution reads. It preserves the [Browser-Renderer Privilege Split](browser-renderer-split.md), the per-origin same-origin policy enforced inside Blink, and password-handling sites' dedicated renderers.*

> "On devices with less than 1.4 GB of RAM, Site Isolation is enabled for sites where users log in. For other sites, multiple cross-site documents may share a process to reduce memory overhead."
> — Chromium project, [`docs/process_model_and_site_isolation.md`](https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md), current

The [Site Isolation](site-isolation.md) decision of 2018 paid roughly ten to thirteen percent of desktop memory to extend the multi-process boundary from per-tab to per-site. The cost defends against the cross-origin speculative-execution reads Spectre disclosed in January of that year. That ten-to-thirteen-percent figure is a desktop measurement on machines with eight or more gigabytes of RAM.

The pattern names what happens elsewhere. On a low-end Android phone with two gigabytes shared with three other applications, on an enterprise WebView2 integration sized for a single foreground site, on an Electron application competing with the user's IDE, the per-site boundary isn't free. The project has documented in advance what it gives up rather than which entire user sessions it terminates.

## Context

A Chromium-based product is running on a device that does not have memory to spare for the full per-site process-count Site Isolation would otherwise enforce. The platform varies; the budget constraint does not. The canonical case is an Android device below the project's 1.4 GB total-RAM threshold, where the Chrome 77 rollout configured the per-site boundary as a partial default at launch.

The broader case includes any device where the [`MemoryPressureMonitor`](https://chromium.googlesource.com/chromium/src/+/main/base/memory/memory_pressure_monitor.h) signal escalates to sustained pressure. The list of qualifying devices is long: low-end ChromeOS devices, older Windows fleets, embedded Linux kiosks sized for one site, Electron applications whose host application has already consumed most of the working set.

The pattern operates inside the architecture [Multi-Process Architecture](multi-process-architecture.md) established and that Site Isolation refined. It is read alongside [Memory Pressure Response](memory-pressure-response.md), which catalogues the full four-level pressure-response sequence (background hygiene, tab discarding, renderer consolidation, GPU cache eviction). This entry treats only the third level, the merge itself, and reads it from the trust-model side. The questions are: what isolation property the merge releases, what it keeps, and what the change means for security review of a Chromium-based product.

## Problem

Site Isolation states an unconditional architectural commitment: each cross-site document gets its own renderer process so that an OS-enforced page-table boundary, not Blink's same-origin checks alone, defends against cross-origin reads through speculative-execution side channels.

On devices below the project's memory threshold the commitment cannot be honored without sacrificing the user's session. The per-site process count would exceed available RAM. The OS would step in: Android's low-memory killer terminates the foreground process; macOS pages aggressively; Windows raises `LowMemoryResourceNotification` events whose handler effect on the browser is itself disruptive. The user would lose every tab.

Three security-relevant questions follow. Which sites must keep their own renderer no matter how tight memory becomes? Which sites can share a renderer with another site safely enough that the trade is worth making? When the merge fires, what does an entry like Site Isolation that stated "cross-origin reads via speculation are impossible" still mean?

## Forces

- **The OS-enforced boundary is the only durable Spectre defense.** Software-enforced same-origin checks run above the speculation layer; the per-site process boundary runs below it. The pattern is releasing the exact defense Site Isolation was built to provide. The release is a security event, not a footnote, even when no exploit is in flight.
- **The user's session is the failure cost of doing nothing.** A browser whose only response to memory pressure is "preserve every architectural commitment" terminates from the OS-killer side and loses the session. The release exists because session loss is the alternative the project ranks as worse than conditional boundary contraction.
- **Some sites are not negotiable.** Password-handling sites cannot share a renderer with arbitrary cross-site content without unacceptable risk. The project's Chrome 77 Android default exempts the sites where users log in from the consolidation. The pattern's first job is naming which sites the merge does and does not touch.
- **The release is auditable from the running browser.** A pattern that quietly disabled Site Isolation would be a footgun. The consolidated mode is observable on the device at [`chrome://process-internals`](https://www.chromium.org/developers/design-documents/process-models/) and [`chrome://memory-internals`](https://www.chromium.org/developers/design-documents/process-models/). It is reportable to a security reviewer asking for the answer rather than the policy.
- **Threshold values are a setting, not a constant.** The 1.4 GB Android breakpoint is in `content/public/browser/site_isolation_policy.cc` as the `kSiteIsolationMemoryThresholdMB` value and is Finch-tunable per [Finch Variations](finch-variations.md). The project varies it by population, hardware class, and time. Reasoning that assumes the constant is set in stone reasons against a moving baseline.
- **The Browser-Renderer Privilege Split is not on the table.** Whatever the merge does to per-site separation, the substrate remains intact: the per-renderer OS sandbox, the renderer's lack of file-system access, the lack of network access, the lack of child-process creation capability, and the IPC-only path to the browser process. The pattern is a contraction of one boundary, not a relaxation of the substrate.

## Solution

Release the per-site renderer-process boundary along a documented gradient, in three concentric scopes whose security properties the project names and a reviewer can read off the running browser.

**Scope A: sites where users log in keep their own renderer.** The Android Chrome 77 default and every later Android configuration enforces full Site Isolation for any origin the browser has observed handling user credentials. The triggers are a password form submission, an OAuth callback, or a credentials-management API call. The decision logic in [`content/public/browser/site_isolation_policy.cc`](https://chromium.googlesource.com/chromium/src/+/main/content/public/browser/site_isolation_policy.cc) and the per-profile observed-password-sites list ([`chrome/browser/site_isolation/site_isolation_policy.cc`](https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/site_isolation/site_isolation_policy.cc)) hold these origins out of every consolidation decision. The trust property: the speculation-channel defense remains in place for the sites whose cross-origin read would be most damaging.

**Scope B: Cross-Origin Opener Policy and Cross-Origin Embedder Policy opt-ins keep their own renderer.** Pages that send the `Cross-Origin-Opener-Policy: same-origin` and `Cross-Origin-Embedder-Policy: require-corp` header pair are flagged `crossOriginIsolated` and held out of consolidation in the same way Scope A is. Sites that need stronger guarantees than the default (financial dashboards, healthcare records, anything using `SharedArrayBuffer`) opt in via headers the server controls and pay the per-site process cost knowingly. The trust property: a site that knows its threat model can recover full Site Isolation regardless of device memory class.

**Scope C: other cross-site origins may share a renderer process.** Below the threshold and outside the Scope A and Scope B exemptions, two cross-site documents may live in the same renderer process. Each retains its own [V8](https://chromium.googlesource.com/v8/v8/+/main/) `Isolate` and its own JavaScript heap. The same-origin policy enforced inside Blink still denies the host page's script direct access to the embedded site's DOM through scripting interfaces. The renderer's OS sandbox remains in place.

What is released is the page-table boundary. The host page's renderer and the embedded site's renderer share an address space. Speculative-execution reads that defeat Blink's same-origin checks at the instruction layer succeed because they run below those checks. The Spectre-class defense Site Isolation was built to provide is conditional, in this scope, on the threshold.

**The release is policy, not implementation accident.** A reader who opens the running browser at [`chrome://process-internals`](https://www.chromium.org/developers/design-documents/process-models/) sees the per-renderer assignment for every frame and can identify the merged group. [`chrome://memory-internals`](https://www.chromium.org/developers/design-documents/process-models/) shows the per-renderer working-set decomposition that drove the merge decision. The reviewer asking "is Site Isolation enabled?" gets a precise answer: enabled by default, conditionally relaxed for Scope C on devices below the threshold, never relaxed for Scope A or Scope B.

**The merge respects [Untrusted Renderer Axiom](untrusted-renderer-axiom.md).** Even inside a consolidated process the browser does not trust the renderer's claims about origin. Cross-site frame identity is established by the renderer's [`SiteInstance`](https://chromium.googlesource.com/chromium/src/+/main/content/browser/site_instance_impl.cc) recorded in `content/browser/`, not by the message body the renderer sends. A renderer-side compromise in a consolidated process can read cross-site data through the now-shared address space. It cannot lift its origin claim past the browser's `RenderFrameHost::GetSiteInstance()` check on an IPC handler. The widening is real; the substrate that contains it is not.

## How It Plays Out

A security review at an enterprise browser vendor asks the question the [Site Isolation](site-isolation.md) entry trains a CIO to expect: is Site Isolation enabled by default on the product's Android population? The team's first-instinct answer is yes. The build config sets `kEnableSiteIsolation`, the policy switch is on, the `SiteInstance` machinery is built into the binary. The pattern is what makes the honest answer longer.

The team opens the device-class distribution of its Android user population (the field-measured device-memory histogram the [Chrome UX Report](https://developer.chrome.com/docs/crux) publishes) and reads off the fraction below 1.4 GB. On the population fraction below the threshold, Site Isolation enforces Scope A and Scope B and releases Scope C. The reviewer's precise answer becomes: "yes for Scope A and Scope B; for Scope C on Android devices below 1.4 GB, the OS-enforced cross-site boundary is conditionally relaxed and the speculation defense reduces to the renderer's per-origin sandbox plus same-origin policy." That is the answer the pattern lets the team give, citably, with the operating thresholds and the device population fraction the reviewer can verify. Without the pattern's vocabulary the team can't make that statement honestly.

A second case: a downstream vendor shipping a Chromium-based browser for a fleet of point-of-sale terminals reads a Project Zero writeup of a V8 type confusion. The bug is CVE-2024-XXXX, a first-link memory-corruption primitive, normally rated High in isolation per the project's [severity guidelines](https://chromium.googlesource.com/chromium/src/+/main/docs/security/severity-guidelines.md) because the V8 heap sandbox would contain the read. The vendor's terminals run on hardware with 1 GB total RAM.

The team's risk model has to account for the consolidated mode. On those terminals the first-link primitive is not contained by the per-site renderer boundary for Scope C origins. The speculation channel reads cross-site data from any cross-site frame the consolidated renderer happens to be hosting. The pattern is the documented condition under which a published CVE's severity rating is conservative rather than accurate. The vendor's downstream advisory cites it explicitly: "On hardware below the consolidation threshold, this vulnerability's effective severity is Critical rather than High for unauthenticated cross-site content, per [Process Consolidation Under Memory Pressure](process-consolidation-memory.md)."

A third case: an Electron application embedded inside a host application that has consumed most of the working set sees a class of customer reports framed as cross-frame data leakage. The product team's first-instinct hypothesis is a Mojo IPC handler bug. The profile shows the application's three renderers (authentication, support-chat, product-content) consolidated into one renderer process under sustained pressure. The host application's memory footprint pushed the available headroom below the consolidation threshold, and the embedded Chromium merged the three renderers because none of them was a Scope A site.

The bug report is real, but the cause is the trust-model release, not the IPC handler. The application's existing IPC code isn't broken. What's broken is the cross-site separation assumption the application code was built on. The remediation is at the application layer: raise the host application's available memory headroom; mark the authentication renderer's origin as a Scope A site via the embedder API; deploy the COOP / COEP header pair on the product-content renderer to opt into Scope B. The pattern names the failure mode so the team can read the customer report correctly and respond without first hypothesizing the wrong root cause.

## Consequences

**The pattern releases one boundary and preserves the rest.** Site Isolation's per-site speculation defense is released, conditionally, for Scope C on devices below the threshold. The Browser-Renderer Privilege Split, the per-renderer OS sandbox, the V8 heap sandbox, the renderer's lack of file-system and network access, and the IPC-only path to the browser process all remain. A reader who treats the release as "Site Isolation is off" misreads the pattern. The precise statement is: the cross-site speculation defense is conditional in Scope C below the threshold; the rest of the trust model holds. That distinction is not editorial preference. It is the difference between an accurate downstream advisory and an alarmist one.

**Severity ratings for renderer-internal bugs become device-class-conditional.** A first-link memory-corruption primitive rated High on the assumption of per-site containment carries a higher effective severity on consolidated devices. Downstream vendors shipping Chromium-based products on constrained hardware cannot read the Chromium [Severity Guidelines](https://chromium.googlesource.com/chromium/src/+/main/docs/security/severity-guidelines.md) directly off the page. They have to translate them through the pattern. The [Exploit Chain Anatomy](exploit-chain.md) entry's full-chain framing assumes per-site renderers. On the consolidated fraction of the population the chain shortens by one link, because the V8-heap-sandbox-bypass link is no longer required to reach cross-site data within the consolidated group.

**Site Isolation's prose becomes thresholded.** Every Chromium-related document that states Site Isolation's guarantee in absolute terms ("each cross-site frame gets its own renderer process") carries an implicit "above the threshold and outside the Scope A and Scope B exemptions" qualifier. The pattern is what makes the qualifier explicit. Documentation, blink-dev discussions, security advisories, and downstream-vendor disclosures that omit the qualifier are imprecise rather than wrong. The imprecision matters when the consumer's device population sits partially below the threshold.

**Detection of consolidated mode is local to the device.** A team that wants to know whether a specific browser instance is operating in the consolidated mode reads the answer off [`chrome://process-internals`](https://www.chromium.org/developers/design-documents/process-models/) on the running browser. There is no central registry of which user populations are consolidated. The pattern is per-device, per-moment, and tied to the OS-side pressure signal. The [Perf Sheriff](perf-sheriff.md) rotation surfaces population-wide regressions in consolidation rate as memory regressions on `chromeperf.appspot.com`. That is the closest the project has to a population-scale visibility surface for the pattern.

**Threshold changes are an operations event with security consequences.** The 1.4 GB Android breakpoint is a Finch-tunable parameter. A change in the threshold changes the fraction of the population for which Scope C releases. The driver may be a release-discipline change responding to a memory regression on the rest of the fleet, or a Chromium-version change that revises the breakpoint based on Chrome UX Report data. Downstream vendors who pin to a specific Chromium version need to watch the threshold value as well as the version. The pattern is one of the few security-relevant parameters whose value is set outside the binary the vendor ships.

**The pattern is not the [Untrusted Renderer Axiom](untrusted-renderer-axiom.md)'s failure.** A renderer in the consolidated mode is no more trusted by the browser than a renderer in the fully isolated mode; the axiom holds. What changes is what the renderer can read from itself. It can now read cross-site data in its own address space through speculation, when before it could not. The axiom's defense (every browser-side IPC handler validates renderer-supplied input regardless of any prior renderer claim) is unaffected. The renderer has more data inside its own boundary to misuse against itself.

## Notes for Agent Context

When generating code for a Chromium-based product that targets Android below 4 GB RAM, embedded kiosk hardware, or an Electron host with multiple concurrent renderers, do not assume per-site renderer separation. The consolidated mode is the documented behavior on devices below the threshold.

When writing or reviewing a Mojo IPC handler in `content/browser/`, treat `RenderFrameHost::GetSiteInstance()->GetSiteInfo()` as the load-bearing identity check. Never trust an origin claim recovered from the message body. Under consolidation, two cross-site frames share a renderer and the message body alone cannot distinguish them.

When designing a new web-platform feature that exposes cross-origin data, default to gating it behind the [`crossOriginIsolated`](https://developer.mozilla.org/en-US/docs/Web/API/crossOriginIsolated) check (which requires the COOP / COEP header pair). Scope B opt-in is the only deterministic way to recover full Site Isolation on consolidated devices.

When auditing a Chromium-based product's security posture, never report "Site Isolation is enabled" without qualifying the report with the device-population fraction below the consolidation threshold. The precise claim is: "Scope A and Scope B fully; Scope C conditionally above the threshold."

When triaging a renderer-resident memory-corruption CVE for a downstream advisory, account for consolidation. The effective severity on consolidated devices is one tier higher than the Chromium severity-guidelines rating on the assumption of per-site containment.

## Sources

The authoritative living description of the design is [`docs/process_model_and_site_isolation.md`](https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md) on `chromium.googlesource.com`. It records the per-site policy, the Android memory threshold, the password-handling-sites fallback, and the COOP / COEP opt-in path. The Chromium blog announcement [*Recent Site Isolation improvements*](https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html), 17 October 2019, is the public-facing source for the Chrome 77 Android rollout and the password-sites-only default below the threshold.

Two upstream sources record the defense the pattern conditionally releases. The original [*Mitigating Spectre with Site Isolation in Chrome*](https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html) blog post of 11 July 2018 is the first public statement of the cross-site speculation-channel defense. The Reis, Moshchuk, Oskov USENIX Security 2019 paper [*Site Isolation: Process Separation for Web Sites within the Browser*](https://www.usenix.org/conference/usenixsecurity19/presentation/reis) records the desktop memory-overhead measurement that motivates the conditional treatment of Android.

The Android device-population context (what fraction of the population sits below the threshold) is derived from the public [Chrome User Experience Report](https://developer.chrome.com/docs/crux), which exposes field-measured device-class memory as a public dataset. The Project Zero [*Reading privileged memory with a side-channel*](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html) post of 3 January 2018 is the authoritative primary source for the speculation-channel threat the pattern's release widens for Scope C.

## Technical Drill-Down

- [`content/public/browser/site_isolation_policy.cc`](https://chromium.googlesource.com/chromium/src/+/main/content/public/browser/site_isolation_policy.cc) — the policy switchboard; the `kSiteIsolationMemoryThresholdMB` constant and the consolidation decision logic live here.
- [`chrome/browser/site_isolation/site_isolation_policy.cc`](https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/site_isolation/site_isolation_policy.cc) — the per-profile observed-password-sites list and the Scope A enforcement path.
- [`content/browser/site_instance_impl.cc`](https://chromium.googlesource.com/chromium/src/+/main/content/browser/site_instance_impl.cc) — the `SiteInstance` implementation; cross-site frame identity is established here regardless of consolidation state.
- [`docs/process_model_and_site_isolation.md`](https://chromium.googlesource.com/chromium/src/+/main/docs/process_model_and_site_isolation.md) — the current design documentation, including the Android consolidation thresholds and the COOP / COEP opt-in path.
- [`chrome://process-internals`](https://www.chromium.org/developers/design-documents/process-models/) — the operator-facing per-frame renderer-assignment view; the consolidated mode is observable here on the running browser.
- [Chromium blog, *Recent Site Isolation improvements*, 17 October 2019](https://blog.chromium.org/2019/10/recent-site-isolation-improvements.html) — the Chrome 77 Android rollout and the password-sites-only default.
- [Chrome Security blog, *Mitigating Spectre with Site Isolation in Chrome*, 11 July 2018](https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html) — the public rationale for the per-site model and the first place the Android memory threshold is named.
- [Chrome User Experience Report](https://developer.chrome.com/docs/crux) — the public field-measured device-class memory dataset; the source for "what fraction of our population sits below the threshold" reasoning.

---

- [Next: Stateless IPC Interface](stateless-ipc-interface.md)
- [Previous: Browser-Renderer Privilege Split](browser-renderer-split.md)