JDK-8177661 : AArch64: Incorrect C2 patterns cause system register corruption
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: aarch64
  • Submitted: 2017-03-27
  • Updated: 2021-02-01
  • Resolved: 2017-03-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 9 Other
10Fixed 9 b163Fixed openjdk8u292Fixed
Related Reports
Relates :  
JDK-8257192 - Integrate AArch64 JIT port into 8u
Description
A rare crash was tracked down to badly-written patterns in aarch64.ad which use iRegX rather than iRegXNoSp as tmp and/or output operands. At times of extreme register pressure, C2 uses system registers such as Rheapbase as scratch. This causes system corruption and crashing.

It is hard to write reproducible test cases for these crashes because it depends on exactly what inlining gets done, and in turn that depends on runtime profile data.
Comments
Fix approved for JDK 9.
27-03-2017
Fix Request Importance: This bug can crash high-performance server apps running on the AArch64 port Nature of Fix: The fix corrects a small number of rules in the AD file for AArch64 to stop the compiler allocating special, VM-dedicated registes as though they were general purpose registers. Risk: Very low -- it only changes the AD rules that re broken and only so as to restrict the opportunities for registers to be allocated. Test Coverage: 1) Basic smoke testing (java Hello, javac Hello.java) 2) The test which originally manifested this problem with a crash passed after incorporating the change for the specific rule found to be causing the bad allocation Otherwise it is very hard to test this more generally (as explained above) Reviewed: Andrew Haley, Vladimir Kozlov Webrev: http://cr.openjdk.java.net/~adinn/8177661/webrev.02
27-03-2017
ILW=crash, rare, no workaround = HLH = P2
27-03-2017