Reduced performance in Java 9.0.1 (vs 8u152)

[Igor Veresov]

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