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

[martin rudalics <rudalics@gmx.at>]

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

What I meant was if people really disabled GC for the rest of their
session and got away with it.  But that was only a rhetorical question
to which the answer is clearly no.  All the examples you cite have a
culprit - an application that produces too much garbage.  Identifying
those applications would be much better than working around them by
disabling GC, for example, while a user is in a minibuffer dialog.  That
latter case even must have an easy to identify responsible, just that
nobody cares.  And remember that every cons eventually collected must
have been allocated first.  We always pay twice here.

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

Hardly.  Sometimes we're lucky as in the "The Emacs master is much
slower than the emacs-27 branch" thread.  More often we're not.

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

The important use case IMO is:

- A user detects, maybe after many hours of use, that memory consumption
   increases.

- The user switches on your option and if memory consumption now
   decreases, there's at least a first workaround.

Personally, I never care about Emacs consuming RAM.  On my machine,
Firefox dwarfs everything else in this regard.

martin