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: 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 23:26:45 -0500
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> [ I have no idea what "fastbins" are, but I'll nod along approvingly.  ]

https://sourceware.org/glibc/wiki/MallocInternals

Fastbins are one of the caches layered on the core malloc code.

> OK, so `malloc_trim` can do a more thorough job and discover that
> there's indeed 200MB free at the top which malloc/free wouldn't
> have noticed?  I guess that makes sense.

Yes.

> PS: One last thing: I must say I'm surprised to see the amount of
> effort that seems to be spent on trying to release that "top" free
> memory.  From where I stand, it seems that it will only very rarely
> allow you to release any non-trivial amount of memory.  Why bother?

We have to keep track of the top of heap anyway, in order to grow it.
Adding a check to shrink it is pretty trivial, and it's our *only* way
to return memory to the system.





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.