JEP 248: Make G1 the Default Garbage Collector

[Kirk Pepperdine]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150602/22d0f5d2/signature.asc>