JEP 248: Make G1 the Default Garbage Collector

[Vitaly Davidovich]

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




On Mon, Jun 1, 2015 at 1:08 PM, Ben Evans <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
>