Get Firefox Now

A lot of people complain about the Firefox “memory leak(s)”. All versions of Firefox no doubt leak memory - it is a common problem with software this complicated. We look to fix the issues where we can. David Baron and others have done a huge amount of excellent work in this area.

What I think many people are talking about however with Firefox 1.5 is not really a memory leak at all. It is in fact a feature.

To improve performance when navigating (studies show that 39% of all page navigations are renavigations to pages visited < 10 pages ago, usually using the back button), Firefox 1.5 implements a Back-Forward cache that retains the rendered document for the last few session history entries. This can be a lot of data. It's a trade-off. What you get out of it is faster performance as you navigate the web.

For those who remain concerned, here’s how the feature works. Firefox has a preference browser.sessionhistory.max_total_viewers which by default is set to -1. When set to this value, Firefox calculates the amount of memory in the system, according to this breakdown:

(reference: nsSHistory.cpp)

No more than 8 pages are ever cached in this fashion, by default. If you set this preference to another value, e.g. 25, 25 pages will be cached. You can set it to 0 to disable the feature, but your page load performance will suffer.

Edit: In the comments, Boris and David pointed out that I misread the code, and that this is a global preference so that there are no more than 8 cached pages for the entire session, not per tab. My initial posting had claimed that it was per-tab. Oops!

Squarefree.com

Firefox memory usage and memory leak news

Many Mozilla community members, including both volunteers and Mozilla Corporation employees, have been helping to reduce Firefox’s memory usage and fix memory leak bugs lately. Hopefully, the result of this effort will be that Firefox 3 uses less memory than Firefox 2 did, especially after it has been used for several hours.

Memory usage

Federico Mena-Quintero submitted a patch to make Firefox discard decompressed image data after five seconds (bug 296818). ImageLib module owner Stuart Parmenter experimented with a competing idea in bug 386377, but now he plans to help with Federico’s patch. The patch will make image data join text runs in using time-based caching rather than traditional space-bounded caching.

Aaron suggested having an “about:memory” page showing a breakdown of Firefox’s memory use (bug 392351). When I pointed out the bug to Brendan Eich, he excitedly assigned the bug to himself.

Eli Friedman discovered that nsFloatCache was no longer necessary and eliminated most of it (bug 381385).

Memory leaks

David Baron checked in a patch for the last bug that contributed to RLk on Linux, bringing the number of XPCOM objects leaked during this test to zero. Since this test runs on Tinderbox, it’s likely that regressions will be noticed quickly, even if they don’t turn Tinderbox orange.

Robert Sayre created a script to load random pages and see whether they cause leaks. The random URLs come from the Yahoo directory (biased toward older, top-level pages), del.icio.us (biased toward newer, geeky pages), and AltaVista (biased toward pornography). The script detects leaks using trace-refcnt, the same test used by RL; future versions might use trace-malloc in order to catch additional leaks. Robert has caught at least 6 distinct leak bugs using this script, 3 of which have already been fixed. See LeakingPages and bug 394517 for details.

David Baron created a series of patches to the cycle collector to aid in debugging leaks. With this code, DEBUG_CC builds of Firefox can notice when an object “expected to be garbage” is not collected and then explain in detail why it was not collected.

Steve England tested the top 500 web sites, finding two leaks. Later, he tested the top 20 Firefox extensions and found leaks in several of them.

David Baron recorded seven leak debugging screencasts, which you can watch to see how David Baron debugs real leaks.

Kris Zyp found a leak in the JavaScript Engine when using the watch method (bug 394709). Igor Bukanov responded quickly with not only a patch for the bug but also a leak detection patch to enable regression testing of JavaScript Engine leaks. I asked him to modify his patch so I could use jsfunfuzz to test for JavaScript Engine leaks, and he did. (This led me to find several bugs in evalcx, but no additional leaks.)

David Baron got the stack walking code and the stack fixer working on Mac, making it possible to use trace-malloc and the refcount balancer on Mac (bug 336517, bug 392118).

How to help

You don’t have to be a C++ programmer to help find leaks in Firefox.

If you’re a Firefox user, an easy way to help is to browse with a trunk nightly build wrapped in a script that calls leak-gauge.pl when Firefox exits. If it reports that documents or windows leaked, try to figure out how to reproduce the leak and then file a bug report.

If you’re an advanced user, you can do something similar with with trace-refcnt, which detects leaks of all reference-counted objects, not just windows and documents. Build Firefox with the .mozconfig option “–enable-logrefcnt” (or build debug) and run your build with XPCOM_MEM_LEAK_LOG=2. When Firefox exits, it will print a detailed but understandable summary of what types of objects leaked.

If you’re are a C++ programmer and want to help diagnose or fix bugs, check out Performance:Leak_Tools along with David Baron’s screencasts, and hang out in #developers on irc.mozilla.org.

This entry was posted

on Thursday, September 20th, 2007 at 12:23 am and is filed under Mozilla.
You can follow any responses to this entry through the RSS 2.0 feed.

Both comments and pings are currently closed.