[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHqAajbj9V+-_=18+sEYa6+J_183+vvkZk+fCFVrQ0qXFA@mail.gmail.com>
Date: Tue, 11 Nov 2025 18:17:33 -0500
From: James Y Knight <jyknight@...gle.com>
To: Rich Felker <dalias@...c.org>, Thorsten Glaser <tg@...lvis.org>
Cc: 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 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
(amortized-linear-time append is required by the spec, so an
exponential size-growth is required). Thus, taking initial capacity of
16 bytes (which reserves 24 on glibc malloc), and appending 1 byte
will immediately grow it to 32 bytes (reserving 40 on glibc) -- even
though the original 24-byte allocation would've sufficed. Or, creating
a string sized 30 bytes (which reserved 48 bytes in glibc malloc), and
appending 4 bytes will grow it to a capacity of 60, which ends up
reserving 72 -- even though the original 48-byte allocation would've
sufficed.
There will, of course, _always_ be cases where you need to actually
grow the container (and move the objects). But, having a
malloc-variant that returns the size can substantially reduce the
memory used, on average, for these small containers, under real world
usage patterns, because it will avoid doubling the size of the
container when there was still space left in the current allocation.
On Tue, Nov 11, 2025 at 4:07 PM Thorsten Glaser <tg@...lvis.org> wrote:
> It seems like, if C++ has a need that must be served by libc’s
> malloc implementation, then that’s an implementation thing, and
> we don’t need to change the C standard for it, but instead ask
> libc implementors to add a function specifically for the use by
> C++ runtimes (which they can use once they (compile-time) tested
> its availability, over the existing way).
I don't believe the C++ proposals ever asked for a Standard C API to
be added -- they do indeed treat it as an implementation detail, so
there's not a requirement to add a new malloc-related API to C for
C++'s purposes.
But...if C _does_ wish to add an API with a goal of it being useful to
C++...then I'd say that realloci is not the API to add.
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.
