RFR: 8273695: Safepoint deadlock on VMOperation_lock

Robbin Ehn rehn at openjdk.java.net
Tue Sep 21 15:47:50 UTC 2021


We should not do any processing in SM::should_process().
The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.

This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
Thus the code querying should release any such Mutex and call process SM::process_if_requested().

The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.

Passes t1-t4 and local stressing.

-------------

Commit messages:
 - Removed string dedup test from problem list
 - Check SWS for processing

Changes: https://git.openjdk.java.net/jdk/pull/5613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5613&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273695
  Stats: 48 lines in 5 files changed: 26 ins; 21 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5613/head:pull/5613

PR: https://git.openjdk.java.net/jdk/pull/5613


More information about the hotspot-runtime-dev mailing list