« OpenRain 1.0 | Main | Gisting, an early preview of MapReduce in Ruby »

September 05, 2008

Chrome's Process Model Explained

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[1] run applications in their own separate process space, while modern browsers[2] 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.


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.


Since multiple tabs can be assigned to a single Renderer