December 31, 2004
Garbage collection for robust game code
In this port, I considered the performance issues associated with garbage collection in game code. I came to the conclusion that it was inappropriate for use during gameplay because it would burn a considerable amount of CPU time and make the frame rate stutter. I also thought that it might be useful for detecting memory leaks during development. Now I think it might actually have wider application.
As a game is developed, people make mistakes. Artists and designers check in buggy assets and programmers check in buggy code. The impact these errors have on development depends on the robustness of the game code. Ideally such errors will not stop the game from running and their impact will be limited to the parts of the game that have an essential dependency on them.
For example, if an artist checks in an animation with the wrong name, the game should not crash. It should complain loudly that the animation is wrongly named but it should run and all the other animations should play correctly. Likewise, if a programmer introduces a bug into one of the characters, that bug should ideally not make the game crash and all the other characters should work correctly.
This allows development to continue relatively unhampered while the asset or code is fixed.
It is difficult to achieve this kind of robustness in the face of certain kinds of memory bug: memory fragmentation and memory leaks. The problem is that memory is a resource that it shared between all parts of the game code. If fragmentation or leaks allow the memory to get into a state where allocations cannot be satisfied by the memory manager, all the code comes to a grinding halt and the game has no option but to crash.
Garbage collection could help here. I still hold the opinion that garbage collection is too slow for use during gameplay. But what if it was held in reserve until leaks and fragmentation actually caused the memory manager to fail? It is better to drop a few frames and let the garbage collector sort it out than to have the game crash. Then although the rest of the team might be frustrated with the frame rate, at least they can still get on with their work.
My idea is to use a garbage collector as a secondary disaster recovery system. The primary memory management methods would be the kind we already use: manual memory management, reference counting, weak references, etc. If these techniques were applied correctly, as one would hope they would be in the final release of a game, the garbage collector would never be activated and would thus have absolutely no impact on performance. Of course, should a memory bug make it into the final release, the difference between an occasional frame drop and a crash would be the difference between TRC pass and failure!
Here are some other potential uses of garbage collection that would not affect the frame rate:
As a game is developed, people make mistakes. Artists and designers check in buggy assets and programmers check in buggy code. The impact these errors have on development depends on the robustness of the game code. Ideally such errors will not stop the game from running and their impact will be limited to the parts of the game that have an essential dependency on them.
For example, if an artist checks in an animation with the wrong name, the game should not crash. It should complain loudly that the animation is wrongly named but it should run and all the other animations should play correctly. Likewise, if a programmer introduces a bug into one of the characters, that bug should ideally not make the game crash and all the other characters should work correctly.
This allows development to continue relatively unhampered while the asset or code is fixed.
It is difficult to achieve this kind of robustness in the face of certain kinds of memory bug: memory fragmentation and memory leaks. The problem is that memory is a resource that it shared between all parts of the game code. If fragmentation or leaks allow the memory to get into a state where allocations cannot be satisfied by the memory manager, all the code comes to a grinding halt and the game has no option but to crash.
Garbage collection could help here. I still hold the opinion that garbage collection is too slow for use during gameplay. But what if it was held in reserve until leaks and fragmentation actually caused the memory manager to fail? It is better to drop a few frames and let the garbage collector sort it out than to have the game crash. Then although the rest of the team might be frustrated with the frame rate, at least they can still get on with their work.
My idea is to use a garbage collector as a secondary disaster recovery system. The primary memory management methods would be the kind we already use: manual memory management, reference counting, weak references, etc. If these techniques were applied correctly, as one would hope they would be in the final release of a game, the garbage collector would never be activated and would thus have absolutely no impact on performance. Of course, should a memory bug make it into the final release, the difference between an occasional frame drop and a crash would be the difference between TRC pass and failure!
Here are some other potential uses of garbage collection that would not affect the frame rate:
- Garage collection could be used to clean up memory between levels or sub-levels or between front-end GUI and gameplay.
- It could be used to clean up after changes to the game state that are beyond the scope of what the code can correctly handle, such as real time changes made by a designer through a level editing tool.
- It could be used as a means of fully compacting memory. This might be done prior to saving an image of memory that will later be used as a load image for release builds.
The point of this post is not demonstrate another useful feature of C#. There is a garbage collector available for C++: http://www.hpl.hp.com/personal/Hans_Boehm/gc/.
# posted by Alastair Patrick : 3:13 PM
