[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251112020423.GH1827@brightrain.aerifal.cx>
Date: Tue, 11 Nov 2025 21:04:23 -0500
From: Rich Felker <dalias@...c.org>
To: James Y Knight <jyknight@...gle.com>
Cc: Thorsten Glaser <tg@...lvis.org>, Alejandro Colomar <alx@...nel.org>,
musl@...ts.openwall.com, The 8472 <the8472.rs@...inite-source.de>,
Thiago Macieira <thiago@...ieira.org>,
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 Tue, Nov 11, 2025 at 06:17:33PM -0500, James Y Knight wrote:
> On Tue, Nov 11, 2025 at 3:51 PM Rich Felker <dalias@...c.org> wrote:
> > I'm still unclear why "size-feedback-malloc" is supposed to be useful
> > enough to justify all of this. It seems like at most it's saving a
> > fairly small % of space at small sizes and an even smaller % (a fixed
> > maximum, the page size) at larger sizes serviced by direct mmap.
> >
> > What is the actual problem folks are trying to solve?
> >
> > Has that ever been stated clearly?
>
> (I'd just note that size-feedback-malloc wasn't the topic for most of
> this thread -- and I'm not sure if realloci proponents have the same
> goal.)
>
> The point of the size-feedback allocation proposals in C++ is, yes, to
> save memory, mostly for relatively-small-sized growable containers.
>
> As it turns out, C++ programs tend to have a lot of such smallish
> strings and vectors running around. Depending on the starting size,
> growth strategy, and malloc implementation details, you can end up
> with remarkably high memory overhead in practice for these small
> containers -- and the size returning allocation API help to ameliorate
> that. Yes, this doesn't result in a _HUGE_ % of total memory usage
> savings, but is noticeable.
>
> Just to take a concrete example, GNU libstdc++'s std::string allocates
> the exact size requested, initially. So, appending a char will always
> initially grow the container, by doubling the size
But in order to utilize a new interface, libstdc++ would have to be
modified to do so, and there would be all sorts of conditional support
and namespacing issues to deal with.
If you're stuck modifying libstdc++ anyway, you might as well just
make it use a better strategy than initially using exact size, then
doubling. This works everywhere and does not require any new contracts
or feature detection.
Rich
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.
