The many instances of Chrome

As many readers of this blog may know, Google Chrome is different from other Windows web browsers. It isolates each of its tabs into an individual process, instead of containing them all in a single multi-threaded process. Google Chrome essentially forks itself each time you create a new tab. This can easily result in 10-20 chrome.exe processes running on your system. But, don't worry -- that doesn't mean more memory or CPU use. Read on.

Fork? That's when a process creates a new running copy of itself, identical to the first. As always (fork or not), the virtual memory between process instances is mostly shared. Therefore, additional RAM usage is negligible. From a RAM use perspective, there is no big difference between forking a process and spawning a new thread.

How does memory/RAM get shared between processes? Well, that's a different subject, but its really simple - its all in the virtual to physical mapping. Physical memory is the actual RAM, where-as virtual memory is an abstraction of that RAM that can exist in RAM, on disk (i.e. a page file), or anywhere else.

As a sharing example, a page of memory may exist at location X in physical RAM. Well, if two processes reference that same physical page of memory, they both can have different virtual pointers to it. If one process writes to that shared memory, Windows will apply a principle known as copy-on-write. This is where the process that wrote to the memory gets its very own copy of the shared page, because its now uniquely modified for that process. Read more on virtual memory if you want to know more.. back to Google Chrome.

Forking is very common for *nix environments, where applications fork themselves all the time. Windows applications traditionally spawn new threads instead of forking the entire process. Google decided to take a different approach, using forks. Note that the technical aspects of the Chrome fork may differ from a traditional *nix fork, but its conceptually the same.

The biggest advantage of isolating each tab into its own process space is that a crash in any one tab can't (or shouldn't) bring down the entire application (all the tabs). Again, since identical virtual memory is shared between processes, there isn't much extra memory overhead associated with all these Chrome processes. Each process will only allocate memory exclusively applicable to the tab it owns. Further, since the Windows CPU scheduler only sees threads, this forking design doesn't affect how Chrome performs during periods of high CPU contention.

One interesting performance note is that Chrome dynamically lowers the priority class of processes hosting background tabs, similar to what Process Lasso's ProBalance does. So, when you switch tabs, Google Chrome lowers the priority class of the old tab's process and raises the priority class of the new tab's process (to below normal and normal, respectively). I would hope that traditional single-process browsers do the same with individual thread priorities, but I wouldn't bet on it.

This lets the Windows CPU scheduler know which process's threads are most important during periods where there is heavy contention for CPU time slices. Of course, the most important threads will be those in the process thats holding the tab you're currently using. The others are important as well, but don't need quite the same level of real-time responsiveness as the foreground process's threads will. Although Windows has built in mechanisms to boost foreground thread performance, giving the Windows CPU scheduler 'hints' as to what should take precedence is always a good idea - after all, its not psychic.

That's what Process Lasso aims to do -- help give the Windows CPU scheduler a few more hints as to what should get precedence, and to rescue the user in the case of catastrophic CPU monopolization (as demonstrated by our CPU Eater demo). If more applications cared as much about their impact on the rest of the system as Chrome does, then perhaps there wouldn't be as much of a need for Process Lasso's ProBalance.

Well, I've spent enough time rambling on.. back to real work. I hope this helps explain to anyone who is concerned by the 20 different instances of chrome.exe they may see running on their PC ;).