JEP 248: Make G1 the Default Garbage Collector

Kirk Pepperdine kirk.pepperdine at
Mon Jun 1 16:18:10 UTC 2015

Hi Charlie,

On Jun 1, 2015, at 5:25 PM, charlie hunt <charlie.hunt at> wrote:

> Hi Ben,
> A couple things to keep in mind.
> 1.)  The impact of this JEP is limited to those Java applications that currently do not set a GC explicitly at the JVM command line. I think this is important to keep in mind as a starting point. A data point you may be able to help with is a survey of applications that do not set a GC explicit as a JVM command line option. I recall only seeing one Java application over the last 15 years that did not set a GC as a JVM command line option, and it was a Java GUI app.

3 of the 5 applications I’m currently tuning did not have the collector set on the command line. Of the 5, G1 should be appropriate for 4 of them bug existing unidentified bugs in G1 knock one off the list.

> 2.)  This JEP’s intent is not to replace the throughput collector (Parallel[Old]GC).  The same applies to CMS GC. Folks who want to use, and do use the throughput collector or CMS GC can still use them.

I’m sorry but as I’ve said before, I don’t find this a compelling argument.

> 3.) One might argue that if a GC is not explicitly specified at the JVM command line, then tuning GC may not be important for that application. In the event an application that does not set a GC explicitly at the command line experiences an observable performance regression, it would be able to restore its performance by setting -XX:+UseParallelOldGC on the JVM command line.

Sorry but I don’t buy this argument either. Most of my customers are not well educated in GC tuning. It’s not that they are bad engineers, it’s just a matter of focus.

> To summarize, this JEP is about what GC to use when none is specified at the JVM command line. Hence its impact is limited to those configurations.
> To me it becomes a question of how many Java applications do not set an explicit GC at the command line, and how many of those want peak throughput performance with little concern of (occasional high) latency?  This is a question I think the community could help us with.

Agreed, the community should help and I’m sure they will/would but only if they know about this issue. As you know, we are both engaged in a lot of educational activities about how the JVM and in particular, GC works. As many as we’ve reached there seems to be 1000sx more that have maybe, maybe a vague idea of how it all works. That, and I still don’t believe we’ve had nearly enough time in the field with a stable version of the collector. I know that everyone in house is excited but I think the prudent thing to do here is hold off until 10. IOWs, out here in the wild, its looking good, very good, but its still not working as well as we hoped it would by now.


More information about the hotspot-dev mailing list