OpenJDK 8 has several Garbage Collector algorithms, such as Parallel GC, CMS and G1. Which one is the fastest? What will happen if the default GC changes from Parallel GC in Java 8 to G1 in Java 9 (as currently proposed)? Let’s benchmark it.

Benchmark methodology

  • Run the same code 6 times with a different VM argument (-XX:+UseSerialGC, -XX:+UseParallelGC, -XX:+UseConcMarkSweepGC, -XX:ParallelCMSThreads=2, -XX:ParallelCMSThreads=4, -XX:+UseG1GC).
  • Each run takes about 55 minutes.
  • Other VM arguments: -Xmx2048M -server
    OpenJDK version: 1.8.0_51 (currently the latest version)
    Software: Linux version 4.0.4-301.fc22.x86_64
    Hardware: Intel® Core™ i7-4790 CPU @ 3.60GHz
  • Each run solves 13 planning problems with OptaPlanner. Each planning problem runs for 5 minutes. It starts with a 30 second JVM warm up which is discarded.
  • Solving a planning problem involves no IO (except a few milliseconds during startup to load the input). A single CPU is completely saturated. It constantly creates many short lived objects, and the GC collects them afterwards.
  • The benchmarks measure the number of scores that can be calculated per millisecond. Higher is better. Calculating a score for a proposed planning solution is non-trivial: it involves many calculations, including checking for conflicts between every entity and every other entity.

To reproduce these benchmarks locally, build OptaPlanner from source and run the main class GeneralOptaPlannerBenchmarkApp.

Benchmark results

Executive summary

For your convenience, I ‘ve compared each Garbage Collector type to the default in Java 8 (Parallel GC).

garbageCollectorTypesJava8

The results are clear: That default (Parallel GC) is the fastest.

Raw benchmark numbers

G2

Relative benchmark numbers

G1

Should Java 9 default to G1?

There is a proposal to make G1 the default Garbage Collector in OpenJDK9 for servers. My first reaction is to reject this proposal:

  • G1 is 17.60% is slower on average.
  • G1 is consistently slower on every use case for every dataset.
  • On the biggest dataset (Machine Reassignment B10), which dwarfs any of the other datasets in size, G1 is 34.07% is slower.
  • If the default GC differs between developer machines and servers, then developer benchmarks become less trustworthy.

On the other hand, there are a few nuances to note:

  • G1 focuses on limiting GC pauses, instead of throughput. For these use cases (with heavy calculations) GC pause length mostly doesn’t matter.
  • This was an (almost) single threaded benchmark. Further benchmarking with multiple solvers in parallel or multi-threaded solving might influence results.
  • G1 is recommended for a heap size of at least 6 GB. This benchmark used a heap size of only 2 GB and even that size is only needed for the biggest dataset (Machine Reassignment B10).

Heavy calculations are just one of the many things that OpenJDK is used for: it’s just one stakeholder in this community wide debate. If other stakeholders (such as web services) prove otherwise, maybe it’s worth changing the default GC. But show us the benchmarks on real projects!

Conclusion

In Java 8, the default Garbage Collector (Parallel GC) is generally the best choice for OptaPlanner use cases.

What’s the Fastest Garbage Collector in Java 8 for Heavy Calculations?

About The Author
- I am the lead for OptaPlanner (java, open source) and I work for Red Hat.OptaPlanner optimizes business resource usage. Every organization faces planning problems: provide products or services with a limited set of constrained resources (employees, assets, time and money). OptaPlanner optimizes such planning to do more business with less resources.OptaPlanner is a lightweight, embeddable planning engine written in Java™. It helps normal Java™ programmers solve constraint satisfaction problems efficiently. Under the hood, it combines optimization heuristics and metaheuristics with very efficient score calculation.OptaPlanner is open source software, released under the Apache Software License. It is 100% pure Java™, runs on any JVM and is available in the Maven Central Repository too.For more information, visit http://www.optaplanner.org

3 Comments

  • Gerhard Hüller
    Reply

    Even taking inito account the low-pause-time goal of G1, it is quite shockingt o see it beaten by SerialGC on a quad-core machine when it comes to throughput.

  • priya
    Reply

    Garbage collection should be dealing with what the name suggests – finding and throwing away the garbage. In reality it is doing exactly the opposite.

  • nisha
    Reply

    Its actually a great and helpful piece of information. I read your blog fairly and most
    of the time you are coming out with some great
    stuff. I shared this with my friends and my followers as its really great stuff
    to share!

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>