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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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

Sadly, malloc_trim does not satisfy the request "a GC that actually
releases the memory back to the system": we do release it back to glibc
but glibc only does it when we're lucky enough that the memory we
released is all at the very end of the heap (and that constraint
apparently also applies to `mallov_trim`).

A concurrent GC would be great, yes.  XEmacs had that, pretty much (not
concurrent, only incremental, but it should not be terribly hard to
push it over the edge and make it concurrent).

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

I'd oppose calling `malloc-trim` in the default config.  So the answer
would be "in your ~/.emacs" (presumably next to the code that changes
the GC config vars ;-)


        Stefan


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