Why Chrome Browser adopted Multi-process architecture?
👷♂️ Software Architecture Series — Part 19.
Behind every decision is a rationale. We don’t implement product code with a complicated architecture from the first go, but we address the immediate or core goals and evolve the architecture over time. Successful software products have undergone major architectural changes over the course of time, chromium browser, which is probably one of the most user web browser, is no exception. Here is the story behind one of its major architectural decision:
The Story:
Back in mid 2000s, one error prone application taking down entire OS or one website crashing the browser engine was a common scenario. Initially, web pages were simple and static. With rise in use of JS based frameworks, dynamic content rendering became an integral part of web browsing. However, with added functionality came added complexity. Avoiding bugs in web application was nearly impossible and so building a rendering engine which never crashes. All it took was one rendering engine or plug-in bug to bring down the entire browser and all of the currently running tabs.
Reason is simple: Applications on OS create a process when they are started and borrow some memory from OS. When application closes, OS takes back the memory allocated. In the early designs of web browsers, every task was put together in one process, which included working on multiple tabs. Hence, if one tab faced a bug and caused rendering engine to crash, entire browser crashed. Moreover, multiple threads of one process often competing for CPU time end up making the process (browser) unresponsive. This flaw raises some serious security concerns as well. A web page that exploits a vulnerability in the rendering engine can often take over the entire PC.
The Change:
Chromium team decided to take on this problem to provide end users with seamless browsing experience. Unlike earlier design in browsers, where one process was creating multiple threads and working through tasks parallelly, Chromium team decided to leverage the concept of multiple process running in parallel and communicating with each other over IPC (inter-process communication).
Chrome browser identified following processes to run parallelly:
· Browser: When Chrome starts, a new browser process is created. It controls UI, network I/O and disk operations.
· Renderer: This process controls the rendering of web pages which contains logic of handling HTML, JavaScript, images, and so forth. For each tab opened, a new renderer process is created.
· Plug-in: Chrome browser opens up for lot of plug-ins. Hence, a separate plug-in process was identified to control the plug-ins used within the browser.
· GPU: Since GPUs handle requests from multiple apps and draw them on same surface, a separate GPU process was identified. GPU is good at handling simple tasks but across multiple cores at the same time.
· Other processes: There are some other processes also running within Chrome browser such as Extension process and utility processes. The list of processes running under Chrome can be viewed by opening its task manager.
The idea is simple, to provide isolation. Websites run in isolation from one another. Crashes or security issues in one tab do not impact the stability of other tabs or the overall browser. Renderer processes run in a sandbox, restricting their access to disk and network I/O. The renderer does not have direct access to low-level network operations. Instead, it relies on the network service provided by the Chromium browser, which can implement additional security checks and controls. This sandboxing helps minimize the impact of security exploits. The host operating system’s built-in permissions and security mechanisms are leveraged to control and limit the renderer’s access to files and directories. This ensures that the renderer process cannot perform unauthorized file operations or access sensitive system files. By limiting renderer’s access to the display, it is prevented from taking unauthorized actions, such as capturing sensitive information displayed on the screen. In the event of a compromised renderer process (e.g. due to a security vulnerability or an exploit), the imposed restrictions significantly limit the potential damage.
In terms of performance, tabs running in background or minimized are considered lower on priority. In the context of Windows operating systems, where minimized processes have their memory placed into an “available memory” pool, Chromium leverages this behavior to optimize memory usage. When a user performs tab switch, instead of immediately releasing all memory, Chromium adopts a gradual memory release strategy. This ensures that if a user switches back to a recently used tab, the tab’s memory is more likely to be readily available (paged in) than less recently used tabs. The OS will only reclaim memory if necessary, and there is no performance hit when there is ample memory available.
Recently, Chrome has been going major architectural changes, inspired from platforms like Android, where it adopts the approach of dynamic process configuration. On powerful hardware, Chrome may choose to split each service into different processes, promoting stability and taking advantage of multi-core processors. However, on devices with resource constraints, Chrome can aggregate multiple services into a single process. This consolidation aims to save memory footprint, which is particularly important on devices with limited resources. Idea is to strike a balance between stability and resource efficiency.
Moreover, multiple renderer processes can execute concurrently, taking advantage of multi-core processors and improving overall performance. A seamless UI experience is provided as users can navigate through tabs easily and without disruptions caused by crashes in one tab affecting others. In the event of a crash in one renderer process, the browser process can quickly create a new renderer process for that specific tab, ensuring a quick recovery without affecting the entire browser.