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 22:55:25 -0500

>>> No.  Even the tiniest allocation still in use at the top of the heap
>>> locks the entire rest of the heap into memory.
>>
>> Hmm... then I don't understand: the user who reports the problem with
>> Emacs claims that calling `malloc_trim` reduces the PSS size of
>> Emacs tremendously (from 260MB down to 60MB).
>>
>> If `malloc_trim` can't release memory other than at the top, then how
>> come glibc didn't recover those 200MB on its own (e.g. it seems 200MB
>> is well beyond the default value of M_TRIM_THRESHOLD)?
>
> Well, let me make up a case that "works" and you tell me if this is
> common in emacs.
>
> Consider you've spent the day doing normal things and your heap is at
> 100 Mb.  Now you do something memory-intensive for a few minutes, and
> stop, and gc runs.  That "something" allocates a lot of memory, but it's
> all going to be at the top of the heap - aside from whatever fits in the
> first 100 Mb.  It's all released, and GC free()'s it all.  malloc_trim()
> at this point would coalesce it and return it to the system.

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


        Stefan

Previous Next

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