JEP 248: Make G1 the Default Garbage Collector

[Yu Zhang]

Hi,

I have done some performance comparison g1/cms/parallelgc internally at 
Oracle.  I would like to post my observations here to get some feedback, 
as I have limited benchmarks and hardware.  These are out of box 
performance.

Memory footprint/startup:
g1 has bigger memory footprint and longer start up time. The overhead 
comes from more gc threads, and internal data structures to keep track 
of remember set.

g1 vs parallelgc:
If the workload involves young gc only, g1 could be slightly slower. 
Also g1 can consume more cpu, which might slow down the benchmark if SUT 
is cpu saturated.

If there are promotions from young to old gen and leads to full gc with 
parallelgc, for smaller heap, parallel full gc can finish within some 
range of pause time, still out performs g1.  But for bigger heap, g1 
mixed gc can clean the heap with pause times a fraction of parallel full 
gc time, so improve both throughput and response time.  Extreme cases 
are big data workloads(for example ycsb) with 100g heap.

g1 vs cms:
I will focus on response time type of workloads.
Ben mentioned

"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."

Can you give more details, like what is the live data set size, how big 
is the heap, etc?  I did some cache tests (Oracle coherence) to compare 
cms vs g1. g1 is better than cms when there are fragmentations. If you 
tune cms well to have little fragmentation, then g1 is behind cms.  But 
for those cases, they have to tune CMS very well, changing default to g1 
won't impact them.

For big data kind of workloads (ycsb, spark in memory computing), g1 is 
much better than cms.

Thanks,
Jenny

On 6/1/2015 10:06 AM, Ben Evans 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.
>
> Thanks,
>
> Ben