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

[Patricio Chilano Mateo]

On Mon, 12 Oct 2020 15:24:13 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> 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.
>
> Yes, looks like this is possible.
> 
> Wouldn't this also make the block
>   if (state != _thread_blocked_trans &&
>       state != _thread_in_vm_trans &&
>       thread->has_special_runtime_exit_condition()) {
>     thread->handle_special_runtime_exit_condition(
>       !thread->is_at_poll_safepoint() && (state != _thread_in_native_trans));
>   }
> in `SafepointSynchronize::block(JavaThread *thread)`redundant? This would eliminate the recursion you mentioned in the
> PR synopsis, I think.

I thought about removing that check, but right now it's also preventing an escape from a suspend. The issue is that
when going back to java, we always check if we were suspended and call java_suspend_self_with_safepoint_check() if
true. After the do-while(is_external_suspend()) loop we call again SafepointMechanism::process_if_requested(this) to
see if we need to stop for a safepoint/handshake. If there is an actual safepoint pending because of a
VM_ThreadSuspend() then unless we keep that check the thread will not notice it was suspended after the safepoint and
will go back to java. Now, I'm thinking the call to SafepointMechanism::process_if_requested(this) in
java_suspend_self_with_safepoint_check() should be moved inside the the do-while(is_external_suspend()). That way we
guarantee after returning from java_suspend_self_with_safepoint_check() that no one will be assuming the thread is
suspended. And in that case I think that check in SS::block can be removed.

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

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