[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ukd7bs4yhho664dkzypomw5hesrvxy2twpb5ntxuhe2cieupc2@i34hmxspwt2j>
Date: Sat, 1 Nov 2025 17:14:24 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Thiago Macieira <thiago@...ieira.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
Hi Thiago, Florian,
On Sat, Nov 01, 2025 at 08:42:30AM -0700, Thiago Macieira wrote:
> On Saturday, 1 November 2025 08:14:05 Pacific Daylight Time Florian Weimer
> wrote:
> > I assume the document here is current?
> > <https://jemalloc.net/jemalloc.3.html>
> >
> > The description is not very precise. I think for avoiding
> > fragmentation, it would be desirable for xallocx to return values
> > great than size + extra if there's a tail that cannot be used by
> > another allocation. It's unclear whether that's permitted.
> > But with a few clarifications, xallocx might indeed be a simpler
> > interface for this.
>
> Agreed. It would be very much implementation-dependent, though.
>
> In other words, xallocx() may return any value greater than the *current*
> size, which may be smaller than the new desired minimum.
>
> In one scenario, let's say you have a block of currently 2304 bytes and you're
> asking for 2560 bytes with an extra 512 "if it won't bother you". But this
> already is in the 4096-byte slab, so all allocations are of that size and
> don't fit the 2048 one. So it will return 4096.
>
> In another, let's say you have a block of 1920 bytes and you make the same
> request. As it can't grow past 2048 without memcpy(), it will return 2048,
> which is less than the requested minimum of 2560. In this case, it's up to the
> caller to decide to malloc() a new block, as it really needs that new minimum.
Hmmm, I would simplify for realloci(). Perhaps we could have the
following semantics:
size_t realloci(void *p, size_t size);
- It will never fail. It always allocates a size >=MIN(oldsize, size).
- When shrinking, either it does actually shrink (if the space can be
reused by others), or returns a large size if that space would anyway
be wasted.
- When growing, it grows to the first step at least as large as the
requested size if possible, or it grows as much as possible. Then
it's up to the caller to judge if that's enough. For example:
actual_size = realloci(p, requested_size);
if (actual_size < needed_size)
do_actual_realloc();
Does this sound good for std::vector?
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
Download attachment "signature.asc" of type "application/pgp-signature" (834 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.
