From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14360 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc() alignment and max_align_t Date: Sun, 7 Jul 2019 20:16:14 -0400 Message-ID: <20190708001614.GH1506@brightrain.aerifal.cx> References: <1561802993.8028.ezmlm@lists.openwall.com> <8c2d963e-1fcf-df2e-2a52-614f0250b594@gmch.uk> <20425c39-b411-b9bb-1e83-bf26dbcd7d4d@adelielinux.org> <20190629135859.GA21055@port70.net> <7dfceb33-b903-de2a-7abe-825f44512f0c@gmch.uk> <6b44b4a2-0047-6304-8c86-058236dc1c74@gmch.uk> <20190707192200.GA2684@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="166452"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14376-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 08 02:16:30 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hkHKX-000hBm-N4 for gllmg-musl@m.gmane.org; Mon, 08 Jul 2019 02:16:29 +0200 Original-Received: (qmail 6084 invoked by uid 550); 8 Jul 2019 00:16:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 6066 invoked from network); 8 Jul 2019 00:16:26 -0000 Content-Disposition: inline In-Reply-To: <20190707192200.GA2684@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14360 Archived-At: On Sun, Jul 07, 2019 at 09:22:00PM +0200, Markus Wichmann wrote: > On Sun, Jul 07, 2019 at 07:17:48PM +0100, Chris Hall wrote: > > Clearly, C11 does not require malloc() to align exactly as max_align_t, and > > bigger is fine. > > > > But I'm curious as to why SIZE_ALIGN is twice as big as it needs to be ? > > > > Design decision. For the algorithm to work, every chunk needs to be able > to contain four machine words (one struct chunk). And with a bit of > maneuvering, this alignment can just be achieved on all chunks with > minimal waste (if a completely new region is allocated in expand_heap(), > then two machine words at the start of it are wasted, but if the new > memory happens to be directly behind the previous section, no waste > occurs at all). > > This makes it easier to reason about chunk sizes. Right now, SIZE_ALIGN > and minimum chunk size (after adding OVERHEAD) are the same. If we > lowered the alignment to two machine words, that would change. Indeed, we could do 16- instead of 32-byte alignment on 64-bit, but then we'd have to preclude the smallest size (16) because it has 0 space after header/footer are accounted for. This is problematic because splitting can lead to a smallest-size chunk without special logic to preclude that, and possibly for other reasons. Note that the header and footer could be reduced to uint32_t rather than size_t; there's no need for huge sizes in this field for managed heap chunks, and mmap-serviced allocations could use a different encoding. And the linked list pointers could be an xor list, dropping the minimum size to 4+4=8==16 on 64-bit and 4+4+4==12 on 32-bit. However the malloc implementation is slated for replacement, so tuning stuff like this is not a very productive activity right now. Rich