A fully concurrent GC running on multiple threads/cores might be great, but I guess this is difficult to implement and introduces a lot of overhead. For simple video games, it might work to always do a full GC per frame, but don't allow it to take more than T milliseconds. In a sense the GC function should be able to be paused and resumed, but it could run on the same thread as the game loop, so no synchronization overhead would arise (in a sense many video games are already little cooperative multitasking systems). The game loop should then decide how to balance the time given to the GC and the memory being collected. This would cause longer frame times and hence sometimes a decrease in frame rate, but never long stalls. Note that the issue also popped up for me in C many years ago. Using Watcom C/C++ in the nineties, I found out that a call to the free function could take a very long time. Also for games that could run many hours or days (e.g. a multi player game server) the C heap could get very fragmented, causing memory allocations and deallocations to take ever more time, sometimes even fail. To make my games run smoothly I had to implement my own memory manager. To make them run for a very long time, I had to implement a memory defragmenter. So in the end, this means a garbage collector :-) Of course this problem is well known, I just wanted to re-state that for games the typical C heap is not very well suitable either.