|
From: Josef W. <Jos...@gm...> - 2004-03-14 00:14:21
|
Hi, [sorry for the late reply, I was in holiday] Am Monday 08 March 2004 02:00 schrieb Jeremy Fitzhardinge: > Yes, the heap size for Valgrind is set to a relatively small value. The > idea is that if a tool needs to allocate large chunks of memory, it > could use the shadow memory pool. For most tools, this is sized by a > well-understood ratio to the client memory size - but for calltree this > doesn't necessarily make a lot of sense. That's the problem here. It should be possible with a CLO to influence this ratio. > We could increase the Valgrind heap size pretty easily, but it eats into > the available client address space. > > How does Calltree use memory? What does it allocate? The same as Cachegrind, i.e. 64bit counters for cache events per instruction. But as there can be multiple counters for the same instruction (separation by thread, by caller context etc.) this already can be much more. Additionally, for call sites I maintain lists of callees with counters, and a shadow call stack for every thread. So I can't do a good estimation in advance, because the space needed depends on the client code. Would it be possible to make a command line option for bigger Valgrind heap space? If there is a out-of-memory condition, the error message could contain a tip to increase the VG heap space by using this CLO. Should I regard this as a problem of Valgrind core? I think I should release Calltree-0.9.7 for a broader "beta test" (before it is included into Suse 9.1). Josef |