Chromium Process Model

Original address: Https://www.chromium.org/developers/design-documents/process-models

This article describes the different process models supported by chromium, as well as the pros and cons of various models.
1. Overview
Most of today's Web pages contain a lot of dynamic code, which makes them look more like applications than mere documents. This change makes the browser no longer a mere document renderer, but an "operating system". Chromium, like an operating system, ensures that the loaded application runs securely and robustly, using multiple OS processes to isolate the site from the web and between the site and the browser. Each process runs within its own address space, the operating system is responsible for scheduling, and a process crash does not affect other processes. Users can also see the resource usage of each process in the Chromium Task Manager.
Browsers can be cut into different OS processes in a variety of ways, and the architecture has many factors, such as stability, resource usage, and observations of the actual use of memory. Chromium supports four process models for research, and a default model for most users.
2. Support Model
Chromium supports four models for assigning Web pages to the render process. By default, Chromium assigns a separate OS process to each Web site instance that the user accesses. However, users can use the command line to switch process models: All instances of a Web site correspond to a process, and a set of related tab pages uses a process and a process as a whole. Different models have different parsing of content sources, or different relationships between tab pages, or both. The next step is to discuss each model in more detail, as well as the things to be aware of.
2.1 process-per-site-instance
By default, Chromium creates a renderer process for each instance of the user's access to the site, which ensures that different site pages are rendered independently and that different accesses to the same site are isolated. Therefore, a crash or high resource footprint of one site access instance does not affect the rest of the browser. This model is based on the parsing of the original content and the Scripting association between tab pages. Therefore, two tab pages may render the page in the same process, but navigating to a cross-site page in a tab page may cause the render process to switch.
Specifically, "site" = registered domain name (e.g. google.com or bbc.co.uk) + protocol (e.g. https://). This is similar to the definition of same Origin policy, but it places subdomains (such as mail.google.com docs.google.com) and ports (such as http://foo.com:8080) in the same site. This is necessary for pages with different subdomains or ports of the same site to access each other through JavaScript.
A site instance is a combination of a set of pages in the site. Two pages reference each other in the script code to indicate that they are interrelated (for example, one page uses JavaScript to open another page in a new window).
Advantage
Isolation of the different site, a site of the crash will not affect the other. Separate tab pages displaying the same site content are separated, and different processes are created by accessing the same site in different tab pages. The crash of one instance does not affect the other. Weakness memory consumption becomes larger, creating more renderer processes than the Process-per-site model. While increased stability creates opportunities for parallelism, there is more memory consumption. More difficult to implement than Process-per-tab and single-process, this model requires complex logic to support process switching in the tab page.

2.2 Process-per-site
Chromium also supports a process model that isolates different site accesses, putting all instances of the same site into a single process. Use the--process-per-site command line switch when starting chromium. The number of Process-per-site renderer decreases and the robustness of the system is reduced while the memory footprint is reduced.
The advantages are to isolate the different site, like the Process-per-site-instance model, where tasks from different site have no effect on each other. Less memory footprint. Fewer processes were created than the Process-per-site-instance and Process-per-tab models. Effectively reduces the memory used by chromium.
Weaknesses increase the renderer process. Site such as Google.com may have many applications in the browser, and these applications run in the same process. As a result, resource contention and application crashes can affect many tab pages, making the browser seem unresponsive. Without breaking backward compatibility, it is difficult to define site boundaries with a smaller qualification for registered domain names. Difficult to implement, like the Process-per-site-instance model, which needs to support process switching when navigating and brokering some JavaScript interactions.
2.3 Process-per-tab
The Process-per-site-instance and Process-per-site models take into account the source of the content when creating the renderer process. Chromium also supports a simpler model that creates a renderer process for each set of script-connected tab pages. Use the command line--process-per-tab to switch.
Specifically, we refer to a set of script-related tab pages as a browsing instance. This echoes the "unit of related browsing contexts" in the HTML field. Each group contains a tab page and other tab pages that the tab page opens with JavaScript code. These tab pages must be rendered in the same process to support JavaScript calls between tab pages.
Advantage is easy to understand, each tab page has a process for it, not change over time. Weakness one page crash, may cause other page crash. If the user navigates to another site in the tab page in browsing instance, the new page will be shared with the previous browsing in instance. It is important to note that, for security reasons, the Chromium Process-per-tab model, in some cases, also forces the tab page to process the switch. For example, ordinary pages are not allowed to share the fate of special pages such as settings, new blank tabs, and so on. Therefore, this model is not actually much simpler than process-per-site-instance.
2.4 Single Process

Finally, for the purpose of comparison, Chromium also supports a single-process model that switches with--single-process. In this model, browser and render are all running in the same OS process.
The single-process model provides a comparison sample for measuring other multi-process models. It is not a secure and robust architecture, because any one render crash will cause the entire browser to crash. It is designed for testing and learning purposes only, and it may contain bugs that other models do not have.
3. Sandbox and plugins
In each multi-process structure, chromium all render processes are executed in a sandbox process that can access only the limited resources of the user's computer. These processes do not have direct access to the user's file system, graphics card, and most other resources. They obtain a license to access resources through the browser process, and browser add security conditions for those accesses. Therefore, the Chromium browser process can mitigate the potential harm to users of the application compared to the render engine, which can be accessed directly.
Browser plugins, such as Flash and Silverlight, are executed in their own processes, with plugins like Flash and even running in chromium sandbox. In the multi-process architecture supported by chromium, each type of dynamic plug-in has and has only one instance of the process. Therefore, all flash instances run in the same process, regardless of which tab page is used from that site.