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

[Konstantin Kharlamov]

Okay, apparently I'm not the only one affected by the memory problem¹, so I'll
try to make the necessary change for it to go over the finish line.

I have a question though. So, wrapping `malloc_trim` in elisp and adding it to
idle with `(run-with-idle-timer)` sounds simple. But, where in code should I do
the `(run-with-idle-timer)` call, i.e. so it's called as is emacs is getting
initialized?

1:
https://www.reddit.com/r/emacs/comments/n13v5l/what_is_the_next_big_feature_after_native_comp/gwc5g77/?context=3

On Wed, 2021-02-03 at 11:02 -0500, Stefan Monnier wrote:
> > 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.
> 
> Thanks.  At least that seems to indicate that glibc does its job
> properly for the way we normally use it.
> 
> > So, I'm thinking of wiring the functional of memory trimming to on-idle
> > hook, without possibility to disable it.
> 
> That seems hard to do (luckily), since AFAICT idle hooks only exist via
> `run-with-idle-timer` and those can always be disabled with things like
> `cancel-timer`.
> 
> > Given how small performance impact in this case would be, I see no
> > reason to even implement an option to disable it.
> > Thoughts?
> 
> My main thought is that if `malloc_trim` indeed makes a significant
> difference, it's a sign that Emacs's own code did its job (it called
> `free` as it should) and that the problem is in how glibc decided not
> to return the memory to the OS.
> 
> That's a behavior that can (and will) change over time outside of
> our control.  So calling `malloc_trim` every time I stop typing for 10s,
> just on account of "maybe glibc didn't reclaim quite as much memory as
> we'd like this time" doesn't sound very appealing to me.
> 
> It sounds like an ad-hoc quick hack.  I love being able to use ad-hoc
> quick hacks, but I don't like enabling such things by default when the
> only use-cases where they're known to be useful are fairly specialized
> (and discouraged by Emacs maintainers ;-)
> 
> So I think we need more info: do the glibc maintainers consider it
> normal for glibc to behave this way?  Why does it behave this way?
> Would the equivalent of `malloc_trim` happen anyway "at some point in
> the future"?  E.g. If you create a test case where you disable GC, let
> the memory use grow to 1GB, then reset the GC vars to their default and
> keep using Emacs modestly, will the memory ever be returned to the OS or
> is an explicit call to `malloc_trim` really indispensable?
> 
> But until we get all the answers to these questions, we can already
> install the code that exposes `malloc_trim` to ELisp.
> 
> 
>         Stefan
>