JEP 248: Make G1 the Default Garbage Collector

Vitaly Davidovich vitalyd at gmail.com
Mon Jun 1 18:23:50 UTC 2015


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.  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>
wrote:

>
> > On Jun 1, 2015, at 11:18 AM, Kirk Pepperdine <kirk.pepperdine at gmail.com>
> wrote:
> >
> > Hi Charlie,
> >
> >
> > On Jun 1, 2015, at 5:25 PM, charlie hunt <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
> >
>
>


More information about the hotspot-dev mailing list