JEP 248: Make G1 the Default Garbage Collector

[charlie hunt]

> On Jun 1, 2015, at 12:27 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Interesting. I didn't see any events of that type - and I only saw a
> couple of the type I alluded to.
>  
> 
> Got some links? I'd like to read up on this.
> 
> I don't have any concrete links, unfortunately, and google won't show all that much (you should see a few items though).  This is based on my (recent) experience and some conversations with people that I've had.  Some themes there were:
> 
> 1) Extra/longer profiling inadvertently causes more noise in the profile, and less optimal code is generated.
> 2) Pressure on nmethod sweeper; if your app doesn't induce sufficient # of safepoints on its own, it can fall behind.
> 3) Some setups required bumping ReservedCodeCacheSize since default (even the bumped default with tiered enabled) didn't suffice
> 4) Extra VM threads were created (C2 and C1 compiler threads), which caused jitter in places where # of cores available to the JVM is precisely tuned.
> 5) java 8 keeps all compiled code, across all tiers, in a homogeneous code buffer; there can be i-cache and instruction TLB pressure.  I believe java 9 will have the segmented code cache, which aims at addressing this problem.  Nobody directly attributed it to this, but it's a known data point in java 8.
> 6) Unknown/unattributed perf anomalies (i.e. tiered was tried, and there was nothing obviously wrong, but peak perf was worse).
> 
> Perhaps Charlie & co have more diverse field feedback on this, but this is now straying off-topic, I suspect.  I was simply highlighting that tiered compilation was actually quite a substantial change to a core and complex VM facility, and even though there were anomalies, it didn’t hurt adoption AFAIK (like with GC, turning off tiered is dead simple -- assuming of course one is willing to experiment and assess their regressions :)).

Yes, I have seen cases where tiered caused issues. But, it also helped a lot cases too.  And, you’ve pretty much summarized the issues.

I think there are some parallels here to the JEP at hand too.  I agree with Vitaly.  IMO, making tiered compilation the default was more risky than what I see with making G1 the default GC. I also think that not many folks paid attention because there is not as much known about the compiler as there is for instance about GC, and there is not as much instrumentation produced by the JVM that tells you if it is the compiler that has caused your application to slow down versus GC that needs tuning. And, the information (currently) produced by the compiler is much harder to read for most (expert) folks too.

charlie

> 
> 
> 
> 
> On Mon, Jun 1, 2015 at 1:08 PM, Ben Evans <ben at jclarity.com <mailto:ben at jclarity.com>> wrote:
> >> But TieredCompilation is also much less likely to be the kind of issue
> >> that gets noticed. Slightly slower performance during startup is
> >> "Meh", longer pause times or visibly decreased throughput is the kind
> >> of thing that ops teams pay attention to.
> >
> > No, it's the opposite problem - startup tended to improve, but peak perf
> > suffered noticeable regressions, which is exactly the throughput degradation
> > one would notice.
> 
> Interesting. I didn't see any events of that type - and I only saw a
> couple of the type I alluded to.
> 
> Got some links? I'd like to read up on this.
> 
> Thanks,
> 
> Ben
>