JEP 248: Make G1 the Default Garbage Collector

[Vitaly Davidovich]

I'm sorry - if I'm upgrading to a new major release of anything, I'm
looking at release notes and doing some sanity testing/checking.  For the
JVM, if default GC is listed as being changed and if my app actually cares
about GC performance, I'm going to check the behavior performance.  For
folks who are oblivious to what GC they're running yet would have a serious
failure due to some performance loss, well, I don't know what to say other
than it's irresponsible.  And if one doesn't want to even be bothered, go
lock in the parallel GC today explicitly and not fret over this.

The real concern brought up in this thread is the miscompilation causing
corruption in lucene.

sent from my phone
On Jun 2, 2015 4:54 AM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:

> Hi Vitaly,
> >
> > 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.
>
> JVM default settings are but one detail in 100s that need to be considered
> when deploying an application.
>
> >
> > 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.
>
> The move to tiered *did* cause pain. IMHO, tiered is not mature enough to
> have made it the default. That is my opinion of the G1 also. I say this in
> the context that this is a technology that being used in mission critical
> applications implying, you don’t really want to accidentally create a grand
> experiment here. That said, I can only share with you my experience and my
> opinion based on that experience. If your opinion is different, so be it.
>
> Regards,
> Kirk
>
> >
> >
> >
> > On Mon, Jun 1, 2015 at 12:25 PM, Ben Evans <ben at jclarity.com> wrote:
> >
> >> Hi Charlie,
> >>
> >> On Mon, Jun 1, 2015 at 4:25 PM, charlie hunt <charlie.hunt at oracle.com>
> >> wrote:
> >>>
> >>> 1.)  The impact of this JEP is limited to those Java applications that
> >> currently do not set a GC explicitly at the JVM command line. I think
> this
> >> is important to keep in mind as a starting point. A data point you may
> be
> >> able to help with is a survey of applications that do not set a GC
> explicit
> >> as a JVM command line option. I recall only seeing one Java application
> >> over the last 15 years that did not set a GC as a JVM command line
> option,
> >> and it was a Java GUI app.
> >>
> >> OK - that is substantially at variance with my experience. Whilst the
> >> majority of applications that I'm asked to take a look at directly do
> >> set a GC explicitly, that is a self-selected sample, as Kirk says - it
> >> is precisely the people that are aware of GC that are least likely to
> >> have issues with this change, because they have already thought about
> >> it, and called us.
> >>
> >> However, if I look at the reactions & questions after talks I get, a
> >> very different picture emerges. My gut feel is that the majority of
> >> applications run with a default algorithm.
> >>
> >> That's just my gut feel, though. I don't think we have to go by that
> >> alone. If we look at the JCP members, we have a number of large
> >> coroporates with diverse use cases. Can we not just approach them &
> >> see if they'd commit a small amount of engineering time to survey
> >> their apps & give us some reporting numbers?
> >>
> >> I can think of at least 2-3 corporates who might well be prepared to
> >> help - if it wasn't too onerous, and we could be specific about what
> >> we would like them to report on.
> >>
> >>> 3.) One might argue that if a GC is not explicitly specified at the JVM
> >> command line, then tuning GC may not be important for that application.
> In
> >> the event an application that does not set a GC explicitly at the
> command
> >> line experiences an observable performance regression, it would be able
> to
> >> restore its performance by setting -XX:+UseParallelOldGC on the JVM
> command
> >> line.
> >>
> >> 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.
> >>
> >>> To summarize, this JEP is about what GC to use when none is specified
> at
> >> the JVM command line. Hence its impact is limited to those
> configurations.
> >>>
> >>> To me it becomes a question of how many Java applications do not set an
> >> explicit GC at the command line, and how many of those want peak
> throughput
> >> performance with little concern of (occasional high) latency?  This is a
> >> question I think the community could help us with.
> >>
> >> OK - so if we were able to identify a large pool of users, what
> >> exactly would we want to ask them? And what sort of sample sizes
> >> (other than the larger the better :) ) would we like?
> >>
> >> Thanks,
> >>
> >> Ben
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150602/6ce05640/attachment.htm>