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

Previous Next

Full log

Message #209 received at 45200 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#45200: [PATCH] Force Glibc to free the memory freed
Date: Wed, 03 Feb 2021 22:26:29 -0500

>> But this only talks about the free space at the "top".  Since in our
>> case most of the free space is not at the top, I wonder:
>> say we have 64KB free at the top and 64MB free elsewhere and we call
>> `malloc_trim` with a `pad` of 16MB, will it release ~48MB of the
>> non-top free memory or will it free all 64MB of the non-top free memory
>> or ... ?
>
> 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)?



        Stefan

Previous Next

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