|
From: Nicholas N. <nj...@ca...> - 2004-06-23 08:24:57
|
On Tue, 22 Jun 2004, Jeremy Fitzhardinge wrote: > Valgrind does have a heap - it's where VG_(malloc) goes, allocated with > VG_(brk). valgrind_base->valgrind_map_end is used for when V mmaps > files, but not memory allocation. The mmap area only needs to be big > enough to fix one .so at a time when reading symbols. I see. Unfortunately, some people have very big .so files (one guy had a 500MB one!) > I picked all the initial numbers out of the air, so this is definitely a > tuning process I expected to happen. Ok. I might commit a couple of the small tweaks (eg. shrink CLIENT_SIZE_MULTIPLE), and then think about and experiment with bigger changes. My goal is to just split the user-space into two, the low part for the client, and the high part for Valgrind + tool + shadow memory. The boundary between them would not be fixed, but move up or down if either part became full while the other half wasn't. (The --pointercheck segment would be adjusted as this happened.) That's why the stack size is important, because if the stack is at the top of the user part, growing down, that fixes the client/Valgrind dividing line. It would be nice if no command-line args were needed for the tricky cases (ie. programs with big stacks) but this might be a case of making the common case (small stacks) easy, and the unusual case (big stacks) possible. N |