ktf/igprof — pull request #18 by jblomer (2013-04-21 12:46:41+00:00)
Title: First version of the empty memory profiler

The empty memory profiler identifies large allocations of potentially unused memory. To do so, it scans allocated memory for runs of 4096 bytes or more containing a pattern that indicates unused memory. The memory scan takes place on free() and during a live heap walk. The results are stored in the MEM_LIVE counter for both freed and leaked memory. The recorded stack frames always belong to the resource allocation.

In its standard mode (-ep), the empty memory profiler looks for memory pages filled with zero bytes. Such pages can occur due to deliberately setting memory to zero, for instance by calloc(), memset(), or initializers. Zero-filled pages can also be the result of memory allocated by mmap of /dev/zero but unused until the profiler scans the memory.

If started as -ei, the profiler initializes allocated memory with a "magic pattern" (0xAA). As a result, only memory that is deliberately set to zero is reported.

If started as -eu, the profiler initializes allocated memory as with the -ei option. However, it records only pages filled with the magic byte. Thereyby, it identifies allocated memory that has never been touched (but that also might have never been mapped to physical memory).

Caveats:
o) In order identify the stack frame of the allocation that corresponds to a resource deallocation, this disabled the DEBUG guard around storing the frame pointer in a counter.

o) The CounterDef struct has been extended by a function pointer derivedLeakSize. If set to non-NULL, it allows to compute the leak size from the content of a live resource, rather than taking the entire size of the resource.

o) For this particular analysis, it doesn't matter if memory is freed at the end of the program or not. It would be nice to be able to add the "leaked memory" to the normal counter value.

Todo:
o) There is little reason why the search for runs of zeros in memory should be restricted to 4K pages. One could think of more fine-granular analysis with runs or arbitrary length starting at e.g. 512B, which also do not need to be aligned.