Generational GC's are what almost every high-performance VM uses and this approach is well-tested in many practical systems. Almost all aplications tend to allo

Generational GC's are what almost every high-performance VM uses and this approach is well-tested in many practical systems. Almost all aplications tend to allocate large amounts of temporary objects, while having large amounts of memory consumed by long-living objects (I would assume that at least one half of used memory in this case are long-living objects). Also, because generational GC is almost invariably copying GC (it is possible to make non-moving generational GC, but that is more of academic interest) it tends to improve caching behavior, which is even more important with each new generation of CPUs. Main reason why copying and generational GCs are not used everywhere is that they tend to generally complicate matters when you want to seamlessly interface with C code (non-managed code in .NET terms), because objects then tend to be moved around by GC, which has to see and be able to update every reference to it's heap. In most applications and runtimes, there are a lot more behind the stages objects allocated by VM and or library routines than objects that you allocate directly in your code. Edit: and I think that Sun's JVM uses generational GC at least since 1.3, if not 1.2.