GNU bug report logs - #45200
Wishlist: There should be a `malloc-trim' function

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: DJ Delorie <dj <at> redhat.com>
Cc: fweimer <at> redhat.com, carlos <at> redhat.com, rudalics <at> gmx.at, hi-angel <at> yandex.ru, eliz <at> gnu.org, 45200 <at> debbugs.gnu.org
Subject: bug#45200: [PATCH] Force Glibc to free the memory freed
Date: Wed, 03 Feb 2021 23:19:40 -0500

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.