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.
3 thoughts on “How does IE8 keep tabs isolated?”
I know more about IE as a user than I perhaps should. I’ve blogged before about my weird IE workflow. Every morning I’ll read the headlines from Boston.com in Outlook and click on all the ones I want to read one after the other. Then I’ll read my feeds in IE, for example your feed, and right click on all the links I want to open to new tabs (or pre-tabs, new windows. The record for IE windows for me: 72 (!))
That is VERY hard on any browser.
From what I’ve been able to figure, IE has no more than 8 processes open for any number of tabs, not including ielowutil (which itself will have one instance, and several others if feeds are being updated.)
For 7 tabs or more, tabs are divided amongst the processes so that a process will share tabs.
IE will saturate the CPU (assuming a dual core of 2GHz or so) at around 30 tabs. At 50 or higher, IE is very slow as the IE processes all contend for CPU.
If your IE history or cookies are corrupt, things get even worse. If the sites you browse are Flash-heavy (Hi, Boston.com!) or if they have compatibility shims applied, it’s worse still.
I suspect IE was designed with the idea that the average user has no more than 8 or perhaps even 12 tabs open at any one time.
At some point I’d really like to see 64-bit plugins, now that the bottleneck has shifted and IE no longer brings down Explorer like it used to. 🙂
David, you’re close but not quite there. (For starters, your theory doesn’t explain my screenshot with 12 Iexplore.exe processes!) I just found an article that explains how the tab-process algorithm works:
Different than I thought, but also less complicated.
Very useful blog, that! 🙂 Seriously, I don’t know why that kind of stuff isn’t in the Windows engineering blog but I am bookmarking that one. Thanks.
Comments are closed.