An in-depth look at modern Web browsers (Part 1)

This article is translated, and the content should be as consistent as possible with the original text. If there is any mistake in translation, criticism and correction are welcome. Inside Look at Modern Web Browser (Part 1) https://developers.google.com/web/updates/2018/09/inside-browser-part1Copy the code

CPU, GPU, memory and multi-process architecture

In this four-part blog series, we’ll delve into the details of Chrome from the advanced architecture to the rendering pipeline. If you want to know how browsers turn your code into a functional website, or if you’re not sure why specific techniques are recommended to improve performance, then this series is for you.

In the first part of this series, we’ll look at computing terminology and Chrome’s multi-process architecture.

Note: If you are familiar with CPU/GPU and process/thread concepts, you can skip to browser architecture.

The core of a computer is the CPU and GPU

To understand the environment in which the browser operates, we need to understand some of the computer parts and what they do.

CPU

The first is the central processing unit, or CPU, which can be thought of as the brain of your computer, a CPU core, like the office worker in the picture, that can handle many different tasks one by one. It can handle everything from math to art, while knowing how to answer customer calls. In the past, most cpus were single-chip, with a core acting like another CPU within the same chip. Now in hardware, you can often have multiple cores to give more computing power to your phone and computer.

Figure 1: Four CPU cores sit at each desk as office workers and handle the tasks they come in

GPU

A graphics processing unit – or GPU – is another part of a computer. Unlike cpus, Gpus are better at handling simple tasks, but across multiple cores at once. As the name suggests, it was originally developed to handle graphics. This is why “using GPU” or “GPU-enabled” in the image context is associated with fast rendering and smooth interchange. In recent years, as GPUS accelerate computing, more and more computing will be able to use gpus directly alone.

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

When you launch an application on a phone or computer, the CPU and GPU power the application and the application runs on the CPU and GPU that use the mechanism provided by the operating system.

Figure 3: A 3-layer computer architecture diagram, with computer hardware at the bottom, operating system in the middle, and applications at the top

Executes programs on processes and threads

Another concept to grasp before delving into browser architecture is processes and threads. A process can be described as the execution of an application. A thread is a thread that exists inside a process and executes any part of its process program.

Figure 4: Process as bounding box, thread is like abstract fish swimming in the process

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

Click on the image to see the animation

Figure 5: Diagram of processes that use memory space and store application data

A process can ask the operating system to start another process to run different tasks. When this request occurs, different portions of memory are allocated to the new process. If two processes need to communicate, they can do so using interprocess communication (IPC). Many applications are designed to work this way, so if the worker process does not respond, it can be restarted without stopping other processes running different parts of the application.

Click on the image to see the animation

Figure 6: Diagram of a separate process communicating through 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 multiple processes communicating through IPC, each with several threads.

Figure 7: Different browser architectures in the process/thread diagram

The important thing to note here is that these different architectures are implementation details. There is no standard specification for how to build a Web browser, and one browser may be implemented in a completely different way than another.

In this series of blogs, we’ll use Chrome’s latest architecture, described below.

At the top are the browser processes that work with other processes that handle different parts of the application. For renderer processes, multiple processes were created and assigned to each TAB, and until recently, Chrome provided one process per TAB when possible. It now tries to provide each site with its own process, including iframe (see Site isolation).

Figure 8: Chrome’s multi-process architecture. A multi-layer display under the renderer process means that Chrome runs multiple renderer processes for each TAB.

Which process controls what?

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

Figure 9: Different processes point to different parts of the browser UI

There are more processes, such as extension processes and user processes. If you want to see the number of processes running in Chrome, click the options menu icon in the upper right corner, select more tools, and then select 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

Earlier, I mentioned 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 crashes, you can simply close the crashed TAB and continue operating while keeping the other tabs active. If all tabs are running on one process, when one crashes, all tabs cannot respond, which is sad.

Click on the image to see the animation

Figure 10: A diagram showing the 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 a way to restrict process permissions, browsers can sandbox certain processes from certain functions. For example, Chrome restricts arbitrary file access to processes that process arbitrary user input, such as the renderer process.

Because processes have their own private memory space, they often contain copies of the common infrastructure (such as V8, which is Chrome’s JavaScript engine). This means more memory usage, because if they are threads within the same process, they cannot be shared as they are. To save memory, Chrome limits the number of processes it can start, depending on the memory and CPU capacity of your device, but when Chrome reaches that limit, it will start running multiple tabs from the same site in a single process.

Save more memory – servitization in Chrome

The same approach applies to browser processes, and Chrome is undergoing architectural changes to run each part of a browser program as a service, which can be easily split into different processes or aggregated into a single process.

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

Click on the image to see the animation

Figure 11: A schematic of Chrome servitization moving different services into multiple processes and a single browser process

Per-frame renderer process-site isolation

Site isolation is a recently introduced feature in Chrome that runs a separate renderer process for each cross-site IFrame. We’ve been talking about one renderer process per TAB model, which allows cross-site iframes to run in a single renderer process and share memory space between different sites. There seems to be no problem running a.com and b.com in the same renderer process. The same origin policy is the core security model of the network, which ensures that one site cannot access data from other sites without consent. Bypassing this policy is the primary target of security attacks, and process isolation is the most effective way to isolate a site. With Meltdown and Spectre, it becomes more obvious that we need to use processes to isolate sites. Since Chrome67, site isolation has been enabled by default on the desktop, with a separate renderer process for each cross-site iframe in the TAB.

Figure 12: Site isolation diagram; Multiple renderer processes point to iframes within the site

Enabling site isolation has been a multi-year effort, and it is not as simple as assigning different renderer processes. It fundamentally changes the way iframes communicate with each other. Opening DevTools on a page where iframe is running on a different process means devTools must perform behind-the-scenes work to make it look seamless. Even running simple Ctrl+F to find words on a page means searching in different renderer processes. You can see why browser engineers call the release of site isolation a major milestone.

conclusion

In this article, we’ve covered a high-level view of the browser architecture and covered 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 delve into what happens between these processes and threads in order to display the site.