The Secrets of modern Browsers part 1: Architecture

Link: developers.google.com/web/updates…

Translation: Crazy geek

CPU, GPU, memory and multi-process architecture

In this four-part series, we’ll cover the nuts and nuts of Chrome from the advanced architecture to the rendering pipeline. If you want to know how the browser converts your code into a functional website, or why you need to use certain techniques to improve performance, this series is for you.

In part 1 of this series, we’ll cover core computing terminology and Chrome’s multi-process architecture.

Note: If you are familiar with CPU/GPU and process/thread concepts, you may want to skip to the browser architecture section of this article.

The core of a computer is the CPU and GPU

To understand the environment in which the browser runs, we need to understand some of the computer parts and their functions.

CPU

The first is the Central Processing Unit — the CPU. The CPU can be thought of as the brain of your computer. The CPU core, in this case as an office worker, can handle many different tasks one at a time as they come in. It can handle everything from math to art, while knowing how to respond to customer calls. In the past, most cpus were single-chip. A core is like another CPU living on the same chip. With modern hardware, you typically get multiple cores to provide more computing power for your phone and laptop.

Figure 1: Four CPU cores sit at each desk as office workers to handle tasks

GPU

Graphics Processing Unit — A GPU is another part of a computer. Unlike cpus, Gpus excel at simple tasks but span multiple cores at once. As the name suggests, it was originally developed for processing graphics. This is why “use GPU” or “GPU support” is associated with fast rendering and smooth crossing in a graphics environment. In recent years, as Gpus accelerate computing, more and more computing can be done on gpus alone.

Figure 2: Many GPU cores with wrenches show that they can handle a limited number of tasks

When you launch an application on a computer or phone, the CPU and GPU are used to support the application. Typically, programs run on the CPU and GPU using the relevant mechanisms provided by the operating system.

Figure 3: Three-tier computer architecture. The machine hardware is at the bottom, the operating system is in the middle, and the applications are at the top.

Executes programs on processes and threads

Another concept to grasp before diving into the browser architecture is Process and Thread. A process can be described as a program in a running state. A thread is a part of a process that exists within it and is used to perform its program tasks.

When you start the program, a process is created. The program may create threads to help it work, but this is optional. The operating system provides a “block” of memory for processes, and all program state is stored in this dedicated memory space. When you close the program, the process also disappears and the operating system frees up memory.

Figure 5: Schematic diagram of a process using memory space and storing data

Processes can ask the operating system to start another process to perform different tasks. When this happens, different memory is allocated for the new process. If two processes need to communicate, they can do so by using interprocess communication (IPC). Many programs work this way, so if one worker process becomes unresponsive, it can be restarted without stopping the other processes running the program.

Figure 6: Schematic diagram of a separate process communicating via IPC

Browser architecture

So how do you build a Web browser using processes and threads? Well, it could be a process with many different threads, or many different processes with a few threads communicating via IPC.

It is important to note here that these different architectures are implementation details. There is no standard specification for how to build a Web browser. One browser may have a completely different structure from another.

In this series of articles, we’ll use Chrome’s latest architecture as described in the figure below.

The most important part is how the browser process coordinates with the program’s other worker processes. For the renderer process, multiple processes are created and assigned to each TAB. Until recently, Chrome provided a process for each TAB; It now tries to provide each site with its own process, including iframe (see Section: Site Isolation).

Figure 8: Chrome’s multi-process architecture. Displaying multiple layers under renderer means Chrome runs multiple renderer processes for each TAB.

What does each process do?

The following table describes each Chrome process and what it controls:

There are more processes, such as extension processes and functional processes. If you want to see the number of processes running in Chrome, click the options menu icon “more_vert” in the upper right corner, select “More Tools,” and then “Task Manager.” This opens a window with a list of the currently running processes and the AMOUNT of CPU/ memory they use.

Benefits of multi-process architecture in Chrome

I mentioned earlier that Chrome uses multiple renderer processes. In the simplest case, you can imagine that each TAB has its own renderer process. Suppose you have three tabs open, each run by a separate renderer process. If one TAB is not responding, you can close the unresponsive TAB and continue running while keeping the other tabs active. If all tabs are running on a process, then when one TAB is unresponsive, none of the tabs will respond. That’s going to be tough.

Figure 10: Schematic showing multiple processes running each TAB

Another benefit of splitting the browser’s work into multiple processes is security and sandboxing. Because the operating system provides ways to limit process permissions, browsers can sandbox certain processes from certain functions. For example, Chrome restricts access to any file from any user input process, such as the renderer process.

Because processes have their own private memory space, they often contain copies of the common infrastructure (for example, V8 is Chrome’s JavaScript engine). This means consuming more memory space, since they cannot follow their own mechanism for sharing if they are running on different threads within the same process. To save memory, Chrome limits the number of processes it can start. This limit varies depending on the memory and CPU power of the device, but when Chrome reaches the limit, it will run multiple tabs open from the same site in a single process.

Save more memory: servitization in Chrome

The same applies to the browser process. Chrome is making architectural changes to run each part of the browser program as a service, which can be easily broken down into different processes or aggregated into a single process.

The general idea is that when Chrome is running on powerful hardware, it might split each service into separate processes to provide greater stability, but if it’s on resource-limited devices, Chrome will consolidate the service into a single process to save on memory footprint. Prior to this change, a similar approach was used on the Android platform to consolidate processes to reduce memory usage.

Figure 11: Servitization of Chrome, moving different services into multiple processes or a single browser process

Frame renderer process: Site isolation

Site isolation is a recently introduced feature in Chrome that allows you to run a separate rendering process for each iframe across a site. We’ve been talking about the one renderer per TAB model, which allows cross-site iframe to run in a single renderer process and share memory space between different sites. It seems ok to run a.com and b.com in the same render process. The same origin policy is the core security model of the Web, which ensures that one site cannot access data from other sites without consent. Bypassing this policy is the primary goal of security attacks. Process isolation is the most effective way to isolate a site. Meltdown and Spectre vulnerabilities reinforce the need to use processes to isolate sites. By default, since Chrome 67 enabled desktop isolation, each cross-site iframe in the TAB gets a separate rendering process.

Enabling site isolation is a multi-year effort. Site isolation is not as simple as assigning different renderers; It fundamentally changes the way iframes communicate with each other. Opening DevTools on a page where a different Iframe process is running means that DevTools has to do a lot of work behind the scenes to make it look seamless. Even finding words in a page with a simple Ctrl + F means searching across different rendering processes. That’s why the browser engineers see the release of site isolation as an important milestone!

conclusion

In this article, we introduced a high-level view of the browser architecture and presented the benefits of a multi-process architecture. We also covered servitization and site isolation in Chrome, which are closely related to multi-process architecture. In the next article, we’ll start delving into exactly what happens between these processes and threads when displaying a web site.