by Marc Chung

Recently, Google released the Chrome web browser, which they describe as being the next step in web browsers for the current gamut of JavaScript intensive web applications. One new feature I’m particularly excited about is process affinity. The online comic describes each tab as a separate running process.

Why is this important?

The short answer is robustness. A web application running in your browser, is a lot like an application running on your operating system, with one important distinction: Modern operating systems¹ run applications in their own separate process space, while modern browser² run web applications in the same process space.

By running applications in separate processes, the OS can terminate a malicious (or poorly written) application without affecting the rest of the OS. The browser, on the other hand, can’t do this. Consequently a single rogue application can suck up mountains of memory and eventually crash your entire browser session, along with every other web application you were using at the time.

Chrome differs by running each web application in a separate process space. By doing this, Chrome–or a user–can terminate a single web application without affecting the other tabs you have open.

Process affinity in Chrome

Chrome’s process model is extremely sophisticated. The web comic only mentions the default behavior, but you can configure Chrome to manage processes differently: one process per web site, or one process per group of connected tabs, or one process for everything.

Process-as-site-instance

By default, there are two main Chrome processes, the Browser and the Renderer. The single Browser process is responsible for transporting messages to and from the Renderer, which in turn is responsible for rendering webpages to the user.

1 Browser process communicates with N Renderer processes.

Each Renderer process has two threads: one Render thread–which renders web pages, and one IPC thread–which transports data in a thread-safe, non- blocking manner between the Render thread and an IPC counterpart sitting in the Browser process. The Renderer process manages 1 IPC thread and 1 Render thread.

Completely separate visits to the same site are managed by different processes, so if you had two tabs open to mail.google.com, one of them could crash without affecting the other. Chrome treats separate browsing contexts as separate processes.

If you’re on mail.google.com, and you navigate to hotmail.com, the tab’s underlying process may switch. In this case, Chrome switches your browsing context because you navigated to another site.

If a web page pops up another webpage (via JavaScript), then the sites are considered connected, and managed by the same process. Chrome uses a single Renderer process to handle a browsing context.

This is Chrome’s default behavior and is called process-per-site-instance. It’s intuitive in that your tab count is (more or less) your process count.

Process-per-site

Since multiple tabs can be assigned to a single Renderer process, wouldn’t it be neat if the Renderer process could manage a group of sites?

That’s what process-per-site does. Chrome defines a “site” similarly to the Same Origin Policy with subdomains added into the mix.

For example, in process-per-site mode, mail.google.com, docs.google.com and reader.google.com are all managed by a single Renderer process. If one of those web applications crash, then the responsible Renderer process will crash, thus taking down the entire collection of tabs.

Unlike the previous process model, a tab does not imply a separate Renderer process.

Process-per-tab

The third and most intuitive process model is called process-per-tab.

In this model, tabs have their own process but unlike process-per-site-instance and process-per-site, none of the underlying process switching logic is applied.

Each tab has it’s own process for the life of tab, so a tab will never change process even if a user consecutively visits hotmail.com, gmail.com, and ymail.com.

One process per tab, forever.

Single-process

Finally, the fourth and simplest process model is the single-process behavior. You can run Chrome in a mode that combines the Browser and Renderer process into a single process. This makes Chrome behave a lot like the browsers we have today2.

Choose your Process model

Anyway, if you made it this far down, then the take away from all this is that, the various process models define different ways of assigning tabs to processes, therefore your user experience will vary depending on your OS, your browsing behavior, and the websites you frequent.

To use a specific process model, you can launch Chrome with one of the following arguments.

--process-per-site
--process-per-tab
--single-process

If you’re interested in reading more about memory isolation and the challenges in building a browser like Chrome, check out Charlie Reis’ paper on Using Processes to Improve the Reliability of Browser-based Applications. Chrome’s process model is derived from this paper.

Thanks to Ben Smith, and the developers in #chromium (irc.freenode.org) for reading drafts of this article.

Updated: Charlie dives into the reasons for a multi-process architecture browser.