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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no
	version=3.4.4
Received: (qmail 21984 invoked from network); 19 Sep 2022 12:37:01 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 12:37:01 -0000
Received: (qmail 18319 invoked by uid 550); 19 Sep 2022 12:36:58 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 18293 invoked from network); 19 Sep 2022 12:36:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1663591005;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=mXQPwmsNYr5jFNMGVUe54+6JNQinV1DQTfKIjBaDNUI=;
	b=gHtJbVirw9VAlXbil+oaVTFr0Ecoxr1zR048vqpr3WOVZe5yoV02t15adEKie2jAObAq8+
	HBkE0dUeaSnfOZeWF+lqSLi5wdI3pcOETF7kdaYbDI67FeQ16NPP0ResnkJjvwLhmnp7YH
	UwY/WAxo8nGyiq6KS4+7ecNX6myWTDc=
X-MC-Unique: 9fDp1wodPEmq8ckwVO-PDw-1
From: Florian Weimer <fweimer@redhat.com>
To: baiyang <baiyang@gmail.com>
Cc: musl <musl@lists.openwall.com>
References: <2022091915532777412615@gmail.com>
	<20220919110829.GA2158779@port70.net>
Date: Mon, 19 Sep 2022 14:36:41 +0200
In-Reply-To: <20220919110829.GA2158779@port70.net> (Szabolcs Nagy's message of
	"Mon, 19 Sep 2022 13:08:29 +0200")
Message-ID: <874jx3h76u.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is
 significantly degraded in musl 1.2 (compared to 1.1)

* Szabolcs Nagy:

> unlike musl those implementations don't return exact size nor have the
> same security and memory fragmentation guarantees, so bad comparision.
>
> tcmalloc:
>   // Returns the actual number N of bytes reserved by tcmalloc for the pointer
>   // p.  This number may be equal to or greater than the number of bytes
>   // requested when p was allocated.
>   //
>   // This function is just useful for statistics collection.  The client must
>   // *not* read or write from the extra bytes that are indicated by this call.
>
> jemalloc:
>       <para>The <function>malloc_usable_size()</function> function
>       returns the usable size of the allocation pointed to by
>       <parameter>ptr</parameter>.  The return value may be larger than the size
>       that was requested during allocation.  The
>       <function>malloc_usable_size()</function> function is not a
>       mechanism for in-place <function>realloc()</function>; rather
>       it is provided solely as a tool for introspection purposes.  Any
>       discrepancy between the requested allocation size and the size reported
>       by <function>malloc_usable_size()</function> should not be
>       depended on, since such behavior is entirely implementation-dependent.

These implementations are buggy or at least mis-documented.  The
interface contract is clearly that for that particular object, the extra
bytes in the allocation are available for reading and writing.  It is
not guaranteed that the allocator will always provide the same number of
extra bytes for the same requested size, but they must be there for the
allocation being examined.  It's even in the name of the function!

Thanks,
Florian