Commit Graph

3 Commits

Author SHA1 Message Date
Julian Seward
26f0bb05e7 Be more careful to separate build flags for the preload shared objects
as opposed to the valgrind code proper.  In particular, make sure that
-mpreferred-stack-boundary=2 does not get used for the preload shared
objects, since that can cause the stack to become misaligned and leads
to segfaults.  Modified version of a patch from Matthias Schwarzott
(zzam@gentoo.org).  Fixes #324050.

Also, fix the configure check in configure.ac for
-mpreferred-stack-boundary=2 so that it checks whether this is
allowable for 32-bit code generation even on 64-bit (x86) hosts.  This
check was wrong before now and led to 32-bit builds on 64-bit hosts
generating poorer code for speed critical helper functions (eg
helperc_LOADV32le) than on 32-bit builds on 32-bit hosts.



git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14471
2014-09-05 20:00:22 +00:00
Julian Seward
32dd8e857c Add documentation for exp-dhat.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11438
2010-10-13 14:06:00 +00:00
Julian Seward
230002ce29 Add DHAT as an experimental tool. DHAT (a Dynamic Heap Analysis Tool)
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
2010-10-12 10:09:15 +00:00