Memory Manager Concepts

What about pooling? That''s an interesting concept. Just allocate a big hunk of mem when your code goes through it''s initializing procedures and write your own alloc/dealloc routines to deal with memory managment inside this blob of memory. Sortof "Hands-on" memory managment. I guess it''s suitable for game development, but I don''t know if it''s worth the extra hazzle, but certainly it''s a good experience to write one.

Link section
Linux Dev Center
Cantrip.org
memorymanagment.org


"Imagination is more important than knowledge..." Albert Einstein

Most versions of the standard allocator use pooling. Effective C++ (Scott Meyers) discusses pooling. Modern C++ Design discusses small object allocators(You can get a free preview of it here).

I dont believe in pooling, it was what i was using before.

I prefer a mixed aproach, where you alocate a medium sized pool (20Mb), and when you need more you allocate another block (also dont believe in resizing the original block)...

Pooling is much easier on consoles (i expect), because we are *almost* assured all memory is ours to use, so we can pretty much partition it and... well... manage it!

Currently I use 20Mb blocks, with the smallest allocation possible being 2Kb, which gives us around 10.240 allocation leafs.

I''m also going to collect allocation information so that I can tweak these parameters later on...

Thanks for the links, any more?

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak

The whole point with pooling is to have several pools for different purposes. Only then you can control memory fragmentation in a good way, which is the biggest advantage of custom memory management. Don''t just use a single pool for everything, as it''s likely that your memory management routine will be more inneffient than the one already built in in the operating system.

You will most likely want to keep the same types of objects in the same pool, or at least objects with roughly the same size. I would actually use two different types of pools, an object pool, and a variable size pool. The object pool can only contain a certain type of objects, and is very fast. The variable size pool need to keep track of the sizes, so it''s slightly more inefficient, and the memory becomes more easilly fragmentated.

> I prefer a mixed aproach, where you alocate a medium sized pool (20Mb), and when you need more you allocate another block

Well, thats exactly how I understood pooling anyway

The latest thing I added to my handler was a specialized subclass with fixed puddle and pool size, organizing the memory in a linked list of (free) puddles at initialization and just handing them out on alloc and putting them back on the list on free.

fredizzimo:
Yea, I had thought about "static" and "dinamic" pools, the static kind being the one where only objects of a certain size can be allocated, the dinamic being where variable-sized objects get allocated...

Also, we can further divide entities in two factions:
- Stuff that is allways uploaded (on memory) while the game is running, like mouse cursor, fonts, etc...
- Stuff that is only present for a limited time, like a map, for example, gets totally thrown out after we jump onto the next level...

Allways present data never generates fragmentation (should be the first thing to get allocated by the engine, and the last to disapear, so, sequencial allocation/deallocation).

Ketzer:
Ya, pooling refers to pretty much all mem managing models where we allocate more than we need now and manage free space, my reply was more directed towards the "monolithic pool" aproach, where (maybe more simplistic engines) only allocated a huge pool and manage it, knowing that the engine will never require more than that preset ammount...

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak

Ok, heres the Class that i''ve come up with on my own:
- Handles pools of 20 Mb.
- If allocation size required is superior to 20 Mb, then a new block to target size is allocated from windows.
- Minimum allocation size is 2048 bytes, if alloc size is inferior to that value, the whole 2048 bytes are reserved to it.
- Keeps track of Maximum & Minimum *Contiguous* Memory free in any block.
- Auto-Sorts blocks per Maximum contiguous mem free values, in descending order.
- Its quite fast (imho)
- *Will be Thread-Safe

Question: I did a stress test and got a few errors. I quickly traced it and I''m pretty sure it is due to multi-threading. Now i''m working on making the whole mem manager class thread safe, so i''ll have to look into my "Multithreading Applications Under win32" book, and see if I can come up with a way that doesnt destroy the class''s speed...

I think I can run this in 2 directions:
- I just make sure the code isnt also being run in another thread, via mutexes or similar...
- I detect current thread, and have a mem manager per thread...

Cmon guys, throw me your experiences in this...

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak