gecko-dev/tools/trace-malloc
Mike Shal 5169c0a913 Bug 864774 - Part 2: Move CPPSRCS to moz.build as CPP_SOURCES; r=joey CLOSED TREE
From 9e0ba7f425143f545eb6c4b26a9a96b5ade4d8e9 Mon Sep 17 00:00:00 2001
2013-04-23 17:54:15 -04:00
..
lib Bug 864774 - Part 2: Move CPPSRCS to moz.build as CPP_SOURCES; r=joey CLOSED TREE 2013-04-23 17:54:15 -04:00
adreader.cpp Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
adreader.h Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
allocation-stacks.c Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
blame.css Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
blame.pl Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
bloatblame.cpp Bug 794510: Part 2: Use more stdint types instead of protypes.h types; r=ehsan 2012-10-11 18:38:04 -05:00
diffbloatdump.pl Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
formdata.c Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
formdata.h Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
getopt.c Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
histogram-diff.sh Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
histogram-pretty.sh Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
histogram.pl Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
leak-soup.pl Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
leaksoup.cpp Bug 823932 Change leaksoup.cpp to use nsAutoTArray rather than nsAutoVoidArray. r=dbaron 2012-12-22 08:59:22 +00:00
leakstats.c Bug 828946 - leakstats should output TBPL-parsable error messages; r=ted 2013-01-16 21:53:45 +00:00
live-bloat.html Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
Makefile.in Bug 864774 - Part 2: Move CPPSRCS to moz.build as CPP_SOURCES; r=joey CLOSED TREE 2013-04-23 17:54:15 -04:00
merge.pl Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
moz.build Bug 864774 - Part 2: Move CPPSRCS to moz.build as CPP_SOURCES; r=joey CLOSED TREE 2013-04-23 17:54:15 -04:00
README
rules.txt Remove dead code in intl. Bug 559489, r=smontagu 2010-07-04 15:42:04 +03:00
spacecategory.c Bug 579517 - Part 1: Automated conversion of NSPR numeric types to stdint types in Gecko; r=bsmedberg 2012-08-22 11:56:38 -04:00
spacetrace.c Bug 792581 - part 23: Replace LL_INIT and LL_UDIVMOD macros. r=ehsan 2012-11-01 20:57:25 -04:00
spacetrace.css Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
spacetrace.h Backed out 2 changesets (bug 579517) 2012-10-25 12:32:24 -04:00
stoptions.h Bug 792581 - part 23: Replace LL_INIT and LL_UDIVMOD macros. r=ehsan 2012-11-01 20:57:25 -04:00
tmfrags.c Bug 792581 - part 20: Replace LL_UI2L macro with int64_t cast. r=ehsan 2012-10-25 19:25:57 -04:00
tmreader.c Bug 794510: Part 2: Use more stdint types instead of protypes.h types; r=ehsan 2012-10-11 18:38:04 -05:00
tmreader.h Bug 794510: Part 6 - Fixups needed to build on Windows and Android and Mac OS X debug, plus shorten comment to be less than 80 columns; r=ehsan 2012-10-18 15:55:48 -04:00
tmstats.c Bug 792581 - part 20: Replace LL_UI2L macro with int64_t cast. r=ehsan 2012-10-25 19:25:57 -04:00
TraceMalloc.pm Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00
types.dat Bug 825866. Part 8: Mass-rename of nsIView to nsView. r=tnikkel 2013-01-04 02:23:11 +13:00
uncategorized.pl Bug 716478 - update licence to MPL 2. 2012-05-21 12:12:37 +01:00

                      Trace Malloc Tools
              Chris Waterson <waterson@netscape.com>
                      November 27, 2000

This is a short primer on how to use the `trace malloc' tools
contained in this directory.


WHAT IS TRACE MALLOC?
=====================

Trace malloc is an optional facility that is built in to XPCOM. It
uses `weak linking' to intercept all calls to malloc(), calloc(),
realloc() and free(). It does two things:

1. Writes information about allocations to a filehandle that you
specify. As each call to malloc(), et. al. is made, a record is logged
to the filehandle.

2. Maintains a table of all `live objects' -- that is, objects that
have been allocated by malloc(), calloc() or realloc(), but have not
yet been free()'d. The contents of this table can be called by making
a `secret' call to JavaScript.


MAKING A TRACE MALLOC BUILD
===========================

As of this writing, trace malloc only works on Linux, but work is
underway to port it to Windows.

On Linux, start with a clean tree, and configure your build with the
following flags:

  --enable-trace-malloc
  --enable-cpp-rtti

Be sure that `--enable-boehm' is *not* set. I don't think that the
values for `--enable-debug' and `--enable-optimize' matter, but I've
typically had debug on and optimize off.


COLLECTING LIVE OBJECT DATA
===========================

To collect `live object' data from `mozilla' using a build that has
trace malloc enabled,

  1. Run `mozilla' as follows:

     % mozilla --trace-malloc /dev/null

  2. Do whatever operations in mozilla you'd like to test.

  3. Open the `live-bloat.html' file contained in this directory.

  4. Press the button that says `Dump to /tmp/dump.log'

An enormous file (typically 300MB) called `dump.log' will be dropped
in your `/tmp' directory.

To collect live object data from `gtkEmbed' using a build that has
trace malloc enabled:

  1. Run `gtkEmbed' as follows:

     % gtkEmbed --trace-malloc /dev/null

  2. Do whatever operations in gtkEmbed that you'd like to test.

  3. Press the `Dump Memory' button at the bottom of gtkEmbed.

The enormous file will be dropped in the current directory, and is
called `allocations.log'.


About Live Object Logs
----------------------

A typical entry from the `live object' dump file will look like:

  Address     Type      Size
  |           |         |
  v           v         v
  0x40008080 <nsFooBar> 16
        0x00000001 <- Fields
        0x40008084
        0x80004001
        0x00000036
  __builtin_new[./libxpcom.so +0x10E9DC]  <- Stack at allocation time
  nsFooBar::CreateFooBar(nsFooBar **)[./libfoobar.so +0x408C]
  main+C7E5AFB5[(null) +0xC7E5AFB5]

One will be printed for each object that was allocated.


TOOLS TO PARSE LIVE OBJECT LOGS
===============================

This directory is meant to house the tools that you can use to parse
live-object logs.

Object Histograms - histogram.pl
--------------------------------

This program parses a `live object' dump and produces a histogram of
the objects, sorted from objects that take the most memory to objects
that take the least. The output of this program is rather spartan: on
each line, it prints the object type, the number of objects of that
type, and the total number of bytes that the objects consume.

There are a two simple programs to `pretty print' the output from
histogram.pl:

  1. histogram-pretty.sh takes a single histogram and produces a table
     of objects.

       Type                    Count    Bytes %Total
       TOTAL                   67348  4458127 100.00
       nsImageGTK                 76   679092  15.23
       void*                    8956   563572  12.64
       ...
       PRLock                    732    61488   1.38
       OTHER                   24419   940235  21.09

  2. histogram-diff.sh takes two histograms and computes the difference
     between them.

                  ---- Base ----   ---- Incr ----   ----- Difference ----
       Type       Count    Bytes   Count    Bytes   Count    Bytes %Total
       TOTAL      40241  1940945   73545  5315142   33304  3374197 100.00
       nsImageGTK    16   106824     151   832816     135   725992  21.52
       PresShell     16    51088     198   340706     182   289618   8.58
       ...
       OTHER      27334  1147033   38623  1493385   11289   346352  10.26

Both of these scripts accept `-c' parameter that specifies how many
rows you'd like to see (by default, twenty). Any rows past the first
`n' rows are lumped into a single `OTHER' row. This allows you to keep
your reports short n' sweet.

Stack-based Type Inference - types.dat
--------------------------------------

Trace malloc uses `speculative RTTI' to determine the types of objects
as it dumps them. Unfortunately, RTTI can only deduce the type name
for C++ objects with a virtual destructor.

This leaves:

 . C++ object without a virtual destructor
 . array allocated C++ objects, and
 . objects allocated with the C runtime function (malloc
   and friends)

out in the cold. Trace malloc reports objects allocated this was as
having type `void*'.

The good news is that you can almost always determine the object's
type by looking at the stack trace that's taken at the time the object
is allocated.

The file `types.dat' consists of rules to classify objects based on
stack trace.


Uncategorized Objects - uncategorized.pl
----------------------------------------

Categorizing objects in `types.dat' is sweaty work, and the
`uncategorized.pl' script is a tool that makes it a bit
easier. Specifically, it reads a `live object' dump file and sorts the
stack traces. Stack traces that account for the most uncategorized
objects are placed first.

Using this tool, you can add the `most effective' rules to
`types.dat': rules that account for most of the uncategorized data.