Introduce key technical terms and Chrome's multi-process architecture
Chrome is standard for programmers, and from the perspective of global market share, its global market share has exceeded 60%.
On the occasion of the 10th anniversary of Chrome, the official released a series of articles, which clearly explained the operation principle of modern browsers in a graphical way. There is a reason why Chrome is so easy to use and so fast. This article is the first of a series of articles. It mainly explains the multi-process architecture of Chrome. The pictures are very interesting and easy to understand.
CPU, GPU, memory and multi-process architecture
We will introduce the specific details of Chrome browser from high-level architecture to rendering pipeline through 4 blogs. If you want to know how a browser converts your code into a functional website; or if you want to determine why a particular technique can improve performance, then this series is for you.
As part 1 of this series, we'll cover key technical terms and Chrome's multi-process architecture.
1. CPU (Central Processing Unit)
The CPU (Central Procession Unit) can be thought of as the brain of your computer. CPU cores, like office workers, can individually handle many different tasks assigned to them. It can handle everything from math to art and return the results. Once upon a time most CPUs were single-core, but in modern hardware you typically operate on multi-core CPUs, which give your phone and computer more computing power.
2. GPU
GPU (Graphics Processing Unit) is another part of the computer. Unlike CPUs, GPUs are better at handling simple tasks and can span multiple cores at the same time.
As the name suggests, it was originally born to deal with graphics. That's why in graphics, when we talk about "using the GPU" or "GPU support", we're usually talking about fast rendering and smooth interactions. In recent years, with the acceleration of GPU development, more and more computing tasks can be realized on GPU alone.
As shown in the figure above, in a three-tier computer architecture, the hardware is at the bottom, the operating system is at the middle, and the applications are at the top.
When you launch an application on a computer or phone, the CPU and GPU are what power the application. Typically, applications run on the CPU and GPU using mechanisms provided by the operating system.
Programs executed on Process and Thread
Another concept to grasp before diving into browser architecture is Process and Thread.
A process can be understood as an executor of an application program, while a thread exists within a process and performs part of the functions of its process program.
Processes are the boundaries of threads, and threads are like fish swimming in the process.
A process can, through the operating system, start another process to perform a different task. At this point, the system will allocate different memory for the new process. If two processes need to communicate, they can communicate by means of IPC (Inter Process Communication).
Many applications are executed this way, so if a worker process (such as a tab) becomes unresponsive, restarting it will not affect other processes of the same application.
browser architecture
So how do you build a web browser using processes and threads?
It could be a process with many different threads or many different processes, with only a few threads able to communicate over IPC.
A very 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 different browsers may have completely different architectures.
The most important thing 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. Until recently, Chrome provided one execution process per tab, and now it tries to provide each site with its own process, including iframes.
As shown in the figure, Chrome's multi-process architecture, the rendering process will display multiple layers, which means that Chrome runs multiple renderer processes for each tab.
What do these processes control?
The following describes each Chrome process and the scope of its control:
Browser: Controls the "Chrome" application, including the address bar, bookmarks, back and forward buttons, and more. You also need to handle Web browser permissions management, such as network requests and file access.
Renderer: Controls all content displayed on the website within the tab.
Plugins: Plugins that control the use of websites, such as Flash.
GPU: Independent of other processes, dedicated to handling GPU tasks, it is divided into different processes, because the GPU will handle requests from multiple processes and draw them on the same Surface.
Different processes that handle different parts of Chrome.
There are many more processes such as: Extension Process and Utility Process. If you want to see the number of running processes in Chrome, click Options in the upper right corner, menu icon → select More Tools → Task Manager.
This will open a window with a list of currently running processes and information on the CPU/Memory they are using.
The 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 3 tabs open, each with its own renderer process. If a tab becomes unresponsive, you can close the unresponsive tab and continue to use it while keeping the other tabs active. If all tabs, run on one process, then when one tab becomes unresponsive, all tabs will not respond. This is embarrassing.
Another benefit of splitting browser 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, the Chrome browser can restrict file access to processes that handle user input, such as the renderer.
Each process has its own private memory space, so they usually contain public infrastructure (eg V8 is Chrome's JavaScript engine). This means more memory usage because if they are threads within the same process, they cannot be shared the way they are.
To save memory, Chrome limits the number of processes it can start. The limit is dynamically adjusted based on the device's memory and CPU power, but when Chrome hits the limit, it opens the site in a new process.
Chrome as a Service - more memory saving
The same approach works for the browser process as well. Chrome is making architectural changes to run each part of the browser program as a service, making it easy to split into different processes or aggregate into the same process.
The general idea is that when Chrome is running on powerful hardware, it may split each service into a different process, providing more stability, but if it's on a resource-constrained device, Chrome will Services are consolidated into one process, thus saving memory usage. Prior to this change, on Android-like platforms, a similar approach had been used to consolidate processes to reduce memory usage.
Site Isolation - independent renderer process
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 having a separate renderer process per tab, which allows cross-site iframes to run in a single renderer process and share memory space between different sites. It seems to be fine 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 other sites' data without consent, bypassing this policy is the main target of security attacks.
Process isolation is the most effective way to separate sites. Because of the classic vulnerabilities of Meltdonw and Spectre, it is very important that we need to use process separation websites. By default, since Chrome 67 with desktop isolation enabled, each cross-site iframe in a tab gets a separate renderer process.
Enabling site isolation is a multi-year engineering effort. Site isolation is not as simple as assigning different renderer processes, it fundamentally changes the way iframes communicate with each other. When we open the devtools on an iframe page running on a different process, it means that the devtools must implement these background communication functions and appear to be seamless. Even using a simple text lookup (Ctrl+F) to find words in a page, this operation is searching through different renderer processes. Because of this, browser engineers consider the release of site isolation as a major milestone.
summary
In this post, we present a high-level view of browser architecture and describe the benefits of a multi-process architecture. We also introduced servitization and site isolation in Chrome, which are closely related to the multi-process architecture. In the next article, we'll start digging into what's going on between these processes and threads in order to display a website.
SHAOXING COLORBEE PLASTIC CO.,LTD , https://www.colorbeephoto.com