JDK-8253778 : ShenandoahSafepoint::is_at_shenandoah_safepoint should not access VMThread state from other threads
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8-shenandoah,11.0.9,15,16
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2020-09-29
  • Updated: 2022-01-05
  • Resolved: 2020-09-30
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 15 JDK 16
11.0.10Fixed 15.0.2Fixed 16 b18Fixed
Related Reports
Relates :  
JDK-8212107 - VMThread issues and cleanup
Relates :  
JDK-8257641 - Shenandoah: Query is_at_shenandoah_safepoint() from control thread should return false
Description
The following tests fail with debug VMs:

compiler/c1/TestLinearScanOrderMain.java
gc/CriticalNativeArgs.java#id1
gc/TestHumongousReferenceObject.java#id2
gc/TestSystemGC.java#id3
gc/class_unloading/TestClassUnloadingDisabled.java#id3
gc/ergonomics/TestDynamicNumberOfGCThreads.java
gc/logging/TestGCId.java
gc/metaspace/TestMetaspacePerfCounters.java#id3
gc/shenandoah/TestSmallHeap.java
gc/shenandoah/compiler/TestC1ArrayCopyNPE.java
gc/shenandoah/compiler/TestC1VectorizedMismatch.java
gc/shenandoah/compiler/TestClone.java#id0
gc/shenandoah/compiler/TestClone.java#id1
gc/shenandoah/compiler/TestClone.java#id2
gc/shenandoah/compiler/TestClone.java#id3
gc/shenandoah/compiler/TestClone.java#id4
gc/shenandoah/compiler/TestClone.java#id5
gc/shenandoah/compiler/TestReferenceCAS.java#id0
gc/shenandoah/compiler/TestReferenceCAS.java#id1
gc/shenandoah/mxbeans/TestChurnNotifications.java#id0
gc/shenandoah/mxbeans/TestChurnNotifications.java#id1
gc/shenandoah/mxbeans/TestChurnNotifications.java#id2
gc/shenandoah/mxbeans/TestChurnNotifications.java#id3
gc/shenandoah/mxbeans/TestChurnNotifications.java#id4
gc/shenandoah/mxbeans/TestChurnNotifications.java#id5
gc/shenandoah/mxbeans/TestPauseNotifications.java#id0
gc/shenandoah/mxbeans/TestPauseNotifications.java#id1
gc/shenandoah/mxbeans/TestPauseNotifications.java#id2
gc/shenandoah/mxbeans/TestPauseNotifications.java#id3
gc/shenandoah/mxbeans/TestPauseNotifications.java#id4
gc/shenandoah/mxbeans/TestPauseNotifications.java#id5
gc/shenandoah/oom/TestAllocLargeObj.java
gc/shenandoah/oom/TestAllocLargerThanHeap.java
gc/shenandoah/oom/TestAllocSmallObj.java
gc/shenandoah/oom/TestClassLoaderLeak.java
gc/shenandoah/oom/TestThreadFailure.java
gc/shenandoah/options/TestArgumentRanges.java
gc/shenandoah/options/TestExplicitGC.java
gc/shenandoah/options/TestHeuristicsUnlock.java
gc/shenandoah/options/TestHumongousMoves.java
gc/shenandoah/options/TestPacing.java
gc/shenandoah/options/TestParallelRegionStride.java
gc/shenandoah/options/TestSingleThreaded.java
gc/shenandoah/options/TestSoftMaxHeapSize.java
gc/stress/CriticalNativeStress.java#id1
java/lang/invoke/RicochetTest.java


# A fatal error has been detected by the Java Runtime Environment: 
#
#  Internal Error (/jdk/src/hotspot/share/runtime/vmThread.hpp:103), pid=2517, tid=2564
#  assert(Thread::current()->is_VM_thread()) failed: Must be
#
# JRE version: OpenJDK Runtime Environment (16.0) (fastdebug build 16-internal+0-adhoc..jdk)
Comments
Fix Request (15u) Same reason as for 11u.
12-10-2020
Fix Request (11u) Fixes the data race (caught by asserts in later JDKs), and keeps Shenandoah codebase in sync. Patch applies cleanly to 11u, passes hotspot_gc_shenandoah, tier{1,2} with Shenandoah.
06-10-2020
Changeset: 8331e63f Author: Aleksey Shipilev <shade@openjdk.org> Date: 2020-09-30 08:58:24 +0000 URL: https://git.openjdk.java.net/jdk/commit/8331e63f
30-09-2020
Fix is in review.
30-09-2020
Yeah, that's Shenandoah assert asking the VMThread state racily. Good that new assert caught this. Should be fixed on Shenandoah side, reassigning to me.
30-09-2020
In the case when a concurrent GC thread ask this question and it is not a shenandoah safepoint. This piece of code doesn't look safe: // check if Shenandoah GC safepoint is in progress static inline bool is_at_shenandoah_safepoint() { if (!SafepointSynchronize::is_at_safepoint()) return false; VM_Operation* vm_op = VMThread::vm_operation(); if (vm_op == NULL) return false; VM_Operation::VMOp_Type type = vm_op->type(); The concurrent gc thread cannot stop the safepoint to end and the memory of the vm operation might be rubbish or the thread which had it on it's stack can be terminated. So the assert is correctly saying this is not safe. In the other case where a GC worker is asking it inside a safepoint, we already know it's shenandoah safepoint because why would the gc worker otherwise be running shenandoah code? So I don't see the assert as wrong. Please advise!
30-09-2020
Hey [~shade] since you are aware of the added assert in 8212107. What's your take on this?
30-09-2020
ILW = HLM = P3
29-09-2020