On Wed, Feb 23, 2005 at 12:49:41PM -0500, Frank Ch. Eigler 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. Internalizing entire backtraces also makes it simple to collect statistics on where the memory is being allocated from. --Doug.
