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: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: carlos <at> redhat.com, rudalics <at> gmx.at, fweimer <at> redhat.com, monnier <at> iro.umontreal.ca, 45200 <at> debbugs.gnu.org
Subject: bug#45200: [PATCH] Force Glibc to free the memory freed
Date: Wed, 03 Feb 2021 15:51:51 -0500

Konstantin Kharlamov <hi-angel <at> yandex.ru> writes:
> α) sometimes, call to `free()` frees memory completely
> β) sometimes, call to `free()` leaves memory lingering forever, till malloc_trim is called additionally.
>
> The answer I'd like to know is why do you not do always either α or
> always β? (I'm leaving out here the question of which way is correct
> and why, I'm rather curious just why the difference in behavior).

If the chunk being free'd happens to be the highest-addressed chunk in
the heap, it "exposes" that hole in the heap below it, if that exceeds
MALLOC_TRIM_THRESHOLD it causes a trim.

If the chunk is *not* at the top of the heap, nothing happens.  We only
trim the top of the heap.

Of course, this assumes that the caching logic doesn't decide to hold on
to the chunk *anyway* (like, if it's put in tcache), in which case it's
not freed despite being at the top of the heap.  Note that any patch
affecting tcache performance will need to be vigorously defended ;-)

IIRC the fastbin cache also holds onto the top chunk.  Since trimming
cleans the fastbin, this often frees the top chunk.  Disabling fastbins
might be an interesting thing to try.

Previous Next

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