Reduced performance in Java 9.0.1 (vs 8u152)

Andrew Haley aph at redhat.com
Tue Jan 2 09:27:25 UTC 2018


On 23/12/17 08:16, Martin Traverso wrote:
> 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?

None of them.  I think the effect you're seeing here might be more to
do with a different unrolling strategy which perhaps leads to more
spilling.  8u152 has a tighter inner loop. It's just one of those
things which happens sometimes with JIT compilers, IMO.  G1 is a red
herring.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


More information about the hotspot-compiler-dev mailing list