JEP 248: Make G1 the Default Garbage Collector

[Vitaly Davidovich]

Charlie,


> But seriously, would you happen to have bug reports that show any “corrupt
> Lucene indexes” issues that have not been fixed in an 8u* release or fixed
> in JDK 9?  I’m not aware of any. But, I may have missed something too.


The bug report discussed earlier is still in unresolved state; it says 9 as
the fix version, but there's really nothing in the bug report to indicate
the problem has been isolated, nevermind solved.  Is the bug report simply
stale then if you're not aware of any issues?

On Tue, Jun 2, 2015 at 10:18 AM, charlie hunt <charlie.hunt at oracle.com>
wrote:

> HI Kirk,
>
> Thanks for the comments and input, as always!
>
> A couple comments below.
>
> thanks,
>
> charlie
>
> > On Jun 2, 2015, at 4:10 AM, Kirk Pepperdine <kirk.pepperdine at gmail.com>
> wrote:
> >
> >
> >>
> >> 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?
> >
> > Lastest version of 8 running Solr/Lucene.
> >
> >>
> >> Any additional description as to the observations, symptoms, etc on
> that one?
> >
> > Using G1 is known to corrupt Lucene indexes.
>
> Does the term “known” imply past tense?  ;-)  You know I’m just having a
> little fun with you, right?
>
> But seriously, would you happen to have bug reports that show any “corrupt
> Lucene indexes” issues that have not been fixed in an 8u* release or fixed
> in JDK 9?  I’m not aware of any. But, I may have missed something too.
>
> >
> >>
> >> 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.
> >
> > Assuming the understand that they have an issue to address. Yesterday I
> had a long heart to heart with a client that had unrealistic expectations
> as to what problems he could and what problems he could not solve with a
> random “lets tune the garbage collector” thought.
>
> I think that is a failure on their part, not your’s or our’s. I’m not sure
> how not changing the default collector to G1 would impact their unrealistic
> expectations though.
>
> >
> >>
> >> 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.
> >
> > Not the case here.
>
> Don’t expect that there is a one(GC) that fits everyone or every
> application.  I think it is a matter of which GC has the best chance at
> offer the best out of the box default GC, with no additional tuning, offers
> the best opportunity for the best experience for the population of all Java
> apps.  Obviously, as illustrated by this long email thread, it is highly
> subjective.
>
> We all have our biased sampling of Java apps, and those who have worked
> closely with GC know what kind of apps would work well with a given default
> configuration of a GC whether that be Parallel GC, CMS GC or G1 GC.
>
> >
> >>
> >> 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.
> >
> > I’m all for calling in an expert.. In fact, I’m thinking, what a crazy
> idea arguing against making G1 the default. It was just like the decision
> to not have CMS clean perm and for RMI to reset calls to System.gc() once a
> minute and to have the default tenuring threshold be 4.. oh then 6. These
> were all great decisions for improving my business  :-)… Anyways, I think
> the points have been made so rather than spamming this list…..
> >
> > Regards,
> > Kirk
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150602/6fe70df7/attachment.htm>