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.

Skip to main content

Heapinfo

Suresh Duddi <dp@netscape.com>
Created  1 March 2002; Last Modified 1 March 2002

Heapinfo is a tool that attempts to hook in at the Allocator layer and gives useful breakdown of heap usage by the application. This tool is available on windows only (not win98)

The hooks for this tool are already available in both release and debug builds of mozilla (28 Feb 2002 onwards - just before 0.9.9 branch)

Step1: Build the heapdump trigger
cvs co mozilla/tools/footprint
cd mozilla/tools/footprint/
nmake -f makefile.win

This will create heapdump.exe and heapmap.pl in your bin/ directory.
Step 2: Run mozilla and invoke your test case to get to point of interest.

Step 3: Trigger heapdump
heapdump.exe

This will create c:\heapdump.txt If the file already exists, this will append to the file.
Step 4: Analyze heapdump
perl heapmap.pl < c:\heapdump.txt

This will analyze the heap dump and print a report like this:

Heap statistics : After pageload (1 cycle)
------------------------------------------------------------
USED               :  8294.42 K in 113835 blocks
FREE               :  1924.33 K in   4800 blocks
Uncommitted FREE   : 21088.00 K in    330 blocks
Overhead           :  1191.13 K in 118649 blocks
Alignment overhead :    39.98 K in   4926 blocks
             Total : 32537.87 K
FREE at heap end   : 15048.00 K in     10 blocks - 65.39% of FREE

Total Commit    : 11424.00 K
Total Uncommit  : 21088.00 K
          Total : 32512.00 K


USED This is memory requested by the application. All returned memory is on a 8 byte boundary.
FREE This is memory that application freed and is still held by the allocator
Uncommitted FREE Freed memory that is neither mapped into physical memory or swap. This only exists as a address and is not taking any system resources.
Overhead For every memory request, malloc() maintains a 8 to 16 byte overhead where it maintains information about the allocation including the size. This is the total of the overhead for all blocks - USED + FREE + Uncommitted FREE
Alignment overhead There is some (max 8 byte) wastage between blocks of memory. This is the total of all overhead caused by alignment of blocks.
Total USED + FREE + Uncommitted FREE + Overhead + Alignment overhead
This should be the total VmData used by the app
FREE at heap end FREE or Uncommitted FREE that is at the end of a heap. This is useful because potentially this is memory that is easily returnable to the operating system.

Total Commit Total memory that is held by the allocator that is mapped either into physical memory or swap. Essentially:
USED + FREE + Overhead + Alignment overhead
Total Uncommit Total memory that is held by the allocator that is neither mapped into physical memory or swap.
Uncommitted FREE
Total
 Total Commit + Total Uncommit
This should equal the earlier Total and must be VmData used by app
.

How it all works

mozilla.exe There is code in mozilla that listens to the message MOZ_HeapDump and does a heapwalk() on all process heaps. Dumps the result into c:\heapdump.txt
heapdump.exe finds a mozilla window or a Netscape 6 window in that order and issues the MOZ_HeapDump message to the window.
The window is found using its title:
Mozilla window : title contains Mozilla { or - Mozilla
Netscape 6 window : title contains - Netscape 6
heapmap.pl is a perl script that analyzes the dump and prints useful information

Issues

  • The totals we get from the breakdown and commit+uncommit almost match. They still dont exactly match.
  • Why is so much Uncommitted FREE held by allocator ?