G1GC success examples (compared to CMS) ?

[Andreas Müller]

Hi Nobuhiko,



>Has anybody found successful test case in G1GC compared to CMS?

Just two/three days ago I have reported  an example of a portal application on this list. Subject was "Good G1 result". I have also extensively tested the same portal using ParallelGC and CMS.



Let me just summarize the Pros and Cons of these 3 algorithms:



1.ParallelGC

Pros:

- very good throughput (98,7%)

- young gen pauses are very short (<100ms)

- it is possible (with my application!) to make Full GC pauses very infrequent by proper generation sizing

- long term stability (days during loadtest ~ weeks in production) is very good

Cons:

- Full GC pauses are long (5s on hardware with low single-thread-performance) and will get worse when we are forced to grow the heap size of now only 1 GB

- to make generation sizing work you have to switch off adaptive sizing (-XX:-UseAdaptiveSizePolicy, this is a small con compared to ParNewGC which is in other respects just as good as ParallelGC)



2. CMS

Pros:

- throughput is almost as good as with ParallelGC

- young gen pauses are more or less as short as with ParallelGC if you apply the same generation sizing (this is actually a feature of ParNewGC running by default with CMS)

- CMS runs are as infrequent as Full GC runs with ParallelGC if you apply the same gen sizing

- CMS pauses (initial mark and remark) were always below 1s (100-800 millis)

Cons:

- I ran into very bad heap fragmentation after 1 day of full load with only 1 GB of heap and untuned gen sizes (promotion rate was too high). I solved that but do not know at what timescale such problems could reappear in production (risk remains!)

- I had to increase heap size from 1GB to 1.5 GB to solve the fragmentation issue



3. G1

Pros:

- the longest pauses were no longer than the CMS pauses

- long term stability was as good as with CMS once I did the configuration properly as suggested on this list (do not set new gen and survivor sizes!)

- lowest footprint: same 1GB heap size as with ParallelGC was by far enough, even less should work well

- stability seems much better now than it was in the early days of CMS (Java 1.4.2/1.5 some years ago with lots of very bad memory violation failures!)

Cons:

- average pause times (200-500ms depending on your target) are much longer than with either ParallelGC and CMS because there is basically only one breed of pauses. If you reduce the duration of these pauses you increase the GC overhead (see below)

- throughput was much lower (93%)

- much higher GC overhead means that G1 does not  work well when the garbage rate increases far beyond the 50-60 MB/s I had in the test (while ParallelGC/CMS in peak situations of other tests cleaned up to 420 MB/s. With other applications on other hardware I have even seen ParallelGC/CMS cleaning 1GB/s in a stable and efficient way)

- G1 is not usable on JDK6 and therefore on older appservers like OC4J



Conclusion:

1.) with heap sizes up to 1-2 GB I stick with ParallelGC because it is the most robust and efficient algorithm and rare (once every hour or few hours) Full GC pauses are acceptable.

2.) with larger productive heaps at the moment I look at CMS and manage the fragmentation issue by proper tuning, intensive testing and close production monitoring

3.) I have an eye on G1 because it seems to live up to its promises and may be able to replace CMS in the next years.



Best regards

Andreas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20121115/2eb8e719/attachment.html