|
From: Robert G. <val...@uu...> - 2007-10-10 10:55:26
Attachments:
versioned_symtab_wip1.patch
|
Following my post on valgrind-users (subject "Dynamically loaded objects -- symbols dissapearing"): I've created a basic alfa version of my patch (attached). It does not yet support storing deltas of different symtab versions. Instead, it copies a SegInfo struct every time discard_syms_in_range() is called. That leads to sometimes insane memory usage, unfortunately. When I ran it with some custom freeradius modules of mine, it created about 220 versions of symtabs which ate around 400MB of memory. I'm planning to extend it further so that somehow magically only changes in SegInfos are stored. The option can be enabled at runtime with --version-symtabs=yes command line argument. I've assumed that a single valgrind (or should I say memcheck?) process is single threaded, is that correct? In particular, I make use of globals (which I saw were used previously), so any threading within the valgrind process would break it totally. You can also see that I extended the struct _ExeContext with one word that's meant to store the version number. Are these extra 4 bytes acceptable in this struct? I know there is plenty of them being allocated. If you think we should try to minimize it, I could think of doing it somehow dynamically, maybe just after this variable-length array that's at the end of it (depending on the value of VG_(clo_version_symtabs)). This way, if someone doesn't want versioned symtabs, we would not need those extra 4 bytes with every struct _ExeContext. Tell me what you think about it. This is not by any means a complete patch, I'm planning on removing repeated code, adding more comments and hopefully making up a way to store deltas of versions of symtabs. Don't apply this yet (but you probably wouldn't anyway). Can I please get write access to SVN so that I can create a branch for my development? I'm not sure if that's possible to do with SVN, but if you could just give me access to one branch (not trunk that is), this would definitely suffice. Thanks -- Robert Goliasz Claranet Ltd. |
|
From: Tom H. <to...@co...> - 2007-10-10 11:05:21
|
In message <200...@ol...>
Robert Goliasz <val...@uu...> wrote:
> I've created a basic alfa version of my patch (attached). It does not yet
> support storing deltas of different symtab versions. Instead, it copies
> a SegInfo struct every time discard_syms_in_range() is called. That leads
> to sometimes insane memory usage, unfortunately. When I ran it with some
> custom freeradius modules of mine, it created about 220 versions of symtabs
> which ate around 400MB of memory.
Excellent.
> I've assumed that a single valgrind (or should I say memcheck?) process is
> single threaded, is that correct? In particular, I make use of globals (which
> I saw were used previously), so any threading within the valgrind process
> would break it totally.
That's fine, as you've probably guessed by all the global variables
that already exist ;-)
Although there will be one thread for each thread in the client
program valgrind is careful to ensure that only one thread will
be running at a time.
The only exception is when one thread is making a system call on
behalf of the client program that may block, in which case another
thread will be allowed to run but the thread making the system call
will wait as soon as the system call is completed until it is given
permission to run again.
> You can also see that I extended the struct _ExeContext with one word that's
> meant to store the version number. Are these extra 4 bytes acceptable in this
> struct? I know there is plenty of them being allocated. If you think we should
> try to minimize it, I could think of doing it somehow dynamically, maybe just
> after this variable-length array that's at the end of it (depending on the
> value of VG_(clo_version_symtabs)). This way, if someone doesn't want
> versioned symtabs, we would not need those extra 4 bytes with every struct
> _ExeContext. Tell me what you think about it.
That sounds like an awful lot of complication for minimal gain to me.
If we assume an average stack trace of 12 entries, then on a 64 bit
system an extra 4 bytes is only a 4% increase in the size of each
execution context.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|