JavaOne: Garbage First

Posted by Charles Humble on May 13, 2008

Community

Java

Topics

Performance & Scalability ,

Deployment / Datacenter

Tags

JVM ,

JavaOne 2008 ,

Concurrency

Sun’s HotSpot Garbage Collectors can be divided into two categories: The young generation and the tenured generation. The majority of allocations will be done in the young generation, which is optimized to have a short lifetime relative to the interval between collections. Objects that survive several collections in the young generation get moved to the tenured generation, which is typically larger and collected less often. The young generation collectors are Serial, ParNew and Parallel Scavenge. All three are stop-the-world copying collectors. Serial uses a single GC thread, whilst ParNew and Parallel Scavenge both use multiple threads. The tenured collectors all use a mark-sweep-compact algorithm. Again three are currently in use: Serial Old, which is another single GC thread, Parallel Old which using multiple GC threads and CMS, a mostly concurrent low pause collector. Garbage First aims to replace CMS and takes a somewhat different approach, straddling the young generation - tenured generation boundary.

In a presentation at JavaOne this year, Tony Printezis provided some more details and a follow up interview is also now available on the JavaOne conference site. In it Printezis provides a summary of how Garbage First (G1) works:

“The heap is split into fixed size regions and the separation between the two generations is basically logical. So some regions are considered to be young, some old. All space reclamation in G1 is done through copying. G1 selects a set of regions, pick the surviving object from those regions and copy them to another set of regions. This is how all space reclamation happens in G1, instead of the combination of copying and in-place de-allocation that CMS does.”

Printezis goes on to describe three main objectives for the new collector:

“The first objective is consistent low pauses over time. In essence, because G1 compacts as it proceeds, it copies objects from one area of the heap to the other. Thus, because of compaction, it will not encounter fragmentation issues that CMS might. There will always be areas of contiguous free space from which to allocate, allowing G1 to have consistent pauses over time. 

The second objective is to avoid, as much as possible, having a full GC. After G1 performs a global marking phase determining the liveness of objects throughout the heap, it will immediately know where in the heap there are regions that are mostly empty. It will tackle those regions first, making a lot of space available. This way, the garbage collector will obtain more breathing space, decreasing the probability of a full GC. This is also why the garbage collector is called Garbage-First.

The final objective is good throughput. For many of our customers, throughput is king. We want G1 to have good throughput to meet our customers' requirements.”

Sun Research have published a paper (pdf document) which provides more details on Garbage-First and provides some information on how these objectives, in particular the real-time goal, are achieved. Whilst most real-time collectors work at the highly granular level of individual objects, Garbage First collects at the region level. If any region contains no live objects it is immediately reclaimed. The user can specify a goal for the pauses and G1 will do an estimate of how many regions can be collected in that time based on previous collections. So the collector has a reasonably accurate model of the cost of collecting the regions, and therefore "the collector can choose a set of regions that can be collected within a given pause time limit (with high probability)." In other words, Garbage-First is not a hard real-time collector - it meets the soft real-time goal with high probability but not absolute certainty. The trade-off is that Garbage-First should yield higher throughput in return for the softer, but still moderately stringent, real-time constraints. This is a good fit for large-scale server applications which often have large amounts of live heap data and considerable thread-level parallelism. Garbage-First also provides some finer control, allowing a user to specify a fraction of time during a period of execution to be spent on garbage collection - for example in the next 120 seconds spend no more than 20 seconds on garbage collection.

Garbage First will be in Java SE 7 and should be committed in the next few weeks. It will also be released as an update to Java 6.

• Older >