[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6415187.eO5KgaWL5Y@tjmaciei-mobl5>
Date: Tue, 04 Nov 2025 12:46:34 -0800
From: Thiago Macieira <thiago@...ieira.org>
To: The 8472 <the8472.rs@...inite-source.de>, Rich Felker <dalias@...c.org>,
Alejandro Colomar <alx@...nel.org>, Florian Weimer <fw@...eb.enyo.de>,
libc-alpha@...rceware.org, musl@...ts.openwall.com,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Tuesday, 4 November 2025 09:24:25 Pacific Standard Time Thiago Macieira
wrote:
> I'll have more information for a more complex application once I finish
> rebuilding everything.
Here are some results with Qt Creator, which is the most complex Qt
application I can test on the drop of a dime.
It called the new function 119 times just to print --help. When I launch it
and immediately close its window, it got called 1152 times.
Looking at those first 119 calls, my previous observation stands: quite a few
of those *could* have been realloc(), but aren't because we lack in C++ a way
to detect that the type could be memcpy'ed about and still be valid (and won't
have one until C++29). Qt has a mechanism to opt-in, but the authors of these
types haven't.
This means this count does not include the reallocations that did use
realloc() because the types used the Qt opt-in, and that includes very common
containers like QStringList. So while this new function would be useful for
Qt-based applications, it would be *more* useful for non-Qt C++ ones
(presuming the C++ Standard finds a way to do so), especially because
std::string is not guaranteed to work after being memcpy()ed around.
What I can't tell is whether a realloci() call would have succeeded. These
calls happen when the container is growing, meaning it's about to create one
or more non-trivial objects in the allocated memory, and the chances are
really good that such objects will themselves allocate memory. For the first
couple of growths, the new elements' memory use will likely prevent the
container from extending in size. However, once the container has grown past a
certain size and freed previous allocations, there may be heap space for the
new objects to be created without occupying memory next to the container.
Similarly, once the heap is sufficiently fragmented in a running application, an
array of sufficient size will necessitate using a sufficiently large free region
in the heap, but the objects' allocations can fit other, smaller free spaces.
--
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.
