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

[Eli Zaretskii <eliz@gnu.org>]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: 45200@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Tue, 26 Jan 2021 01:28:01 +0300
> 
> On Mon, 2021-01-25 at 17:17 -0500, DJ Delorie wrote:
> > Eli Zaretskii <eliz@gnu.org> writes:
> > > Thanks, but is it really a good idea to call malloc_trim each time we
> > > free some chunk of memory?
> > 
> > malloc_trim() is very expensive relative to free(), partly because of
> > what it needs to do, and partly because it flushes the fastbins cache.
> > If you call it every, say, 1000 iterations of free, that might suffice.
> > Or perhaps after each GC run.
> 
> (un-ccing Glibc maintainers as this question is Emacs-specific)

Please don't, I invited them to these discussions because they can
help us make the right decisions.

> After a GC run, would that be at the end of `garbage_collect` function as Stefan
> mentioned?

That'd be easy to implement, but I'm not yet sure it's the best
alternative.  In particular, I'd like to have some idea regarding how
much time such a call could take.  In some usage patterns Emacs calls
GC very frequently, which slows down command execution and makes Emacs
less responsive.  So much so that some people raise the GC threshold
too high trying to avoid this slowdown, and raising the threshold too
much is generally not a good idea.  I don't want us to slow GC down
even more so that more people would shoot themselves in the foot by
raising the threshold.