[Valgrind-developers] Memory profiling code segments

[Nicholas N. <nj...@ca...>]

Hi,

I'm looking at ways to improve how code and data segments are handled in
Massif, the memory profiling skin.  At the moment, the --code and --data
options are pretty useless, because they tend to dwarf the stack and heap.

AIUI, this is because when a code/data segment is mmap'd into memory, the
page table is updated but nothing is actually loaded.  Then, as each page
of the new segment is touched, it gets faulted into memory.  And many
programs will only touch a fraction of the code/data segments they mmap
in.  It would be much more useful to only consider pages that have been
touched at some point, because untouched pages can be considered not part
of the program's footprint.

So here's how I propose handling this.  I'll start with code segments,
because they're easier:

 - When a code segment is mmap'd in, record the pages it covers as
   "untouched".

 - When a new basic block is translated, check if its page(s) is
   "untouched".  If so, add PAGE_SIZE to the "code used" count, and mark
   the page(s) as "touched".

 - When a code segment is munmap'd, subtract PAGE_SIZE from the "code
   used" count for every page in the segment that has been marked
   "touched".

(Massif would maintain a mini-page table to hold the markings.)

Data segments can be handled similarly;  however, tracking them will be a
lot more expensive because every LOAD/STORE will have to be tracked.
Maybe this could be optimised, 99.999% of LOADs/STOREs won't cause a page
fault.

Three complications I can think of:

1. Shared memory.  Valgrind currently doesn't distinguish between private
   and shared memory when it reads /proc/pid/maps;  skins aren't told
   whether segments are private or shared.  This should change.  Then
   I could distinguish between "private code used" and "shared code used".

2. According to fscked.org/writings/SHM/shm-2.html, mmap()s from
   /dev/zero are prefaulted.  I'm not sure if this is (a) correct, (b)
   whether mapping /dev/zero is different to using an ANONYMOUS map.  I
   looked at the 2.4.19 sources but couldn't work this out.

3. brk().  Judging from the kernel sources, brk() is just like an
   ANONYMOUS mmap, so handling it isn't a problem.

Can anyone see any problems with my idea, or enlighten me further about
complication 2?

Thanks very much.

N