Arena Allocators in C: The End of Memory Leaks?
Arena allocators group memory with similar lifetimes into a single large chunk, then free it all at once. This guide walks through a complete C implementation, covering allocation, reallocation, and clearing, and shows how passing an arena pointer makes allocation explicit and lifetimes caller-controlled.
This saves individual memory allocations (which remember, are slow), and makes us have to worry less about managing memory since we only have to worry about a couple of different “chunks” of memory instead of small pieces used for individual arrays.
- teo_zero
Please be aware that pointer arithmetic is not defined on void * pointers, although many compilers allow it. You had better use char * for "data".
Also, your code is prone to overflow when you add data, used, alignment and size.
And finally, the realloc function could be reworked to do nothing if new_size is <= old_size.
- sweetjuly
> This will be used to align the data. For some reason, our computers are much better at dealing with data that is aligned at 8 bytes. This means that the start of each new allocation has to be at a multiple of 8 bytes.
Casting a pointer which is not aligned to its natural alignment has undefined behavior in C. It's not just an issue of unaligned accesses being slow; in practice, your program might also crash or access unexpected data on real platforms with real compiler implementations.
- unwind
More obvious problems with the code as shown:
- The macros doing arithmetic (KiB, MIN etc) don't put their arguments in parentheses, that is very dangerous.
- The code assumes that int and i32 are the same size.
- Don't cast the return value of malloc(). Please Google this.
I appreciated the use of structs by value, that's a nice design.
I agree there's a risk of overflow in the arithmetic around sizes/alignment, but with a 64-bit `usize` that should be mostly theoretical.