Game Development Reference
In-Depth Information
Theirdatastructureshavetokeeptrackofalargenumberofblocksofavailable
and used memory. Any time a piece of memory changes state from used to avail-
able, the data structures must be traversed quickly. When blocks become available
again, the memory manager must detect adjacent available blocks and merge them
to make a larger block. Finding free memory of an appropriate size to minimize
wasted space can be extremely tricky. Since default memory managers solve these
problems to a large extent, their performance isn
tashighasanothermemory
manager that can make more assumptions about how and when memory alloca-
tions occur.
If your game can allocate and deallocate most of its dynamic memory space at once,
you can write a memory manager based on a data structure no more complicated
than a singly linked list. You
'
'
d never use something this simple in a more general
case, of course, because a singly linked list has O(n) algorithmic complexity. That
would cripple any memory management system used in the general case.
A good reason to extend a memory manager is to add some debugging features. Two
features that are common include adding additional bytes before and after the alloca-
tion to track memory corruption or to track memory leaks. The C runtime adds only
one byte before and after an allocated block, which might be fine to catch those pesky
x+1
and
x-1
errors but doesn
'
t help for much else. If the memory corruption seems
pretty random, and most of them sure seem that way, you can increase your odds of
catching the culprit by writing a custom manager that adds more bytes to the begin-
ning and ending of each block. In practice, the extra space is set to a small number,
even one byte, in the release build.
Different Build Options Will Change Runtime Behavior
Anything you do differently from the debug and release builds can change the
behavior of bugs from one build target to another. Murphy
s Law dictates that
the bug will only appear in the build target that is hardest, or even impossible,
to debug.
'
Another common extension to memory managers is leak detection. It is a common
practice to redefine the new operator to add
__FILE__
and
__LINE__
information
to each allocated memory block in debug mode. When the memory manager is shut
down, all the unfreed blocks are printed out in the output window in the debugger.
This should give you a good place to start when you need to track down a memory
leak.
