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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Konstantin Kharlamov <hi-angel <at> yandex.ru>
Cc: fweimer <at> redhat.com, dj <at> redhat.com, carlos <at> redhat.com, rudalics <at> gmx.at, 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 16:44:17 +0200

> From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
> Date: Wed, 03 Feb 2021 11:23:43 +0300
> Cc: carlos <at> redhat.com, fweimer <at> redhat.com, 45200 <at> debbugs.gnu.org, dj <at> redhat.com
> 
> Second, most importantly, what `malloc_trim(0)` does is it restores the correct behavior. I mean, what's the point of ever freeing memory if it's not freed, right?

The purpose of freeing memory is to make it available for further
allocations by the program.  You seem to interpret "freeing memory" to
mean that memory should be returned to the OS, but that's not
necessarily true, and isn't required to allow the freeing program be
able to allocate more memory in the future.

> The problem we're dealing here with is an actual bug in glibc⁵. What this implies is that if the fix indeed hurts performance someplace, well, then it's that this place requires additional performance-related fixes. As opposed to just ignoring the bug because of performance got somewhere decreased. Things like, changing the slow algorithm, or modifying GC behavior for specific usecases…

The fact that the bug you reported didn't get any responses in  more
than a month, let alone wasn't fixed, could be a sign that not
everyone agrees this is a bug...

Previous Next

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