Google Chrome’s Architecture – Tab-based Processes and a JavaScript Virtual Machine

I’ve just installed Google Chrome and was extremely excited when I started digging deeper into the architecture behind Google’s new browser. It appears that Chrome is an earnest attempt by Google to address the modern day needs of a web browser.

I believe it is just so very “c-o-o-l” to allocate the web application rendered in each tab in the browser to a separate application process. Of course, there will be a degree of duplication of global data structures within each spawned process, but the isolation between processes is a much needed feature that modern day browsing demands. Theoretically, I can now be assured when I am browsing two different web sites on two different tabs in Google Chrome, that an asynchronous AJAX request on one tab does not lock up my browser; especially in the event that I may be committing a banking transaction in the next tab. In the Microsoft world, we have the option of hosting a web application in it’s own Application Domain in IIS on the web front end server to isolate it from other hosted web applications. Chrome completes the cycle by now providing isolation at the client-side. From the memory management point of view, the moment you close a tab, memory is deallocated and the process is destroyed. Though I am a strong Microsoft supporter, I must say that IE7 drives me nuts when I have many tabs open simultaneously and IE7’s responsitivity degrades each time I open an additional new tab. 

Google engineers from the V8 team in Denmark who specialize in virtualization technologies, introduced another cool new concept in Chrome called “Hidden Class Transitions” to enable JavaScript to run faster in the browser. The concept, again, was so simple. We know JavaScript is a functional scripting language where you could create objects and add properties seamlessly. The folks in the V8 team wrote a virtualization engine that ensured that each time similar objects in JavaScript shared the same properties and “hidden state”, these objects were classified as belonging to the same hidden class. V8 then compiles the JavaScript directly to machine code that runs directly on the CPU running the browser. This meant no more interpretational JavaScript. The V8 engine also employs “precise garbage collection” which means that Google engineers keep track of all hidden class pointers on the stack. While there are several architectural benefits to this approach, the main one being; V8 can incrementally garbage collect; the garbage collection process only lasting a few milliseconds. As V8 is open source and not coupled to Chrome, other browsers could implement the engine or developers could make use of it for custom implementations or extensions.

The ability to launch an “Incognito” window in Google Chrome is another cool feature that ensures that nothing running in the window is logged to the computer. While no history is stored for processes in this mode, cookies belonging to running sessions are automatically cleared once the browser window is closed.