Chrome is standard for programmers, and in terms of global market share, it has more than 60% of the global market.

In honor of Chrome’s 10th anniversary, we’ve released a series of articles that clearly illustrate how modern browsers work, and why Chrome works so well and so fast.

This series of 4 articles, the first article mainly explains Chrome multi-process architecture, with pictures very interesting, also very easy to understand, is a popular science article. If you are interested, you can read it. If the response is good, I will continue to translate the following 3 articles. If you feel good, click a like or leave a message to share!

CPU, GPU, memory, and multi-process architectures

In four posts, we’ll cover the details of Chrome from the advanced architecture to the rendering pipeline. If you’re wondering, how does the browser turn your code into a functional website? Or if you want to determine why specific techniques can be used to improve performance, this series is for you.

In part 1 of this series, we’ll cover key technical terms and Chrome’s multi-process architecture.

1. CPU

The CPU(Central Procession Unit) can be thought of as the brain of your computer. CPU cores, like office workers, can individually handle the many different tasks assigned to them. It can handle everything from math to art and return the results. There was a time when most cpus were single-core, but in modern hardware, you typically operate on multi-core cpus, which provide more computing power for your phone and computer.

2. GPU

A Graphics Processing Unit (GPU) is another part of a computer. Unlike cpus, Gpus are better at handling simple tasks and can span multiple cores at once. As the name suggests, it was originally developed for processing graphics. That’s why in graphics, when we talk about “using a GPU” or “GPU support”, we’re usually talking about fast rendering and smooth interactions. In recent years, with the accelerated development of GPU, more and more computing tasks can be realized on GPU alone.

As shown above, in a three-tier computer architecture, the hardware is at the bottom, the operating system is in the middle, and the applications are at the top.

When you launch an application on a computer or phone, the CPU and GPU power the application. Typically, applications run on cpus and gpus using mechanisms provided by the operating system.

Programs executed on Processes and Threads

Another concept to grasp before delving into the browser architecture is Process and Thread.

A process can be understood as the executor of an application program, while a thread exists inside a process and performs some functions of its process program.

The process is the boundary of the thread, and the thread is like the fish swimming in the process.

A process can start another process to perform different tasks through the operating system. At this point, the system will allocate different memory for the new process. If two processes need to communicate with each other, they can communicate through inter-Process Communication (IPC). Many applications execute this way, so if a worker process (such as a TAB) is unresponsive, restarting it does not affect other processes in the same application.

Browser architecture

So how do you build a Web browser using processes and threads?

It may be an independent process with multiple threads, or a structure with multiple processes but only some of them communicate IPC.

One important point to note here is that these different architectures are implementation details. There is no standard specification for how to build a Web browser, and the architecture of different browsers can be completely different.

Most important is how the browser process coordinates with other processes responsible for different parts of the application. For the renderer process, multiple processes are created and assigned to each TAB. Chrome, which until recently provided an execution process for each TAB, is now trying to provide its own process for each site, including iframe.

As you can see in Chrome’s multi-process architecture, the renderer process displays multiple layers, indicating that Chrome is running multiple renderer processes for each TAB.

What do these processes control?

Here’s a look at each Chrome process and what it controls:

  • Browser: Controls the Chrome application, including the address bar, bookmarks, back and forward buttons, etc. You also need to handle permission management for Web browsers, such as network requests and file access.
  • Renderer: Controls all content displayed on the site in tabs.
  • Plugins: Plugins that control the use of websites, such as Flash.
  • GPU: Independent of other processes and dedicated to processing GPU tasks, it is divided into different processes because the GPU will process requests from multiple processes and draw them on the same Surface.

Different processes for handling different parts of Chrome.

There are more processes, such as the Extension Process and the Utility Process. If you want to see how many processes are running in Chrome, click on the menu icon in the upper right corner → Choose more Tools → Task Manager.

This opens a window with a list of currently running processes and the CPU/Memory information they use.

Benefits of Chrome’s multi-process architecture

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 with its own renderer process. If one TAB is unresponsive, you can close the unresponsive TAB and continue using it while keeping the other tabs active. If all tabs are running on the same process, then when one TAB is unresponsive, none of the tabs will respond. This is awkward.

Another benefit of splitting browser work into multiple processes is security and sandboxing. Because the operating system provides a way to limit process permissions, browsers can sandbox certain processes from certain functions. For example, Chrome can restrict file access to processes that process user input, such as renderers.

Each process has its own private memory space, so they usually contain common base functionality (V8 is Chrome’s JavaScript engine, for example). This means more memory usage because they cannot be shared the way they are if they are threads within the same process. To save memory, Chrome limits the number of processes it can start. The limits are dynamically adjusted based on the memory and CPU power of the device, but when Chrome reaches the limits, it opens the site in a new process.

Chrome servitization – Saves more memory

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

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

Site isolation – Separate renderers

Site isolation is a recently introduced feature in Chrome that allows you to run a separate renderer process for each cross-site iframe.

We’ve been talking about a separate renderer process for each TAB, which allows cross-site iframes 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 renderer process. The same origin policy is the core security model of the network. It ensures that one site cannot access the data of other sites without consent. Circumventing this policy is the main target of security attacks. Process isolation is the most effective way to isolate a site. Because of the classic vulnerabilities Meltdonw and Spectre, we need to use process separation sites, which is very important. By default, since Chrome 67 enabled desktop isolation, each cross-site iframe in the TAB gets a separate renderer process.

Enabling site isolation is a multi-year project. Site isolation is not as simple as assigning different renderers; it fundamentally changes the way iframes communicate with each other. When we open DevTools on iframe pages running on different processes, it means devTools must implement these background communication functions and look seamless. Even if you use simple word lookup (Ctrl+F) to find words on a page, this operation is searching for different renderer processes. This is why browser engineers see the release of site isolation as an important milestone.

summary

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 the multi-process architecture. In the next article, we’ll start delving into what happens between these processes and threads in order to display a web site.

Original address:

https://developers.google.com/web/updates/2018/09/inside-browser-part1

“Online roundtable” 👈 recommends my knowledge planet, 50 quality questions a year, online learning on the table.

Recommended reading:

Writing is the core competitiveness of | Google engineers decryption “guess draw little song” | illustration: HTTP request scope | Android experience | P adaptation technology entrepreneurship choice listing HTTP transmission coding | | what is cost you? HTTP cache | | | HTTP content-type illustration about HTTP cookies auxiliary model of actual combat | | | the org.eclipse.swt.accessibility auxiliary mode small program Flex layout | good PR makes you more | password management