Integrated: 8273695: Safepoint deadlock on VMOperation_lock

Robbin Ehn rehn at
Mon Oct 4 06:52:11 UTC 2021

On Tue, 21 Sep 2021 13:17:43 GMT, Robbin Ehn <rehn at> wrote:

> 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.

This pull request has now been integrated.

Changeset: 79579942
Author:    Robbin Ehn <rehn at>
Stats:     51 lines in 5 files changed: 29 ins; 21 del; 1 mod

8273695: Safepoint deadlock on VMOperation_lock

Reviewed-by: dcubed, pchilanomate, eosterlund



More information about the hotspot-runtime-dev mailing list