I've read some allocator walkthroughs before but I thought that this line stood out:
"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.
This becomes particularly important when the allocation and metadata cannot (or should not) be stored in the same address space. An example of this is allocating memory on GPUs.
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.
> so alloc() doesn’t just need to hand back a pointer. it needs to hand back a pointer that’s correctly aligned for whatever type the caller is about to store there.
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.
[ Header ][ ...variable padding... ][ Back Pointer ][ User Memory ]
^ always exactly sizeof(void*)
bytes before User Memory,
no matter how much padding
came before it
and then it says we don't need to align the back pointer and we end up with
[ Header ][ Back Pointer ][ Padding ][ User Memory ]
without a clear explanation of how we now get to the back pointer if it's behind the variable alignment.
Old magazines like The C/C++ Users' Journal and DDJ used to have ads for companies selling malloc()/free() replacement libraries, exactly because a single implementation isn't adequate to all scenarios.
Having to recode malloc and free from "scratch" in school was a great teaching experience and there's not a month since where I don't encounter something that I understand better thanks to that exercise.
16 comments
[ 0.25 ms ] story [ 30.1 ms ] thread"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.
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.
You might as well always align to 8 bytes and make your header a multiple of 8.
I bet this is better optimized in Rust.