Sounds as if Google is coming out with a new web browser--launching today--that has some pretty sophisticated and long-desired features (though I wouldn't have known how to define them).
Most important, from my perspective, is the way the application is supposed to handle memory.
The corporate blog says, "By keeping each tab in an isolated 'sandbox,' we were able to prevent one tab from crashing another." The same design feature means that, though the program will occupy a bit more memory when you first start it, as you open more and more windows, and leave the program running for hours (or, as in my case, days), the program should use less memory, run faster, and be more stable.
One of the things that has bothered me about Firefox, which has been my browser of choice for the last couple of years, is the way it slowly comes to dominate my computer's processes. It doesn't take long, often, before Firefox is occupying 16 to 25% of my dual-core processor's power . . . in my machine slows to a crawl. --And I have a 2 GHz processor with 3 GB of RAM! Not good!
The comic book that "explains" the program uses a lot of technical language (language, I will confess, that is largely over my head), but you get the idea:
When we started this project, the gears guys were saying that one of the problems with browsers is that they're inherently single-threaded. For example, once you have JavaScript executing, it's going to keep going, and the browser can't do anything else until JavaScript returns control to the browser. So developers write APIs that are asynchronous--and every now and then the browser locks up because JavaScript is hung up on something.
The gears guys were thinking about a multi-threaded browser, but that lead us to talk about, well, instead of multiple threads--what if we have multiple processes? Each having its own memory and its own copy of the global data structures.
We're applying the same kind of process isolation you find in modern operating systems. So, separate processes rendering separate tabs. and now you have separate JavaScript threads as well. One tab can be busy, while you're still using all the others. And if there is a browser bug in the renderer (and our experience is that it's almost impossible to eliminate all blogs), we still only lose the one tab. When one tab goes down, you get a "Sad Tab," but it doesn't crash the whole browser.
You can find more explanations like that--complete with potentially helpful illustrations--beginning on page 5 of the 38-page comic book. [NOTE, however, if you're not a gear-head, I expect your eyes will glaze over by page 14, when they begin to talk about JavaScript and Google's new V8:
JavaScript itself is classless. You can create a new object, dynamically add properties to it, and go on. But in V8, as execution goes on, objects that end up with the same properties will share the same hidden class and we can start applying dynamic optimizations based on that. . . . [I]n existing JavaScript virtual machines, . . . you don't know exactly where all the pointers are--you start searching through the execution stack to see which words look like pointers.
But the ones that sort of look like pointers could also be integers that just happen to have the same address as an object in the object heap.]
--Yes, I thought you'd enjoy that little bit of dialogue!
Suffice it to say, I look forward to testing this new browser.
[For a less enthusiastic--one might almost say jaundiced--view of Chrome, see Lance Ulanoff's Don't Get Hooked on Google Chrome Hype.]
