A Peek into modern Browser Architecture (part 1)

preface

This article is my translation of Mario Kosaka’s inside Look at Modern Web Browser series. Translation here does not mean literal translation, but to express the meaning of the author based on personal understanding, and try to add some relevant content to help people better understand.

CPU, GPU, memory and multi-process architecture

In this four-part tutorial series, I’ll start with Chrome’s high-level architecture and work my way down to the details of rendering pipelines. If you’ve ever wondered how a browser can turn your code into a usable website, or if you’re wondering why a certain way of writing code can improve a website’s performance, you’re in the right place. This article is for you.

In the first article in this series, we’ll take a look at some key computer terms and the multi-process architecture of Chrome.

The core of a computer – CPU and GPU

To understand the browser environment, we need to understand some of the computer components and what they do.

CPU

First, let’s talk about the Central Processing Unit (CPU), the brain of a computer. A CPU is a chip in a computer that has one or more cores on it. We can compare a core of the CPU to an office worker, who has powerful functions, such as astronomy, geography, piano, chess, painting and calligraphy. It can process the tasks assigned to it sequentially one by one. Long ago, most cpus had only one core, but today’s hardware devices often have multiple cores, because multi-core cpus can greatly increase the computing power of phones and computers.

The four CPU cores happily work on the tasks assigned to them, one after the other, at their respective stations

GPU

The Graphics processor, or GPU (Graphics Processing Unit), is another important part of a computer. Unlike a powerful CPU core, a single GPU core can only handle a few simple tasks, but it is better than a single GPU with many, many cores working at the same time, which means its parallel computing capability is very strong. Graphics processors (Gpus) are designed to handle graphics, so when you talk about using or GPU backed graphics, you’re going to think of things like fast graphics rendering and smooth user experience. In recent years, as the concept of GPU acceleration has gained popularity, computing on gpus alone has become more and more common.

Each GPU core has only one wrench, which means its capabilities are very limited, but there are so many of them!

When you open an application on your phone or computer, it’s actually the CPU and GPU behind the application. In general, your application needs some mechanism provided by the operating system to run on the CPU and GPU.

A three-tier computer architecture, with the hardware machine at the bottom, the operating system sandwiched in the middle, and the running applications at the top

Executes programs on processes and threads

Before we dive into the browser architecture, we need to understand the concepts of processes and threads. A process can be considered a executing program. Threads run in processes, and a process may have one or more threads that can execute any part of the application’s code.

Processes are like fish tanks, and threads are the fish swimming in the bathtub

When you start an application, the operating system creates a process for the application and allocates a private memory space for the process. This space is used to store all data and state associated with the application. When you close the program, the corresponding process will also disappear, and the corresponding memory space of the process will be freed by the operating system.

Processes use memory space allocated by the system to store application data

Sometimes, to meet the needs of the function, the created process will ask the system to create other processes to handle other tasks, but the new process will have a new independent memory space instead of sharing memory space with the original process. If these processes need to communicate, they do so through Inter Process Communication. Many applications adopt this multi-process approach to work, because processes and processes are independent of each other and do not affect each other. In other words, if one worker process dies, the other processes will not be affected, and the dead process can be restarted.

Different processes communicate through IPC

Browser architecture

So how do browsers work with processes and threads? In fact, it can be divided into two types of architecture, one is single-process architecture, that is, only start a process, this process has multiple threads working. The second is multi-process architecture, where the browser starts multiple processes, each with multiple threads, and the different processes communicate via IPC.

Architecture diagram for single-process and multi-process browsers

The diagram above actually contains the concrete implementation of the browser architecture. In reality, there is no universal browser implementation standard, so the implementation of different browsers may be completely different.

To better illustrate this series of articles, we’ll focus on the latest Chrome architecture, which uses a multi-process architecture. Here’s an architecture diagram:

Chrome’s render process is used to indicate that Chrome will create a render process for each TAB.

Chrome has a Browser process that collaborates with other processes to implement browser functionality. For renderer processes, Chrome tries to assign a separate process to each TAB or even each iframe on a page.

How do the processes work together?

Here are the specific tasks that each process is responsible for:

Different processes are responsible for different parts of the browser’s interface content

In addition to the processes listed above, Chrome has many other processes working, such as the Extension Process and the Utility Process. If you want to see how many processes are running in your Chrome browser, you can click more buttons in the upper right corner of the browser to select more tools and task managers:

Benefits of Chrome’s multi-process architecture

So why is Chrome doing multi-process architecture work?

One of the benefits is that multiple processes make browsers very fault tolerant. For most simple scenarios, Chrome assigns a separate render process to each TAB. For example, if you have three tabs, you have three separate renderers. When one of the tabs crashes, you can close it at any time without affecting the other tabs. However, if all the tabs run in the same process, they will be associated, and all of them will be suspended.

Different tabs have different rendering processes

Another benefit of Chrome’s multi-process architecture is that it provides security and sanboxing. Because the operating system can provide ways for you to limit what each process can do, browsers can exclude certain processes from certain functions. For example, Chrome limits the ability of TAB renderers to read and write randomly to system files because they may process random input from users.

However, the multi-process architecture also has its downside, which is the memory consumption of the process. Since each process has a separate memory space, they cannot share the same memory space as threads in the same process. This causes the problem that some basic architectures (such as the V8 JavaScript engine) can coexist in the memory space of different processes, and these duplicate contents can consume more memory. So to save memory, Chrome limits the number of processes that can be started. When the number of processes reaches a certain threshold, Chrome will run all tabs that visit the same site in one process.

Save more memory – Chrome servitization

The same optimization can be applied to the browser process. Changes are being made to the Chrome architecture to break up the parts of the browser itself (Chrome) into different services, which can be run in separate processes or combined into a single process.

The main reason for doing this is to make Chrome work differently on different hardware capabilities. When Chrome runs on more powerful hardware, the browser process-related services are run in a separate process to improve system stability. Conversely, if hardware performance is poor, these services are executed in the same process to reduce memory footprint. Even before this architecture change, Chrome was already doing something similar with Android.

Chrome makes the difference between running browser-related services in the same process and running them in different processes

Single frame rendering process – Site Isolation

Site Isolation is a recently launched feature in Chrome that assigns a separate rendering process to iframes of different sites within a web Site. As mentioned earlier, Chrome assigns a separate rendering process to each TAB, but if a TAB has only one process, iframes from different sites will run in that process, which means they will share memory, potentially breaking the same-origin policy. The same origin policy is the core security model of the browser. It can prevent a web site from accessing another site’s data without consent. Therefore, circumventing the same origin policy is the main purpose of many security attacks. Proces Isolation is the best and most effective way to isolate websites. Add Meltdown and Spectre to the CPU and site isolation becomes imperative. Therefore, after Chrome 67, the desktop version of Chrome will have site isolation enabled by default, so that each iframe across the site will have a separate rendering process.

Site isolation allows cross-site iframes to have separate processes

Web isolation technology has been our engineers’ research and development efforts for several years. It is not as simple as assigning a separate rendering process to different iframes on different sites, because it fundamentally changes the way each iframe communicates with each other. When you open devTool on the right, Chrome has to do a lot of behind-the-scenes work to make sure you don’t notice the difference, which is hard to do. For simple functions, such as using Ctrl + F to search a page for a keyword in DevTool, Chrome traverses multiple rendering processes. That’s why our browser engineers hailed this as a milestone when it came out.

conclusion

In this article, we explore the high-level architectural design of the browser and the benefits of a multi-process architecture. We also discussed servitization and site isolation, which are related to the multi-process architecture of the browser. In the next article we will begin to delve into how these processes and threads render our web pages.

Keep an eye on my technical updates

I am the green onion of the attack, pay attention to me and I progress together into a full stack engineer on my own!

A peek into modern Browser Architecture (Part 1)

Follow my personal official account to get my latest technical updates!