From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS,URIBL_BLACK shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 51A631F601 for ; Tue, 6 Dec 2022 16:19:59 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="Jz2931o2"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 540E2383B6CC for ; Tue, 6 Dec 2022 16:19:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 540E2383B6CC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1670343598; bh=YcLryXZK73waJbeXVBeoEN5ZpOsKBS5bItj5bG8hMFQ=; h=To:Cc:Subject:In-Reply-To:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Jz2931o2bFMLpLub5SP/p5OZA/uCSAXcq+amEOdTuzR/tQj+SSbay2aNBmJSjZENh rfzEdjXQKkIYCE28kCHhkTSpL2BFMQolSqkljF1L4yXbEEmqn2aWt29PN1qpYWShlR LumUnQLifLpOboSwNq9URPAbzrvOUQIWY3kpVNaI= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 0807738469BF for ; Tue, 6 Dec 2022 16:19:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0807738469BF Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-671-r89yMvf2ONiHSEcYFKlcUQ-1; Tue, 06 Dec 2022 11:19:32 -0500 X-MC-Unique: r89yMvf2ONiHSEcYFKlcUQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 451F985A5A6; Tue, 6 Dec 2022 16:19:32 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 31965C15BA4; Tue, 6 Dec 2022 16:19:32 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 2B6GJLsH1816425; Tue, 6 Dec 2022 11:19:21 -0500 To: Zack Weinberg Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] malloc: Use correct C11 atomics for fastbin In-Reply-To: Date: Tue, 06 Dec 2022 11:19:21 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: DJ Delorie via Libc-alpha Reply-To: DJ Delorie Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Zack Weinberg via Libc-alpha writes: > Every time we start talking about fastbins vs tcache again I start > wondering, again, what's stopping us from replacing the entire malloc > implementation with jemalloc, There's a couple of things, but they're technical details, not political ones: * There's a copy of a "mini-malloc" in the dynamic loader that needs to be somewhat compatible with the full copy in libc.so so that data allocated in the loader can be used later. * The current malloc knows a lot about glibc internals like pthreads and fork, so as to manage those boundaries properly (thread start/stop, etc). * Benchmarks have shown that the various mallocs each have their strong points and weak points, so expect some complaints about performance loss when switching mallocs. Your favorite allocator may perform poorly in someone else's favorite application. * Testing, testing, testing. Libc's malloc is used in all Linux distros *and* Hurd, which means it's known to work with tens if not hundreds of thousands of programs. To propose a new system-wide allocator, you need to replicate this level of effective testing. > or any other implementation designed less than 20 years ago. Comments like this are not appreciated. Age does not imply quality. Please stick to technical points.