Why malloc always does more than I asked for?(ssenthilnathan3.github.io) |
Why malloc always does more than I asked for?(ssenthilnathan3.github.io) |
if (a->cursor + size > a->limit) return NULL; // out of memory
if (size > a->limit - a->cursor) return NULL; // out of memory if (size > a->limit - a->cursor) return NULL; [ Header ][ ...variable padding... ][ Back Pointer ][ User Memory ]
^ always exactly sizeof(void*)
bytes before User Memory,
no matter how much padding
came before it
[ Header ][ Back Pointer ][ Padding ][ User Memory ]
You might as well always align to 8 bytes and make your header a multiple of 8.
Malloc doesn't know the required alignment (because has no idea what the type is, everything is cast through void). So all malloc implementations have a minimum alignment guarantee. Typically 16 bytes these days on x86, as that means even 128bit SSE values will end up aligned by default.
You couldn't go below the sizeof(void ) anyway, the backpointer needs to aligned too.
The padding only happens when you use memalign or aligned_malloc to specify a much larger alignment.
But most C code out there assumes malloc will always return something that is at least aligned to sizeof(void *), it's very rare to see aligned_alloc. So how is your alloc allocation going to know when it can get away with a smaller alignment?
Even if you are on a cpu that doesn't fault on unaligned memory access, any malloc implementation that doesn't align by default will have serious disadvantages in any benchmarks. IMO, There is no good reason to use an unaligned backpointer.
"to get individual free() working, the allocator needs to remember something about every allocation it handed out. and that’s the moment metadata stops being optional."
That's just a very nice distillation of an important concept.
The conventional approach for allocating memory on GPUs for games and other applications is to use a real-time allocator such as TLSF. However, it is not usually discussed that TLSF is real-time because it stores metadata in-band. It is possible to create a variant of TLSF that preserves its real-time properties while storing metadata out-of-band, but this requires careful consideration.
If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be important.
Something I noticed is that _very often_ the code that is calling malloc(n) is keeping track of n somehow for its own reasons (bounds checking, grow/gap pointers, etc) so merging the value halves stack churn and it’s an easy win.
likely it'd be perf. hit in most cases. They'd have to copy at the tail end (likely) of the allocated area or the start and offset the pointer. They'd need to know the size of the metadata and account for that. including aligning it, hence the tail feels 'nicer'
It's possible to manually use mmap and forgo malloc entirely, rolling your own arena manager.