Providing an arena management API to help applications remain compact

[Gordon Messmer]

On Tue, Mar 3, 2026 at 1:51 AM Florian Weimer <fweimer@redhat.com> wrote:

> * Gordon Messmer via Libc-help:
>
> > That led me to thinking that an arena allocator would be very helpful,
> > because if the application could at least keep its allocations (or its
> > library's allocations) contiguous, it could release memory that it
> > freed. And that led me to thinking: glibc uses a per-thread arena
> > allocator, what if it just exposed that API to the application?
>
> The per-thread allocator currently does not have a strong arena
> affinity.  On free, it puts anything into the thread-local cache
> regardless of the arena the allocation is in.  So it's not really an
> arena-based allocator.
>

If this API were considered, would you recommend renaming the functions? Or
merely documenting the lack of arena affinity?


> The API might work if it's purely advisory,


That's more or less how I was thinking about it, as well.


> This part in malloc_arena_free does not really work:
>

Yeah, I had doubts about that one as well. Probably just drop that
function...

Is this extension interesting enough to continue working on? And if so,
where should I stage it for review?