G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector]

[Jungwoo Ha]

FYI, most of our users also can not use G1 because of the higher resource
usage.
That means more memory and more CPUs for GC.
We've seen GC CPUs grow by 3x when using G1.
Though, we are able to change between Parallel and CMS without complaints.
Our users use shared machines, so any significant increase in CPU or memory
is not acceptable.
Rather tuning CMS to achieve latency goal is more feasible than using G1.
Also, just using CMS with default settings perform much better than G1.


On Wed, Jul 29, 2015 at 1:04 PM, Andrew Haley <aph at redhat.com> wrote:

> On 07/29/2015 06:55 PM, Doug Lea wrote:
> > On 07/29/2015 12:09 PM, Andrew Haley wrote:
> >> I am concerned that G1 does not perform well with some important
> >> workloads.  In particular, on heavily-loaded systems some
> >> multi-threaded programs which generate a lot of garbage run
> >> significantly more slowly with G1.  I've been measuring the
> >> performance loss and it's about 20-30%, depending on the application.
> >
> > The problem is that there is a full memory fence when issuing
> > cross-region GC write barriers. Most concurrent producer-consumer
> > designs hit this case frequently, and can run almost arbitrarily
> > slower, down to the rate of issuing fences (MFENCE/DMB/etc).
> > I know that Erik Osterlund (and possibly others) are looking into ways
> > of removing this fence. I sure hope they succeed before jdk9 ships!
>
> Indeed.
>
> I'm looking at a 5-6% degradation (measured against the parallel GC)
> in performance over a range of benchmarks on the system I measured.
>
> As I understand it, one of the acceptance criteria of a Java release
> is that it must not have overall worse performance than the previous
> Java release.  As it stands, I don't think that this version of Java
> is going to meet that requirement.
>
> Andrew.
>



-- 
Jungwoo Ha | Java Platform Team | jwha at google.com