All the nonsense aside, now that it seems like multi-process architectures are beginning to surface in the world of web browser development, I thought it would be a good idea to dig in to the feature a bit and, at the very least, provide links to some useful information for those who are interested in what multi-process architectures mean for web browsers.
One of the more notable features included in the unveiling of Google’s Chrome was what Google refers to as “Crash Control.” This feature allows for a “Windows Task Manager” type of interface for managing web browser processes. Aside from providing the interface for explicit management of the running (or dying) processes, it is also meant to shield tabs within the same running instance of the browser chrome (for lack of a better word) from any issues arising in other concurrently running tabs. In essence, when you accidentally load a web page in one tab that was developed using Microsoft Word, you don’t have to worry about the severe code bloat of the page bringing your other tabs to a screeching halt. Or if the JavaScript of one page goes off into la-la land, you won’t necessarily lose any of the other non-offending tabs.
Months after this feature was unveiled in Chrome, it was announced as a feature of Maxthon under the name “The Isolator:”
Maxthon 2.5.1…includes a feature called The Isolator that separates the functions of each Web tab from all other tabs and other parts of the browser. The Isolator protects other tabs from also becoming frozen because a single unresponsive tab is monopolizing a computer’s resources.
Though it certainly wasn’t the first implementation (despite what MaxthonGuy might want you to believe), The Isolator is one of the first official implementations of a multi-process architecture among the web browsers that actually show up on the Browsersphere radar. Unlike Chrome’s “Crash Control,” though, The Isolator is still considered to be “in advanced beta.”
Other than the press release, I wasn’t able to find much on Maxthon’s actual implementation. On the other hand, there has been plenty of coverage on Chrome’s implementation. Marc Chung, for example, does an excellent job of explaining Chrome’s process model. He even goes so far as to show you how you can control the type of process model used by Chrome at launch time. He also points to another interesting article from Chromium Blog that explains why Chrome uses the multi-process architecture and why the architecture is more relevant today than it was when web browsers were first created, and refers to a publication from which Chrome’s process model was derived.
Though the multi-process architecture has been heralded by many web users, it isn’t without its downsides. Google Chrome Memory Usage – Good and Bad explains the trade-offs of separating tabs into their own distinct processes, including the following:
While the multi-process model provides clear robustness and performance benefits, it can also be a setback in terms of using the absolute smallest amount of memory. Since each tab is its own “sandboxed” process, tabs cannot share information easily. Any data structures needed for general rendering of web pages must be replicated to each tab.
For more information on Chrome’s implementation of the multi-process architecture from both a developer’s and end user’s perspective, I recommend checking out the following links:
And finally, here are some other multi-process-related links related to web browsers other than Maxthon and Chrome:
Tags:
Architecture,
Charlie Reis,
Chrome,
Chromium Blog,
Crash Control,
Firefox,
Google Chrome,
IE8,
Maxthon,
MaxthonGuy,
Multi-process,
Performance,
Stainless,
The Isolator
As promised, Firefox 3.6 RC1 was released yesterday. Despite my warnings against downloading the candidate of the release candidate earlier this week, it doesn’t look like there was ever more than one candidate, so if you jumped the gun and downloaded that candidate, you’ve likely got the same build anyway.
