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

[Konstantin Kharlamov]

On Wed, 2021-02-03 at 08:39 +0100, martin rudalics wrote:
>  > Well, I didn't send the patches for my only benefit, but for benefit
>  > of others people. The new ELisp function is something that not too
>  > many people would benefit from, and I mean, including those who
>  > disable GC.
>
> Does anyone really disable GC and get away with it?

Sure. There's for example this post¹, which is probably where I got the idea to 
only run GC on idle from. The question is highly upvoted, it has 4k views, and 
the only positive answer basically says "it's okay as long as you got memory" 
(well, I got memory), and notes that there's also a point in only disabling GC 
during startup. Similar advice to only disable it during startup has this 
pretty upvoted reddit post²

Here's another example³, except in this case the author only disables GC while 
they're inside minibuffer, and enables it back upon exiting. This then got 
propogated here as well⁴

On top of that, there are countless advices on just increasing the 
`gc-cons-threshold` (not inifitely increasing, just making some sane larger 
value), that would surely reinforce an idea of just making GC run only on idle, 
if one ever comes across such advice or just figures it out.

>  > That is because it would be an opt-in feature, which you
>  > need to know about to enable it, and not many will ever find out about
>  > it.
>
> I wouldn't be afraid of that.  In the past months we had a sufficient
> number of candidates caring about the memory consumption of their Emacs
> sessions.  An opt-out feature OTOH would get us soon a couple of people
> who decide that your feature is responsible for some new slowness and
> recommend to throw it out.  So making this an opt-in feature and at the
> same time giving some recommendations of what users can do when they
> detect that their sessions consumes more memory than expected would be a
> finely balanced solution IMO.

Well, I have 2 things to say on that.

First of, so far the impact seemed to be small. If one ever comes to blame the 
new feature, they surely should have actual measurements to support that 
hypothesis.

Second, most importantly, what `malloc_trim(0)` does is it restores the correct 
behavior. I mean, what's the point of ever freeing memory if it's not freed, 
right? The problem we're dealing here with is an actual bug in glibc⁵. What 
this implies is that if the fix indeed hurts performance someplace, well, then 
it's that this place requires additional performance-related fixes. As opposed 
to just ignoring the bug because of performance got somewhere decreased. Things 
like, changing the slow algorithm, or modifying GC behavior for specific 
usecases…

It is the general rule that correct behavior rarely correlates with good 
performance. You might for example omit locks in thread-heavy application, and 
you get better performance at cost of thread races. Things like that.

---------

1: 
https://emacs.stackexchange.com/questions/34342/is-there-any-downside-to-setting-gc-cons-threshold-very-high-and-collecting-ga
2: 
https://www.reddit.com/r/emacs/comments/4j828f/til_setq_gcconsthreshold_100000000/d34gbsp/?context=3
3: 
https://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/
4: https://javaguirre.me/2016/10/19/fixing-my-performance-problems-on-emacs
5: https://sourceware.org/bugzilla/show_bug.cgi?id=27103