fixed_block_allocator block_size

[twiggler]

When allocating from a memory_stack using a fixed_block_allocator in debug mode , I have noticed that the effective size of the memory_stack on my machine is 24 bytes smaller than the requested block size. I have determined that 16 bytes are used by a fence; if I understand correctly, the remaining 8 bytes are used by the node of the intrusive list linking the blocks.

My questions are:

1. How can I query the exact size of the overhead per block? I now fell back to to adding 32-bytes of slack.
2. Although 8 wasted bytes is not a big deal for me, is it conceptually speaking necessary to keep the node around when the block is allocated?

[foonathan]

How can I query the exact size of the overhead per block? I now fell back to to adding 32-bytes of slack.

There is detail::memory_block_stack::implementation_offset, I can make that public.

Although 8 wasted bytes is not a big deal for me, is it conceptually speaking necessary to keep the node around when the block is allocated?

The arena has to deallocate all blocks at the end, so there needs to be some pointer to it. And while the stack itself also stores a pointer, it can grow, so it can't rely on that. I could in theory optimize it for fixed_block_allocator but I don't know whether that's really worth it.

[twiggler]

Ah, I see.
I share your doubts about optimizing for fixed_block_allocator. Making detail::memory_block_stack::implementation_offset public makes the amount of necessary slack space predictable, and would be a welcome improvement.