RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v2]

[David Holmes]

On Tue, 13 Oct 2020 20:53:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The same problematic execution sequence detailed in 8223572 for the external_suspend case was there for async
>> exceptions too. So, while the thread was blocked in the handshake a ThreadStop() operation could have been executed.
>> After returning from the handshake there was no async exception check. We probably never noticed it because the throw
>> would happen anyways on some later transition back to java (vm->java or native->java).  As to how was that call made
>> before and what change got rid of it: this code was there before handshakes existed. ThreadStop() was implemented as a
>> safepoint and we were probably relying on the special_runtime_exit_condition() check at the end of SS::block() (exactly
>> like the one I'm removing from ~TIVFH and which I'll try to get rid of to eliminate recursions).
>
> Makes sense. Thanks!

Not to belabour this but I don't understand what this sentence:

// If we are at a polling page safepoint (not a poll return)

is actually making a distinction between. What is a "poll return" here versus a "polling page safepoint"?

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

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