Re: malloc() alignment and max_align_t

[Rich Felker <dalias@libc.org>]

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