Archived

This topic is now archived and is closed to further replies.

Prozak

Unified Memory Pool

Recommended Posts

Prozak    898
Hi all, I created a mem pool managing system code, that allocates a large section of memory and then manages it for other classes/ structs. My question is, how do you calculate the initial size of the mem pool, and how do you manage its growth? linked lists? how large should those be? a 10 set of 5mb linked lists, =50mb... or is it better to have a single contiguous mem pool, and resize it if we need more? but doesnt resizing involve creating a new one, destroying the old one and a copy? that can be quite expensive for 50mb of data... any insights would be welcomed... :D

[Hugo Ferreira][Positronic Dreams]
I Am Digerati.

Share this post


Link to post
Share on other sites
superpig    1825
quote:
Original post by pentium3id
Hi all,
I created a mem pool managing system code, that allocates a large section of memory and then manages it for other classes/ structs.
My question is, how do you calculate the initial size of the mem pool, and how do you manage its growth? linked lists?
how large should those be?
a 10 set of 5mb linked lists, =50mb...
or is it better to have a single contiguous mem pool, and resize it if we need more? but doesnt resizing involve creating a new one, destroying the old one and a copy? that can be quite expensive for 50mb of data...

any insights would be welcomed... :D


I''d probably use the ''page'' approach. When the first 5mb pool is full, allocate a second 5mb pool. As you go on, allocate more and more pools, storing them in a linked list. When you allocate objects, start at the first pool, and keep going through the pools until you find one with enough space. Every now and again, reorder the list so that the emptiest page is at the beginning.

I''d also recommend freeing up pools when they become empty, but specifing a ''pool cache'' - number of pools with free space above a certain level to keep around - to avoid freeing up a pool and then immediately having to allocate it again.

If you go with this, though, I''d also recommend a handle-based memory system, where you use a ''Smart Handle'' (like a Smart Pointer, but is a handle) to look up an ''object ID'' in the memory manager''s lookup table, and get the object''s actual address from that. The advantage is that you can then move the objects around within the pages (''defrag'' them, making each chunk of free space larger and possibly allowing you to close down some pages), because you only need to update the object pointer in the lookup table, and everything using it will just use the new value.

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4

Share this post


Link to post
Share on other sites
Prozak    898
Does that kind of smart pointer work by using a pointer to a pointer?

So that, whn i move a block of memory i set the pointer A to the new location, and because all smartpointer use a pointer to pointer A, wich in turn points to the mem location, we allways get it right... right?

isnt this too costly? pointer to pointers?

[Hugo Ferreira][Positronic Dreams]
I Am Digerati.

Share this post


Link to post
Share on other sites
marijnh    182
If you use the page approach you do not really have to move the allocated objects anymore, so no pointer-to-pointer is needed - the originally returned memory location stays the same.
Of course, having pointers-to-pointers is not the end of the world performance wise, and if you have the freedom to change the location of your in-memory data you can do stuff like reorganizing data to prevent fragmentation.
Hmm i just realize i''m not sure i am answering your question here... aww nevermind.

Share this post


Link to post
Share on other sites
superpig    1825
quote:
Original post by pentium3id
Does that kind of smart pointer work by using a pointer to a pointer?

Basically, yeah. The memory manager just keeps an array of pointers (probably void* pointers), and the smart pointer keeps an index into that array. So, YourType *CSmartPointer::operator ->(){return (YourType *)memoryManager::index[myHandleValue];}

quote:

isnt this too costly? pointer to pointers?


Nah, not really.

quote:
Original post by marijnh
If you use the page approach you do not really have to move the allocated objects anymore, so no pointer-to-pointer is needed - the originally returned memory location stays the same.
Of course, having pointers-to-pointers is not the end of the world performance wise, and if you have the freedom to change the location of your in-memory data you can do stuff like reorganizing data to prevent fragmentation.



That''s quite a significant ability. If your pages are 5mb each, then defragmenting your pages could spell the difference between a memory footprint of 10mb and a memory footprint of 25mb.

Another thing about handles is they let you do things like reference counting pretty easily, without needing to derive all your objects from some base class. Rather than the memory manager''s lookup table being a simple handle->pointer conversion array, if it''s going to be there anyway you could store the reference count there too (so it becomes more of a ''database'' of all the objects in memory). That would let you do things like perform garbage collection on your pages.

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4

Share this post


Link to post
Share on other sites