JEP 248: Make G1 the Default Garbage Collector
yu.zhang at oracle.com
Mon Jun 1 18:28:34 UTC 2015
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
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.
"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.
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
> 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.
More information about the hotspot-dev