JEP 248: Make G1 the Default Garbage Collector
charlie.hunt at oracle.com
Mon Jun 1 17:36:33 UTC 2015
> On Jun 1, 2015, at 11:25 AM, 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 is quite a contrast from my experience.
At the end of the day I think JEP is more about the out of the box experience wrt GC. In age where Java heaps are much larger than we saw 5, 10 and 15 years, and there being more of a shift from throughput to latency as area of focus for GC, G1 tends offer a better happy medium between throughput and latency than Parallel GC unless you are lucky enough that the default out of the box heap sizing for Parallel GC allows the app to execute through its lifetime with no Full GC, or they occur at a frequency that can be tolerated, or the Full GC pause time is acceptable.
> 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?
That’s understood … I wouldn’t be expecting anyone to set aside engineering time and do a bunch of testing. I think it is a simple question to ask, i.e. how many of your Java apps do you not set an explicit GC on the JVM command line? Those that do set an explicit GC will not be impacted. So they are not of interest.
> 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.
IMO, such a team / company is going to be their own worst enemy with this kind of strategy / decision making, especially if the Java apps they are running are critical their success.
>> 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?
See my comment above … it’s a simple (survey) question, i.e. How many Java apps do you have that do not set an explicit GC on the JVM command line? It might interesting to also know if these apps also do not care if they have multi-second pause times, i.e. only care about throughput.
More information about the hotspot-dev