In message <[EMAIL PROTECTED]>
Robert Goliasz <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
http://www.compton.nu/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
