You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.



performance: tools

Contact: Cathleen Wang (cathleen@netscape.com)

Memory Leaks

Tools for tracking down memory leaks.

  • XPCOM Memory Leak tools (this document also has information on Mozilla's other memory leak tools). See also a tutorial on using these tools and the refcount balancer.
  • Rational Purify®. (Commercial)
  • GlowCode. (Commercial)
  • ElectricFence.
    • "Electric Fence ... uses the virtual memory hardware of your system to detect when software overruns the boundaries of a malloc() buffer. It will also detect any accesses of memory that has been released by free(). Because it uses the VM hardware for detection, Electric Fence stops your program on the first instruction that causes a bounds violation."
    Specifically, it works by placing each heap allocation on its own VM page. Since the dynamic footprint of the browser is pretty large, this may make it tough to use "in real life".
  • Leaky. This is a home-grown tool that Kipp put together:
    • "Its a tool called leaky. What it does it help you track down memory leaks and some kinds of memory corruption. It also has entry pointers for logging addref/release calls. The key thing that leaky does is this: it logs all calls to malloc/free/realloc/new/delete into a log file. The logging data includes information about size and address, as well as the *call stack of the operation*. The leaky program then can translate the call stack data from addresses into symbols and then dump the data out." *
  • refcount balancer. This is another home-grown tool that does finer-grained instrumentation and allows you to focus on specific objects rather than entire runs.
  • Insure++®. (Commercial) Evaluation copy is free. Linux version.
  • LeakTracer.
  • ccmalloc.
  • debauch Dead?
  • memwatch.
  • Geodesic Systems' GreatCircle Dead? Scott Furman has done some preliminary work to get this product working with Mozilla.
  • Julian Seward writes of Valgrind, an open-source memory debugger and profiler for Linux/x86: `Snapshots 20020511 and later of the tool are able to run Mozilla correctly on both Red Hat 6.2 and 7.2. It will also do detailed low-level I1/D1/L2 cache profiling, so you can see which bits of Mozilla create cache misses. You'll need the patch from bug 124335 if working with versions prior to 1.0RC2.

Profiling

The following tools are used to measure product performance.

  • Rational PurifyPlus. (Commercial) Used to be called Rational Quantify.
    • qfy2html.pl. A Perl script for munging Quantify 6.0 output into hyperlinked HTML to share with your friends. Run Quantify, save your results as text, and then let this thing rip.
    • Quantifying Mozilla on Solaris. Instructions on how to make Quantify play nicely with Mozilla on Solaris.
  • For performance work on Mac, you can use either the Metrowerks Profiler (on subsets of the codebase), or Apple's Instrumentation SDK. For details, see the page on Mac performance.
  • hiprof. A hierarchical instruction profiler for Digital Unix. There is an online tutorial, courtesy Jim Nance (jim_nance@yahoo.com):
    • "I like it because it does not require you to recompile the program, because it give accurate times for callers, and because it comes with DU so that everyone developing there should already have it." *
  • jprof. Sampling profiling tool by Jim Nance that runs on RedHat 6.1, 6.2.
  • MOZ_TIMELINE Timing instrumentation. Extremely useful for app startup measurements.
  • eazel profilers. Two profiling tools from Eazel/gnome.org, runs on Linux.
  • JS Runtime Profiler. Profile JavaScript usage, dumps output to a file.
  • Sysinternals utilities. Win9x/Me/NT/2K utilites for monitoring system usage. CPU/Mon, Diskmon, Filemon, Regmon, etc.
  • gprof. Part of the GNU Binutils. Back in May 1999 there were rumors that gprof had trouble with dynamically linked and loaded objects (like Mozilla). Currently (March 2006) gprof is still being developed, so hopefully that's no longer true (assuming it ever was). The link to the gprof manual above is years out of date but, at the time of writing, it's the latest version of the manual on gnu.org. To get an up to date version of the manual, get the gprof source and run |. configure; make html| in the gprof source directory.