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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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