From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16360 invoked from network); 20 Sep 2022 19:54:16 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 19:54:16 -0000 Received: (qmail 9301 invoked by uid 550); 20 Sep 2022 19:54:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9281 invoked from network); 20 Sep 2022 19:54:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=bnv4db68lXeNFcb4AxST7azr3TkQz3xEB2+SzpgEeVU=; b=AApDsyM7gPkvqlLtzGThielVPDddp+TiqmU7Fx9EJMauWwfpqb6MVDy98LiAFglNlI hSuoeAk/cIgssVPoO9Kf/eictWWpPGf/LmbY1vpg8wSfq5Rpxg1uSOwtmQtOl8OsSLTB K1CTyFd3EFt1xXmsbjvCDrbWjjVRTmxSli3JiEhTyp5Ybm8lY1CfF+98REZf++FigzGC 2IFrgM7vwIax5uZZX3grmbwK4eMb0LRlyBpk4ESgvXC43O8kPzcIIgIDKeG0fcDUTFQm oAXXn6ft+2biEKahvk0PQ62JeaeSgCoa5GcgiOTCetpcCxCaJf39srXmovdwoszJx8rA xboA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=bnv4db68lXeNFcb4AxST7azr3TkQz3xEB2+SzpgEeVU=; b=Fq+Qb4RBIS+44Au1PYPrUeucqFyN/+NzrjBFo7nbJXaKcD/ER25ZkUg7edGntJKyKo npsvWkigjk7M3LpidhddXLE5rushTOspkiYna87iFFv8M6cyNydW9gK1cJGcz3RTqcri qDZKaV+q99C15EK9vPb39HivyN204x+8NtQ0YGNlXH4wD/pENYusgLLFQgrJDOkn3iGu 1HRj0nLYV/QVaNj8yUitl7azJgIF8HfTN5/1sxO/9+/8SZECuxJ7kBqTfOo/ne7MI66U pcVlw4vCfT1vBVQAGdfFQGiy2ISr2V7GKGmCmkSWUu6Yqyx7VGFG3x25m3jUiu06hZ64 1Qpw== X-Gm-Message-State: ACrzQf1Yb5SAkIuKdcZATSFW+7hvKTPLc6mSfqpQjF+CwIw/r+39YF2x LeAgaMd0wiieuWuQsVkIXLuPdxApSUU4AMmi9cg9rw== X-Google-Smtp-Source: AMsMyM7vn23B+C6e3bUN4grJDL4Mu1UQawV/U1qNVxYP54fB5yEXiWVv9Foj+WQQ8hgKIiTusPa6+WDTnIEWgdB20Mo= X-Received: by 2002:a0d:db0c:0:b0:34a:2b8:c84e with SMTP id d12-20020a0ddb0c000000b0034a02b8c84emr20331848ywe.126.1663703640625; Tue, 20 Sep 2022 12:54:00 -0700 (PDT) MIME-Version: 1.0 References: <2022091915532777412615@gmail.com> <20220919110829.GA2158779@port70.net> <874jx3h76u.fsf@oldenburg.str.redhat.com> <20220919134659.GO9709@brightrain.aerifal.cx> <874jx2phqm.fsf@oldenburg.str.redhat.com> <20220920173423.GE2158779@port70.net> In-Reply-To: <20220920173423.GE2158779@port70.net> From: James Y Knight Date: Tue, 20 Sep 2022 15:53:34 -0400 Message-ID: To: James Y Knight , musl@lists.openwall.com, Florian Weimer , Rich Felker , baiyang Content-Type: multipart/alternative; boundary="00000000000083231505e9213036" Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) --00000000000083231505e9213036 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 20, 2022 at 1:34 PM Szabolcs Nagy 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. --00000000000083231505e9213036 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 20, 2022 at 1:34 PM Szabolcs = Nagy <nsz@port70.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 p= arts of the proposal,=C2=A0nor am I the right person to do so even if it we= re. I brought it up to potentially inform the discussion of C library APIs,= =C2=A0not to debate whether the C++ proposal itself is ready (it's clea= rly 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 implementati= on which returns exactly the requested size (e.g. `return {::operator new(s= ize), size};`), if no better option is available in the underlying allocato= r.

nor how existing allocator tooling (interposers, profilers)
would handle the new interface.

User re= placement of the C++ global allocators is supported in the standard, but in= terposition of malloc is only an implementation-defined extension. In pract= ice (and as documented by glibc), a malloc interposer must interpose upon t= he complete set of malloc-APIs which are ever used anywhere in the binary. = (Of course, the base malloc implementation CAN harden itself against incomp= lete 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 rea= lly great
&= gt; to have an API exposing this functionality designed to be implemented i= n a
> co= mmon way across libc malloc implementations -- and eventually added to
<= /span>> POSIX or C= .
this is done the wrong way around.
=

Eh. Standard= ization often goes better when there is already concrete implementation exp= erience, and some level of agreement, rather than doing brand new design. T= hat said, I didn't intend to prescribe how someone else should best go = about making this happen, if indeed anyone wishes to do so.
--00000000000083231505e9213036--