Collecting performance data on heap usage

Question

I am working on a compiler module that adds extra instructions around every load/store in an application with an emphasis on heap objects. One of the performance factors is the size of the object being accessed; different instructions are chosen at run time for different object sizes.

I have chosen a few benchmarks from SPEC to grade the performance impact of my changes. Currently, I am limited to just looking at overheads measured by perf. This leads to a substantial amount of guessing about why certain benchmarks are more severely impacted than others. Supporting each hypothesis with more data seems like a good step to take. From each benchmark, for each object allocated on the heap, it would be useful to know:

• The size of each heap allocation or reallocation
• The number of times each allocation is accessed throughout the run of the application.

I have been successful in #1. It was easy enough to inject a few printf() calls into glibc as I am already tinkering in glibc. I do not know how to get #2; access counts seem much better suited to a framework or wrapper tool and I don't know which one would work best.

Can you provide a recommendation on how to collect this information?

Answer 1

If you're doing the instrumentation in assembly (which I think you are?), you can, in the data segment, just stick in a label with a value:

        .data
# probably some other stuff goes here
        .align 4
count:
        .long   0

and increment it like so:

        movl    count, %eax
        addl    $1, %eax
        movl    %eax, count

choosing an appropriate register. Though I suppose if you're doing it at the head of a function call, %eax would get clobbered anyway.

Answer 2

Valgrind has a tool 'DHAT" - dynamic heap analysis tool - that can collect this data. The output is not exactly in the format I want, but it is close enough for research work. The access counts are summarized as "average [reads|writes] per byte per allocation"; the exact access count isn't reported nor recoverable from other report data. Maybe some open source development in my future?

http://valgrind.org/docs/manual/dh-manual.html

valgrind --tool=exp-dhat --show-top-n=100000 --trace-children=yes --log-file="log.file" ./benchmark