JDK-8195859 : AArch64: vtableStubs gtest fails after 8174962
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9.0.4,10
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: aarch64
  • Submitted: 2018-01-22
  • Updated: 2021-02-01
  • Resolved: 2018-01-26
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 11 JDK 9 Other
10 b42Fixed 11Fixed 9.0.4Fixed openjdk8u292Fixed
Related Reports
Relates :  
JDK-8195685 - AArch64 cannot build with JDK-8174962
Relates :  
JDK-8257192 - Integrate AArch64 JIT port into 8u
Relates :  
JDK-8196221 - AArch64: Mistake in committed patch for JDK-8195859
Description
gtest vtableStubs introduced by 8174962 fails on AArch64 with an invalid insn encoding
Comments
Thanks Valdimir -- will push to jdk10 and dev jdk
26-01-2018
Fix request approved for JDK 10 by group lead. Aarch64 only changes.
25-01-2018
Fix Request: Why? This bug can potentially crash an AArch64 JVM when a method has a suitably large enough i/vtable. What? The fix corrects address generation so that it copes with offsets that overflow teh available immediate offset range. Risk? The risk is low because this only changes code generated for i/vtable lookups and only makes a difference in the case where when i/vtables have large indices (a case whihc is already broken). This circumstance has not actually been known to affect production code but it is a potential source of error. Reviewers? It has been reviewed by Andrew Haley. webrev (for jdk10 and jdkdev) is here: http://cr.openjdk.java.net/~adinn/8195859/webrev.02
25-01-2018
The problem is that lookup_virtual_method assumes that a constant vtable index will always be safe to use as a 9-bit immediate operand. The call to ldr needs to test the value and, if it is too large, load it as an immediate into a scratch register then use a load via an indirect register.
22-01-2018