JEP 248: Make G1 the Default Garbage Collector

[Vitaly Davidovich]

>
> Yes, I would expect the majority of teams to act that way. I am still
> finding a fair number of teams on JDK 6. If that's not irresponsible
> engineering, I don't know what is - running your production apps on a
> totally unsupported platform that has a number of ways in which it
> cannot be fixed if it breaks.



>
> Yet, a surprisingly large number of people do exactly that. We may not
> like it, but it's what happens, and by forcing a potentially breaking
> change onto those sort of teams, all we do is hurt the platform's
> reputation.


At the risk of sounding politically incorrect, I'd say such shops are on
their own and their accommodation in decisions like this should be heavily
discounted.  It's just irresponsible to do otherwise for the health and
longevity of the platform.

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.

On Mon, Jun 1, 2015 at 12:56 PM, Ben Evans <ben at jclarity.com> wrote:

> Hi Vitaly,
>
> On Mon, Jun 1, 2015 at 5:36 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> >
> >> I would worry that faced with such a regression, the team would simply
> >> not upgrade to 9. Not everyone is a GC expert or has the experience
> >> (or time) to dig into why a regression is happening, and they may
> >> simply decide "9 is not for us" - which would be a real shame &
> >> detrimental to the platform.
> >
> > This is simply irresponsible engineering if that were to happen.  You're
> > saying someone can't even be bothered to look at release notes and notice
> > that the GC changed? They would get a regression on a major java release
> and
> > do *zero* investigation? With all due respect, I find such an argument
> > ridiculous.
>
> Yes, I would expect the majority of teams to act that way. I am still
> finding a fair number of teams on JDK 6. If that's not irresponsible
> engineering, I don't know what is - running your production apps on a
> totally unsupported platform that has a number of ways in which it
> cannot be fixed if it breaks.
>
> Yet, a surprisingly large number of people do exactly that. We may not
> like it, but it's what happens, and by forcing a potentially breaking
> change onto those sort of teams, all we do is hurt the platform's
> reputation.
>
> > Don't mean to harp on tiered compilation, but did that prevent java 8
> > adoption? Did it cause massive pain? And this is an area (JIT) much more
> > opaque to troubleshoot (short of microbenches) than GC.
>
> 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.
>
> Ben
>