malloc_trim() behaviour

[Carlos O'Donell]

On 05/14/2015 05:41 AM, Ondřej Bílka wrote:
> On Wed, Feb 18, 2015 at 10:30:28PM +0100, Frank Meerkötter wrote:
>> Hello,
>>
>> I've got a question about the actual behaviour of malloc_trim().
>>
>> man malloc_trim says:
>> [...]
>> malloc_trim - release free memory from the top of the heap
>> [...]
>> This function cannot release free memory located at places other than
>> the top of the heap.
>> [...]
>>
>> Today I've looked that the implementation of malloc_trim()
>> malloc/malloc.c and I am a bit puzzled now as its (as far)
>> as I can see not the behaviour described in its man page.
>>
>> __malloc_trim() calls mtrim which makes use of
>> __madvise (paligned_mem, size & ~psm1, MADV_DONTNEED);
>>
>> My understanding is that madvise(MADV_DONTNEED) would allow
>> me to release a range of memory back to the OS. This range
>> wouldn't need to be at the top of the heap.

Correct, but keeping the range at the top allows for simpler
accounting and less meta-data to load when doing a free.

>> Is the man-page outdated? Am I looking at the wrong place?
>> What is the actual behaviour of malloc_trim()?
>>
> No, manual is correct and current malloc only frees top of heap.
> 
> Current allocator is very old and its quite memory intensive.
> You should use tcmalloc/jemalloc until somebody rewrites it to decent
> allocator. 

The glibc malloc, tcmalloc, and jemalloc each have their own uses
and their own tradeoffs. I wouldn't say glibc is memory intensive.
In particular the jemalloc and tcmalloc in particulr can use up
to 2 or 3 more times the memory than glibc's allocator, but are
faster in specific use cases.

That doesn't mean that glibc is perfect, not at all, it needs
much more work. The per-thread arenas, fast bins, and locking
code all needs review. It would be great if we could get to a
lockless algorithm too :-)

Cheers,
Carlos.