DHAT: a dynamic heap analysis tool
As with the Massif heap profiler, DHAT measures program progress by counting instructions, and so presents all
age/time related figures as instruction counts. This sounds a little odd at first, but it makes runs repeatable in a way
which is not possible if CPU time is used.
10.2. Understanding DHAT’s output
DHAT provides a lot of useful information on dynamic heap usage. Most of the art of using it is in interpretation of
the resulting numbers. That is best illustrated via a set of examples.
10.2.1. Interpreting the max-live, tot-alloc and deaths
fields
10.2.1.1. A simple example
======== SUMMARY STATISTICS ========
guest_insns:
1,045,339,534
[...]
max-live:
63,490 in 984 blocks
tot-alloc:
1,904,700 in 29,520 blocks (avg size 64.52)
deaths:
29,520, at avg age 22,227,424
acc-ratios:
6.37 rd, 1.14 wr
(12,141,526 b-read, 2,174,460 b-written)
at 0x4C275B8: malloc (vg_replace_malloc.c:236)
by 0x40350E: tcc_malloc (tinycc.c:6712)
by 0x404580: tok_alloc_new (tinycc.c:7151)
by 0x40870A: next_nomacro1 (tinycc.c:9305)
Over the entire run of the program, this stack (allocation point) allocated 29,520 blocks in total, containing 1,904,700
bytes in total. By looking at the max-live data, we see that not many blocks were simultaneously live, though: at the
peak, there were 63,490 allocated bytes in 984 blocks. This tells us that the program is steadily freeing such blocks
as it runs, rather than hanging on to all of them until the end and freeing them all.
The deaths entry tells us that 29,520 blocks allocated by this stack died (were freed) during the run of the program.
Since 29,520 is also the number of blocks allocated in total, that tells us that all allocated blocks were freed by the end
of the program.
It also tells us that the average age at death was 22,227,424 instructions.
From the summary statistics we see that
the program ran for 1,045,339,534 instructions, and so the average age at death is about 2% of the program’s total run
time.
10.2.1.2. Example of a potential process-lifetime leak
This next example (from a different program than the above) shows a potential process lifetime leak.
A process
lifetime leak occurs when a program keeps allocating data, but only frees the data just before it exits.
Hence the
program’s heap grows constantly in size, yet Memcheck reports no leak, because the program has freed up everything
at exit. This is particularly a hazard for long running programs.
150