RFR: 8224671: AArch64: mauve System.arraycopy test failure
Andrew Haley
aph at redhat.com
Thu May 23 12:18:10 UTC 2019
Well, this one was a doozy.
Mauve is an old Java test suite, from many years ago. Thankfully
though, AdoptOpenJDK still run it, and we received a surprising report
about a test failure in System.arraycopy().
It turns out that in C1-compiled code an ArrayStoreException is
wrongly thrown as an ArrayIndexOutOfBoundsException. After a lot of
debugging, the bug turned out to be the calculation of ~x, a bitwise
inversion:
__ eonw(rscratch1, r0, 0);
This looks reasonable enough: EOR r0 with ~0. But it's wrong: the EONW
instruction has no immediate form. So how are we not getting an
assembly-time error? This turns out to be a misfeature of C++ combined
with the nasty way we declare registers in HotSpot.
When C++ processes the overloads for eonw() it looks first for an
exact match of the immediate operand then applies the default integer
conversions. One of these silently (!) converts 0 to a NULL
pointer. Unfortunately (very unfortunately) the register declaration
for r0 is a NULL pointer, so
__ eonw(rscratch1, r0, 0);
generates
eonw x8, r0, r0
which always sets r0 to -1, which causes the ArrayIndexOutOfBoundsException.
The fix is to use ZR instead of r0.
In order to make sure that this never happens again I've provided a
declaration for the immediate form of these instructions. It will
generate a compile-time error if this mistake ever happens again.
http://cr.openjdk.java.net/~aph/8224671/jdk-test.changeset
We'll need backports for all releases.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-compiler-dev
mailing list