1

Is it possible to create a memory pool implementation that follows the simple logic:

1 - Allocate n bytes worth of memory pool.

2 - Use modified new(); function/operator that does not allocate memory only gets a pointer to the beginning of the memory pool. This way objects are created dynamically without overhead.

3 - When the memory pool runs low, it deallocates what is left of it and allocates a new memory pool

4 - the objects created in the first memory pool are left to pick up the memory based on their sizes. The difference of what was allocated in the first pool and what was given back when it ran low is restored by the objects upon their deletion.

My worries are mainly about the fact that I have no idea how to delete the memory pool smaller than it was allocated, KEEPING IN MIND that besides what is left in the end of the memory pool object there is also a OS header for the memory pool that is before the first object, allocated in the pool. What approach do I need to make sure no memory is leaked, that deleting the excess memory pool won't delete objects that are allocated in it and that the header for the memory pool fragment is safely removed.

Thanks!

EDIT: Note that the intent is for memory to be allocated by the memory pool and released by the objects, which may have different lifetime. If this is possible at all...

R. Martinho Fernandes
  • 228,013
  • 71
  • 433
  • 510
dtech
  • 47,916
  • 17
  • 112
  • 190
  • 1
    You cannot deallocate anything other than what you allocated. Just leave the old arena until it's entirely disused. – Kerrek SB Jan 16 '12 at 13:39
  • 1
    Why is this tagged "C"? "C" has no "new()" function, and is entirely different from C++ in this matter. – Kerrek SB Jan 16 '12 at 13:40
  • Point (3) will invalidate all pointers into the pool. – Fred Foo Jan 16 '12 at 13:40
  • @larsmans: read again: The OP wants to "deallocate what's left", not "deallocate the entire pool". – Kerrek SB Jan 16 '12 at 13:41
  • @KerrekSB: then apparently I don't understand the intended algorithm. Never mind. – Fred Foo Jan 16 '12 at 13:42
  • @larsmans: I think the OP wants to chop off the unused part of the pool and only deallocate that unused end, somehow. I cannot make any sense of #4, though. – Kerrek SB Jan 16 '12 at 13:43
  • If there is a small set of classes that if often re-used, a separate pool for each class is much easier. The instances can keep a reference to their own pool so that they are always released to the correct one. Releases to a pool can make 'adjustments' to the pool level by destroying the object, instead of repooling it, if the pool is too full. Allocations from a pool that is empty can just create a new object. – Martin James Jan 16 '12 at 13:57
  • @Kerrek SB - I am faking object oriented programing in C an I am using a new() function as a wrapper for the c allocation underneath. Technically neither C nor C++ have a new() function since in C++ it is an operator. – dtech Jan 16 '12 at 14:04
  • @ddriver: That's beside the point, though. What matters is that in C++ you simply cannot move an object's memory representation around, while in C that is in principle OK, as long as the programmer ensures the program's correctness. So there are potentially very different concerns in the two languages. – Kerrek SB Jan 16 '12 at 14:09

1 Answers1

3

Firstly, this sounds like an arena allocator (as mentioned in the comments), if you want to know what you should be searching for.

Note that arenas are only really useful if you plan to tear down the whole thing at once; if you expect to reclaim memory from deleted objects for re-use, you end up writing your own heap sitting on top of the arena. If you just want to keep the arena-chunk alive until the last object is deallocated, you can manage with a refcount.

Secondly, the only common way I know to allocate memory which you can later shrink without possibly moving (like realloc), is using memory maps: this is platform-specific.

Useless
  • 64,155
  • 6
  • 88
  • 132