Relative Performance of Java's Garbage First (G1) Garbage Collector?

Question

Does anyone know of any performance benchmarks of Java's new Garbage First (G1) Garbage Collector (as compared to the "old" GCs)?

In terms of GC pause times, Sun states that G1 is sometimes better and sometimes worse than CMS. While the G1 collector is successful at limiting total pause time, it's still only a soft real-time collector. In other words, it cannot guarantee that it will not impact the application threads' ability to meet its deadlines, all of the time. However, it can operate within a well-defined set of bounds that make it ideal for soft real-time systems that need to maintain high-throughput performance.

I'd like to see actual measures of throughput and latency for Java's CMS (concurrent mark sweep) and G1 (garbage first) collectors.

• Dr. Dobb's | G1: Java's Garbage First Garbage Collector
• InfoQ | Sun's Garbage First Collector Largely Eliminates Low Latency/High Throughput Tradeoff
• Java HotSpot Garbage Collection | The Garbage-First Garbage Collector

Answer 1

The original scientific article ("Garbage-First Garbage Collection" by Detlefs, Flood, Heller and Printezis) contains some details on actual measures (in section 4).

Answer 2

We have just finished a series of testing over CMS and G1, using comparable ergonomics. This is product specific and very subjective, AND we're using Java 6 (so G1 is in the "preview" build) but...

A system using CMS is 20% faster than G1. This was tested with 8GB and 12GB heap space, with 1GB and 1.5GB young space (respectively).

Again - subjective, single system, specific load - but that's our experience.

Answer 3

UPDATED: see below

If you have a web application, or another application that handles a lot of clients/req, and the response time is important for you, then you better use CMS. this test was found in 'Java performance and scalability'

UPDATE : 18 Nov 2019

Here are compared the pauses for each garbage collector. Its 2019 and I think that best option for WebApp is still CMS, until you can switch directly to ShenandoahGC (skip G1)

link : ShenandoahGC Main

It is important to understand that GC pauses might not be the only significant contributor to response times in regular applications. Having large GC pause spells the problem with response time with a very high probability, but the absence of long GC pauses does not always mean decent response time. Queueing delays, network latencies, other services latencies, OS scheduler jitter, etc. could be the contributing cost. Running Shenandoah with response time measurement is recommended to get the full picture of what is going on in the system, which can then be used to correlate with GC pause time statistics.

For example, this is a sample report with jHiccup on one of the workloads:

Answer 4

This Taranfx article (2009-08-29) compares Java 5, 6, and 7 performance on 4 simple benchmarks.

Answer 5

G1 is compared to CMS mostly faster due to the idea of multi-threads. Compared to the Parallel-GC I don't know - it might be the same. Of course G1 is more real-time due to not two kinds of threads running (mostly the small one). It's faster because any thread should produce the same impact to performance. Even compacting is done only on copying. For more details have a closer look at this: http://geekroom.de/java/java-expertise-g1-fur-java-7/