Studying Hare's builtin functions for memory allocation...
If the debug tag's set allocates additional space for the pointer & size of the preceding allocation, whilst enforcing alignment to some pagesize reading from the `envp` array on startup.
If compiled against LibC it defers to its memory allocation functions.
As for the self-hosted memory allocator... `malloc` returns null for size of 0, & defers primarily to kernel-specific code for massive allocations.
1/2?
Normally though Hare's malloc rounds the size to a power of 2 & looks up that "bucket". If null it falls back to arena allocation, or kernel-allocating a new arena. Otherwise it pops that entry off that bin's linkedlist & validates it. Regardless it saves the allocated size to this "chunk" & increments a profiling counter.
Meanwhile free locates the header fields from the pointer, decrements that counter, considers asking the kernel to free it, & pushes it onto the correct bin.
2/3!
Arena allocation btw means incrementing a pointer into free memory.
Given a size of 0 realloc's synonymous with free, given NULL its synonymous with malloc. Otherwise it validates that we've changing its effective size before allocating, copying the memory, & freeing. Could this be faster?
Upon shutdown it validates all remaining allocations, & would validate there aren't any if they provided themselves a way to check if they're crashing.
3/3 Fin! Later: CPU-specific runtime!
