bug#45200: [PATCH] Force Glibc to free the memory freed

[DJ Delorie]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> Yet another word of memory used,
>>> Since 200MB is peanuts, I figure that extra 24B should be acceptable ;-)
>> *per chunk*.
>
> No, those counters are meant to be global.  

To clarify, that extra word was the "chunk age" information, not the
aggregate metrics.

> One thing that remains a bit unclear for me is in the doc of
> `malloc_trim`; it says:
>
>        The pad argument specifies the amount of free space to leave  untrimmed
>        at the top of the heap.  If this argument is 0, only the minimum amount
>        of memory is maintained at the top of  the  heap  (i.e.,  one  page  or
>        less).   A nonzero argument can be used to maintain some trailing space
>        at the top of the heap in order to allow future allocations to be  made
>        without having to extend the heap with sbrk(2).
>
> But this only talks about the free space at the "top".  Since in our
> case most of the free space is not at the top, I wonder:
> say we have 64KB free at the top and 64MB free elsewhere and we call
> `malloc_trim` with a `pad` of 16MB, will it release ~48MB of the
> non-top free memory or will it free all 64MB of the non-top free memory
> or ... ?

No.  Even the tiniest allocation still in use at the top of the heap
locks the entire rest of the heap into memory.