JEP 248: Make G1 the Default Garbage Collector

[charlie hunt]

> On Jun 1, 2015, at 12:06 PM, Ben Evans <ben at jclarity.com> wrote:
> 
> Hi Vitaly,
> 
>>> Instead, G1 is now being talked of as a replacement for the default
>>> collector. If that's the case, then I think we need to acknowledge it,
>>> and have a conversation about where G1 is actually supposed to be
>>> used. Are we saying we want a "reasonably high throughput with reduced
>>> STW, but not low pause time" collector? If we are, that's fine, but
>>> that's not where we started.
>> 
>> That's a fair point, and one I'd be interesting in hearing an answer to as
>> well.  FWIW, the only GC I know of that's actually used in low latency
>> systems is Azul's C4, so I'm not even sure Oracle is trying to target the
>> same use cases.  So when we talk about "low latency" GCs, we should probably
>> also be clear on what "low" actually means.
> 
> Well, when I started playing with them, "low latency" meant a
> sub-10-ms transaction time with 100ms STW as acceptable, if not ideal.
> 
> These days, the same sort of system needs a sub 500us transaction
> time, and ideally no GC pause at all. But that leads to Zing, or
> non-JVM solutions, and I think takes us too far into a specialised use
> case.
> 
> Having said that, there is definitely a decent-sized class of systems
> (not just in finance) that cannot really tolerate any more than about
> 10-15ms of STW. So, what usually happens is that they live with the
> young collections, use CMS and tune out the CMFs as best they can (by
> clustering, rolling restart, etc, etc). I don't see any possibility of
> G1 becoming a viable solution for those systems any time soon.

And, in this case what they do today is no different than what they would do with G1 as the default collector. In either case, they are gonna specify -XX:+UseConcMarkSweepGC as the GC to use because it is not the default GC, now or proposed.

So let’s go back to what the JEP is suggesting, (the default GC being changed from Parallel GC to G1 GC), resist the temptation of what the JEP is not suggesting, i.e. a replacement for Parallel GC or CMS GC. When that day comes, (which will very likely be well after JDK 9), there will be distinct JEPs for those changes.

The use case we are talking about is the “out of the box” experience.

One question that may be worth pondering … suppose G1 happened to be the default GC today, and there was a JEP to make Parallel GC the default GC. What would your reaction to that JEP be?  I’m asking that question since I’d like to get a sense if your concerns are more about conservatism (not wanting to change behavior), stability of G1 or otherwise.

thanks,

charlie 

> 
> Thanks,
> 
> Ben