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

[Daniel D.Daugherty]

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

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

Your last comment is exactly why I want this `guarantee()` here. If we run into
that set of conditions I want us to crash and investigate what the heck is going
on here. It's also the reason why @pchilano and I agreed that this change should
be targeted to jdk/jdk (JDK18) instead of JDK17. We want time for this change
to percolate in the system.

While I've done a lot of Mach5 test runs for this change (plus the fix for JDK-8271251),
there is no substitute for letting this change bake for a couple of months...

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

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