This document describes the different process models that Chromium supports for its rendering engines, as well as caveats in the models that are relevant for the beta release.
Web content has evolved to contain significant amounts of active code that run within the browser, making many web sites more like applications than documents. This evolution has changed the role of the browser into an operating system rather than a simple document renderer. Unlike current browsers, Chromium is built like an operating system to run these applications in a safe and robust way, using multiple OS processes to isolate web sites from each other and from the browser itself. This improves robustness because each process runs in its own address space, is scheduled by the operating system, and can fail independently. Users can also view the resource usage of each process in Chromium's Task Manager.
There are many ways that a web browser could be segmented into different OS processes, and choosing the best architecture depends on many factors, including stability, resource usage, and observations from actual usage. For its beta release, Chromium supports four different process models to allow experimentation and measurements, which will help us select a default model that best fits most users.
Chromium supports four different architectures that affect how the browser is split into OS processes. By default, Chromium uses a separate OS process for each instance of a web site the user visits. However, users can specify command-line switches when starting Chromium to select one of the other architectures: Chromium can instead use one process per web site, or it can isolate each group of connected tabs, or it can place everything in a single process. These models differ in whether they reflect the origin of the content, the browser's user interface, or both. This section discusses each model in greater detail; caveats in Chromium's current implementation are described later in this document.
By default, Chromium creates a rendering process for each instance of a site the user visits. This ensures that pages from different sites are rendered independently, and that separate visits to the same site are also isolated from each other. Thus, failures (e.g., renderer crashes) or heavy resource usage in one instance of a site will not affect the rest of the browser. This model is based on both the origin of the content and aspects of the browser's user interface, such as tabs and windows. As a result, two tabs may display pages that are rendered in the same process, while navigating to a cross-site page in a given tab may switch the tab's rendering process. (Note that there are important caveats in Chromium's current implementation, discussed in the Caveats section below.)
We define a site as a registered domain name (e.g., google.com or bbc.co.uk) plus a scheme and port (e.g., https://foo.com:8080). This is similar to the origins defined by the Same Origin Policy, but it groups subdomains (e.g., mail.google.com and docs.google.com) into the same site. This is necessary to allow pages that are in different subdomains of a site to access each other via Javascript, which is allowed by the Same Origin Policy if they set their document.domain variables to be identical.
A site instance is a collection of connected pages from the same site. We consider two pages as connected if the user navigates to one from the other (e.g., by opening a link in a new tab) or if the pages share a script connection (e.g., if one page opened the other in a new window using Javascript).
Strengths
- Isolates content from different sites. This provides a meaningful form of fate sharing for web content, where pages are isolated from failures caused by other web sites.
- Isolates independent tabs showing the same site. Visiting the same site independently in different tabs will create different processes. This will prevent contention and failures in one instance from affecting other instances.
Weaknesses
- More memory overhead. This model will create more renderer processes than the process-per-site model described below. While this increases stability and may add opportunities for parallelism, it also increases memory overhead.
- May require proxying for some JavaScript calls. A small set of JavaScript interactions are permitted between pages from different origins, such as accessing certain properties of the window object. A complete implementation should proxy such interactions between renderer processes. (For more on this issue, see the Caveats section.)
Chromium also supports a process model that isolates different sites from each other, but groups all instances of the same site into the same process. To use this model, users should specify a --process-per-site command-line switch when starting Chromium. This creates fewer renderer processes, trading robustness for lower memory overhead. This model is based on the origin of the content and not aspects of the browser's user interface, such as tabs and windows.
Strengths
- Isolates content from different sites. As in the process-per-site-instance model, pages from different sites will not share fate.
- Less memory overhead. This model likely creates fewer concurrent processes than the process-per-site-instance and process-per-tab models. This may be desirable to reduce Chromium's memory footprint.
Weaknesses
- Can result in large renderer processes. Sites like google.com host a wide variety of applications that may be open concurrently in the browser, all of which would be rendered in the same process. Thus, resource contention and failures in these applications could affect many tabs, making the browser seem less responsive. It is unfortunately hard to identify site boundaries at a finer granularity than the registered domain name without breaking backwards compatibility.
- May require proxying for some JavaScript calls. Like the process-per-site-instance model, this will require support for some cross-process JavaScript interactions.
Process-per-tab
The process-per-site-instance and process-per-site models both consider the origin of the content when creating renderer processes. Chromium also supports a simpler model which dedicates one renderer process to each group of script-connected tabs. This model can be selected using the --process-per-tab command-line switch.
Specifically, we refer to a set of tabs with script connections to each other as a browsing instance, which also corresponds to a "unit of related browsing contexts" from the HTML5 spec. This set consists of a tab and any other tabs that it opens using Javascript code. Such tabs must be rendered in the same process to allow Javascript calls to be made between them (most commonly between pages from the same origin), without needing to serialize references between renderer processes.
Strengths
- Simple to understand. Each tab has one renderer process dedicated to it that does not change over time.
Weaknesses
- Leads to undesirable fate sharing between pages. If the user navigates a tab in a browsing instance to a different web site, the new page will share fate with any other pages in the browsing instance.
Single process
Finally, for the purposes of comparison, Chromium supports a single process model that can be enabled using the
--single-process command-line switch. In this model, both the browser and rendering engine are run within a single OS process, much like Firefox or Safari.
The single process model provides a baseline for measuring any overhead that the multi-process architectures impose. It is not a safe or robust architecture, as any renderer crash will cause the loss of the entire browser process. It is designed for testing and development purposes, and it may contain bugs that are not present in the other architectures.
Sandboxes and plug-ins
In each of the multi-process architectures, Chromium's rendering engines are executed within a sandboxed process that has limited access to the user's computer. These processes do not have direct access to the user's filesystem, display, or most other resources. Instead, they gain access to permitted resources only through the browser process, which can impose security policies on this access. As a result, Chromium's browser process can mitigate the damage that an exploited rendering engine can do.
Browser plug-ins, such as Flash and Adobe Reader, are also executed in their own processes, though these are not yet sandboxed. In each of the multi-process architectures that Chromium supports, there is one process for each type of active plug-in. Thus, all Flash movies run in the same process, regardless of which sites or tabs they appear in.
In preparation for Chromium's beta release, not all aspects of the multi-process architectures have been fully implemented. This section lists a few caveats with Chromium's current implementation, along with their implications.
- Renderer-initiated navigations within a tab do not yet lead to process switches. If the user follows a link, submits a form, or is redirected by a script, Chromium will not attempt to switch renderer processes in the tab if the navigation is cross-site. Chromium only switches renderer processes for browser-initiated cross-site navigations, such as typing a URL in the location bar or following a bookmark. As a result, pages from different sites may be rendered in the same process, even in the process-per-site-instance and process-per-site models. This is likely to change in future versions of Chromium.
There is one exception: Chromium allows pages to fork a new rendering process via JavaScript, in a way that is compatible with the links that appear in Gmail messages. A page can open a new tab to about:blank, set the new tab's window.opener variable to null, and then redirect the new tab to a cross-site URL. In that case, a renderer-initiated navigation will cause Chromium to switch renderer processes in the new tab. Thus, opening a link from Gmail (or pages with similar logic) will not adversely affect the Gmail process.
- Frames are currently rendered in the same process as their parent page. Although cross-site frames do not have script access to their parents and could safely be rendered in a separate process, Chromium does not yet render frames in their own processes. Similar to the first caveat, this means that pages from different sites may be rendered in the same process. This will likely change in future versions of Chromium.
- There is a global limit to the number of renderer processes that Chromium will create. This prevents the browser from overwhelming the user's computer with too many processes. The limit is currently 20 renderer processes on most machines, and fewer on machines with small amounts of installed memory. As a result, a single renderer process may be dedicated to multiple sites. This reuse is currently done at random, but future versions of Chromium are likely to apply heuristics to more intelligently allocate sites to renderer processes.
- Location bar searches do not yet lead to process switches. Location bar searches are browser-initiated navigations that display results from the user's default search engine. Users are likely to follow cross-site links from these search result pages. However, due to the first caveat, these pages would be rendered in the search engine's process, rather than a new process. For users of the process-per-site model that search frequently, this would cause most of their pages to render in the same process. Thus, Chromium currently renders location bar search results in the tab's current process (using a new process if the tab is new), rather than in the process dedicated to the search engine. As a result, there may be multiple processes dedicated to a given site. In the next version of Chromium, this heuristic will likely be applied only in the process-per-site model. It will likely be removed in future versions, once the first caveat has been resolved.
- Permitted cross-site JavaScript calls do not yet work across processes. A small set of Javascript interactions (e.g., certain properties of the window object) are not subject to the Same Origin Policy, and can be accessed from pages from a different origin (within the same browsing instance). Because the process-per-site-instance and process-per-site models may place cross-site pages in a separate renderer process, attempts to access these objects and functions will currently fail. We view this as acceptable due to the first caveat, since this will only affect cases where the user navigates a tab to a cross-site page via the location bar or bookmarks. This suggests a user intention to treat the page as independent from other tabs. In future versions of Chromium, we will likely proxy calls for this small set of objects and functions between rendering processes. This will allow such scripts to work as expected, allowing us to resolve the first caveat.
Two classes in Chromium represent the abstractions needed for the various process models:
BrowsingInstance and
SiteInstance.
The
BrowsingInstance class represents a set of script-connected tabs within the browser, also known as a unit of related browsing contexts in the HTML 5 spec. In the process-per-tab model, we create a renderer process for each
BrowsingInstance.
The
SiteInstance class represents a set of connected pages from the same site. It is a subdivision of pages within a
BrowsingInstance, and it is important that there is only one
SiteInstance per site within a
BrowsingInstance. In the process-per-site-instance model, we create a renderer process for each
SiteInstance.
To implement process-per-site, we coalesce all
SiteInstances from the same site. Thus, there is only one
SiteInstance per site throughout the browser, regardless of
BrowsingInstance.
