bug#45200: [PATCH] Force Glibc to free the memory freed

[DJ Delorie]

Stefan Monnier <monnier@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.