|
From: Jeremy F. <je...@go...> - 2004-06-23 17:11:46
|
On Wed, 2004-06-23 at 09:24 +0100, Nicholas Nethercote wrote: > 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!) Yes, it's a problem. I think the correct fix is to 1) implement the dwarf reader properly 2) use incremental loading 3) not require mapping the whole thing (at the very least, we only need the debug info, not all the text+data; we could probably only map parts of the debug info as needed, or not at all if we just read() it). > > 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.) Yes, that's an idea. You could make shadow grow down as the userspace grows up. > 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. Well, there's no reason the stack needs to be at the top of the address space. Solaris x86 puts it down low, under the executable. You could fit a 128Mbyte stack there without it getting in the way. J |