Understanding the G1 Garbage Collector – Java 9

Oracle’s Java 9 Hotspot VM ships with the Garbage First (G1) GC as its default garbage collector. This GC, first introduced in Java 7, has the unique ability to efficiently and concurrently deal with very large heaps. It can also be configured to not exceed a maximum pause time. In this post, we’ll take a look at how the G1 works compared to other collectors and why it can so easily outperform other state-of-the-art GCs on large heaps.

How does the G1 Garbage Collector work?

Most state-of-the-art GCs classify heaps into either young generation or old generation objects. This is done mostly because studies of real-world Java applications have shown that more than 90% of objects don’t survive their first garbage collection. Older objects (objects that have survived a few collection cycles) however tend to remain alive and have a 98% chance of surviving. Java GCs split the young generation objects further into the survivor space and the Eden space. Newly allocated objects are always allocated to the G1 Eden space. Once an object survives its first garbage collection, it’s moved to the survivor space. When an object survives multiple collection cycles, it’s eventually moved to the older generation. This is done so that a run-time efficient algorithm can be used on new objects (this algorithm’s run-time depends only on the number of surviving objects but wastes half the heap size) and a memory-efficient algorithm can be used on the old generation (this algorithm’s run-time depends on the heap size, but it uses available memory as efficiently as possible). A heap of such a collector could look like this:

G1 Garbage Collector advantages

Compared to most other garbage collectors, the G1 has two big advantages: (1) it can do most of its work concurrently (i.e., without halting application threads), and (2) it uses non-continuous spaces, which enables the G1 to efficiently deal with very large heaps. Also, the G1 can collect both the young and the old generation at once. This has something to do with the unique way the G1 uses the available heap. Instead of splitting the heap into three spaces (Eden, survivor, and old) like most other GCs, it splits the heap into many (often several hundred) very small regions. These regions are fix-sized (about 2Mb by default). Each region is assigned to a space.  A G1 heap could look like this:

(O: old, S: survivor, E: Eden, U: unassigned)

Splitting the heap into small regions enables the G1 to select a small group of regions to collect and finish quickly. If a region is scheduled for collection, all surviving objects will be copied from the collected region to an unassigned region. Assuming that the collected region was of the Eden space, the unassigned region holding all surviving objects will then become a survivor region. Ideally, if a region is full of garbage (meaning it doesn’t contain a single surviving object), the region can be declared “unassigned” and no work has to be done there.

Granted, if one wants to collect the entire heap, the G1 has to do the same amount of work as any other GC, but this is where the G1 shines because it doesn’t have to collect the entire heap. It doesn’t even have to collect an entire generation. It can select any number or combination of regions to collect. To optimize collection time, it always selects regions that are full (or almost full) of garbage and thereby minimizes the amount of work it has to do to free heap space for subsequent allocations. Other GCs always collect an entire generation, meaning their run-time complexity often depends on the total heap size. In the G1 case, however, this depends on the amount of live objects because memory can be freed without handling an entire generation. Ideally, when the heap is big enough, some regions will always be completely full of garbage, making it easy to collect them.

In addition, the G1 can do most of its work concurrently. In the Java world, we already know about concurrent collections from the Concurrent Mark & Sweep GC (CMS). However, the CMS can only collect the old generation concurrently, it still needs to halt the application to collect the young generation. The G1 only stops the application at the beginning of the GC to do some quick bookkeeping before it immediately resumes the application. This phase is called the “Initial Mark”. Then, while the application is executing, the GC will follow all references and mark life objects (“Concurrent Mark” phase). When this is done, the application is suspended again, and a final cleanup is made (“Final Mark” phase) before selecting a few regions and collecting them (“Evacuation” phase). As the evacuation phase is fast, especially for large heaps, the G1 usually outperforms other GCs in terms of suspension time of the executed application.

Downsides of the G1 GC

The downside is that the G1 doesn’t perform well with small heaps. Where the sweet spot lies depends on the application in question. If needed, you can always fall back to the old default collector by setting the -XX:+UseParallelOldGC flag. If the G1 has too little heap available, you will see “Full GC”s in the GC log. A Full GC is only performed when the G1 determines that the usual mode of operation as described above is no longer possible. In this case, the entire heap is collected with a memory-efficient (but slow) algorithm that ideally will make things better for the next collection. If there are “Full GC”s occurring, you should increase the heap size if possible and fall back to another GC if necessary.

Due to the small regions, the G1 can be configured to limit its maximum pause time by setting -XX:MaxGCPauseMillis=n. The G1 will then estimate the maximum number of regions it can collect at once without overstepping this limit based on previous collections as well as on the amount of detected garbage. The G1 is still far from being a real-time collector, however, it performs better than other collectors that can’t even begin to adhere to such a limit because of their rigid heap structures.