RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be

Robbin Ehn rehn at openjdk.java.net
Mon May 24 10:35:07 UTC 2021


On Mon, 24 May 2021 04:42:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please consider this change-set which address the issue on hand.
>> 
>> I identified two problems:
>> 
>> - is_locked() uses the _owner field which is unordered (no storestore|storeload) on store-side.
>> Fixed by leaving the handshakee being processed in queue until completed.
>> And remove looping, since if ever the queue is empty the handshakee may processed.
>> If ever want to loop again, we must make sure queue is not empty before removing the processed handshake.
>> But there is, at this moment, no performance benefit to that, so I chosse the simple, easy to reason about version. (some crazy stress test can see a difference)
>> 
>> Note that I'll do a follow-up and make is_locked() ifdef ASSERT only.
>> 
>> - have_non_self_executable_operation() only provide correct acquire if first in queue matched, if second item matched it could be re-orderd with reading the poll state.
>> Fixed by adding a loadload.
>> 
>> I could at first reproduce by checking _active_handshaker in update_poll (~1/50) and an increase in the test time by ten.
>> (real reprod ~1/400 with increased test time)
>> If we are updating the poll there should not be an active handshaker.
>> The above fixed the issue.
>> But after a rebase when I was trying to pin point the issue I could no longer reproduce even without any changes.
>> 
>> Added Atomic store/load to _active_handshaker since it may be concurrently loaded (it may only be used to ask if current thread is active handshaker).
>> 
>> Passes stressing relevant test on aarch64 and t1-7.
>> 
>> Thanks, Robbin
>
> src/hotspot/share/runtime/handshake.cpp line 594:
> 
>> 592:                        op == match_op ? "including" : "excluding", p2i(match_op));
>> 593: 
>> 594:   return op == match_op ? HandshakeState::_succeeded : HandshakeState::_processed;
> 
> Pre-existing: what does _processed mean versus _succeeded?

- Processed means we did progress, so do not yield.
- Succeeded means you processed the OP you add to the queue. (For your purposes you don't need to revisit this handshakee)

> src/hotspot/share/runtime/safepointMechanism.cpp line 116:
> 
>> 114: 
>> 115: void SafepointMechanism::update_poll_values(JavaThread* thread) {
>> 116:   assert(thread == Thread::current(), "Must not be");
> 
> I assume the message should say "Must be".

Yes, fixing.

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

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


More information about the hotspot-runtime-dev mailing list