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

[Stefan Monnier]

>> But wouldn't glibc release that memory even without calling
>> `malloc_trim` simply because it's at the top and is larger than
>> `M_TRIM_THRESHOLD`?
> Probably, if you disabled fastbins.  Like I said earler, I think
> fastbins bypasses the top-of-heap consolidation, so the chunks might be
> free'd but in the fastbin cache.  malloc_trim() flushes the fastbin
> cache.
> There are other ways to flush the fastbins but they're harder to
> programmatically invoke (i.e. "magic rules").
> Also, fastbins bypass the chunk consolidation, so even if all the memory
> is free()'d it might still be in small-chunk form in the fastbins, ready
> for fast re-use.

[ I have no idea what "fastbins" are, but I'll nod along approvingly.  ]

OK, so `malloc_trim` can do a more thorough job and discover that
there's indeed 200MB free at the top which malloc/free wouldn't
have noticed?  I guess that makes sense.

Since our GC doesn't move objects, there will often be some left over
live object near the top that will prevent most of those mythical 200MB
from being released.

Anyway, thanks for bearing with us and hand-holding me until I start to
feel like I understand the situation.
I have a much better understanding of what Emacs might be able to do.


        Stefan


PS: One last thing: I must say I'm surprised to see the amount of effort
that seems to be spent on trying to release that "top" free memory.
>From where I stand, it seems that it will only very rarely allow you to
release any non-trivial amount of memory.  Why bother?