There's been some public discussion lately about memory usage in Google Chrome. We think about our memory usage quite a bit so we're happy to see other people paying attention too. This has been a topic of discussion before, but our multiprocess architecture makes measuring memory utilization difficult with the standard set of tools. The crux of the problem is that Chromium goes to great lengths to share memory between processes. However, that shared memory is difficult to account for in the Windows Task Manager. On Windows XP, using the default Task Manager measurement of memory leads to double counting. On Vista, using the default view leads to under counting.

There are a couple of more accurate ways to measure memory utilization in Chromium (or Google Chrome). The easiest is to crack open the task manager that is built into Chromium which tries to account for our memory usage more holistically. If you want even more detail, you can click on "Stats for nerds" which is a link to about:memory.

If you don't fully trust Chromium's task manager or about:memory, the gold standard for measuring memory usage is to look at the system's total commit charge before, during, and after using Chromium. It's a little tricky to get right because you'll need to shut down other services that may kick in while you are running your test. Here's the basic procedure:

1. Shut down any unnecessary services
2. Reboot your computer
3. Using the windows task manager, measure the Total Commit Charge of the system*
4. Run the application you are seeking to test, in this case, Chromium
5. Measure the Total Commit Charge again
6. Close the application
7. Measure the Total Commit Charge one more time
8. Subtract your first measurement from your second, and you should have the memory used by Chromium
9. To validate your test, make sure that the first and last measurement are nearly identical

*On XP, Commit Charge shows up on the bottom of the Windows Task Manager. On Vista, look at the Performance tab of the Windows Task Manager and use the "Memory" number.

For more information on memory usage and how to measure it, check out the Memory Usage Backgrounder on chromium.org.

Posted by Brian Rakowski, Product Manager

We recently announced the availability of developer tools for Google Chrome. We are now releasing ChromeDevTools, which enables JavaScript debugging using Eclipse.

You can set breakpoints, inspect variables and evaluate expressions all from within Eclipse. The screenshot shows the debugger in action stopped at a breakpoint.

The project is fully open sourced on a BSD-license and consists of two components, an SDK and a debugger. The SDK provides a Java API that enables communication with Google Chrome over TCP/IP. The debugger is an Eclipse plugin that uses the SDK and enables you to debug JavaScript running in Google Chrome from the Eclipse IDE.

We hope this project will help web app developers and welcome feedback as well as contributions.

Posted by Alexander Pavlov, Software Engineer

Since we began work on an extensions system for Chromium, we've received a lot of positive feedback. While the system is not yet complete, we've noticed that a lot of you have started creating and installing extensions for daily use. This is really encouraging, and it motivates us to quickly finish things up, to enable extensions by default on all Google Chrome releases.

If you're using extensions now, you should keep in mind that they are powerful software. Extensions integrate with your browser, so they can access and change everything that happens in it. For example, the same technology that enables an extension to periodically check the number of messages in your Gmail inbox could also be used to read all your personal mail and tweet it to your mom! This can happen because of malicious intent or simply because of a bug.

To help protect your experience when using extensions, we recently enabled auto-update for extensions on the dev channel release. Like Chrome's auto-update mechanism, extensions will be updated using the Omaha protocol, giving developers the ability to push out bug fixes and new features rapidly to users of their extensions. This is an important step towards a v1 release of extensions for all users, so we're pretty excited.

In addition, when we turn the extension system on, we plan to offer a gallery with ratings and comments that you can use to judge whether you want to install a particular extension. We will also have processes in place that, combined with reports from users, should help limit the number of malicious extensions that get uploaded and distributed to users. These processes will include removal of extensions that we have reason to believe are malicious. Until these things are in place and the extension system is officially launched, we recommend that you only install extensions that you built yourself.

Posted by Aaron Boodman, Software Engineer

We have just started using a new compression algorithm called Courgette to make Google Chrome updates small.

We have built Google Chrome to address multiple factors that affect browser security. One of the pillars of our approach is to keep the software up to date, so we push out updates to Google Chrome fairly regularly. On the stable channel these are mainly security bug fixes, but the updates are more adventurous and numerous on developer channel.

It is an anathema to us to push out a whole new 10MB update to give you a ten line security fix. We want smaller updates because it narrows the window of vulnerability. If the update is a tenth of the size, we can push ten times as many per unit of bandwidth. We have enough users that this means more users will be protected earlier. A secondary benefit is that a smaller update will work better for users who don't have great connectivity.

Rather then push put a whole new 10MB update, we send out a diff that takes the previous version of Google Chrome and generates the new version. We tried several binary diff algorithms and have been using bsdiff up until now. We are big fans of bsdiff - it is small and worked better than anything else we tried.

But bsdiff was still producing diffs that were bigger than we felt were necessary. So we wrote a new diff algorithm that knows more about the kind of data we are pushing - large files containing compiled executables. Here are the sizes for the recent 190.1->190.4 update on the developer channel:

• Full update: 10,385,920 bytes
• bsdiff update: 704,512 bytes
• Courgette update: 78,848 bytes

The small size in combination with Google Chrome's silent update means we can update as often as necessary to keep users safe.

More information on how Courgette works can be found here.

Posted by Stephen Adams, Software Engineer

Today we're releasing the Sputnik JavaScript test suite. Sputnik is a comprehensive set of more than 5000 tests that touch all aspects of the JavaScript language as defined in the ECMA-262 standard.

Soon after the V8 project started we also began work on what would become the Sputnik tests. The goal was to create a test suite based directly on the language spec that checked the behavior of every object, function and individual algorithm in the language. The task was given to a team in Russia – hence the name "Sputnik" – which went about systematically producing tests. As the test suite grew we used it to ensure that V8 conformed to the spec and to detect unexpected changes in our behavior.

Now that the test suite is complete we're happy to be able to release it as an open source project, under the BSD license. We hope Sputnik can be as useful to other implementers of JavaScript as it has been to us, particularly at a time where implementations change rapidly.

The goal is not that all implementations should pass all tests. V8 set out with that intention and we learned the hard way that sometimes you have to be incompatible with the spec to be compatible with the web. Rather, we want Sputnik to be a tool for identifying differences between implementations.

One of the biggest challenges for web developers today is the many incompatibilities between browsers. Finding these differences is the first step towards removing them. In an ideal world web developers would not have to worry about which browser is being used to view their site and users would not have to worry about whether a site supported their browser. We hope the Sputnik tests will make the browser community take another step towards making that a reality.

Posted by Christian Plesner Hansen, Software Engineer

Since the initial launch of Google Chrome back in September we have had the Elements and Resources tabs of WebKit's Inspector available. We are now ready to present Inspector's Scripts and Profiles panels built on top of the V8 engine providing web developers with full-featured Javascript debugger and sample-based profiler in the dev channel release of Google Chrome. We are also re-introducing the Elements and Resources tabs running out of process for better robustness, security and support for the new debugger and profiler setup.

You can invoke new developer tools by selecting "JavaScript console" from the Developer menu (or using Ctrl+Shift+J). For example, running the statistical profiler on the V8 benchmark suite (below screenshot) will give exact information on the actual code execution as the data is generated straight from running the optimized code from V8.

As with the rest of Google Chrome, the developer tools are open source and built upon WebKit and in particular WebKit's Inspector. We would love to get feedback - both in terms of bugs reports and feature requests - on the Chromium public issue tracker. Or even better yet, we would love to get contributions to improving developer tools further in WebKit and Google Chrome.

Posted by Yury Semikhatsky, Software Engineer

We're excited to see many people are experimenting with the upcoming extension features of Chrome in the dev channel. We're getting a lot of great feedback and are working hard to bring extensions to the stable channel as quickly as possible.

First of all, we've set up a new discussion group for extension-related topics. Going forward, chromium-extensions will be your one-stop shop for extension development news, feedback and questions. If you're interested in developing extensions, we invite you to join us at chromium-extensions.

Second, as part of the latest dev channel release, we've had to make a breaking change to the crx format. This change adds signatures to our package format, which are necessary to enable automatic updates. Unfortunately, this means that any existing extensions will stop working, and will have to be repackaged.

• If you've developed an extension, you can learn how to repackage your extensions for Chrome v 3.0.189.0 in the packaging doc on our developer site. Note that your extension ID will now be your public key, so you'll have to change any code that uses that.
• If you're using an extension someone else has developed, you will have to reinstall it once the developer has repackaged it (as described above). We've already updated our sample extensions.

Even though the whole point of the dev channel is to make our APIs available early while they're still changing, we don't make these changes lightly. Once we push the extension system to the stable channel, breaking changes should be very rare (we'd like to say non-existent, but we don't want to jinx ourselves).

Posted by Nick Baum, Product Manager