JDK-8261236 : C2: ClhsdbJstackXcompStress test fails when StressGCM is enabled
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 11.0.9,16,17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2021-02-05
  • Updated: 2022-06-15
  • Resolved: 2021-07-28
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 11 JDK 13 JDK 15 JDK 17 JDK 18
11.0.14Fixed 13.0.9Fixed 15.0.5Fixed 17.0.2Fixed 18 b08Fixed
Related Reports
Blocks :  
JDK-8257146 - C2: extend the scope of StressGCM
Relates :  
JDK-8231586 - enlarge encoding space for OopMapValue offsets
Description
Running serviceability/sa/ClhsdbJstackXcompStress.java with -XX:+StressGCM on linux-aarch64 (both release and debug mode) leads to the following assertion failure:

sun.jvm.hotspot.utilities.AssertionFailure: sanity check
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.RegisterMap.setLocation(RegisterMap.java:160)
at jdk.hotspot.agent/sun.jvm.hotspot.compiler.ImmutableOopMapSet.updateRegisterMap(ImmutableOopMapSet.java:303)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.senderForCompiledFrame(AARCH64Frame.java:407)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.sender(AARCH64Frame.java:289)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:207)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:212)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:119)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.sender(CompiledVFrame.java:185)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:143)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:81)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:300)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483)

The failure can be reproduced deterministically on JDK 16 and 17 with the following line:

$ make run-test TEST="serviceability/sa/ClhsdbJstackXcompStress.java" TEST_VM_OPTS="-XX:+UnlockDiagnosticVMOptions -XX:+StressGCM -XX:StressSeed=2"
Comments
RFR(17u) Clean backport to fix SA after JDK-8231586. Tested with hs:tier1
10-09-2021
Thanks, Christoph. jdk11 case is similar to jdk13.
03-09-2021
11u fix request is missing, approving, assuming the information for 13u is vaild as well.
03-09-2021
RFR(13u) Should fix SA and for parity with jdk15. Serviceability stress shows no issue due to difference in test code. But fixed test reveals no assert as well. \ The patch applies almost cleanly, copyright year of ImmutableOopMapSet need to be adjusted. Tested with tier1
02-09-2021
RFR(15u) The changes fixes SA after JDK-8231586. Applies cleanly. Tested with tier1 and by instruction from bug description
01-09-2021
Changeset: 752b6df3 Author: Nick Gasson <ngasson@openjdk.org> Date: 2021-07-28 01:54:33 +0000 URL: https://git.openjdk.java.net/jdk/commit/752b6df34c92c02ac0992566e3efa7bc22b96aa1
28-07-2021
Looks like this was caused by JDK-8231586 which changed the OopMapValue::oop_types encoding from a bit mask to a simple integer enum, but the corresponding change wasn't made in SA which is still treating it as a mask in OopMapStream. The frame where the crash occurs has a derived oop (=3) in the oop map which gets misinterpreted as a callee saved value (=2, so 3&2>0) and chaos ensues.
15-07-2021