Re: malloc() wastes 50%...

[John Moser <john dot r dot moser at gmail dot com>]

On Fri, 2006-09-01 at 18:41 -0400, Mike Frysinger wrote:
> On Friday 01 September 2006 14:20, John Moser wrote:
> > A little probing and I find that the memory allocator in glibc seems to
> > be wasting ... a lot of memory.
> 
> are you looking at just virtual memory ?  overcommitting with virutal memory 
> isnt that big of a deal, what you should worry about is wasting of actual 
> memory (the RSS value) and i doubt that's glibc's fault
> -mike

mtrace replaces sbrk(), malloc(), free(), realloc(), memalign(),
valloc(), calloc(), and cfree() with wrappers to the native allocator.
It then stores all calls to these in an output file.  Later the file is
run through a simulator which uses tuning values (i.e. MMAP_THRESHOLD
etc) to determine how much heap and mmap() is held by the program versus
how much malloc() memory was used.

Because of this, mtrace can tell how much the brk() segment has grown
since it started (by tracing sbrk()); and the simulator can tell which
allocations are mmap()ed (by using the tuning variables to figure out
how the allocator would have done it).  The simulator is then able to
tell you how much memory was allocated by the allocator, how much was
requested by the program, and how much was wasted.  It can also graph
this over the life of the program (it emits a profile file based on the
data).

In short, I am not looking at virtual memory or RSS; I am looking at the
areas of memory managed by the allocator only.

-- 
John Moser <john.r.moser@gmail.com>

Attachment: signature.asc
Description: This is a digitally signed message part