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

Previous Next

Package: emacs;

Reported by: Konstantin Kharlamov <hi-angel <at> yandex.ru>

Date: Sat, 12 Dec 2020 18:44:02 UTC

Severity: wishlist

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: DJ Delorie <dj <at> redhat.com>
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 23:28:54 +0300

On Wed, 2021-02-03 at 14:36 -0500, DJ Delorie wrote:
> Konstantin Kharlamov <hi-angel <at> yandex.ru> writes:
> > > So I think we need more info: do the glibc maintainers consider it
> > > normal for glibc to behave this way?  Why does it behave this way?
> > 
> > Very good question! I hope Glibc mainainers that are on CC list will be able
> > to
> > answer.
> 
> The answers are "yes" and "performance".  Sorry.
> 

Thanks for chiming in. Let me rephrase a question of mine: right now, Glibc behaves in an odd way:

α) 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).
This bug report was last modified 3 years and 78 days ago.

Previous Next

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