* (speedup) addMemEvent: generate inline code to check whether a
memory access is within 16k of the stack pointer, and if so
don't bother to call the helper
* (speedup) find_Block_containing: cache the most recently seen 2
blocks, and check new references in them first. This gives a
worthwhile speedup.
* (fix) at the end of the run, merge stats from un-freed blocks
back into APs. This fixes misleading stats that cause un-freed
blocks to appear to not have been accessed at all.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11480
* change the per-block-byte freq count type from 8- to 16-bit
so as to reduce the misleadingness of eventual numbers for
frequently accessed blocks
* disable debug printing
* add command line parameters to control the number of APs shown
in the final output, and to control the sorting order
* show average block size for each AP
* avoid possible problems when retiring a block and merging its
per-byte access counts into the AP's counts
* add a trailer message giving some important hints to the user
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11434
is a heap profiler that is complementary to Massif. DHAT tracks heap
allocations, and connects which memory accesses are to which blocks.
It can find the following information:
* total allocation and max liveness
* average block lifetime (# instructions between allocation and
freeing)
* average number of reads and writes to each byte in the block
("access ratios")
* average of longest interval of non-access to a block, also
measured in instructions
* which fields of blocks are used a lot, and which aren't
(hot-field profiling)
Using these stats it is possible to identify allocation points with
the following characteristics:
* potential process-lifetime leaks (blocks allocated by the point just
accumulate, and are freed only at the end of the run)
* excessive turnover: points which chew through a lot of heap, even if
it is not held onto for very long
* excessively transient: points which allocate very short lived blocks
* useless or underused allocations: blocks which are allocated but not
completely filled in, or are filled in but not subsequently read.
* blocks which see extended periods of inactivity. Could these
perhaps be allocated later or freed sooner?
* blocks with inefficient layout (hot fields spread out over
multiple cache lines), or with alignment holes
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11431
