How does IE8 keep tabs isolated?

Andy Ziegler, a Program Manager on the IE8 team, just published an interesting post on the IE Blog going into some technical details about how Internet Explorer keeps tabs separate from one another. The subject of tab isolation is fascinating, in a geeky way, and extremely relevant even to non-geeks, for two reasons. First, tab isolation is a reliability feature; if one tab crashes, you don’t want to lose all your other tabs. And second, it’s also a security feature, one that browser developers have been wrestling with for years in the form of cross-site scripting and other attacks.

Microsoft takes a lot of heat for being a follower in browser development, but as Ziegler notes, they’ve been ahead of the curve on this one:

On March 5, 2008, Microsoft released the first IE8 beta with Loosely-Coupled IE (or LCIE for short). This was the first mainstream implementation of tab isolation. On September 2, 2008, Google Chrome’s first beta released with “process isolation.” Mozilla Firefox has recently discussed an “Out of Process Plugins” (OOPP) or Electrolysis project aimed at isolating Firefox plug-ins, such as Flash, from the rest of the browser.

You can see the IE8 design at work if you open up a single tab and then check the Processes list in Task Manager. With one tab open, you’ll see two instances of Iexplore.exe. Why two?

IE8 isolates the frame process (title bar, back button, address bar, etc.) from the tabs processes (that show web pages). If anything causes a site to crash (an extension like Flash, or the rendering or scripting engine, etc.), the frame and other tab processes will not crash. IE isolates the whole tab – all of its code, data, and extensions – to keep IE resilient to webpages with issues.

One interesting thing I’ve noticed over the past year or so while working with IE8 is that there isn’t a predictable correlation between the number of tabs and the number of processes. For instance, right now I have 16 IE8 tabs open, but Task Manager shows only nine processes running:

I’ve heard some theories about how IE8 combines tabs into a single process while still maintaining the ability to recover in the event of a crash, but I haven’t seen any official documentation on the subject. Andy, if you’re looking for new blog topics, that’s a good one for you.

Update: I decided to explore a little more intently and found a great blog post from the IE support team that explains how IE manages the number of new tab processes. Geeky but interesting.

Ziegler’s post also contains a terse but interesting competitive analysis of the differences between the sandboxing approaches taken by IE and Google Chrome. Not surprisingly, he argues that Microsoft’s approach is fundamentally more secure. I’ll let you read and decide.

Finally, if your eyes bulged out a bit when you saw the memory in use by each one of those Iexplore.exe processes in the Task Manager shot above, you’re not alone. I watched that phenomenon for several months until I finally got a handle on what’s going on. The first time I saw a single process shoot up over 500 MB, it was fairly alarming, but it’s worth noting that this system has 10GB of RAM and isn’t close to running out of memory. As I’ve noted earlier, Windows believes in the philosophy that empty RAM is wasted RAM.

If I were to open this same assortment of tabs on a machine with, say 2 GB of memory, I’d see a very different memory usage pattern, with each process quickly surrendering memory when another process needs it.

And here’s what’s most interesting of all, and a testament to IE’s ability to recover. From Task Manager, I just forcibly ended the three processes that were consuming most memory on that list. As I killed each process, I saw the tab (or tabs) associated with that process reload in the browser. When I was all done, I hadn’t lost a single tab and Task Manager looked very different:

That’s 12 processes, totaling roughly 598MB of memory. Compare that with the previous load, which involved nine processes using 1,051 MB of memory. For those keeping score, that’s a 43% drop in memory usage. I don’t recommend randomly killing Iexplore.exe processes this way, but it’s comforting to know you can do so with no adverse consequences.