I assume that the project has been abandoned since a some pull requests are pending.
Anyways, I will address a few things here for those coming to this repository in search of knowledge from this code base.
Problems with using "AllocationHeader"
Wasted Memory: AllocationHeader as is used in this repository simply adds overhead in terms of wasted padding memory. Regardless of the fact that the memory(m_start_ptr + m_offset) is already aligned, AllocationHeader header wastes as low as alignment bytes or padding + alignment bytes of memory.
Probable Cache Misses: Since the AllocationHeader is stored before the memory pointer that allocate gives away, there is a probability of cache miss when using free if the memory pulled in does not align with cache boundary. It might be a small cost or a big one depending upon how many times free is called. It's bad since the entire point of a custom allocator is performance with solid metrics of memory usage.
Current Implementation of AllocationHeader stores garbage: As has been addressed in issue #8, AllocationHeader currently stores garbage since it stores the address of a stack allocated AllocationHeader that would go out of scope once it goes out of scope i.e. as soon as the allocate function ends
AllocationHeader allocationHeader{padding};
AllocationHeader * headerPtr = (AllocationHeader*) headerAddress;
headerPtr = &allocationHeader; // <---------- allocationHeader would go out of scope
A better way of implementing is to use push/begin constructs that would store the offset of stack and pop/end which would reinstate the stack allocator back to the pushed offset.
I assume that the project has been abandoned since a some pull requests are pending.
Anyways, I will address a few things here for those coming to this repository in search of knowledge from this code base.
Problems with using "AllocationHeader"
AllocationHeaderas is used in this repository simply adds overhead in terms of wasted padding memory. Regardless of the fact that the memory(m_start_ptr + m_offset)is already aligned,AllocationHeaderheader wastes as low asalignmentbytes orpadding + alignmentbytes of memory.AllocationHeaderis stored before the memory pointer thatallocategives away, there is a probability of cache miss when usingfreeif the memory pulled in does not align with cache boundary. It might be a small cost or a big one depending upon how many timesfreeis called. It's bad since the entire point of a custom allocator is performance with solid metrics of memory usage.AllocationHeaderstores garbage: As has been addressed in issue #8,AllocationHeadercurrently stores garbage since it stores the address of a stack allocatedAllocationHeaderthat would go out of scope once it goes out of scope i.e. as soon as the allocate function endsA better way of implementing is to use push/begin constructs that would store the offset of stack and pop/end which would reinstate the stack allocator back to the pushed offset.