Garbage collection gets even more clever

Garbage collection is one of those topics where the smart developer acknowledges how much he or she doesn't know about how it really works, while the know-it-alls dispense advice whose freshness date expired sometime around Java 1.3. Does garbage collection, by its very nature, always bring your VM to a complete halt? Should you use System.gc() to periodically clean things up manually? Or should you remain blissfully unaware of such concerns and create objects to your heart's content?

For those inclined to be too clever by half and manage their own memory (and hey, if you really like memory management, there's always C... but I digress), you might want to get up to speed on just how clever the JVM's garbage collector already is.

Jon Masamitsu describes the JVM's various garbage collectors in a recent blog, Our Collectors. He shows six collectors and describes their strategies and side effects, along with how to use or disable them by means of -XX flags:

• "Serial" is a stop-the-world, copying collector which uses a single GC thread.
• "ParNew" is a stop-the-world, copying collector which uses multiple GC threads. It differs from "Parallel Scavenge" in that it has enhancements that make it usable with CMS. For example, "ParNew" does the synchronization needed so that it can run during the concurrent phases of CMS.
• "Parallel Scavenge" is a stop-the-world, copying collector which uses multiple GC threads.
• "Serial Old" is a stop-the-world, mark-sweep-compact collector that uses a single GC thread.
• "CMS" is a mostly concurrent, low-pause collector.
• "Parallel Old" is a compacting collector that uses multiple GC threads.

He also describes a promising new collector in his diagram:

That box represents the new garbage collector that we're currently developing called Garbage First or G1 for short. G1 will provide:

• More predictable GC pauses
• Better GC ergonomics
• Low pauses without fragmentation
• Parallelism and concurrency in collections
• Better heap utilization

G1 straddles the young generation - tenured generation boundary because it is a generational collector only in the logical sense. G1 divides the heap into regions and during a GC can collect a subset of the regions. It is logically generational because it dynamically selects a set of regions to act as a young generation which will then be collected at the next GC (as the young generation would be).

A lot of people understand garbage collection as simply the brute-force "stop the world" exercise that causes AWT apps from 10 years ago (on 10 year old hardware) to seize up, and thus give Java a bad name in some camps. But with a decade of optimization, GC has gotten more clever and more powerful and with some exceptions (which are probably the domain of real-time Java), is probably not something to attempt to second guess anymore.