JEP 248: Make G1 the Default Garbage Collector

charlie hunt charlie.hunt at oracle.com
Tue Jun 2 14:46:30 UTC 2015


> On Jun 2, 2015, at 9:26 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> 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?

I just saw the comments from David Weiss, which I think this is the bug you are referring too, where he mentioned that there is a strong suspicion the issue is related to G1 and goes on to say that it is a difficult issue to reproduce and possibly could be an interaction between several other things. I’m paraphrasing of course.

This bug reminds of a case I recall seeing in CMS where there was a heap corruption issue that eventually got isolated as an OS driver bug. Took months to isolate. The driver, at what seemed to be random times, decided to write a value into the Java heap and corrupted an oop. I don’t recall the exact details, but I seem to recall it was writing to an address as a 64 bit value instead of a 32-bit value.

Do I think the bug report is stale?  No I don’t think so.  I’m not involved on a regular basis. I’m hypothesizing there is no new information. Someone who’s closer to the situation can possibly offer comments.

thanks,

charlie

> 
> On Tue, Jun 2, 2015 at 10:18 AM, charlie hunt <charlie.hunt at oracle.com <mailto: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 <mailto: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: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20150602/213efbf6/attachment-0001.html>


More information about the hotspot-gc-dev mailing list