| 
  | 
Message-ID: <87bjll4wg2.fsf@mid.deneb.enyo.de> Date: Sat, 01 Nov 2025 16:14:05 +0100 From: Florian Weimer <fw@...eb.enyo.de> To: Thiago Macieira <thiago@...ieira.org> Cc: Alejandro Colomar <alx@...nel.org>, 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 * Thiago Macieira: > On Saturday, 1 November 2025 06:05:57 Pacific Daylight Time Florian Weimer > wrote: >> For the std::vector case at least, what applications want is some form >> of non-moving realloc that allows the application to specify an >> arithmetic progression and an interval, and the realloc variant should >> change the size of the allocation to an element of the arithmetic >> progression that resides within the specified interval, or fail. > > That would indeed be better. When growing, the class doesn't know > how many more items are coming, so a best effort from the runtime is > welcome. There's a chance that the smaller allocation that the > runtime was able to fulfill will suffice and thus we'll have avoided > an extra relocation of the elements. > > Wouldn't this be the xallocx() interface from jemalloc? It allows > the caller to pass the number of elements/bytes it really needs and > the number of elements/bytes it speculates it will need. > > However, it's not necessary. 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.
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.