JEP 248: Make G1 the Default Garbage Collector

[charlie hunt]

I would have to defer to the compiler team to offer additional information above what is in the bug report. I see in the bug report that it is currently targeted to be fixed in JDK 9. 

Sorry, but that’s about all I know for details.

charlie

> On Jun 1, 2015, at 1:23 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Charlie,
> 
> While we have your attention :), what is the status of the issues the Lucene guys highlighted earlier in this thread? In particular, this bug: https://bugs.openjdk.java.net/browse/JDK-8038348 <https://bugs.openjdk.java.net/browse/JDK-8038348>.  If there are known miscompilations, I'd say those are showstoppers for this JEP, no?
> 
> Thanks
> 
> On Mon, Jun 1, 2015 at 2:10 PM, charlie hunt <charlie.hunt at oracle.com <mailto:charlie.hunt at oracle.com>> wrote:
> 
> > On Jun 1, 2015, at 11:18 AM, Kirk Pepperdine <kirk.pepperdine at gmail.com <mailto:kirk.pepperdine at gmail.com>> wrote:
> >
> > Hi Charlie,
> >
> >
> > On Jun 1, 2015, at 5:25 PM, charlie hunt <charlie.hunt at oracle.com <mailto:charlie.hunt at oracle.com>> 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.
> 
> At the risk of getting off topic a bit, what is the version of the JDK where you are seeing the one that has an unidentified bug in G1?
> 
> Any additional description as to the observations, symptoms, etc on that one?
> 
> >
> >>
> >> 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.
> 
> That’s ok, we can agree to disagree. :-)
> 
> And, just to clarify, the potential impact for this JEP is that population of Java apps that do not set an explicit GC on the command line, and whether those application may see a better out of the box experience in terms of throughput, latency and footprint with G1 than with Parallel GC.
> 
> >
> >>
> >> 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.
> 
> I understand that it is a matter of focus. However, if those folks are not calling in an expert to tune GC, then they probably feel that the issue not that important for them address.
> 
> At the same time, consider there may likely be cases where if G1 was the default collector, the need for calling in an expert to tune GC beyond G1’s defaults setting may not be needed. In other words, they would have a better out of the box experience with G1 than with Parallel GC.
> 
> >
> >>
> >> 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.
> 
> For this JEP, I don’t think folks have to know how GC works to deal with the change in default collectors. For that population of apps that don’t set an explicit GC, they need to know that if they see a performance regression between a previous JDK to JDK 9, one of the things they should look at is setting / using Parallel GC, which would be in the release notes, or should they call in an expert, it would be one of the first changes suggested.
> 
> thanks,
> 
> charlie
> 
> >
> > Regards,
> > Kirk
> >
> 
>