[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <176696393.VBMTVartND@tjmaciei-mobl5>
Date: Fri, 31 Oct 2025 10:07:25 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com,
"A. Wilcox" <AWilcox@...cox-tech.com>,
Lénárd Szolnoki <cpp@...ardszolnoki.com>,
Collin Funk <collin.funk1@...il.com>,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>,
"Paul E. McKenney" <paulmck@...nel.org>, Alejandro Colomar <alx@...nel.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
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.
Download attachment "signature.asc" of type "application/pgp-signature" (871 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
