Reduced performance in Java 9.0.1 (vs 8u152)

Andrew Haley aph at
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 (,
> 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

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the hotspot-compiler-dev mailing list