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

[Konstantin Kharlamov]

On Wed, 2021-02-03 at 10:35 +0100, martin rudalics wrote:
>  >> 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. 

I'm not sure where you got this answer from. The first link I referred to has a
user which does exactly that, and it is a highly upvoted question with 4k views.

To me that seem to imply the answer is "yes".

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

Sure, I completely agree with you. But that is orthogonal to the problem of
free()ed memory not actually being freed.

>  And remember that every cons eventually collected must
> have been allocated first.  We always pay twice here.

First of, glibc has per-thread cache (since 2.26 version, I think), 
specifically for the usecase of apps allcating and freeing memory too often. 
The cache is not affected by `malloc_trim()`, I was assured by people on #glibc 
IRC channel on that.

Second, if Emacs indeed sees it's gonna allocate memory again right away, then 
it shouldn't have even freed the memory in the first place. No free — no 
malloc_trim().