[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHp1KzfPk+AnCh2xXEVXpU-_ZH5=uuu36My51yfJoLo9-w@mail.gmail.com>
Date: Tue, 20 Sep 2022 15:53:34 -0400
From: James Y Knight <jyknight@...gle.com>
To: James Y Knight <jyknight@...gle.com>, musl@...ts.openwall.com,
Florian Weimer <fweimer@...hat.com>, Rich Felker <dalias@...c.org>, baiyang <baiyang@...il.com>
Subject: Re: The heap memory performance (malloc/free/realloc) is
significantly degraded in musl 1.2 (compared to 1.1)
On Tue, Sep 20, 2022 at 1:34 PM Szabolcs Nagy <nsz@...t70.net> wrote:
> this does not seem to discuss how existing applications
> that override new() would cope with this.
I'm certain this isn't the right forum to discuss the C++-specific parts of
the proposal, nor am I the right person to do so even if it were. I brought
it up to potentially inform the discussion of C library APIs, not to debate
whether the C++ proposal itself is ready (it's clearly not: it didn't make
it into C++23).
nor how existing implementations on top of c allocators
> would implement it (given that we just agreed that
> malloc_usable_size is not suitable for such use).
As the doc says, implementations should use the trivial implementation
which returns exactly the requested size (e.g. `return {::operator
new(size), size};`), if no better option is available in the underlying
allocator.
nor how existing allocator tooling (interposers, profilers)
> would handle the new interface.
>
User replacement of the C++ global allocators is supported in the standard,
but interposition of malloc is only an implementation-defined extension. In
practice (and as documented by glibc), a malloc interposer must interpose
upon the complete set of malloc-APIs which are ever used anywhere in the
binary. (Of course, the base malloc implementation CAN harden itself
against incomplete interposition if it wishes -- as musl does to support
interposers that fail to define aligned_alloc.)
> If someone wants to push forward this area, IMO, it would be really great
> > to have an API exposing this functionality designed to be implemented in
> a
> > common way across libc malloc implementations -- and eventually added to
> > POSIX or C.
this is done the wrong way around.
Eh. Standardization often goes better when there is already concrete
implementation experience, and some level of agreement, rather than doing
brand new design. That said, I didn't intend to prescribe how someone else
should best go about making this happen, if indeed anyone wishes to do so.
Content of type "text/html" skipped
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.
