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 17:21:44 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I haven't thought very much about it, so I'm sure it's easy to shoot
> holes through it, but I imagined something like:

A bit of devil's advocacy just for giggles...

> - one `static unsigned long hoard_size` keeps the approximate amount of
>   space that is free but not returned to the OS.
>   Not sure where/when to keep it up to date cheaply, admittedly.

With full atomic access because malloc is multi-threaded; atomics are
expensive compared to thread-local or nonexisting data.  Updating this
has to be in the critical path, too.

> - one `static unsigned long smallest_recent_hoard_size`.
>   This is updated whenever we allocate memory from the OS.

We map huge chunks at a time, but they stay unbacked until they're
actually used.

> Then you'd call `malloc_trim` based on a magic formula

That's cheating ;-)

>> Yet another word of memory used,
>
> Since 200MB is peanuts, I figure that extra 24B should be acceptable ;-)

*per chunk*.  You allocate 1 byte and you get 32 at the moment, because
of these lower limits.  We're already getting complaints about this
particular overhead.

Previous Next

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