New Fennec Releases

June 26, 2009 by pavlov

fennec logo

Welcome to the world both Fennec 1.0 Beta 2 for Maemo and Fennec 1.0 Alpha 2 for Windows Mobile.

In addition to Maemo and Windows Mobile builds, you can also download desktop builds for Windows, Mac, and Linux.

For these releases we have worked on improving the user experience, replacing our old theme with a much nicer looking one and fixing numerous usability issues.  We’ve continued to increase performance and responsiveness.  We’ve revamped how you install Add-ons, improved our download manager and the whole look of the application.  We’ve started work on making forms on web pages easier to use, providing a nicer combo box UI than before.

Both of these builds are built on top of the same front end and back end codebases — their version differences are just to express their currently different usability levels.

We’re starting to see some very exciting Fennec Add-ons being built by the community, including things like GeoGuide which uses the new Location Aware APIs to show you things like maps and weather near where you currently are, and other things like GraffiTwit, a Twitter client that lets you not only write tweets but also post images you’ve drawn.

We’ll continue to polish the user experience and improve performance, and are already hard at work on some changes that will make big performance improvements.

Fennec 1.0 Beta 1

March 17, 2009 by pavlov

Fennec 1.0 Beta 1

I’m super happy to announce the first beta release of Fennec for the Maemo platform.

Fennec 1.0 Beta 1 includes lots of great improvements, especially around performance.  Starting with this beta, I’m able to use Fennec as the primary browser on my N810.  We’ve done heavy optimizations to our frontend code and made a number of optimizations to the platform, resulting in greatly increasing zooming speed and making panning pretty smooth.  We’ve also been able to improve startup performance by reducing a good bit of unnecessary work.  We’ve enabled TraceMonkey bringing to mobile the huge JavaScript speed improvements the JIT has brought to  Firefox 3.1 betas.  A number of performance hotspots have been identified that we’ll continue to focus on until we ship final –  in fact, we have fixed number of issues already for the next beta.

On the feature front, we’ve enabled plugins so you can now watch videos on your favorite sites, and we’ve got in our first pass at improved bookmark management and support for bookmark folders.  A lot of time was spent on infrastructure that we could use to build the rest of our app with.  You’re now able to scroll things like preferences and the new bookmarks list.  One of our main focuses for the next milestone will be on polishing the user interface — areas like the extension manager will get a face lift and we’ll start working more on some of the usability issues people have reported.

Madhava Enros, our lead user interface designer for Fennec, has put together a great video of Beta 1 that not only shows off many of the things we’ve done but also does a great job of explaining many of the choices we’ve made.


Add-ons are starting to pop up and are already showing some of the great possibilities that Fennec provides.

The Weave guys have been working hard and have an extension for Fennec now that allows you to sync data from your desktop to Fennec.  Having your desktop’s tabs, bookmarks, and awesome-bar contents on your mobile device really make a huge difference.

Mozilla Weave

Felipe Gomes’ gesture addon is another great example of what we’re capable of.  You can see a video of the awesome extension he’s done below:

Fennec Alpha 2

December 22, 2008 by pavlov

We’re happy to announce that our second alpha release of Fennec has come together.  While we focused much of the previous alpha on getting the user experience how we wanted, we’ve spent much of the time since focused on improving performance.  We’ve made major strides improving startup performance, panning and zooming performance, and responsiveness while pages are loading.
We’ve re-factored a significant amount of the front end code resulting in substantial speed improvements as well providing a much better base for extension authors to build upon.

In addition to the native Maemo release, we’ve also released desktop versions of Fennec as we did with Fennec Alpha 1.  Windows, OS X and  Linux clients are available.  While not our main focus, these builds allow content and extension authors to experiment with our mobile browser on their desktop.

The release notes have information on a quick start, how to install, what’s new, known issues and how to provide feedback. So if you’re interested in getting involved with Mozilla Mobile, install Fennec and tell us what you think.

In addition to the great performance work, we’re starting to work towards feature completion.  We’re making great progress on our Windows Mobile builds and are starting to roll on Symbian.  There is a lot going on in mobile-land these days and if you’re interested I’d encourage you to help out however you can!

Ten Years

October 23, 2008 by pavlov

It was 10 years ago today that I first got involved with the Mozilla project.

As I once said: “I did, like, some random, like, little basic things.

In the beginning…

It all started sometime in 1995 when I started running Linux.  Sometime over the next couple of years I decided to write a GUI email client.  Ironically, the only real option at the time was Netscape CommunicatorGTK+ and GNOME were both new and I decided to go with them as my toolkit of choice.  Eventually I ended up with the Balsa email client.  Through my journey with the Linux desktop I had gotten to know a number of people, including one Mike Shaver who at the time was at Netscape.

In late 1998, while living in northern Georgia, I signed up to volunteer at the Atlanta Linux Showcase.  Over October 23 and 24, I talked to quite a few Linux, GTK+, and GNOME community members and by the end had volunteered to help port Mozilla from Motif to GTK+.  Little did I know at the time where that would lead me.

You see, 10 years ago I was a senior in high school, working at a small ISP building websites and maintaining our servers.  I’d been writing C code for a few years but had done very little object oriented coding and no C++.

Mozilla GTK - 11/16/98

Mozilla GTK - November 16, 1998

Within a month, with the help from folks such as Matt Wilson and Chris Blizzard, Owen Taylor, we had Mozilla up and running on GTK+.

We had a lot to do.  Back then we were using GTK+ version 1.1.x and as it was under rapid development to provide all the features we needed, we were bumping our version requirement every few weeks.  Pretty sure that was driving the folks at Netscape crazy.

Back then we had implementations of all the native widgets you can think of.  Things like radio buttons, check boxes, text input fields.  I remember one day Ramiro Estrugo told me that there had been a decision to redo all of our widgets in a cross-platform way.  He was worried how I would take it, given it meant throwing away a bunch of my code, but it seemed like a good idea to me.

It was right around then that XUL entered the picture.

On November 24, 1998 AOL announced they were buying Netscape.  There was some fear about what this would mean for Mozilla.  AOL’s CEO Steve Case responded with some encouraging words.

Sometime in January/February 1999, I received a call from David Winton, who was working on a documentary about Netscape and Mozilla.  He wanted to bring out a film crew to Georgia to follow me around for a few days.  Apparently my explanation on why these guys would want to come out worked as my parents agreed and a few weeks later the film crew showed up.  The followed me around work, school and home for a couple days.  It was a pretty strange experience.

At the end of March 1999, my mom and I ended up flying out to California for the 2nd Mozilla Party.  While in California, we met up with the the Winton duPont film crew again and and they shot some more film.  It was on April 1, while sitting in the Netscape cafeteria, I found out that one of the major Mozilla/Netscape figureheads Jamie Zawinski was leaving.  At the time he wrote on his website: “For those of you who choose to continue, I wish you all the best of luck.”  Maybe his luck came in handy as this was just the beginning.

Onward to Netscape…

By May of 1999 I had a job offer to move to California and work for Netscape.  I accepted and started at the end of June.  My primary task at that time was continued improvement of the GTK+ widget and graphics code.

During my first week at work, David Hyatt added intrinsic window sizing for XUL windows.  That way, they would size to their contents.  This totally broke Linux as I had somehow forgotten to handle top-level window resizing.  Oops.  A frantic but fun way to start things off.

The rest of the year was a lot of long nights at work and a lot of learning to live on my own.  I ended up building out a lot of widget and graphics implementations including getting the GTK+ drag and drop code working and adding our file picker API.  It wasn’t long before Chris McAfee and Brian Ostrom first introducted me to La Bamba.

In early 2000 myself and Scott Collins went up to San Francisco to watch a preview of Code Rush at the Winton duPont office.  It was pretty cool to see so many folks on video I had only heard about, ones who had left Netscape before I joined.  I remember this trip because on our way back, a big sheet of plywood fell out of a truck in front of us on 101 and ended up slamming in to the front of Scott’s car and ending up covering the windshield.  Fortunately we were OK and able to pull over without being able to see anything.

A few months later Code Rush was released.  Just before it was released, there was a showing in a big theater room in Mountain View with many of the people in the video in attendance.

In March 2000 using an early MacOS X Rhapsody (later renamed Darwin) pre-pre-release on my unsupported PowerMac 9600, I set off to port Mozilla to the platform.  At this point, most all of the Mac guys at Netscape were still working on OS9 and most of them were unconvinced that OSX would become real.  For some reason or another, pretty much daily my Mac would refuse to boot and so I’d have to reinstall the OS to get it booting again.  Eventually I got it to the point of popping up a window that rendered pages, but it wasn’t very stable and didn’t work very well.  The work sat mostly untouched for nearly 2 years until the rest of the Mac community became interested.

Despite Netscape having a security library to handle cryptography, they had been unable to release the source code along with the original source code due to US cryptography restrictions.  I don’t remember all the details, after getting it all building on Linux and a lot of work from the legal department and the security guys, in March 2000 we were able to land it on the trunk.

2000 was a busy year.  In addition to those things, I built a new Unix file picker using XUL (which I still believe was better than the current GTK one), built our clipboard code and made it support all the crazy ICCCM text formats, rewrote our event queues, and got old-style plugins working using crazy Xt magic.

The Netscape mail servers were all inside the firewall, so if you wanted to read your mail you needed to VPN in.  All but one, which you could access over SSL using a client certificate.  I never did much with the mail and news code, but I made a deal with one of the IT guys to give me access to the server if I implemented IMAP and SMTP over SSL — so I did.

Despite outcries from engineering that the product wasn’t ready, Netscape decided to ship Netscape 6 on November 14, 2000. This was the first major release since Netscape 4.5, and by all accounts was a horrible release.  It was neither stable nor fast.

In late 2000, I started my first attempt at rewriting our graphics layer.  It was simply called gfx2.  A lot of people around thought it was a good idea, but no one really wanted to help build it.  I built out a decent X implementation that was fully scriptable, but eventually let it drop.  The time just wasn’t right yet.

I continued working on the GTK+ code, making many significant optimizations, until January 2001, when I switched over to designing and building a new image library.  There were a number of issues with the old code including that it did cache matches based on the image size, so if you used the same image multiple times on a page, you would refetch it from the network every time.  This was in the days of using lots and lots of spacer images, so this could be very expensive.  The scale and many other pieces lived deep in the image library code rather than in the platform specific code which made it difficult to optimize.

"design docs"

I spent much of the first few months building out and designing something I was happy with.  Using XPCOM for the one thing it was really designed for, I added pluggable image decoders that could be easily added, made the caching to be much smarter than the previous library and by the end of March, things were getting turned on on the trunk.  Looking back, it was a pretty rough landing.  Because of the way things were implemented, the code that handled background images was still using the old image library.  Things stabilized pretty well over the next couple months and by August things were fully cleaned up and the old image library was removed.

A lot was going on around this time.  The network library that had built the previous year was being heavily worked on, a new cache system was being built.  A word of wisdom to anyone who might build something on top of a network library: wait until it is fully stable before building on top of it.

Towards the end of the year, as part of making the image library do threaded image decoding, I built a thread-safe cross-platform timer implementation.  It seemed to work pretty well when I wrote it, so we landed it and replaced all of our platform specific timer implementations, getting rid of a great number of bugs due to platform differences.  Unfortunately, as is often the case with threaded code, things weren’t so simple and over the next few years there were numerous thread-related issues in this code.  Thanks to Brendan Eich for figuring out many of them!

Most of the Mozilla community spent the first half of 2002 fixing bugs on the road to Mozilla 1.0.  I spent most of it fixing image library bugs and timer bugs.

Around March or April, David Hyatt and Ben Goodger and others started discussing building a smaller, cleaner browser.  We often ended up at Denny’s around 1AM having long conversations about how to make the browser new.  On April 1, the first checkin for what would become Phoenix (and later Firefox) occurred.

On June 5, 2002, after 4 years of development, we finally had something we were ready to call Mozilla 1.0 and we released it to the world.  It sure was a lot nicer than the Netscape 6 that had gone out the door a year and a half earlier.

Post Mozilla 1.0, I got interested in embedded platforms and spent a while looking at what it would take to port Mozilla to the Playstation 2.  I built a small 2d graphics library, ported NSPR and other pieces of the codebase.  Many of the pieces ran well individually, but the compiler and toolchain that was available at the time had a hard time compiling and linking all our large code base without generating bad code.  Between this and the PS2 network adapters not taking off that we decided to drop this project.  It was a fun learning experience and taught me quite a bit about writing compact code.

On September 22, the first version of Phoenix was released with 4 more versions coming out before the end of the year.

Anya - March 25, 2003

In 2003, I lead a small team building Anya, a client/server browser solution built on Gecko, similar to what Danger did and Skyfire and Opera Mini do today.  The client was very small — Windows Mobile was around 30KB on disk and could render most sites on the web.  We sent over a binary stream from the server of things to draw that could be easily replayed on the client.  We also built a PalmOS and Linux client.  There were a number of fun technical challenges we were looking forward to solving such as running JavaScript to allow things such as client-side input validation.  Unfortunately AOL wasn’t really sure what to do with it.  I was able to get permission to open source the code, but I never had much time to document it or get it out there the way I would have liked.  I know some companies ended up using the code in various ways in the end.

On June 3, 2003 I removed MNG support from the browser.  It caused a big uproar from the ten guys who were using the format and everyone who thought they might someday.  It was a small test of the Mozilla module owner system as well as a lesson to many about being careful about what features you add as inevitably someone will be angry if you remove it.

The end of Netscape.  A new beginning for Mozilla…

In July 2003, 4 years after I had started working there, AOL laid off the remaining browser team.  I didn’t find myself particularly sad.  The lessons I had learned and the people I had met had lead to growth that I can only now really start to understand.  We had all built something we were proud of, grown the community a lot, and truly believed that Mozilla would be a success.  As part of ending browser development, the Mozilla Foundation was spun out on its own.

It was time for me to move on.  Having spent nearly 5 years working on Mozilla, I found it difficult to find a place with the culture and openness I was looking used to.  I remember talking to a great number of companies at the time, some with very interesting projects, but none were quite what I was looking for.  I went to work at Open Source Applications Foundation in September 2003 working on their Chandler project working on many parts of the backend including client syncing.  I still remained semi-active in the Mozilla community, although not as active as I would have liked.

After a year at OSAF, in October 2004, I decided to leave and go work at Oracle with Mike Shaver, Dan Mosedale and Vladimir Vukićević building Lightning, a calendaring extension for Thunderbird.  Despite having worked on building XUL itself, I hadn’t spent much time writing it.  During my time at Oracle I wrote a lot of JavaScript and XUL as we built out frontend.  As our team was small and fairly isolated from the rest of the corporate beast, several of us primarily worked remotely, often from the Mozilla office.

November 9, 2004, Firefox 1.0 (and Halo 2) was released.  Mitchell has a great writeup of the day, so I won’t try to  cover it here, but needless to say it was a pretty exciting day for everyone.  It was a pretty major accomplishment for the very small Mozilla Foundation to have hit.  I’m glad I was able to be a part of it.

Cairo Firefox - November 18, 2004

As Vlad and I were both interested in graphics, in our spare time we started building a cairo backend for Mozilla.  We got things up and running pretty quickly on Linux but both realized we couldn’t expose all the functionality we really wanted to.  Doing everything we wanted was going to require more than our spare time.

After around 6 months at Oracle, I realized I just wasn’t excited by calendaring and decided to leave.

A return to the Mozilla…

After weighing my options I found that I was still passionate about browsers and changing the web, and so I joined the Mozilla Foundation full time at the end of May 2005.  Amusingly, the project I wanted to work on was redesigning the Mozilla graphics system, still, around 7 years after I first worked on it.  Vlad, who also joined MoFo, and I set off on a two and a half year project, one of the biggest ones I can remember rebuilding our graphics engine.

One of the major flaws our old graphics code had was that it only implemented the least common denominator of platform functionality, and so even backed by something like cairo, the Gecko graphics API didn’t expose all the functionality we needed to do rich graphics on the web.  Not all platforms support the same set of functionality.  For example, Mac OS X has APIs to draw curves with anti-aliasing while Windows does not.

Coming up with a new graphics API was pretty straightforward.  As they say, the third time’s the charm.  We had both played with cairo and knew it could do many of the things we needed.  It was important to select the right software graphics implementation, but there wasn’t much out there besides cairo and agg.

After playing with both, deciding that we didn’t want to build our own from scratch and finding that agg wasn’t at the right level, we decided to go with cairo.  We knew that meant we’d have to contribute a lot to it, but it seemed better than the alternatives.

A lot of the work we had to do in cairo was centered around performance and taking advantage of platforms.  Many of the cairo developers were on Linux, but few were on Windows and Mac.  Vlad did some amazing work on getting these all hooked up.

On the Gecko side, we wanted to take advantage of our new graphics capabilities as much as possible.

As part of the graphics changes, we decided to take on re-writing our text handling as well without thinking much about what that meant.  I’m here to tell you, text rendering is hard.  There are a lot of languages, fonts, and unicode codepoints.  Each platform has a different way of finding the right fonts for the text you want to render, except Windows, where you’re basically on your own.  Fortunately, Windows gave us the most freedom to implement correct font selection and after 4 or 5 different tries, we finally got it right.  We ended up porting it to Mac and using it there and are in the process of using it on Linux.  At the same time, Robert O’Callahan rewrote much of the text layout code in Gecko to take advantage of the new font APIs we could provide.  Looking back, we probably spent more time on text rendering than we did on the rest of the graphics changes.

The graphics work continued at full speed until the end of 2007, when I took a few months to look at memory usage.  I’ve written in pretty great detail about the work that went on in fixing the memory usage in Firefox that continued on until March 2008.

A few weeks before we were going to release 3.0, I took off on a pre-planned vacation to Barbados for three weeks.  Because I was on the beach when 3.0 went out the door on June 17, 2008, the accomplishment of shipping never really hit me.  I wish I could have celebrated with everyone else, but I’m not sure I would have traded the relaxation of the beach.

As Firefox 3 was wrapping up, I started looking for my next challenge and agreed to help build our mobile browser, Fennec.  After returning from Barbados, I was refreshed and ready to roll.  Our team has made great strides in building Fennec, and just last week released our first alpha.  It is amazing to be part of another project from the early days and facinating to watch people change the way they use the web.

Today, 10 years later

I’m at FSOSS 2008, a conference that is in many ways similar to the one that started this whole thing for me.  I’m amazed by the work that this school has done to teach its students the open source culture and a different way of thinking.  I hope that for at least one person attending, it results in a great journey for them.

Looking Forward…

The future is bright for Mozilla, and I look forward to continuing to be a part of this great community.  The web is really starting to take off with new capabilities like offline, video, audio, SVG, and location awareness.  The community, a group of amazing people, has built an outstanding platform, an outstanding desktop browser, and is building what will be an outstanding mobile browser.

Fennec Alpha 1

October 17, 2008 by pavlov

I’m excited to say that yesterday we pushed out our first alpha release of Fennec.  I suggest checking our Madhava’s great video showing Fennec in action.  The team has been working very hard for a while and it is great to get our first big milestone in front of people.  We’ve still got a lot of work to do and over the next few milestones you’ll be seeing performance improvements, more UI refinement and Windows Mobile builds.

The feedback so far has been very useful and I hope to see more continue coming in.

New contributors + Big Patches + HG = ?

June 5, 2008 by pavlov

We’ve seen tremendous interest in Firefox and the Mozilla platform, not just from consumers, but also from groups of developers that would like to build on top of and contribute to Mozilla itself.  One of the challenges that these groups often face is that if their work is any more extensive than a simple patch, it’s difficult for them to effectively publish their work and to collaborate with others during development.

Transitioning to a distributed version control system like Mercurial has helped this situation some; branching is easy, as is merging back in to the mainline.  But even with that, these developers would still be isolated, working within essentially their own private repository.

We’d like to make it easy for these people to give their work wider exposure within the community, without having to make a decision up front as to whether the work will be included in mozilla-central or not.

Our rules for giving new commiters access to the main repository don’t work well for groups with large changes, and we’d like to come up with a different process whereby these people would still have to go through the same effort as other contributors to become full “Mozilla contributors”, but that, in the meantime, they can make their work available and can collaborate with others.

I’ve been working with Mitchell and Brendan on coming up with a policy that allows people to more easily work together in cases such as these.  Mitchell be posting what we’ve come up with shortly.

Firefox 3 Memory Usage

March 11, 2008 by pavlov

As the web and web browsers have matured, people have started expecting different things out of them. When we first released Firefox, few people were browsing with tabs or add-ons. I’ve written before about how web usage patterns have changed, so too have our strategies on how to effectively make use of system resources such as memory.

While Firefox 2 used less memory than it’s predecessor, Firefox 1.5, we intentionally restricted the number of changes to the Gecko platform (Gecko 1.8.1 was only slightly different than Gecko 1.8) on which Firefox was built. However, while the majority of people were working on Firefox 2 / Gecko 1.8.1, others of us were already ripping into the platform that Firefox 3 was to be built on: Gecko 1.9.

We’ve made more significant changes to the platform than I can count, including many to reduce our memory footprint. The result has been dramatic, and you can see for yourself by getting a copy of the recently released Firefox 3 Beta 4.

Here’s What We’ve Done:

Reduced Memory fragmentation

As I’ve written about before, long running applications such as ours can wind up wasting a lot of space due to memory fragmentation. This can occur as a result of mixing lots of various sized allocations and can leave a lot of small holes in memory that are hard to reuse.

One of the things we did to help was to minimize the number of total allocations we did, to avoid unnecessarily churning memory. We’ve managed to reduce allocations in almost all areas of our code base. The graph below shows the number of allocations we do during startup. The graph below shows we were able to get rid of over 1/3 of them! Olli Pettay, Jonas Sicking, Johnny Stenback, and Dan Witte all made a big difference here.

alloccount.png

I carefully studied the fragmentation effects of various allocators and concluded that jemalloc gave us the smallest amount of fragmentation after running for a long period of time. I’ve worked closely with the jemalloc author, Jason Evans, to port and tune jemalloc for our platforms. It was a huge effort resulting in Jason doubling the number of lines of code in jemalloc over a 2 month period, but the results paid off. As of beta 4 we now use jemalloc on both Windows and Linux. Our automated tests on Windows Vista showed a 22% drop in memory usage when we turned jemalloc on.

Fixed cycles with the Cycle collector

Some leaks are harder to fix than others. One of the most difficult ones is where two objects have references to each other, holding each other alive. This is called a cycle, and cycles are bad. In previous versions, we’ve used very complex and annoying code to manually break cycles at the right times, but getting the code right and maintaining it always proved to be difficult. For Gecko 1.9, we’ve implemented an automated cycle collector that can recognize cycles in the in-memory object graph and break them automatically. This is great for our code as we can get rid of lots of complexity. It is especially significant for extensions, which can often inadvertently introduce cycles without knowing it because they have access to all of Firefox’s internals. It isn’t reasonable to expect all those authors to write code to manually break the cycles themselves.

Basically, the cycle collector means there are whole classes of leak that we can easily avoid in both our code and in extensions, and that’s good for everyone. You can thank Graydon Hoare, Peter Van der Beken and David Baron for their amazing hard work on this.

Tuned our caches

Firefox uses various in-memory caches to keep performance up including a memory cache for images, a back/forward cache to speed up back and forward navigation, a font cache to improve text rendering speed, and others. We’ve taken a look at how much they cache and how long they cache it for. In many cases we’ve added expiration policies to our caches which give performance benefits in the most important cases, but don’t eat up memory forever.

We now expire cached documents in the back/forward cache after 30 minutes since you likely won’t be going back to them anytime soon. We have timer based font caches as well as caches of computed text metrics that are very short lived.

We also throw away our uncompressed image data as I describe below…

Adjusted how we store image data

Another big change we’ve made in Firefox 3 is improving how we keep image data around.

Images on the web come in a compressed format (GIF, JPEG, PNG, etc). When we load images we uncompress them and keep the full uncompressed image in memory. In Firefox 2 we would keep these around even if the image is just sitting around on a tab that you haven’t looked at in hours. In Firefox 3, thanks to some work by Federico Mena-Quintero (of GNOME fame), we now throw away the uncompressed data after it hasn’t been used for a short while. Not only does this affect images that are on pages in background tabs but also ones that are in the memory cache that might not be attached to a document. This results in pretty dramatic memory reduction for images that aren’t on the page you’re actively looking at. If you have a 100KB JPEG image which uncompress to several megabytes, you won’t be charged with the uncompressed size when you’re not viewing it.

Another fantastic change from Alfred Kayser changed the way we store animated GIFs so that they take up a lot less memory. We now store the animated frames as 8bit data along with a palette rather than storing them as 32 bits per pixel. This savings can be huge for large animations. One extreme example from the bug showed us drop from using 368MB down to 108MB — savings of 260MB!

Hunted down leaks

Most leaks are a pain in the ass to find and fix in any complex piece of software. There are small leaks, big leaks, and in-between leaks. If you leak a small piece of text once an hour you probably won’t notice. If you leak a large image every time you move the cursor, you’ve got a big problem. Both are important to fix, because even the little ones add up. Some leaks are only leaks until you leave a page, so they don’t show up with conventional leak-finding tools, but they make a difference if you have a page opened all day long like GMail.

Leak HuntBen Turner has gotten pretty good at Leak Hunt.

We’ve fixed many leaks, ranging from small DOM objects that get leaked on GMail until you leave the site to entire windows that were leaked holding on to everything inside of them when you closed them.

Overall, we’ve been able to close over 400 leak bugs so far, most of which are very uncommon, but can still occur. We’ve greatly improved our tools for detecting leaks. Carsten Book, in particular, has done an amazing job at finding and reporting leaks.

Measuring Memory Use

As I’ve learned the hard way, accurately measuring memory usage is hard.

This part gets a bit technical, feel free to skip over. The short summary is Windows Vista (Commit Size) and Linux (RSS) provide pretty accurate memory measurement numbers while Windows XP and MacOS X do not.

If you’re running Windows Vista and take a look at Commit Size in task manager, you should get some pretty accurate memory numbers. If you’re looking at Memory Usage under Windows XP, your numbers aren’t going to be so great. The reason: Microsoft changed the meaning of “private bytes” between XP and Vista (for the better). On XP the number is the amount of virtual memory you’re application has reserved for use. For performance reasons you often want to reserve more memory than you actually use. The application can tell the operating system that it isn’t going to use parts of the reserved space and to not back the virtual space with physical space. On Vista, Private Bytes is the commit size, which only counts the memory the application has actually said it is actively using. Since virtual memory size has to be greater than or equal to your commit size, XP memory numbers will always appear bigger than Vista ones, even though the application is using the same amount of memory.

On Mac, If you look at Activity Monitor it will look like we’re using more memory than we actually are. Mac OS X has a similar, but different, problem to Windows XP. After extensive testing and confirmation from Apple employees we realized that there was no way for an allocator to give unused pages of memory back while keeping the address range reserved.. (You can unmap them and remap them, but that causes some race conditions and isn’t as performant.) There are APIs that claim to do it (both madvise() and msync()) but they don’t actually do anything. It does appear that pages mapped in that haven’t been written to won’t be accounted for in memory stats, but you’ve written to them they’re going to show as taking up space until you unmap them. Since allocators will reuse space, you generally won’t have that many pages mapped in that haven’t been written to. Our application can and will reuse the free pages, so you should see Firefox hit a peak number and generally not grow a lot higher than that.

Linux seems to do a pretty good job of reporting memory usage. It supports madvise(), allowing us to tell Linux about pages we don’t need, and so its resident set size numbers are fairly accurate. You can use ps or top to measure RSS.

Ways to test

There are many ways to measure memory usage in a browser. Open up 10 tabs with your favorite websites in them and see how much memory the browser is using. Close all but the last tab and load about:blank or Google. Measure again. Another simple test is simply loading Zimbra, Google Reader and Zoho each in their own tab and logging in. We’ve learned that users do so many things with the browser it is nearly impossible to construct a single test to measure memory usage.

We wanted more of a stress test — One that was more reproducible than loading random sites from the web. We took our Standalone Talos framework and Mike Schroepfer modified it to cycle pages through a set of windows while opening and closing them to try and approximate people running for a long period of time. Talos makes it pretty straightforward to get this up and running, and is great for measuring things like memory usage and layout speed. This works great for Firefox and allows measuring performance and other metrics, but the page cycling code doesn’t work with other browsers.

Since we wanted to test cross-browser, we modified the tests to run cross-browser and we wired up some of our talos code that uses the Windows Performance Counters to measure Private Bytes (commit size on Vista).

For the results below we loaded 29 different web pages through 30 windows over 11 cycles (319 total page loads), always opening a new window for each page load (closing the oldest window alive once we hit 30 windows). At the end we close all the windows but one and let the browser sit for a few minutes so see if they will reclaim memory, clear short-term caches, etc. There is a 3 second delay between page loads to try and get all the browsers to take the same amount of time. We used the proxy server that is part of Standalone Talos to make sure we were serving up the same content. We had to disable popup blocking to allow the test window to open the 30 windows for running the test. You can get the simple webpage test here and the python script to monitor memory usage here. These things are built on top of the standalone talos framework so you’ll need to drop the python script in with talos to get good results. Mad props to Mike Schroepfer for getting this all working.

Results

ff3-ff2-ie7.png

Looking at the graph:

  • All browsers increase in memory use slightly over time, but the Firefox 3 slope is closer to 0.
  • The _peak_ of Firefox 3 is lower than the terminal size of Firefox 2!
  • The terminal state of Firefox 3 is nearly 140MB smaller than Firefox 2. 60% less memory!
  • IE7 doesn’t appear to give any memory back, even after all the windows are closed!
  • Firefox 3 ends up about 400mb smaller than IE7 at the end of the test!

This is just one test that I feel shows the great progress that has been made. We’ll continue working on adding additional tests that can measure more of the ways that users use their browser.

Conclusion

Our work has paid off.

We’re significantly smaller than previous versions of Firefox and other browsers.

You can keep the browser open for much longer using much less memory.

Extensions are much less likely to cause leaks.

We’ve got automated tools in place to detect leaks that might result from new code. We’re always monitoring and testing to make sure we’re moving in the right direction.

All of this has been done while dramatically improving performance.

Thanks

Many people have worked on this but I’d like to specifically thank: David Baron, Carsten Book, Peter Van der Beken, Igor Bukanov, Brendan Eich, Jason Evans, Alfred Kayser, Federico Mena-Quintero, Robert O’Callahan, Olli Pettay, Mike Schroepfer, Mike Shaver, Jonas Sicking, Johnny Stenback, Ben Turner, Vladimir Vukicevic, Dan Witte, Boris Zbarsky, and everyone else I’m forgetting who has worked on this. Everyone really pulled together to make this happen.

jemalloc on trunk — linux edition

February 27, 2008 by pavlov

Back on the 12th of February we turned jemalloc on in our Linux builds.  Sorry for not posting sooner!  We saw a good performance increase and a drop in memory.  Neither were as large as the wins we saw on Windows but still good.  I tried tuning the glibc allocator a bit but was mostly unsuccessful at making it both faster and use less memory at the same time.  Also over time the fragmentation results just weren’t quite what we were hoping for.

Things in the memory world are looking pretty great.  Our work seemed to have paid off.  There is always more to do but Firefox 3 beta 4 will be great.

jemalloc now on the trunk

February 5, 2008 by pavlov

Our Windows nightlies (beta4pre, this is not in beta 3) now include jemalloc. These builds are leaps and bounds better than the last build I posted.

Tons of amazing work has gone in to this. I’d like to thank Jason for making all the crazy changes to jemalloc that we wanted and Ted for his days and days of crazy build stuff. Thanks to Benjamin for his work getting the CRT building initially — we wouldn’t be here without it. We’ve worked day and night for weeks to make this happen and it is finally here.

Due to the requirement for you to have Microsoft Visual Studio 2005 SP1 Professional, –enable-jemalloc is off by default in configure. If you have the right stuff installed toss it in your mozconfig and magic should happen.

We’re still evaluating the switch on Mac and Linux, but you can use the same configure flag to build on those platforms.

APNG

January 24, 2008 by pavlov

I received word recently from Brendan Sera-Shriar at Seneca College about this APNG portal site that he, along with folks from PHUG, got off the ground recently.  The site looks great and should help provide a wealth of information about a great new feature in Firefox 3 (and Opera 9.5 and other products to follow…).

They’ve got several cool samples up and I’m sure they’d love to add more if you’ve got them.

We seem to have introduced some flashing bug while the animations load.  I filed bug 413933.  Should get fixed soon I hope!

3d animating dolphin