Skip to main content


G1GC vs. Concurrent Mark and Sweep Java Garbage Collector

Lately, inquiries about the G1GC Java Garbage Collector have been on the rise (e.g., see this graph).  So last Friday we took one of our Search Analytics servers running HBase RegionServer and a semi-recent version of Oracle Java (build 1.7.0_07-b10) and switched it to G1 (-XX:+UseG1GC and no other G1-specific parameters).  Below are some before and after graphs taken from SPM, which is what we use to monitor all our servers, of course.  Click on them for full size.

G1GC Switch from CMS
G1GC Switch from CMS

Can you tell what time we made the switch?  If you cannot tell, have a look at the graph below for a more obvious and more dramatic before and after.

G1GC vs. CMS, GC Details
G1GC vs. CMS, GC Details

Bases on the above graphs, we can see that, at least in this particular workload, G1GC does more collections, but they are smaller and thus take less time.  We’ll keep monitoring JVMs using G1, and if they continue to perform well, we’ll switch to them wherever applicable.  Here is one more look at the situation:

G1. vs. CMS Dashboard
G1. vs. CMS Dashboard

On this SPM Dashboard you should compare the panel/graph on top (using CMS) with the panel/graph directly below it (G1).

In short, we are seeing some more GC work done on the Young generation with G1, but a lot less work being done with the Old generation and thus we see far fewer long pauses than with CMS garbage collector!

If performance and/or monitoring excites you, come join us! If you want to learn more about Java GC and live in or near New York, register for Living with Garbage by Gregg Donovan, a Senior Software Engineer at Etsy.

Please tweet this post about G1GC.

Have you tried G1 Garbage Collector lately?  How did it work for you?


7 thoughts on “G1GC vs. Concurrent Mark and Sweep Java Garbage Collector

  1. Could you provide a little more detail about STW pauses you observed on CMS vs G1 ? I believe CMS GC time of up to 12 seconds depicted on “CMS vs G1 Dashboard” were not stop the world. Did more new gen work of G1 lead to more pauses ?

  2. These are matching our experiences with G1 GC. But you might want to add a metric : CPU usage. The tradeoff with using G1 is a little bit more CPU consumption.
    Out of curiosity, what was the size of the heap for your tests ? Any tests of G1 with large heap size (over 16GB) ?

  3. Those large spikes in the GC time for G1 can definitely be smoothed out.

    The upcoming 1.7u40 has a bit better default values for g1.

    The biggest benefit of G1 is that it doesn’t need to compact like cms does and your heap doesn’t get fragmented like crazy over time and have crazy long pauses like you can see with cms.

Leave a Reply

Stay up to date

Get tips, how-tos, and news about Elastic / ELK Stack, Observability, Solr, and Sematext Cloud news and updates.

Stay up to date