The G1 Java Garbage Collector
At JavaOne, Sun released Java SE 6 update 14 with the first revision of the Garbage First (G1) garbage collector. Although officially still experimental, you can switch the G1 collector on and test your application with it. Although I'm currently writing an in-depth article on what G1 is and how it works, I wanted to introduce it in this blog first.
G1 is a low-pause, low-latency, sometimes soft real-time, collector that allows you to set max pause time goals and max collection intervals through suggestions on the Java VM command line. Although it cannot guarantee it, G1 will attempt to meet your goals, and hence introduce as little latency as possible into your application. This in turn may also make the VM run more predictably as it attempts to meet the pause time goals you provide.
According to Sun (look here: http://java.sun.com/javase/technologies/hotspot/gc/g1_intro.jsp) these are the attributes of the G1 collector:
- Parallelism and Concurrency. G1 uses all available CPUs (cores, hardware threads, etc.) to speed up its “stop-the-world” pauses when an application's Java threads are stopped to enable GC. It also works concurrently with running Java threads to minimize whole-heap operations during stop-the-world pauses.
- Generational. G1 is generational, meaning it treats newly-allocated (aka young) objects and objects that have lived for some time (aka old) differently. It concentrates garbage collection activity on young objects, as they are the ones most likely to be reclaimable, while visiting old objects infrequently. For most Java applications, generational garbage collection has major efficiency advantages over alternative schemes.
- Compaction. Unlike CMS, G1 performs heap compaction over time. Compaction eliminates potential fragmentation problems to ensure smooth and consistent long-running operation.
- Predictability. G1 is expected to be more predictable than CMS. This is largely due to the elimination of fragmentation issues that can negatively affect stop-the-world pause times in CMS. Additionally, G1 has a pause prediction model that, in many situations, allows it to often meet (or rarely exceed) a pause time target.
That was taken right from Sun's site minus a few sentences. However, the part on generational is very simplistic. Compared to the parallel collector and others in Java SE, G1 doesn't maintain hard boundaries between generations. In fact, the heap is more like one large generation broken down into equally-sized regions (called remembered sets). The collector concentrates its work on sub-sets of regions at certain points of time, in effect treating them like different generations (young or old).
I'll get into these details in my article. For now you can check out java.sun.com for more details, or review the presentation given my Paul Ciciora at JavaOne this year on G1: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008