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

[David Holmes]

On 31/07/2021 2:14 am, Daniel D.Daugherty wrote:
> 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...

Okay but I want to be sure we revisit this before 18 ships. That 
guarantee seems potentially stronger than required - hopefully we will 
catch that during testing.

Thanks,
David

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