[musl] Re: realloci(): A realloc() variant that works in-place

[Thiago Macieira]

On Friday, 31 October 2025 09:22:40 Pacific Daylight Time Alejandro Colomar 
wrote:
> Thiago, if you need this, it would also be useful to clarify what it
> would be useful for, and numbers if the micro-optimizations are
> important for you.

As in the other email, this is important for us in C++ because we cannot 
guarantee in a generic container's implementation that the object's type can 
be moved in memory. A very common example of this is libstdc++'s std::string, 
which may contain a pointer pointing to itself. If the object is moved 
elsewhere in memory, the pointer may need adjusting.

Plus, as in the other email, in the common case of a growing container, the 
implementation will need to perform multiple iterations of malloc()
+move+free(), each of which with a bigger buffer. This is a situation where 
there's a good chance of realloci() succeeding and the current solution 
wasting heap space because it can't satisfy the new, bigger allocation with 
space previously freed.

To show this, see this Godbolt example:
https://godbolt.org/z/b8xKb4jjj

This shows what the inner reallocation of a vector of std::string would be. 
The difference between resize_current() and resize_realloci() is the call to 
realloci() before falling back to the current code. In the latter's 
implementation, if realloci() succeeds in resizing the block, the function 
block below the .L56 label is skipped. If it can't resize, then we're no worse 
than before, modulo an extra function call and branch.

Additionally, not shown in the code above, the implementation could be used 
for shrinking too. This would allow the higher layer to decide to do it in 
places where it currently doesn't, because moving the elements is unacceptably 
expensive (just the fact it is O(n) is an impediment in some cases). And even 
if an allocator implementation can't reuse the just-freed memory for new 
allocations after this shrinking, it *can* advise the OS that the physical 
memory can be reclaimed (MADV_DONTNEED), and I'd expect this to be part of the 
Quality of Implementation for any good libc, with implementation-defined 
thresholds.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251031/fdfe8ba5/attachment.sig>