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

From: Konstantin Kharlamov <[email-masked]>
Date: Wed, 03 Feb 2021 11:23:43 +0300

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