Make G1 the Default GC - not a good idea for heavy calculation use cases

[Chi Ho Kwok]

The linked JEP literally states:

* The change is based on the assumption that limiting latency is often more
important than maximizing throughput. If this assumption is incorrect then
this change might need to be reconsidered.
* The resource usage of G1 is different from Parallel. When resource usage
overhead needs to be minimized a collector other than G1 should be used,
and after this change the alternate collector will have to be specified
explicitly.


I'm not sure why linking a throughput benchmark is relevant to the
discussion - we already know that throughput collector is king for
efficiency. G1 and CMS are both aiming at reducing latency which is the
most important factor when you run a user facing programs like web
services, search with Solr/Lucene, desktop program with an user interface,
etc, and I agree with the assessment that latency is more important to the
user than throughput.

A job that takes 5 minutes can take 6 without anyone noticing, but a stuck
web request / user interface is immediately annoying. The questions should
be -


*Readers of hotspot-gc-use, does the workload you run prefer limiting
latency or maximizing throughput?*
*What is your current heap size, and do you plan on expanding it?*


Question 2 is relevant as throughput collector already feels slow starting
with 4 or 8GB heaps, and useless for 32GB+ because collection times goes to
seconds. I think we should be prepared for larger heaps, machines with
128GB+ RAM aren't that rare anymore.


My response would be, for web services (servlet + embedded jetty
specifically)

1. Latency. Used CMS for years, but G1 is both lower overhead and has zero
issues so far with concurrent collection failures unlike CMS, also reduced
amount of -XX:whatever from 15 lines to just target pause time millis and
initiation %.
2. 28GB per java process is standard here (staying below 32 for zero based
compressed OOPS), but might go for more next generation. G1 also increased
density by 20%, I can run a higher concurrent session count on the same
memory size than before - CMS needed a large safety margin (we had
initiating occupancy on 74%, concurrent cycle ends with heap used between
78 and 84%). Our workload is multi threaded - we've can hit 100% load on 16
vCPU with just a single process, but keep it below 50% usually. Load is
bursty - users decide when to hit the site, not us.


For Android Studio (and a bit tuning sensitive: Eclipse / IntelliJ /
PyCharm)

1. Latency! Android Studio especially creates a ton of garbage, going with
G1 fixed all my "input lag" due to heavy background processing. CMS was
Jetbrain's default configuration but failed quite hard on larger projects
(concurrent failure in desktop app = sigh), and throughput GC was
unworkable due to noticeable pauses mostly right after a key press. Auto
completion / analyzing the change happens at key press - generating garbage
- and a program being stuck right when you expect a character to appear on
screen is just horrible user experience.
2. -Xms1G -Xmx3G. G1 does just fine, claiming more memory from the OS when
needed and releasing it if heap is mostly empty. It needs about 30% more
room for objects to die than CMS/ParallelGC in Android Studio's object
allocation pattern, using the same -Xms2G -Xmx2G introduced a lot of
concurrent failures. Peak RAM usage has grown but average (due to better
resizing behavior?) has dropped.

(same thing applies to the other 3 IDE's I've mentioned, but they are a bit
less horrible out of the box and easier to tune for, no massive garbage
storms after key press in Eclipse, just high GC load during builds.)


I guess I'm an exception, using a lot of custom GC flags in my eclipse.ini
/ studio64.exe.vmoptions, but it improved the quality of life enormously; I
knew them anyway from tuning web services days. It would be good if heavier
desktop programs ran great by default instead of "meh" or "laggy".


Kind regards,

-- 
Chi Ho Kwok
Digibites Technology
chkwok at digibites.nl

On 31 July 2015 at 13:51, Geoffrey De Smet <gdesmet at redhat.com> wrote:

> Hi guys,
>
> I've ran some benchmarks on OptaPlanner use cases with the latest OpenJDK 8
> to asses the impact of switching the default to G1:
>
> http://www.optaplanner.org/blog/2015/07/31/WhatIsTheFastestGarbageCollectorInJava8.html
>
> Short summary: G1 is consistently worse in every use case for every
> dataset...
>
> --
>
> With kind regards,
> Geoffrey De Smet
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20150801/7a74752c/attachment.html>