JDK-8232046 : AArch64 build failure after JDK-8225681
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2019-10-09
  • Updated: 2024-02-06
  • Resolved: 2019-10-11
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 14
14 b19Fixed
Related Reports
Relates :  
JDK-8225681 - vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due to a) MT-unsafe modification of inline cache
Description
(synopsis is provisional, until the root case is found)

=== Output from failing command(s) repeated here ===
* For target jdk__optimize_image_exec:
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/compiledIC.cpp:760
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/jdk-jdk/src/hotspot/share/code/compiledIC.cpp:760), pid=25666, tid=25671
#  assert(destination == (address)-1 || destination == entry) failed: b) MT-unsafe modification of inline cache
#
# JRE version: OpenJDK Runtime Environment (14.0) (fastdebug build 14-internal+0-adhoc.shade.jdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 14-internal+0-adhoc.shade.jdk-jdk, mixed mode, tiered, compressed oops, serial gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x7c7b04]  CompiledDirectStaticCall::verify_mt_safe(methodHandle const&, unsigned char*, NativeMovConstReg*, NativeJump*)+0x88
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping to /home/shade/jdk-jdk/make/core.25666)
#
   ... (rest of output omitted)

* All command lines available in /home/shade/jdk-jdk/build/linux-aarch64-server-fastdebug/make-support/failure-logs.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/ff8716224f35 User: adinn Date: 2019-10-11 13:05:02 +0000
11-10-2019
There is a further wrinkle here on AArch64. The generated code for a direct static stub call can be either a NativeJump i.e. a bl(address) or a NativeGeneralJump i.e. a wide constant load (movz, movk, movk) followed by a branch to register (br). The bl(imm) form is encoded using b(pc()); i.e. a branch to self. This is detected as a special-case in XXXJump::jump_destination() which reports it to the generic code as offset -1. XXXJump::set_jump_destination(-1) also resets the instruction to a branch to self. The alternative format is encoded using movptr(rscratch1, 0); br(rscratch1) It ought to be possible to switch this to a branch to self by inserting movptr(rscratch1,pc()). However, this does not work as the branch fails to get relocated as a self-branch when the generated code is copied from the scratch generation buffer into the code cache. The problem can be resolved by including 0 as a second special case in XXXJump::jump_destination and also reporting it as -1. It is ok for XXXJump::set_jump_destination(-1) to reset to a branch to self.
10-10-2019
The problem appears to be that the AArch64 implementation of CompiledDirectStaticCall::set_stub_to_clean has never included any call to reset the jump destination to -1. I believe it was written prior to integration into jdk9 when the x86 code also omitted this reset and was not updated after integration to conform to the expectation subsequently instituted on x86 and all the other architectures. This would conform with Eric's observation that the error targeted by the fix to JDK-8225681 arises when there is a race to patch a stub after deopt. If we pass the first assert with an is_old method then aarch64 will not have rest the destination. Note that on aarch64 jump destination value -1 is only symbolic (aka a lie). The value written in the code to indicate an uninitialized jump destination is actually the address storing the target destination. The various Native*Jump methods to set and get the jump destination hide this encoding. Since aarch64 is an AOT target I believe the code in method CompiledDirectStaticCall::set_stub_to_clean should follow x86 in performing this reset to -1 only when the static stub is not an aot stub.
09-10-2019
Actually, I believe the verification code consolidation made AArch64 assert stronger than before. https://hg.openjdk.java.net/jdk/jdk/rev/c16f3a24a6fc#l1.25 <--- second assert checks for "data == 0" This passes the build and tier1 tests: diff -r 5185bc8dcbb1 src/hotspot/share/code/compiledIC.cpp --- a/src/hotspot/share/code/compiledIC.cpp Tue Oct 08 15:30:39 2019 +0200 +++ b/src/hotspot/share/code/compiledIC.cpp Wed Oct 09 05:23:30 2019 -0400 @@ -756,7 +756,7 @@ "a) MT-unsafe modification of inline cache"); address destination = jump->jump_destination(); - assert(destination == (address)-1 || destination == entry, + assert(AARCH64_ONLY(old_method == NULL ||) destination == (address)-1 || destination == entry, "b) MT-unsafe modification of inline cache"); } #endif // !PRODUCT
09-10-2019
Not sure that is a valid special case for AArch64, though, need someone familar with that code to look.
09-10-2019