From nobody Thu Feb 09 15:31:57 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PCLSv5wh6z3pgLL for ; Thu, 9 Feb 2023 15:31:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PCLSv5Kb9z45RX; Thu, 9 Feb 2023 15:31:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675956719; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mEgu3Zfc/CAk7PR/IJFTyaPaYnnV73pQKnoS6tJaDjA=; b=BI0gtlo898gBEDhopEP4BROFz5fY2DltNx/yd76fCBfARYfpSrAWrfp1P+CTA5jex0wJEa PSJiWJeK7nH6hsQdkvedG9PV5uxM6GCRg2SF6y8I565229EXh98BSRCZbIa+wFbG1MYstO Rx6k4ZChZbJB2EXUnYOomgGtJHzltV223B9e2qQt7y8u5WRXTY6+KjVfb2KUN5bASlyE8j 27GfRPZZEgAffHqOEvLv4TP+hJzC8SByvz6JbTNeeHwKBx+7DvKKjPU4aEJYX7jN0ZJF/r AIHZWXA/w/wJ2gjezNq3cUTwMn9DCT2lDsu8rat5JrWSKE5GNxWEbKdzbREyMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675956719; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mEgu3Zfc/CAk7PR/IJFTyaPaYnnV73pQKnoS6tJaDjA=; b=nQ+EgW7O6LhCFysB/zGQqrTeiYtHi5Nt13oqRNSFLlAy0gwFml/P8xqpC9HAeZuuSfIFby QAaEZV+Bz+qchcpgnR4HhG5W7xuCJxpAhB5zZ5v9Y4cdZtB5xekad1eUAdMurMOxFNdihb a6OcEIq3s99xmiUqBuZ6zwVunxhMbm5lACGTg2/gAoW4qCD1y5GBD7VqDsBi1LxP/lbYLg I+bjMlYCXMJZWk36IiUznHMpk67TQOkTWfSe0YfNPQUXnYsNKpTHbXi1WD1ai5ql7/8Pvv kOjgAkSBJdhyL2Ub/ffu5WYRRqUpm4olPE5yS5z9QnliTFFlcU4SBoBgCkBdcw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1675956719; a=rsa-sha256; cv=none; b=yYzWRaBgsP5g9b+LfGMNRgtBb97qFZ42HqGrWBjmQndzkRfLv3ZQG0lmvseGpatow63nZr dqMXDjjiVnNxoBCy6l+G/SFROJoo0FcgWDtQSUqPQHXSOLSfC6fqJRQf7dR9NTg7sAE7PS j/0ErGF8IlthZ4jkbazKFQHkfdWsDdTLv2q18s6r058j7kgbeVW1INApLXCYfG8s3gY4rN qqbJfGc8lNurCj2rhUIjbml1y+TTAPkq7aglVmJ8RtBRpfB9E2rDuT8OQUJTNdu+9tMQF6 ySFdyO9KznGyrJ6bre8EdeqZd+fmR7tgtnUVF5YN/TLYfCs9vu+adjGy0kxeng== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PCLSv4NQgzQSl; Thu, 9 Feb 2023 15:31:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host81-158-36-31.range81-158.btcentralplus.com [81.158.36.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id EEECB1B5E; Thu, 9 Feb 2023 15:31:58 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: CFT: snmalloc as libc malloc From: David Chisnall In-Reply-To: <3bacad17-ff6b-8bd3-0559-a70274dcd632@gmail.com> Date: Thu, 9 Feb 2023 15:31:57 +0000 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2429423C-C66C-4466-AE47-AE72B67C41E9@FreeBSD.org> References: <2f3dcda0-5135-290a-2dff-683b2e9fe271@FreeBSD.org> <3bacad17-ff6b-8bd3-0559-a70274dcd632@gmail.com> To: "Floyd, Paul" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: N On 9 Feb 2023, at 13:12, Floyd, Paul wrote: >=20 > Another allocator to add to my list. I'll give it a go some time, but = I have a lot of things on my plate at the moment. >=20 > I had a quick look. Do you support reallocf? Not in snmalloc itself. FreeBSD libc supports this as a wrapper around = realloc: = https://github.com/freebsd/freebsd-src/blob/6332ef8941999b0c074d1ece0e1e10= 8447c70b98/lib/libc/stdlib/reallocf.c#L34 So libc using snmalloc does support it. > Looking to the fairly short term future, I couldn't see anything for = the upcoming C23 sized/aligned free functions. It may be premature as = the standard isn't out yet. Most of those can be implemented using the same underlying APIs as = posix_memalign, we can add them once they=E2=80=99re standardised. The = libc++ implementations of the C++ equivalents all simply wrap = posix_memalign. > Recently I did some work on adding a warning for realloc of size 0 to = Valgrind (not finished code review yet). I see that you 'free and return = NULL' (in the same camp as glibc and ptmalloc). However, jemalloc is in = the other camp "maybe free and return a pointer to something" (along = with Solaris and musl). That's not really an issue since realloc of 0 is = "implementation defined". However, it is slated to become UB in C23. We used to return NULL on malloc(0), and subsequently also on = realloc(0). We changed it because sort and (I think) pkg both call = realloc via a wrapper that checks for a NULL return and calls abort, yet = also pass 0 as an argument to realloc. This meant that I was unable to = buildworld after this, which was quite exciting (especially since I = forgot to create a boot environment before that update) - most other = things worked, but some key bits of FreeBSD didn=E2=80=99t. Our malloc code path could be shortened slightly if we could rely on = code accepting behaviour that conforms to the standard from malloc, = rather than the behaviour that glibc=E2=80=99s malloc happens to = provide. I was quite surprised to see this from code in the FreeBSD = base system, since none of the third-party code that I=E2=80=99ve used = with snmalloc had this behaviour. David