On 15-Aug-09, at 2:17 AM, FFT wrote:
Some guy there is saying Gambit's GC may be slow. Someone might want to address that concern. I was impressed with Gambit's performance so far, but I don't really care about real-time and I don't know enough about the internals.
http://www.reddit.com/r/programming/comments/9ad60/another_realworld_use_of_...
Gambit's current GC is a hybrid stop-and-copy and mark-and-sweep. The main characteristic for this discussion is that when there is a GC, all currently allocated objects which might be reclaimed are checked for reachability from the roots (in other words it is not a generational garbage collector). A generational garbage collector would have two (or more) types of GCs: minor GCs where a (small) subset of the whole heap is scanned, and major GCs where all of the heap is scanned.
Generational GCs have a higher cost for mutations, but the average GC pause is lower. On the other hand, when there is a major GC, the GC pause may be longer than for a nongenerational garbage collector. In other words a nongenerational GC has more predictable GC pauses (although on average they are longer), which is a good thing for real- time applications like games (you wouldn't want your animation to run smoothly in general, and every 5 seconds have a "frame skip"). Of course the best situation would be to have a real-time garbage collector, but QuantZ shows that it is not necessary for a real-time game if you are careful how much and when you allocate.
Marc