Multi-process architecture of chrom

Multi-process Architecture(Original address: http://www.chromium.org/developers/design-documents/multi-process-architecture)

This document describes the upper-layer architecture of chromium.

A. Problem

There is almost no possibility of creating a rendering engine that never crashes or hangs up, or a perfect and secure rendering engine.

In some ways, browser is a bit like a single user, multi-task operating system in the past. In such an operating system, if there is an improper program, the entire system will crash. This is like a webpage or plug-in error, which can cause the crash of the entire browser and all the labels currently running.

The operating system is much stronger, because they divide applications into independent processes, which run independently and do not affect each other, crash in a program generally does not affect other applications or the entire system, and the data of a user who wants to access other users is not allowed.

B. Architecture Overview

The main process, also known as the "Browser" process, is used to run the UI and manage the tab.

Similarly, a tab process is called a "render" process, which uses the web-kit Layout Engine to parse and arrange HTML.

C. manage multiple render processes

Each render process has a global renderprocess object management, communication between the parent process (browser), and Global Status. browser maintains a corresponding renderprocesshost for each renderprocess, used to manage the browser status and for communication. The communication between browser and Renderer uses Chromium's IPC System.

D. Management View

Each render process has one or more renderview objects, which are managed by renderprocess. renderview corresponds to the content of each tab.

The corresponding renderprocesshost maintains an renderviewhost object, which corresponds to the view in each Renderer.

Each view has a viewid. This viewid is used to differentiate multiple views in a Renderer, and these IDs are unique in a Renderer process, however, the entire browser is not unique. Therefore, to distinguish a view, you need an renderprocesshost and a view ID.

The communication between browser and the specified tab content is completed through these renderviewhost objects. These renderviewhost objects know how to transmit messages to renderprocess through renderprocesshost and then to renderview.

E. Components and interfaces

In the render process:

• Renderprocess processes IPC through the renderprocesshost corresponding to the browser. Each render process has only one renderprocess, which is the communication path between browser and render.
• The renderview object communicates with the renderviewhost in the browser (through renderprocess), and The renderview object also communicates with our WebKit embedded layer. This object represents the page content in the tab or window.

In the browser process:

• The browser object represents the browser window at the highest level.
• The renderprocesshost object represents the communication between the browser and renderview. Each render process has only one renderprocesshost.
• The renderviewhost object encapsulates the communication with renderview.
• In browser, renderwidgethost processes the input and painting of renderwidget.

F. Share the render Process

Generally, a new window or a new tab will create a new process and a renderview. However, sometimes multiple tabs may share a render process.

When a web application opens a new window, it looks forward to a synchronous communication, such as a javascript window. open. In this case, we need to reuse this process in the new window.

We also have a way to point a new tab to an existing render process, which is used when there are too many processes, or the user already has a process to open and navigate to the domain name. You can view these methods here (http://www.chromium.org/developers/design-documents/process-models ).

G. Renderer that monitors crashes and hooligans

When each IPC is connected to the browser process, the browser process monitors the process handle.

If these handles are triggered, the render process has crashed and tabs is notified of this crash. So far, we will display a "Sad tab" page to notify users that this Renderer has crashed. Click the reload button to reload the page or open a new navigation. When this happens, we will notify that there are no processes and a new one will be created.

H. Turn Renderer into a sandbox

If WebKit runs in a separate process, we can restrict its access to system resources. For example, we can allow this Renderer to only access the network through its parent process browser. Similarly, we can restrict the access to the file system through the operating system's permission system.

In addition to restricting Renderer access to the file system and network, we can also restrict Renderer access to User display and related objects. Every render process runs in an invisible window, which is independent and called "desktop", which can block a "dangerous" Renderer (implanted with dangerous code) open a new window or capture your keyboard clicks.

I. Return the memory

Because Renderer runs in a separate process, we need to consider the hidden low-priority problem of tabs.

Normally, Windows will automatically put a minimal process into a "valid memory pool". When the process is in the low-memory state, Windows will store the memory in the hard disk, until they change to higher-priority memory.

To make the program visible to users better respond, we can apply this principle to "hidden" tabs. When a Renderer is not the highest level tab, we can release the "Working Set" Size of the process as a hint to the system, so that the system can transfer its memory to the hard disk (if the system thinks it is needed ).

We found that reducing the working set size also reduces the performance of Tab switching. When the user switches between two tabs, we gradually release the memory. This means that if the user switches back to the recently used tag, the memory of the tag is more likely to be page-based (stored to disk), but the less used tab will not be page-based.

Of course, users with enough memory don't need to worry about this, because Windows only recycles the data they need, so if the memory is enough, this will do no performance benefit.

This helps us to get a more optimized memory usage at a low memory. The less used tab will be completely replaced by the memory to the hard disk, while the front-end tab, it can be fully loaded into the memory. In contrast, a single-process browser randomly distributes all its tab data to the memory, so that it cannot separate the used or not practical data so clearly, in this way, memory and performance are wasted.

J. Plug-ins

The Firefox-style npapi plug-in runs in its own process and is separated from Renderer. Specific can see here: http://www.chromium.org/developers/design-documents/plugin-architecture.