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