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

Previous Next

Full log

View this message in rfc822 format

From: DJ Delorie <dj <at> redhat.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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 19:31:56 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>> Yet another word of memory used,
>>> Since 200MB is peanuts, I figure that extra 24B should be acceptable ;-)
>> *per chunk*.
>
> No, those counters are meant to be global.  

To clarify, that extra word was the "chunk age" information, not the
aggregate metrics.

> One thing that remains a bit unclear for me is in the doc of
> `malloc_trim`; it says:
>
>        The pad argument specifies the amount of free space to leave  untrimmed
>        at the top of the heap.  If this argument is 0, only the minimum amount
>        of memory is maintained at the top of  the  heap  (i.e.,  one  page  or
>        less).   A nonzero argument can be used to maintain some trailing space
>        at the top of the heap in order to allow future allocations to be  made
>        without having to extend the heap with sbrk(2).
>
> 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.

Previous Next

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