[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 371916] New: execution tree xtree concept
From:       Philippe Waroquiers <bugzilla_noreply () kde ! org>
Date:       2016-10-31 21:48:38
Message-ID: bug-371916-17878 () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=371916

            Bug ID: 371916
           Summary: execution tree xtree concept
           Product: valgrind
           Version: 3.12 SVN
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
          Assignee: jseward@acm.org
          Reporter: philippe.waroquiers@skynet.be
  Target Milestone: ---

Summary:
###########################
This patch implements a new "xtree" module in pub_tool_xtree.h and m_xtree.c.
This module generalises the data structure used by massif to
visualise the heap usage.

An xtree can be used to visualise any kind of resource or event associated
to stack traces.
For example, we could use an xtree to show some counts/events
related to system calls, e.g. the nr of bytes read/written by read/write
syscalls, ...

In the current patch, it is however only used for representing heap usage.
Tools that are replacing malloc/free/... can now very easily also
produce a heap memory representation.

massif internals has been changed to be based on this new xtree module.

memcheck, helgrind and massign are now supporting a new option
  --xtree-memory=none|allocs|full
to produce a heap usage report at the end of execution.
These tools also now provides the 'xtmemory [filename]' gdbserver
monitor command to produce an xtree heap usage report on demand.

An xtree can be saved in 2 formats:
  * massif format
  * callgrind format


Performance:
##############################
Depending on the application, the massif tool is typically a few percents
to 2 times faster than the 3.12 massif (e.g. perf/heap is about twice faster
now).
Massif also typically now uses less memory (e.g. perf/many-xpts uses now
125Mb of arena core memory instead of 205Mb).


Some more detailed changes
##########################
pub_tool_xtree.h, coregrind/m_xtree.h, coregrind/pub_core_xtree.h:
* implementation of the generalised xtree.
  (this is the bulk of the change)

docs/xml/manual-core.xml, docs/xml/manual-core-adv.xml:
* document the new options and Execution Tree concept.

coregrind/m_debuginfo/debuginfo.c:
* Addition of a symbol name cache, maintained/cleared similarly to
  the current cfsi_m_cache.

coregrind/m_deduppoolalloc.c, pub_tool_deduppoolalloc.h:
* function VG_(allocStrDedupPA) specialised to create a de-duplicating
  pool for strings.

coregrind/m_main.c, coregrind/m_options.c,
coregrind/m_replacemalloc/replacemalloc_core.c, coregrind/pub_core_options.h:
* addition of the new options --xtree-memory=none|allocs|full
  and --xtree-memory-file=filename

include/pub_tool_xarray.h, coregrind/m_xarray.c:
* new function VG_(xa_str_is_member), to search a string in an
  xarray of strings.

massif/ms_main.c:
* change internal implementation so as to use the new xtree module.

helgrind/hg_main.c,
memcheck/mc_include.h, memcheck/mc_main.c, memcheck/mc_malloc_wrappers.c,
massif/ms_main.c:
* support for option --xtree-memory
* support for gdbserver command xtmemory [filename]

Various small changes to massif test .exp files (mostly because the
--stats output has changed, due to the changed implementation).

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]