Re: a mudflap experiment on freebsd

[Nicholas Nethercote <njn at cs dot utexas dot edu>]

On Wed, 23 Feb 2005, Doug Graham wrote:

> > Regarding memory consumption, perhaps libmudflap's default backtrace
> > parameter should be set to zero, for both speed and space reasons.
>
> If it's storing all the backtraces that is burning up all the memory,
> another approach might be to keep a separate hash table for storing
> backtraces, then hash new backtraces and see if the same backtrace already
> exists from a previous call to malloc.  If so, no need to allocate a
> new one.  That's essentially what the hprof Java profiler does, and it
> works pretty well.  The average application might have many thousands
> of mallocs, but only a few distinct backtraces.  Also, saving program
> counters instead of symbolic names in the backtrace would probably save
> a lot of memory, and might also make hashing the backtrace cheaper.
> Or the strings containing the symbolic names could be internalized rather
> than allocating a new string for every symbolic name in every backtrace.

That's pretty much what Valgrind does -- each backtrace is just N program 
counters, and there's a symbol table full of strings, more or less.  When 
a backtrace is printed, Valgrind looks up the symbol table, which is not 
particularly fast, but printing error messages is relatively rare.

With respect to backtrace sizes, Valgrind's default is 4 but almost 
everybody immediately sets that to something much higher.  Many people set 
it to something like 40 so as to get the biggest possible trace.  So I 
think that trying to get around the problem of memory consumption by 
making the default backtrace size small won't work.

N