Request for feedback on WG14 proposal N3849 (alloc_at_least)

[Charles Munger]

On Thu, Apr 23, 2026 at 2:46 PM Wilco Dijkstra <Wilco.Dijkstra@arm.com>
wrote:

> Hi Paul,
>
> > Sure, but I was wondering not about microbenchmarks, but about realistic
> > applications. That's a key point in determining the cost/benefit
> > tradeoff for this proposal.
>
> My result implies you can't measure a few extra calls to realloc unless
> you are
> doing millions every second.
>
> > Clearly the main motivation for the proposal is performance, as realloc
> > already provides the functionality needed for correctness. So, what
> > performance costs and benefits would typical glibc-using apps see?
> > That's not clear from the proposal.
>
> I agree it's not clearly stated, but only the first case seems to be
> performance
> related. The others talk about saving memory in bump allocators. This kind
> of
> allocator uses relatively large blocks, so the wastage would be a small
> percentage,
> and wouldn't affect performance.
>
> In general choosing a size that minimizes such wastage is easy. However you
> could use malloc_usable_size since its cost would be small compared to the
> overhead of mmap.
>
Perhaps you can share your benchmark code? I am not sure that it is
possible within the laws of physics to write a malloc_usable_size + realloc
implementation with 5 cycles of latency; even a single load from L1 cache
will exceed that.

Throughput may be a different story; if your processor is speculating that
the address is always the same then realloc may impose a limited cost, but
that won't always be true in a real program. Getting the true size to
realloc to is also dependent on malloc_usable_size, which has data
dependencies on a load, at least. Each of those also involves going through
the PLT.

If realloc() in glibc is very cheap when reallocating to the actual size,
there is still no guarantee in portable code that may be used with
different libc implementations. Some malloc implementations will perform a
moving reallocate on a sampled basis anyway, even if it "could have" fit.
Part of the goal of this proposed standard API is that programs could use
it with nearly-zero overhead regardless of the libc implementation, and
that it would be straightforward for libcs to implement without exposing
implementation details (if they don't want to) or adding extra storage
overhead.

>
> Cheers,
> Wilco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260423/5e1cdb8d/attachment-0001.htm>