JEP 248: Make G1 the Default Garbage Collector

[Vitaly Davidovich]

My $.02 on the issue ...

Undoubtedly, making G1 the default collector will uncover some cases that
aren't handled well by it ... but that's a good thing! First, it's
impossible for Oracle to test G1 across the same variety of workloads that
exist in the wild.  Asking developers to move to G1 voluntarily is good,
but there will be a large audience that will not be reached.  Second, as
noted, Java 9 migration is already going to require folks to test against
it, and if they're performance sensitive, then presumably there will be
performance tests done prior to production deployment.  If they find
regressions, there's an easy flag to enable old behavior, and they can move
on if they're not interested in digging deeper.  Luckily, GC
introspection/monitoring is pretty good, so performance anomalies of
consequence should be fairly easily spotted (not necessarily the root cause
though!).  This is different from, say, tiered compilation which is a bit
more difficult to introspect/monitor/analyze/etc.

I think for the greater good of G1, this should be done.  If Java 9 is
released without it being default, yes, Oracle will have a couple more
years of lab time + sporadic field feedback to tune/change things further,
but the same unforeseen issues are almost as likely to creep up in Java 10
if it's made default then -- this is just kicking the can down the road,
and I don't see the point.

On Thu, Apr 30, 2015 at 10:11 AM, Kirk Pepperdine <kirk.pepperdine at gmail.com
> wrote:

> Hi Charlie,
>
>
> > Fwiw, we should not forget that anyone who is currently specifying an
> explicit GC to use in his or her JVM command line args will not experience
> any difference in behavior.
>
> True… I would say that this group would mostly include those that use CMS.
> Those are the people I’m finding that I’m helping move along.
>
>
> > They will still get the collector they specify to use. The (potential)
> impact will be on those who do not specify a GC to use.
> >
> > What I would like to hear from Kirk and others who frequently work with
> customers on GC, what’s the percentage of Java applications they have
> worked with that do not explicitly specify a GC?
>
> Good question. I think that most of the people I work with stumble into
> the GC problem and then after mucking about for a bit call me. So it’s not
> a very good data sample.
>
> >  And, of those, what percentage of those apps fall into the categories
> of small heap and desire low latency, or desire high throughput even at the
> cost of frequent full GCs?
>
> Difficult to say. No one I know wants a GC pause. That said, the majority
> of people I deal with are those where the pause is interfering with some
> aspect of their business so again, a very biased sample.
>
> I appreciate the bandaid analogy and what I can say is that I certainly
> wouldn’t want anyone ripping off the bandaid on my mission critical
> application. Don’t forget 9 is going to give them a good rap across the
> knuckles as it is. I have spoken about the changes that will come with Java
> 9 at JavaLand, JAX-Mainz, JAX-Finance, and Istanbul Tech-talks. I’ll give a
> rough estimate of most than 1500 developers and I would say that the vast
> majority were clearly unaware of the planned changes in 9, unaware that
> they could start testing against 9 today, unaware of tiered compilation and
> unaware that it’s the default setting in 8. Say what you like but that
> seems to the norm AFAICT.
>
> My final note on this subject is; I don’t think we need to be reminded
> that this is a widely used platform. That said, my position isn’t based in
> resistance to the G1, it based on the need for decisions to be
> conservative. Should the G1 be the default collector? I still think it’s a
> bit early to answer that question but I’m sure by 10 if things process as
> they have it won’t be.
>
> Regards,
> Kirk
>
> >
> > thanks,
> >
> > charlie
> >
> >> On Apr 30, 2015, at 7:27 AM, Mattis Castegren <
> mattis.castegren at oracle.com> wrote:
> >>
> >> Hi.
> >>
> >> I also work with customers but I would like to give an argument FOR
> changing the default.
> >>
> >> I don't think we will ever come to a point where G1 is better for ALL
> users. Even with a near perfect G1 implementation there may be cases where
> the parallel collector gives better throughput.
> >>
> >> Right now, I think G1 will be better for most users. There are probably
> also corner cases where G1 COULD be better, but where small issues reduces
> performance. By changing the default to G1, we will be able to easier find
> these as we will expose more users to G1.
> >>
> >> Finally, there will be a set of users who only care about throughput,
> and who will see a performance regression. In those cases, they can go back
> to using parallel. But hopefully, there will be far fewer users who need to
> tune their application to run with parallel GC than there are users who
> have to (or should) tune their application to run with G1.
> >>
> >> In the case of huge, business critical, applications, we will always
> introduce a risk by changing default collectors. This is true if we change
> to G1 in JDK 9, 10 or 11. I prefer to just rip the band aid off. We know
> that the collector we will focus on going forward is G1, so we should let
> as many people use it as possible.
> >>
> >> Of course we should document this a lot, so that users who go up to JDK
> 9 and see performance regressions can at least try to run with Parallel to
> see if it is due to the GC.
> >>
> >> Kind Regards
> >> /Mattis
> >>
> >> -----Original Message-----
> >> From: Kirk Pepperdine [mailto:kirk at kodewerk.com]
> >> Sent: den 30 april 2015 13:18
> >> To: Stefan Johansson
> >> Cc: hotspot-dev at openjdk.java.net Source Developers
> >> Subject: Re: JEP 248: Make G1 the Default Garbage Collector
> >>
> >> Hi Stefan,
> >>
> >> Indeed, the improvements have been amazing. I have been getting many
> clients to bench with it and although the results have been mixed, overall
> many have been able to move forward. However I still would not recommend G1
> to anyone who can't move to 1.8.0_40. Of course this change will obviously
> come post _40 but still, the recent emergence of the G1 as a viable
> production ready collector suggests that making it a default maybe a wee
> bit optimistic.
> >>
> >> The change is based on the assumption that limiting latency is often
> more important than maximizing throughput. If this assumption is incorrect
> then this change might need to be reconsidered.
> >>
> >> I would agree with this assumption. In most cases latency is more
> important. However G1 doesn't always provide lowest latency especially in
> smaller heaps.
> >>
> >>
> >> G1 is seen as a robust and well-tested collector. It is not expected to
> have stability problems, but becoming the default collector will increase
> its visibility and may reveal previously-unknown issues.
> >> I not sure it's prudent to treat the entire Java eco-system as guinea
> pigs. I believe it's more prudent to have the willing take that first step
> rather than have it unwittingly dropped on everyone
> >>
> >>
> >>
> >> At the end of the day, I don't have any say in any of this (as it
> should be). All I can do is let you know what I'm seeing through my straw
> with the hope that you'll find the information useful. From what I see,
> there is not nearly enough experience in the tuning the G1 in that is
> especially true in the general population to make this type of change at
> this point in time. I'm also not sure that we have all the tuning options
> we need to ensure "happy apps" in the wild. For example, I think the
> incremental accumulated waste in tenured regions is a problem that I'm not
> sure we have the tools to solve. I'm not even sure if it's a recognized
> problem. In fact I'm not even sure it's a real problem as at the moment
> it's only a theory based on observations I'm making by looking at numbers
> of GC logs produced by applications using recent releases of the G1.
> >>
> >> I would suggest that for Tiered the default config for 8 is was also a
> bit premature. I've had to have a number of clients have to roll back off
> of it.
> >>
> >> - Kirk
> >>
> >> On Apr 29, 2015, at 3:03 PM, Stefan Johansson <
> stefan.johansson at oracle.com> wrote:
> >>
> >>> Hi Kirk,
> >>>
> >>> A lot of effort is put into G1, it has been continuously improving
> over the last couple of years and we now believe that G1 is ready to become
> the default. G1 will not improve all use case, but the same is true for the
> other collectors. For users where throughput is the main concern, Parallel
> GC can still be used by specifying -XX:+UseParallelGC on the command-line.
> >>>
> >>> Regards,
> >>> Stefan
> >>>
> >>> On 2015-04-29 09:10, Kirk Pepperdine wrote:
> >>>> Hi all,
> >>>>
> >>>> Is the G1 ready for this? I see many people moving to G1 but also I'm
> not sure that we've got the tunable correct. I've been sorting through a
> number of recent tuning engagements and my  conclusion is that I would like
> the collector to be aggressive about collecting tenured regions at the
> beginning of a JVM's life time but then become less aggressive over time.
> The reason is the residual waste that I see left behind because certain
> regions never hit the threshold needed to be included in the CSET. But, on
> aggregate, the number of regions in this state does start to retain a
> significant about of dead data. The only way to see the effects is to run
> regular Full GCs.. which of course you don't really want to do. However,
> the problem seems to settle down a wee bit over time which is why I was
> thinking that being aggressive about what is collected in the early stages
> of a JVMs life should lead to better packing and hence less waste.
> >>>>
> >>>> Note, I don't really care about the memory waste, only it's effect on
> cycle frequencies and pause times.
> >>>>
> >>>> Sorry but I don't have anything formal about this as I (and I believe
> many others) are still sorting out what to make of the G1 in prod.
> Generally the overall results are good but sometimes it's not that way up
> front and how to improve things is sometimes challenging.
> >>>>
> >>>> On a side note, the move to Tiered in 8 has also caused a bit of
> grief. Metaspace has caused a bit of grief and even parallelStream, which
> works, has come with some interesting side effect. Everyone has been so
> enamored with Lambdas (rightfully so) that the other stuff has been
> completely forgotten and some of it has surprised people. I guess I'll be
> submitting a talk for J1 on some of the field experience I've had with the
> other stuff.
> >>>>
> >>>> Regards,
> >>>> Kirk
> >>>>
> >>>>
> >>>> On Apr 28, 2015, at 11:02 PM, mark.reinhold at oracle.com wrote:
> >>>>
> >>>>> New JEP Candidate: http://openjdk.java.net/jeps/248
> >>>>>
> >>>>> - Mark
> >>>
> >>>
> >>
> >
>
>