Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 8 down vote favorite
3

I have been researching creating my own allocator methods (that will support things such as a memory pool and profiling), however, as I continue my research I have been looking for how this was done in game development. Are there any "go to" examples of allocators used in game development, and if so, what are the advantages of them (if known).

share|improve this question
do you really need to? it's just one of the most complicated things a team can implement ever, if they can implement it. – Gajoo Mar 18 '12 at 23:50
2  
It is a field of interest for me, so I would like to learn about it and implement it – chadb Mar 18 '12 at 23:54
I must say that the subject is really interesting... There are cases where that can mean allot, but on you average PC game I would rather worry about the actual game... – rioki Mar 20 '12 at 9:58

3 Answers

up vote 17 down vote accepted

Game Engine Architecture has some information regarding this topic. The basics are that you need to do some analysis to understand what your memory requirements per level/frame/etc. are like, but there are a few patterns the author mentions having seen several times:

  • Stack-based allocators: These allocate a large segment of memory once, and then allocate pointers within that block of memory in response to requests from elsewhere in the game. This is useful to avoid context switches required by memory allocation, and also because you can use your own techniques to enforce contiguity, or specific alignment for SIMD operations. Some engines also use a double-ended stack where one kind of resource is loaded from the top and the other is loaded from the bottom. Perhaps LSR (Load and Stay Resident, the kind of thing that will be needed throughout the entirety of your game) from the top, and per-level data from the bottom.
  • Single frame memory, or double-buffered frame memory: Memory for operations that occur within one or two frame cycles. This is useful because rather than having to allocate/deallocate every frame, you can simply blow away last frame's data by resetting the pointer you use to keep track of memory to the beginning of the block.
  • Object Pools: A block of memory for many same-size objects, such as particles, enemies, projectiles. These are useful because you can easily achieve contiguity by finding the first unused segment in your pool. They also make iteration easy, because each object is at a known offset from the last.

The biggest thing the author mentions to look out for is memory fragmentation. This is less of an issue if you're developing for e.g. a PC where you have some kind of memory paging backup that you can count on, but in a fixed memory context like a console, there's the risk of being "out of memory" when trying to allocate for a large object because your memory is fragmented in such a way that only small contiguous blocks are available. To that end, he recommends that a stack-based allocator as above also include a method of periodically defragmenting its contents.

For more information on the actual code involved in this, I highly recommend Christian Gyrling's article, "Are we out of memory?", which covers techniques for custom allocators, mostly from a perspective of analyzing memory usage patterns, but this is also applicable to devising a custom solution for memory management.

share|improve this answer
up vote 0 down vote

From what I have seen (but not done) each game tends to either inherit the allocation mechanisms from a framework, from a game engine, from the previous version (2010 -> 2011) or it gets a set of new ones written specifically for its structure (either when data structures are reusable and of fixed size or of numerous types and variable sizes).

Also we had different allocators for sound files/components than for levels and other game objects in the same project. In other projects allocators are inherited from external libraries only for the components managed by that lib.

The optimization really depends on your needs. But usually allocation is done before entering to the game scene and then memory is reused. Some games can get away with gaving no custom allocators. But for action games where the processor, memory and data resources are budgeted you can't afford to lose processing time on large allocations, you can't waste memory to fragmentation and other problems.

Concerning examples you should simply start by having a look at the OGRE 3D game engine it has a few options to configure memory allocators.

share|improve this answer
up vote 1 down vote

The mistake that is often made is to write your own allocators so that you can have more control over how much memory is used by each system and have more visibility on what is going on. A much better way to achieve this is to use a memory profiler. There are plenty of memory profilers out there, my profiler MemPro being one example. This is a totally non-invasive way to keep track of all memory usage, and you can automatically break it down into sub systems using callstack wildcard filters. Ideally its best to keep your memory allocation and memory tracking totally separate, they have totally different requirements.

Arbitrarily dividing your memory into pools can often be detrimental because each pool will have an overhead. You can end up using much more memory than you need without actually realising it. To reduce wastage it’s always better to lump everything together, the slack is then shared by the whole system.

The only reasons for using custom allocators are CPU performance (mainly for cache coherency) and to limit fragmentation. A perfect example of this is a particle system. You want all particles contiguous in memory and you don’t want to pepper main memory with lots of short lived allocations. Another good example for partitioning off is a scripting language.

If you want an example of a general purpose malloc replacement you can have a look at my VMem allocator. It has been used in a number of shipped AAA games. It has techniques that limit fragmentation and keep the memory footprint low, something critical for console games. It’s also very fast under high thread contention. My website has extensive documentation on these techniques.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.