Short answer(s): no, and yes. Longer answer: Memory management is hard in soft real-time systems like video games, no matter whether you use GC or not. If you

Short answer(s): no, and yes. Longer answer: Memory management is hard in soft real-time systems like video games, no matter whether you use GC or not. If you do any dynamic memory allocation, you're going to run the risk of eventually hitting an malloc() or free() call that blocks your main thread. However, avoiding memory leaks is especially important for gaming applications, especially if you're targeting console hardware. Game code tends to create very large numbers of tiny objects during each session, and need to be able to re-use the memory taken by those objects quickly as the game context changes. GC is a great way to protect yourself from leaks, if you can avoid long GC pauses during gameplay. There are a large number of strategies for keeping GC from blocking time-sensitive threads in your program. The solution you describe is a little like generational garbage collection (which AutoZone, incidentally, does). In generational GC, rather than scan the entire heap on every pass, you focus on recently-created objects, as they're most likely to be garbage. Also, using GC for some parts of your application doesn't mean you have to use it everywhere. You might divide your application such that real-time threads use a more deterministic memory-management system, while less performance-critical code gets the productivity and stability advantages of GC.