From my understanding unless you're going to make some good money off the engine, memory management isn't worth the hassle. Firstly it involves overloading the new operator so you actually know how much memory is being used and were its being created. Forcing objects to be created in chunks that wont separate them across ram and so forth. I'd look into the benefits against the time it takes to implement it, then ask your self why you want it.

first question is, how much memory are you allocating? and how often are you allocating memory?

basically, all good engines use some form of pool allocator. at startup, the engine will grab a bunch of large blocks of contiguous memory (ie: pools) and will allocate out of those pools, instead of using the bare heap.

why do this? well, it comes down to how you access memory. and if your writing a teeny game with a handful of objects, its really probably not worth doing, but if you want to have big scenes, with lots of objects, particles, etc, using a pool system becomes very useful. for the following reasons.

- you can allocate different pools to different kinds of memory (eg: graphics resources in GPU friendly ram).
- for objects which are both small, and allocated frequently (like particles) using a pool will massively reduce heap fragmentation (as only the pool will get fragmented). and you can happily 0 the entire pool when your not displaying particles, eliminating fragmentation entirely.
- it puts a hard limit on the size of your resources, and the memory footprint your game will use. if you run out of memory, you will know exactly where, and why.
- using a pool for level objects, means that when you leave the level, you can simply 0 the entire pool. no more leaks (as long as nothing is holding resources which point to the pool of course!).
- you can defragment a pool at runtime. of course doing this means that anyone holding a reference or pointer to your data must be holding a weak pointer to it. this is generally a good idea anyway, boost has one you can use.
- you can garbage collect from pools at runtime. usually using a reference counted system. can be useful, but also needs things like dead pool lists to keep objects around for a few frames until downstream references are released, etc.

on large games (ala commercial titles), each subsystem will get its own pool, and maximum budget. and its up to each subsystem to dole out memory from that pool as it sees fit. the UI subsystem might get 20mb of ram, out of which needs to come fonts, UI, textures, etc. the resource system might grab 256mb of ram, 128mb of which is a pool for models, 64mb for textures, and 64mb for level objects.. etc etc.

For your own stuff, having a few different pools can be useful, having a separate pools for things like particles is a godsend (and even if you only use pooling for particles, it still helps a lot), and a separate pool for your level objects. can make life a lot easier.

It really comes down to how often, and how much memory your allocating. allocating a lot of very small objects, and then deleting them shortly afterwards will not make the heap a happy place.

personally, ive had it drilled into me over various console tiles to avoid the heap like the plague . There are lots of great pool allocator algorithms out there (eg: slab) but its only worth it if your allocation patterns are problematic.

A simple memory manager used in a lot of commercial games is the mark/release system: 1, 2.

From my perspective, the rules of YAGNI/KISS mean that Garbage collection (other than simple reference-counting) and Defragmentation is a waste of time.

Quote:Original post by Hodgman
A simple memory manager used in a lot of commercial games is the mark/release system: 1, 2.

From my perspective, the rules of YAGNI/KISS mean that Garbage collection (other than simple reference-counting) and Defragmentation is a waste of time.

I agree, its worth getting some pools in, get some simple ref counting going. and if you really need it, you can bolt on defragging later. (as long as you adhere to the pointers to things in pools being weak pointers).