Google Chrome: the Making of a Cross-Platform Browser

Google's Evan Martin and Mads Ager discuss the challenges behind making a browser work well on Linux, Mac OS and Windows.
The Developers Speak

JG: In a nutshell, what inspired Google to create Chrome and how did it come about?

EM: We built Google Chrome because we believed we could add real value for users and help drive innovation on the Web. Google Chrome is built for speed, has a very simple interface and uses innovative technology to ensure it is always secure and stable, providing a great experience for users as they browse the Web. But what's more, by making Google Chrome open source and developing a powerful new JavaScript engine, V8, we believe we can help spur innovation in the industry and provide developers with the platform with which to build the next generation of Web applications. This is good for users, and good for Google, as we benefit directly when the Web gets better.

LJ: What is the Google Chromium Project?

EM: After we wrote the code for Google Chrome, we open sourced it under the name Chromium. Much like Firefox is a trademark of Mozilla, Google Chrome is a trademark of Google; the name Chromium is not, so distributions are free to use it to refer to the same project. We hope that developers and browser vendors take a look at the Chromium source code and that it will be useful for new projects built by the Open Source community in the future.

JG: This being our cross-platform development issue, we're curious to explore the challenges and innovations in that area. What have been the major issues in making Chrome great on all of its platforms?

EM: Much of the challenges we've encountered on Linux stem from how heterogeneous the user base is—which, surely, is also the strength of Linux. This ranges from how to port simple UI decisions (Chrome's shade of blue was chosen to look good next to the blue seen on every Windows computer), to getting boring technical details (a binary built on Ubuntu won't work on a Fedora machine), to real problems that will require engineering work to solve.

One good example of the latter is adapting our sandboxing model for Linux. Getting a process sandboxed in a way that's useful to us is challenging on Windows, with the relevant source code consisting of more than 100 files, but it needed to be implemented only once to work everywhere. On Linux, there are a variety of easier-to-use but different sandboxing systems available, and different Linux distributions ship with different (or no) sandboxing APIs. Here's an article about a kernel patch we've proposed for discussion toward that end:

JG: What innovations does Chrome bring to browsing?

EM: We did a lot of interesting things in building Google Chrome. First, it's simple and easy to use—we've designed Google Chrome to be as unobtrusive as possible, taking up the minimum amount of space on your screen, and allowing you to search and browse all from the address bar. Its multiprocessed architecture also ensures Google Chrome is fast and stable. Additionally, we designed Google Chrome for speed from the beginning, including building a new JavaScript engine called V8 from scratch to handle rich, complex Web applications.

JG: Can you tell us more about V8, its history, your rationale for developing it and who the key people were behind it?

MA: The V8 Project started in late 2006. At that time, existing JavaScript engines did not perform very well. The goal of the V8 Project was to push the performance of JavaScript engines by building a new JavaScript engine on which large object-oriented programs run fast. The V8 Project was pioneered by the dynamic duo of serial virtual machine builders Lars Bak and Kasper Lund in a farmhouse outside Aarhus, Denmark.

JG: What innovations and new approaches does V8 bring to the browser?

MA: V8 uses the concept of hidden classes and hidden class transitions combined with native code generation and a technique called inline caching to make property accesses and function calls fast. V8 uses precise generational garbage collection to make the engine scale to large object-oriented programs that use a lot of objects. In addition, V8 contains a JavaScript regular expression engine that was developed from scratch, is automata-based and generates native code for regular expressions.

JG: What language(s) is Chrome/V8 written in?

MA: V8 is mostly written in C++, but some of the basic JavaScript libraries are implemented in JavaScript itself.

JG: What platforms does V8 support?

MA: V8 runs on Windows, Linux and Mac.

JG: What CPU architectures does it support for native code compilation of JavaScript?

MA: V8 supports IA32 and ARM.

JG: Are there plans to extend it to other CPU architectures?

MA: We are working on a 64-bit version.

JG: Is the code generation better on some architectures than others?

MA: There are different trade-offs for the different architectures, and we try to make the code generators as good as we can for the different architectures. The code generator for IA32 does register allocation and does more inlining than the code generator on ARM. In general, the IA32 code generator has been tuned more than the ARM one.

JG: Did you name it after the internal combustion engine or the vegetable drink?

MA: The internal combustion engine. It was developed in the context of Google Chrome, and we thought that there should be a powerful V8 engine under the “chrome”.

JG: Why did Google choose to develop a new JavaScript engine and use WebKit rather than use code from Mozilla?

EM: We have always been and remain great supporters of Firefox—Mozilla helped lead the way in much of the innovation we've seen in the browser space during the last couple years, with features like tabs, search boxes in the browser chrome and extensions. They've also proved that you can build a mass-market software product using open-source technology and collaborative development in the open. However, we initially thought of our work in this space as an experiment and didn't want to impose our ideas on anyone else. Rather, we thought about developing a new JavaScript engine and open-sourcing it so that other browser developers could benefit.

We think that numerous open-source projects are good for the entire space because they allow developers to make advances and share them quickly. We continue to have a great relationship with Mozilla, and many of our engineers actively work on features in Firefox through Mozilla's public participation process.

JG: What can you tell us about the status, road map and challenges regarding the Linux version? We're salivating here.

EM: The Developer version is available for a few Linux distributions already. Although this is an early release and not ready for your average user, we hope you get an idea of what Google Chrome for Linux will be like and keep following our development in the open as we make progress on a beta and stable version.

JG: How many developers in how many locations are dedicated to Chrome development, and how many solely to the Linux version?

EM: Although we don't go into details about the number of Google employees on any particular product, we have a core team of engineers who are working hard to get the Linux build of Google Chrome up and running. As a team, to prevent fragmentation, we try to have all developers work on all platforms—I refactor code on Windows to make it work on Linux, and if someone on the Mac team breaks the Linux build, it's his or her responsibility to fix it. Pieces like the networking stack can be worked on from any platform, so developers can just pick their preference.

At one point, I counted Google developers contributing from more than a dozen different locations (some work from their homes); we have even more once you count the contributions we receive from other developers. One of my favorite experiences of this project has been filing a bug one evening, then waking up the next day to see a patch to fix it from someone in Europe.

We've also received many patches from outside of Google, and have even promoted some of our best contributors to committers themselves.

JG: Was there a specific Google application that prompted Google to decide it needed a bigger/faster browser?

EM: I think of Google Chrome as being less about making Google applications faster and more about making the Web as a whole faster.

JG: What toolkits are used to build Chrome? And, are there any interesting issues regarding tools worth mentioning?

EM: Google Chrome on Linux relies on a ton of free software—about:credits lists more than 15 subprojects we include source from—as well as standard system libraries like FreeType, NSS (the Mozilla SSL/TLS implementation) and GTK+. There has been a lot of discussion on-line over toolkit choice; it was surprisingly uncontroversial within the team to choose the one that Firefox and Flash depend on and that we had more experience with. I think other options would have been just as good, and I would, in particular, love to see someone knowledgeable about Qt contribute patches.

Regarding tools, I'd like to especially call out gold, the fast linker that is little known but has been a lifesaver for us.

JG: How has the development of Google Chrome for Linux been going? Can you share some ups and downs you've experienced so far?

EM: I run only Linux at home. For me personally, the biggest up was after working on Windows for so long, to be able to install and use it finally myself.

JG: Is there a tentative date for when a beta release will be ready for Linux?

EM: Not yet, but we're working hard on it. You can track our progress on Linux development by running the in-progress version available at or via the mailing lists and source found on the Chromium developer site at

JG: Will the Linux and Mac OS versions one day catch up with and enjoy equal functionality with the Windows release?

EM: Yes, it is one of our highest priorities right now.

JG: Thanks to you both for your fascinating insights on Google Chrome!

James Gray is Linux Journal Products Editor and a graduate student in environmental sciences and management at Michigan State University. A Linux enthusiast since the mid-1990s, he currently resides in Lansing, Michigan, with his wife and cats.


James Gray is Products Editor for Linux Journal.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

chromium builds

mockgeek's picture

it took me a while to find these links, but i've been downloading the latest builds of chromium and running them. they are rather stable but do have some quirks about them. i wouldn't switch to this as your default browser just yet.

here is the link to the build page:

i actually scripted a process to read the LATEST file in that directory which contains the version/build number of the latest and then download it.

do note that these builds come sometimes 5 or 6 a day.


davedmiller's picture

Can some one share a link to the linker "gold" mentioned in the article? Thx