RFR: 8271348: Add stronger sanity check of thread state when polling for safepoint/handshakes [v2]

[David Holmes]

On Fri, 30 Jul 2021 01:13:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think the thread's state can change during this loop so having the check in the
>> loop will catch if it changes to something bad.
>> 
>> The assert() in `block()` is to catch any future new callers to `block()` that aren't
>> calling from the right thread_state.
>> 
>> Yes, I specifically wanted a `guarantee()` here to catch this condition in 'release' bits.
>> The original internal programming bug was racy and I want to make sure we have the
>> best chance to catch any future racy uses.
>
> I would expect any state change to restore the original state before we get back into this loop. So this seems a little paranoid, but okay I guess.

No on further thought I'm not sure about this. If we take the path to SS::block() then this guarantee must hold. But what if we don't take that path? What if this is called due to a local poll and the thread is executing code that precludes the possibility of a global poll (e.g. holds Threads_lock) - what are the potential valid states in that case?

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

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