[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2717922.fDdHjke4Dd@tjmaciei-mobl5>
Date: Tue, 11 Nov 2025 13:56:04 -0800
From: Thiago Macieira <thiago@...ieira.org>
To: Alejandro Colomar <alx@...nel.org>, James Y Knight <jyknight@...gle.com>
Cc: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
The 8472 <the8472.rs@...inite-source.de>, Florian Weimer <fw@...eb.enyo.de>,
libc-alpha@...rceware.org, 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, 11 November 2025 12:36:33 Pacific Standard Time James Y Knight
wrote:
> As has been stated multiple times, realloc on most modern malloc
> implementations can't typically grow an allocation, beyond the small
> amount of growth into the padding space for the implementation's
> chosen size bucket. And when you're talking about small growth like
> that, it is substantially less expensive to have an API to tell the
> allocator to give you that otherwise-wasted memory up-front, from the
> initial allocation.
I've already provided evidence to the contrary, showing realloc() did grow in-
place 7.3% of the time, doubling the size of the allocation. See my email from
last Wednesday.
> > But, there's no need to rush the growth.
>
> Please see the section in the doc,
> https://wg21.link/p0401r6#reallocation which explicitly discusses and
> rejects an 'in-place realloc'.
I don't see that conclusion there. The second bullet point of that section is
the one that talks about realloci() and doesn't reject it. It only says that
it could probe with a growing size to see how big it can get, but I suppose
the API the authors were thinking of returned a boolean, not a size. With a
size indicating how big it did get, there would be no need to probe.
The paragraph below the bullet points talks about Allocators, which are an
important but not the only use-case for this. If realloci() did exist, there
would need to be a paper to allow Standard Library containers to use the
function, and that could be based on the P0401 paper. For everyone else who
doesn't use Allocators, we can get the immediate benefit directly from
realloci().
> If you want to defer growth, you need
> to add a new branch to the control flow for growing the buffer. That
> would be a significant overhead compared to simply setting a slightly
> larger capacity up-front, which can be provided for free by the malloc
> implementation at the point of allocation.
You can do both. The compiler must emit both code paths anyway (aside from
very limited scenarios I've never observed), so the only difference is what
happens at runtime. Growing a buffer by 100% to add one element amortises the
cost of adding the next N, but is a cost if it doesn't add nearly that many.
Besides, fine-tuning this can be done in the container, as a Quality of
Implementation metric.
> One _could_ do that, but it would be exceedingly silly to add a brand
> new realloci API with the justification that it's "useful for
> C++"...when it's not. Only to wrap it -- with a substantial
> performance cost! -- to act like size-feedback-malloc, which is the
> API that would actually be useful.
--
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.
