Today I gave a presentation at Google I/O explaining some of the cool ideas that lie at the heart of our upcoming extension system. For those who didn't get a chance to attend the conference, you can check out the slides, below:

The actions menu, visible in full-screen mode, will let you show speaker notes. We'll also post a video of the talk as soon as it's available.

As some of you know, it's already possible to write extensions using the latest developer build of Google Chrome. You can find out more about the system, and learn how to write your first extension, by reading our HOWTO document. We've really focused on making extensions as easy as possible to write, so you'll be up and running in no time.

We're still pretty early in the development of the extensions system, and we're constantly adding new features and tweaking the APIs based on your feedback. So if you try it out, we'd love to hear from you at chromium-discuss@chromium.org.

Happy coding!

Update: Video of this talk is now available, as are videos of a number of other Google Chrome-related talks.

The V8 JavaScript engine has been designed for scalability. What does scalability mean in the context of JavaScript and why is it important for modern web applications?

Web applications are becoming more complex. With the increased complexity comes more JavaScript code and more objects. An increased number of objects puts additional stress on the memory management system of the JavaScript engine, which has to scale to deal efficiently with object allocation and reclamation. If engines do not scale to handle large object heaps, performance will suffer when running large web applications.

In browsers without a multi-process architecture, a simple way to see the effect of an increased working set on JavaScript performance is to log in to GMail in one tab and run JavaScript benchmarks in another. The objects from the two tabs are allocated in the same object heap and therefore the benchmarks are run with a working set that includes the GMail objects.

V8's approach to scalability is to use generational garbage collection. The main observation behind generational garbage collection is that most objects either die very young or are long-lived. There is no need to examine long-lived objects on every garbage collection because they are likely to still be alive. Introducing generations to the garbage collector allows it to only consider newly allocated objects on most garbage collections.

To keep track of how well V8 scales to large object heaps, we have added a new benchmark, Splay, to version 4 of the V8 benchmark suite. The Splay benchmark builds a large splay tree and modifies it by creating new nodes, adding them to the tree, and removing old ones. The benchmark is based on a JavaScript log processing module used by the V8 profiler and it effectively measures how fast the JavaScript engine can allocate nodes and reclaim unused memory. Because of the way splay trees work, the engine also has to deal with a lot of changes to the large tree.

We have measured the impact of running the Splay benchmark with different splay tree sizes to test how well V8 performs when the working set is increased:

The graph shows that V8 scales well to large object heaps, and that increasing the working set by more than a factor of 7 leads to a performance drop of less than 17%. Even though 35 MB is more memory than most web applications use today, it is necessary to support such working sets to enable tomorrow's web applications.