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

[DJ Delorie <dj@redhat.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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.

As long as gc runs between each type of "task", a high-memory task will
be trimmable because GC would have freed all that memory and it's all
together at the top of the heap.

What would cause a problem is, say, if in the middle of running a high
memory task you *also* load a font or something and *that* locks the top
of the heap.