On Thu, 2015-06-18 at 14:20 +0800, 王阳 wrote:
> I have done it two times with different options series. The result is
> as follows:
> 1.--tool=helgrind --gen-suppressions=all --stats=yes
> --profile-heap=yes --track-lockorders=no --read-var-info=yes
> --trace-children=yes --error-limit=no --log-file=xxx.log myprog
Ok, the origin of the memory is related to the locks/nr of locks
your application creates and/or locks/keeps locked.
About 50Gb of memory is consumed for hg.ids.4.
> 51,760,182,272 in 341,498: hg.ids.4
This is the 'universe of locksets' : ie. all the locksets that
helgrind has ever seen.
It looks like your application uses a lot of locks
and keeps a lot of locks in a status 'locked' shown by:
> locks: 1,029,288 acquires, 915,546 releases
From the above, I guess your application has thousands
of locks, and that each thread has sometimes hundreds
of locks held.
Well, if that is the case, I think helgrind data structure
is not done for such a behaviour :(
There is no garbage collection of the lock set universe.
At this point, I think there are 2 possible approaches:
* implement in helgrind a garbage collection of the univ_lsets
(unclear if this is implementable, and for sure not trivial)
* you change the limits of Valgrind max memory, to e.g. go
to 128G or 256G.
You might refer for that to the revision r13278, which increased
from 32G to 64G. That gives the various constants to multiply by 2
or 4 to go to 128G or 256G.
So, checkout the SVN version, then do
svn diff -r13277:13278
and follow that pattern to increase to 128 or 256G
Philippe
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
