Boost.Interprocess has stateful allocators suitable for shared memory segments: they may be re-usable for other mmapped address ranges too.
Otherwise, you may need to roll your own. In increasing order of complexity, you could consider:
- a simple arena allocator: this is almost trivial, but has no way to free individual objects and reuse their memory
- a simple object pool allocator: this works for fixed-size objects with almost no overhead (assuming the object is at least as large as a pointer, you can maintain a singly-linked list of freed objects)
- a hybrid system with multiple object pools for different sizes (but each pool is individually a simple fixed-size instance)
- some kind of slab/slub allocator (multiple fixed-size pools sharing a simple underlying allocator of large fixed-size slabs)
- a SLOB allocator
- a full malloc/free implementation (several are open source, so you can take an implementation and rip out anything you don't need).
Which of those are suitable will depend on some information you haven't given:
- object size
- object pools work if you have only one, or only a few, sizes of object to allocate
- arena allocators don't care about object size
- neither support
realloc
- object lifetime
- object pools generally support arbitrary malloc/free sequences
- arenas usually allow deallocation only all-at-once (so you just reset the arena to an empty state). You could modify this to allow LIFO deallocation.
- space/performance tradeoffs
- the full heap implementation will probably be the slowest and most complex, but is also the most flexible
- SLOB is easier and lighter-weight, but suffers more from fragmentation