- Inside Look at Modern Web Browser (Part 1)
- Originally written by Mariko Kosaka
- The Nuggets translation Project
- Permanent link to this article: github.com/xitu/gold-m…
- Translator: Colafornia
- Proofread by CoderMing Sakila1012
CPU, GPU, memory, and multi-process architecture
This four-part blog series takes a peek inside Chrome, from high-level architecture to the details of the rendering process. If you’ve ever wondered how browsers translate code into functional websites, or if you’re not sure why a particular technique is recommended to improve performance, this series is for you.
This article, the first in a series, introduces core computing terminology and Chrome’s multi-process architecture.
Tip: If you’re already familiar with CPU/GPU, process/thread concepts, skip to the browser architecture section and start reading.
The core of a computer is CPU and GPU
To understand the environment in which the browser operates, we need to understand several computer parts and what they do.
CPU
Figure 1: Four CPU cores as office workers, sitting at desks doing their respective work
The first computer part you need to know is the Central Processing Unit, or CPU for short. The CPU can be thought of as the brain of a computer. A single CPU core, like the office worker pictured here, can solve many different tasks one by one. It can solve everything from math to art while also knowing how to respond to customer requests. In the past, cpus were mostly single-chip, and a core was like another CPU on the same chip. With modern hardware, you often have more than one kernel, providing more computing power for your phone and laptop.
GPU
Figure 2: Many GPU cores with specific wrenches mean they can only handle a limited number of tasks
A Graphics Processing Unit (GPU for short) is another part of a computer. Unlike cpus, Gpus excel at handling simple tasks across cores simultaneously. As the name suggests, it was originally developed to solve graphics. This is why “GPU use” or “GPU support” in a graphics environment is all about fast rendering and smooth interaction. In recent years, with the popularity of GPU-accelerated computing, more and more computations are possible by GPU alone.
When you launch an app on a computer or phone, it’s the CPU and GPU that power the app. Typically, applications run on cpus and gpus through mechanisms provided by the operating system.
Figure 3: Three-tier computer architecture. The bottom is the machine hardware, the middle is the operating system, and the top is the applications.
Executes programs on processes and threads
Figure 4: Process as bounding box, thread as abstract fish swimming in the process
Another theory to understand before delving into browser architecture is processes and threads. A process can be described as the execution of an application. Threads exist in a process and execute any part of a program.
A process is created when the application is started. Optionally, the program may create one or more threads to help it work. The operating system provides a “block” of memory that processes can 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.
Figure 5: Schematic diagram of a process using memory space and storing application data
Processes can request the operating system to start another process to perform different tasks. At this point, different parts of memory are allocated to the new process. If two processes need to talk, they can do so through interprocess communication (IPC). Many applications are designed so that if a worker process becomes unresponsive, that process can be restarted without stopping other processes running in different parts of the application.
Figure 6: Schematic diagram of individual processes communicating via IPC
Browser architecture
So how do you build a Web browser with processes and threads? It may consist of one process with many threads, or several processes with different threads communicating through IPC.
Figure 7: Process/thread diagram for different browser architectures
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. The way one browser is built can be very different from another.
In this blog series, we illustrate Chrome’s recent architecture as shown below.
At the top is the browser thread, which coordinates with processes that handle tasks for other modules of the application. For renderers, multiple renderers are created and assigned to each TAB. Until recently, Chrome assigned a process to each TAB when possible. Now it tries to assign a process, including iframe, to each site (see Site isolation).
Figure 8: Chrome’s multi-process architecture. Multiple layers are displayed under the render process, indicating that Chrome is running multiple render processes per TAB.
What does each process control?
The following table shows each Chrome process and what it controls:
| process | control |
|---|---|
| The browser | Controls the “Chrome” section of the app, including the address bar, bookmarks, and the back and forward buttons. And handle privileged parts that are invisible to web browsers, such as network requests and file access. |
| Apply colours to a drawing | Control site display within tabs. |
| The plug-in | Control any plug-ins your site uses, such as Flash. |
| GPU | Process GPU tasks independent of other processes. Gpus are divided into different processes because gpus process requests from multiple different applications and draw on the same surface. |
Figure 9: Different processes point to different parts of the browser UI
There are more processes such as extension processes and application processes. If you want to see how many processes are running in your Chrome browser, click the options menu icon in the upper right corner, select more tools, and then select Task Manager. A window opens listing the currently running processes and their current CPU/ memory usage.
The benefits of Chrome’s multi-process architecture
As mentioned earlier, Chrome uses multiple rendering processes. In the simplest case, you can imagine that each TAB page has its own rendering process. Suppose you have three tabs open, each with its own separate rendering process. If a TAB becomes unresponsive, you can close it while the other tabs are still running and ready to use. If all tabs are running on the same process, then when one becomes unresponsive, all tabs become unresponsive. It’s a terrible experience.
Figure 10: The renderer process running on each TAB page is shown
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 function-specific processes. For example, Chrome restricts access to arbitrary files 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 that more memory is being used, and if they were threads in the same process, those copies would not be shared. To save memory, Chrome puts a limit on the amount of memory that can be accelerated. The limit depends on the amount of memory and CPU capacity available on the device, but when Chrome runtime reaches the limit, it will start running the same process on different tabs on the same site.
Save more memory – servitization in Chrome
The same applies to browser processes. Chrome is undergoing an architectural change to run each module of a browser application as a service, making it easy to disassemble or aggregate processes.
The conventional wisdom is that when Chrome is running on powerful hardware, it breaks up each service into different processes to improve stability, but when Chrome is running on resource-limited devices, it aggregates services into a single process to save memory footprint. Prior to this architectural change, a similar consolidation process to reduce memory usage had been used on Android-like platforms.
Figure 11: Servitization of Chrome, moving different services into multiple processes and a single browser process
Renderer process for each iframe – site isolation
Site isolation is a feature recently introduced in Chrome that runs a separate rendering process for each iframe. We’ve talked a lot about per-tab renderers, which allow cross-site iframes to run in a single renderer, sharing memory across different sites. Running a.com looks ok in the same rendering process as b.com.
The same origin policy is the core security model of the Web. The same-origin policy ensures that sites cannot access data from other sites without their permission. One of the main goals of security attacks is to bypass the same origin policy. Process isolation is the most efficient means of separating sites. With Meltdown and Spectre, it becomes increasingly necessary to use processes to separate sites. After Chrome 67, the desktop version of Chrome has site isolation turned on by default, and each TAB’s iframe has a separate rendering process.
Figure 12: Site isolation diagram with multiple renderers pointing to iframes within the site
Enabling site isolation is the result of years of engineering effort. Site isolation is more than just assigning different renderers. It fundamentally changes the way iframes communicate. Opening developer tools on one page and letting iframe run on different processes means developer tools have to work behind the scenes to make it look seamless. Even running a simple Ctrl + F to find a word on a page means searching in different renderer processes. You can see why the browser engineers made the release of site isolation a major milestone!
conclusion
This article explains the advantages of browser architecture versus multi-process architecture from a high-level perspective. We also covered servitization and site isolation in Chrome, which are closely related to multi-process architecture. In the next article, we’ll begin to delve into what happens in processes and threads to render a site.
Did you enjoy this article? If you have any questions or suggestions for future articles, feel free to contact me in the comments section or on Twitter at @kosamari.
If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.
The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.