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

[Stefan Monnier]

>>> No.  Even the tiniest allocation still in use at the top of the heap
>>> locks the entire rest of the heap into memory.
>>
>> Hmm... then I don't understand: the user who reports the problem with
>> Emacs claims that calling `malloc_trim` reduces the PSS size of
>> Emacs tremendously (from 260MB down to 60MB).
>>
>> If `malloc_trim` can't release memory other than at the top, then how
>> come glibc didn't recover those 200MB on its own (e.g. it seems 200MB
>> is well beyond the default value of M_TRIM_THRESHOLD)?
>
> Well, let me make up a case that "works" and you tell me if this is
> common in emacs.
>
> Consider you've spent the day doing normal things and your heap is at
> 100 Mb.  Now you do something memory-intensive for a few minutes, and
> stop, and gc runs.  That "something" allocates a lot of memory, but it's
> all going to be at the top of the heap - aside from whatever fits in the
> first 100 Mb.  It's all released, and GC free()'s it all.  malloc_trim()
> at this point would coalesce it and return it to the system.

But wouldn't glibc release that memory even without calling
`malloc_trim` simply because it's at the top and is larger than
`M_TRIM_THRESHOLD`?


        Stefan