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

[Konstantin Kharlamov]

On Wed, 2021-02-03 at 10:15 -0500, Stefan Monnier wrote:
> > Stefan, what do you think? Will it be okay if I implement a patch that runs
> > `malloc_trim(0)` when Emacs is idle?
> 
> That's yet another reason why we should provide that function to ELisp,
> and then have ELisp decide when it's called (whether after GC, or on
> idle or what).

Okay, let's discuss this idea. It seems that running `malloc_trim(0)` on idle 
(let's say, after 10 seconds of idling, which implies a user might have switch 
to a browser, or something) should resolve all performance concerns. Especially 
given, measurements show it has pretty negligible impact even when located on 
return from GC.

To answer you question in another email about memory benefits given default 
Emacs settings: well, today I tried creating a testcase that would reproduce 
problem with default settings, but haven't really succeeded at it. I have a 
testcase where Emacs without the patch has ≈20M more memory than the one with 
the patch, but that's pretty small difference, and offhand I didn't manage to 
get it increased any further.

So, I'm thinking of wiring the functional of memory trimming to on-idle hook, 
without possibility to disable it. Given how small performance impact in this 
case would be, I see no reason to even implement an option to disable it.

Thoughts?