Deep Dive into modern Browsers (Part 1)

CPU, GPU, memory, and multithreaded architecture

In this four-part blog series, we’ve taken a look inside Chrome, from the advanced architecture to the details of the render channel. If you’ve ever wondered how browsers can turn your code into a feature on your website, or if you’re not sure why specific techniques are recommended to improve performance, this series is for you.

As part one of this series, we’ll look at some of the computer’s core philosophies and Chrome’s multithreaded architecture.

Computer core CPU and GPU

First we need to understand the browser’s operating environment. We need to understand a few core parts of the computer and what they do.

CPU

Figure 1: 4CPU cores, like office workers sitting at every desk to deal with incoming tasks.

First, the Center Processing Unit, also known as the CPU, is considered the brain of a computer. A CPU core, think of it as an official worker, can handle one task after another. For the most part, the CPU was a simple chip. A core is just like another CPU in the same chip. In modern electronics, there is often more than one core, giving you more processing power in your phone and laptop.

GPU

Figure 2: Many GPU processor cores with wrenches, indicating that they can only handle a limited number of tasks.

The Graphics Processing Unit, or GPU, is another part of the computer. Unlike cpus, Gpus excel at simple tasks, but can span multiple cores simultaneously. As the name suggests, it was originally developed for processing graphics. This is why, in graphics environments, using gpus, or GPU support, has always been associated with faster rendering and smoother intersections. In recent years, as GPU computing speeds up, it is possible for gpus to perform more and more calculations alone.

When you open an application on your computer or phone, the CPU and GPU drive the application. In layman’s terms, applications run on cpus and gpus through the mechanism of the operating system.

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

Run programs in processes and threads

Figure 4: A process is like a closed box, and threads are like abstract fish swimming around in the process

Another concept that needs to be recognized before I go into browser architecture is processes and threads. The running of an application can be understood as a process. A thread exists in a process, that is, executing a part of a program.

When you run a program.A process is createdThe program may create (many) threads to help it work, but this is not necessary. The operating system provides a memory space for processes to work on, and all applications remain in a separate memory space. When you close the application, the process is erased from memory by the operating system.

Figure 5: Schematic diagram of process space usage and how to store an application. See the animation

A process can ask the operating system to run other processes to run different tasks. When this is done, memory allocates different space to the new process. Two processes can communicate with each other through Inter Process Communication (IPC). Many applications work with this design, so if a worker process is no longer responsive, it can be restarted without stopping the rest of the application running on the process.

Figure 6: Communication between different processes via the designed IPC. See the animation

Browser design

So how do browsers use processes and threads today? Does it use one process with multiple threads? Or are there multiple processes, each with many threads, that communicate with each other using IPC?

Figure 7: Different browsers use different process/thread architectures

One thing to note here is that different architectures are different implementation details. There is no specification for how to build a browser. One browser’s implementation of one method may be completely different from another.

For this blog series, we’ll use Chrome’s most recent architecture, as shown below.

The first diagram shows browser processes coordinating processes that handle other functional modules. For renderers, one is created for each TAB page. Previously, When a TAB page was ready, Chrome assigned it to a process. It now tries to provide its own processes for each site, including Iframes (see:Site Isloation)



Figure 8: This diagram represents Chrome’s multi-process architecture. Multiple layers are shown under Render, indicating that Chrome runs multiple render processes for each TAB page.

What does each process control

Process isolated tasks in other processes. It is spread out across processes because the GPUS process requests from various applications and draw them on the same plane

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

There are more processes, such as: extension process, public process, etc. If you want to see more processes running in your Chrome, click on the three dots that have merchants. Select More Tools, and then select Task Manager. This opens a window with a list of currently running processes, and you can see what CPU/ memory is being used, etc.

Benefits of Chrome’s multi-process architecture

Earlier, I mentioned that Chrome uses multiple rendering processes. The simplest case: you can imagine that each TAB page has its own rendering process. If you have three tabs open, each TAB runs a separate render process. If you want the TAB page to stop responding, then you can close the TAB page that does not respond and continue to use it, ensuring that other tabs are not affected. If all TAB pages are running in the same process, when one TAB page does not respond, all TAB pages do not respond. That would be terrible.

Figure 10: Shows a different process running on each TAB page. See the animation

Another benefit of the browser’s separate way of working is that different processes are safe and sandboxed. Because the operating system provides a way to limit process ownership, browsers can sandbox some functional processes. One example: Chrome limits access to files that various input processes, such as renderers, can do at will.

Because processes have their own private memory space, they often contain copies of common utilities (e.g. V8 is Chrome’s JS engine). If they are not in the same process and have no way to share with each other, they consume more memory space. How many threads Chrome can drop for a thread to save memory. This limitation depends on the memory and CPU support provided by your device, but when Chrome reaches its limits, it will run multiple tabs in the same process.

Save more memory with Chrome services

The same applies to the browser process. Chrome is undergoing a structural change. By running each part of the browser as a service, it can be easily split into different processes or aggregated into a single process.

The common thinking is that When Chrome is running on powerful hardware, its applications will run in different processes as separate services to get more stability, but when running on resource-constrained devices, Chrome will put the services in one process to save memory. Prior to this change, similar merging processes to reduce memory usage had been used on The Android platform.



Figure 11: Shows Chrome’s service architecture moving from multiple services scattered across multiple processes to a single process.See the animation

Render process per frame – Site Isolation

Site Isolation is a recently introduced feature in Chrome that allows you to run different rendering processes for your quadrate Site services. We are talking about using a renderer process for each TAB model, which would allow iframes across sites to run in the same renderer process and different sites to share memory space. Running an a.com and a b.com in the same render process looks fine. The same origin policy is the core security mechanism of the Web, which ensures that one site, in a different case on another site, cannot access data. Bypassing this policy is the primary goal of security attacks. Process separation is the most effective way to separate sites. Meltdown and Spectre for crashes and uncertain errors, we need to isolate sites using processes to make them easier to troubleshoot. Since Chrome67, site separation is enabled by default on the desktop, and every time you TAB a site’s iframe, you get a separate rendering process.

Figure 12: Shows site separation, with multiple renderers executing iframes within the site.

Site separation technology has been available for many years. Site separation is not simply a matter of assigning different renderers; It fundamentally changed the way iframes communicate with each other. Opening a DevTools page with iframes on it means devTools has to do some behind-the-scenes work to make it look seamless. Even if you run a simple Ctrl+F to find a word on a page, that means you need to look it up across different smudge processes. Now you can see why our browser engine releases site separation as a major milestone feature

conclusion

Here, we summarize the benefits of the browser advanced architecture at a higher level, and then the multi-process architecture. It also summarizes Chrome services and site separation, which are deeply related to multi-process features. In the next article, we’ll delve into what processes and threads do to display a website.

The original address: developers.google.com/web/updates…