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

[Konstantin Kharlamov <hi-angel@yandex.ru>]

On Tue, 2021-01-26 at 16:55 +0200, Eli Zaretskii wrote:
> > 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.

Sorry, okay.

> > 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.

Yeah, that's true, there's an existing advice to make GC only run on idle. Which is the reason btw this bugreport eventually came to life ☺