Reduced performance in Java 9.0.1 (vs 8u152)

Kirk Pepperdine kirk at kodewerk.com
Sat Dec 23 10:01:31 UTC 2017


Hi Martin,

I’ve setup benchmarks that saturation the CPU creating a zero sum gain condition. Under these conditions you can get some idea of GC overhead by looking at workload throughput times. Under these conditions I’ve found that no matter how you tune G1, the closest you can get to CMS numbers is about 10%. I believe one of the costs is one that you’d experience and that is RSet refinement queue updating. You maybe able to get a handle on this cost by making Eden large enough that your bench doesn’t experience a GC cycle during the run. My guess is this should minimize (hopefully) eliminate RSet refinement costs which may give you an idea on that cost. It’s something that I've not tired myself so might just be a crazy/ridiculous experiment.

Kind regards,
Kirk

> On Dec 22, 2017, at 11: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
>> 



More information about the hotspot-compiler-dev mailing list