Philippe Waroquiers c99e3af927 This patch decreases significantly the memory needed to store the lineloc info. ...

On a big executable, the trunk needs:
dinfo: 134873088/71438336  max/curr mmap'd, 134607808/66717872 max/curr

With the patch, we have:
dinfo: 99065856/56836096  max/curr mmap'd,   97883776/51663656 max/curr

So, peak dinfo memory decreases by about 36Mb, and final by 15Mb.

(for info, valgrind 3.9.0 uses
dinfo: 158941184/109666304  max/curr mmap'd, 156775944/107590656 max/curr
So, compared to 3.9.0, dinfo peak decreases by about 40%, and the final
memory is divided by more than 2).

The memory decrease is obtained by:

* using a dedup pool to store filename/dirname pair for the loctab source/line
  information.
  As typically, there is not a lot of such pairs, typically a UShort is
  good enough to identify a fn/dn pair in a dedup pool.
  To avoid losing memory due to alignment, the fndn indexes are stored
  in a "parallel" array to the DiLoc loctab array, with entries having
  1, or 2 or 4 bytes according to the nr of fn/dn pairs in the dedup pool.
  See priv_storage.h comments for details.

  (there was a extensible WordArray local implementation in readdwarf.c.
   As with this change, we use an xarray, the local implementation was
   removed).

* the memory needed for --read-inline-info is slightly decreased (-2Mb)
  by removing the (unused) dirname from the DiInlLoc struct.
  Handling dirname for inlined function caller implies to rework
  the dwarf3 parser read_filename_table common to the var and inlinfo parser.
  Waiting for this to be done, the dirname component is removed from DiInlLoc.

* the stabs reader (readstabs.c) is broken since 3.9.0. 
  For this change, the code has been updated to make it compile with the new
  DiLoc/FnDn dedup pool. As the code is completely broken, a vg_assert(0)
  has been put at the begin of the stabs reader.

* the pdb reader (readpdb.c) has been trivially updated and should still work.
  It has not been tested (how do we test this ?).
  A follow-up patch will be done to avoid doing too many calls to
  ML_(addFnDn) : instead of having one call per ML_(addLineInfo), one
  should have a single call done when reading the filename table.

This has also be tested in an outer/inner setup, to verify no
memory leak/bugs.




git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14158

2014-07-14 21:20:57 +00:00

145 KiB

Raw Blame History

View Raw