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

[daniel.daugherty at oracle.com]

On 8/1/21 10:38 PM, David Holmes wrote:
> 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.

For some reason, this email didn't post in the PR...

We'll definitely be keeping on this situation during JDK18 testing.

Dan


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