Reduced performance in Java 9.0.1 (vs 8u152)

[Uwe Schindler]

Hi,

Allocation free does not mean that it is not affected by G1GC. As G1GC is using more parallelity it also needs to add more checks / barriers into the code that also affects stuff that does not do allocations. So in general, by using G1GC I have seen slowdowns of up to 10% for code only does calculations. This is  (by the way) one reason, why Elasticsearch people still recommend to use CMS collector with generally small heap sizes (Elasticsearch - or better said Apache Lucene does most stuff including expensive calculations outside of heap in mmapped files).

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
> bounces at openjdk.java.net] On Behalf Of Martin Traverso
> Sent: Friday, December 22, 2017 11:13 PM
> To: Eric Caspole <eric.caspole at oracle.com>
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: Reduced performance in Java 9.0.1 (vs 8u152)
> 
> Yes, I'm aware of that change. This code is allocation-free, so I wasn't
> expecting that to be a factor. I'll rerun the benchmarks with that and report
> back.
> 
> - Martin
> 
> > On Dec 22, 2017, at 1:20 PM, Eric Caspole <eric.caspole at oracle.com>
> wrote:
> >
> > Hi Martin,
> >
> > As you may know, JEP 248 made G1 the default collector for 9 where it was
> ParallelGC earlier: http://openjdk.java.net/jeps/248
> >
> > I tried your JMH specifying +UseParallelGC by JMH annotations and the
> performance of 9 seems quite even to 8u131 that I have handy.
> >
> > Maybe you could try this for yourself and see how it goes.
> >
> > Regards,
> > Eric
> >
> >> On 12/22/2017 12:59 PM, Martin Traverso wrote:
> >> Hi,
> >>
> >> We're in the process of migrating and qualifying Presto
> (http://prestodb.io) to build and run on Java 9. One of the key dependencies
> is a library of pure-java compression and decompression algorithms
> (http://github.com/airlift/aircompressor).
> >>
> >> In the course of trying to understand the performance characteristics
> when running on Java 9, we discovered a significant drop in performance for
> the compression algorithms (up to 10%) when compared to 8u152.
> >>
> >> Here's a summary of the results and instructions on how to run the
> benchmarks: https://github.com/martint/aircompressor/tree/perf
> >>
> >> These are the outputs of JMH's perfasm profiler:
> >>
> >> Java 8u152: https://github.com/martint/aircompressor/blob/perf/perf-
> 8.txt
> >> Java 9.0.1: https://github.com/martint/aircompressor/blob/perf/perf-
> 9.txt
> >>
> >> The generated assembly looks very different, but as far as I can tell, it's
> just different decisions of when and which registers to spill.
> >>
> >> - Martin
> >