[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2891052.RmrKFJ9eKF@tjmaciei-mobl5>
Date: Sun, 02 Nov 2025 15:10:45 -0800
From: Thiago Macieira <thiago@...ieira.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: 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: realloci(): A realloc() variant that works in-place
On Sunday, 2 November 2025 05:31:59 Pacific Standard Time Alejandro Colomar
wrote:
> The purpose of realloci() is being extremely cheap. So, why would one
> ask for extra size?
Speculative growth. When the container is being added to, it knows it needs at
least one more element, but it can't predict the future to know how many more.
So it asks "pretty please" for a few more.
However, we can keep the code and simply ask for a bit more in the same
parameter, instead of two. With the interface as you've described, it's not a
failure to be unable to return as many bytes as requested.
> If the caller needs 37 kiB, it should ask for exactly 37 kiB. The
> allocator would likely give 40 kiB.
With ptmalloc inside glibc, the rounding up is likely only to be to the
smallest allocation unit, that is, 16 bytes. So it's unlikely to return 40 kB,
aside of some special circumstances (e.g., an mmap()-backed allocation).
However, the upper layer can ask for 40 kB if it speculates it might need that
and only be given 37.5 kB.
> Then the caller will ask again when
> it needs 41 kiB. Why would the caller want to allocate something like
> 64 kiB (just as an example), but then be happy with 37? This call is
> much cheaper than an actual move with realloc(3) or malloc(3)+free(3).
So it is. I don't know yet whether it's going to be too expensive to call it
for every single element growth - I expect it will be. So container is
probably going to request more than a single element when growing, but
probably not double as it does today.
All this will need fine-tuning once implementations exist.
> So, why not require the caller to not ask too much? We could go back to
> reporting an error if there's not enough memory.
>
> Of course, it would still guarantee no errors when shrinking, but
> I think we could error out when growing.
I'd prefer no errors either way. If there isn't memory to grow the underlying
space (a brk() system call returns ENOMEM), then realloci() returns as much as
it could get but not more.
--
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.
