[15] RFR(S): 8248845: AArch64: stack corruption after spilling vector register

[Nick Gasson]

Hi,

Bug: https://bugs.openjdk.java.net/browse/JDK-8248845
Webrev: http://cr.openjdk.java.net/~ngasson/8248845/webrev.0/

This crash was seen on the Panama vectorIntrinsics branch and a minimal
test case is attached to the JBS entry, but it should also affect
vanilla jdk/jdk although I haven't found a reliable way to reproduce it.

  0x0000ffffa173fd40:   ldr	x11, [sp, #120]
  0x0000ffffa173fd44:   ldr	x10, [sp, #48]
  0x0000ffffa173fd48:   add	x10, x10, x11
  0x0000ffffa173fd4c:   str	q16, [x10, #16]    ; <==== CRASH HERE

X10 loaded from sp+48 contains a valid pointer but X11 from sp+120
contains a garbage value. Here's the relevant opto assembly that spills
to sp+120:

  6b4 +   spill [sp, #80] -> [sp, #16]	# vector spill size = 128
  6bc +   spill [sp, #24] -> [sp, #120]	# spill size = 64

These two instructions have been scheduled in the wrong order: 6b4
writes 16 bytes at sp+16 which overwrites another live value at sp+24.
Instruction 6bc spills the clobbered value at sp+24 to sp+120. If I dump
out the instructions before scheduling or pass -XX:-OptoScheduling the
order is correct.

It seems to be a known limitation that the scheduler doesn't correctly
compute anti-dependencies when a vector occupies more than two slots,
because PhaseOutput::ScheduleAndBundle() already has a check to skip
scheduling if a too-wide vector was generated. Unfortunately the check
is wrong as a pair of slots is 8 bytes not 16:

  // Scheduling code works only with pairs (16 bytes) maximum.
  if (C->max_vector_size() > 16)

Actually the test here used to be > 8, but was changed as part of
JDK-8076276 which added AVX512 support [1]. I couldn't see any
explanation of that change in the bug or mailing list thread, but it
seems wrong and reverting it fixes this crash.

This affects AArch64 because OptoScheduling is enabled by default and
NEON vectors are 16 bytes wide.

Tested hotspot_all_no_apps, jdk_core on AArch64 and x86_64.

[1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017579.html

--
Thanks,
Nick