RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake()

[Patricio Chilano Mateo]

On Mon, 12 Oct 2020 08:12:04 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> has_special_runtime_exit_condition() checks for async exceptions, external_suspend and JFR suspend. The last two can
>> actually be set while we are in the handshake. It doesn't mean that the caller will consider the target suspended, but
>> the _suspend_flags might be different at construction and destruction of TIVFH. As for async exceptions, I realized we
>> have a similar issue as the one described in 8223572 when calling handle_polling_page_exception() on a return poll:
>> - T calls ThreadSafepointState::handle_polling_page_exception() because another thread called T.stop() (which we
>>   implement with a handshake)
>> - T calls SafepointMechanism::process_if_requested(thread())
>> - T calls HandshakeState::process_self_inner() and processes the handshake which calls set_pending_async_exception()
>> - T returns from SafepointMechanism::process_if_requested(thread()) and goes back to java without calling
>>   check_and_handle_async_exceptions() to throw the ThreadDeath() exception
>> 
>> I'm not sure if delaying the throw of ThreadDeath is allowed, so if we need to keep the current behaviour I can add a
>> call to check_and_handle_async_exceptions():
>> @@ -987,6 +987,7 @@ void ThreadSafepointState::handle_polling_page_exception() {
>>      // Process pending operation
>>      SafepointMechanism::process_if_requested(thread());
>> +   thread()->check_and_handle_async_exceptions();
>> 
>>      // restore oop result, if any
>
> Reading that comment I realized that this change would break in flight pr #119
> 
> To refresh memories: there I'm adding a new suspend flag currently required for object reallocation. I'm using a
> handshake to synchronize with the suspendee thread S. After the handshake it is guaranteed that the stack of S is
> walkable and S cannot push/pop frames. This would not work anymore.  I could replace the handshakes (in
> [escapeBarrier.cpp line 172,
> 218](https://github.com/openjdk/jdk/pull/119/files#diff-b72c15f49cba82da2158d4e9a4ab0e92R172-R173)) with vm operations
> though. Should be ok.

I see. You should still be able to use handshakes. I think the issue is that in handle_polling_page_exception(),
instead of calling SafepointMechanism::process_if_requested(thread()), we should be doing { ThreadInVMfromJava
__tiv(thread());} and { ThreadInVMfromJavaNoAsyncException __tiv(thread());} for the polling on return and not on
return respectively. That will process a safepoint/handshake and then check the special conditions before going back to
java.

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

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