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 sta

Answer 1

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 2

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/

Answer 3

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

Answer 4

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 5

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