Reduced performance in Java 9.0.1 (vs 8u152)

[Martin Traverso]

I'm not sure I understand why it would need to insert barriers in this
code, though. It's effectively a single method that doesn't access any
state besides a couple of byte[] that are passed in (no shared state, no
object/field references, etc). Other than the safepoint polling on loop
backedges, there should be no "external interference". In the generated
assembly (https://github.com/martint/aircompressor/blob/perf/perf-9.txt),
which instructions correspond to barriers?

In any case, I re-ran the benchmarks using G1 on both Java 8 and 9 and the
results are very similar to what I observed initially. I updated the page
with the outputs of the latest runs, in case you want to take a look:
https://github.com/martint/aircompressor/tree/perf

Thanks,

- Martin






On Fri, Dec 22, 2017 at 7:29 PM Igor Veresov <igor.veresov at oracle.com>
wrote:

> The barriers are substantially more complicated though.
>
> igor
>
> > On Dec 22, 2017, at 2:12 PM, Martin Traverso <mtraverso at gmail.com>
> wrote:
> >
> > 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
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20171223/a3a5d4dd/attachment.html>