Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ?

[Reingruber, Richard]

Hi Robbin,

   > >> +    if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) &&
   > >> +        _thread->has_special_runtime_exit_condition()) {
   > >> +      _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint());
   > >> +    }
   > 
   > You need to verify that async exception check is correct.
   > If we are returning to native it should not be delivered AFAIK.

You're right. I guess ThreadInVMForHandshake::transition_back() should do the same as
SafepointSynchronize::block(). I'll come back with an webrev tomorrow after nightly testing.

Thanks, Richard.

-----Original Message-----
From: Robbin Ehn <robbin.ehn at oracle.com> 
Sent: Dienstag, 7. Mai 2019 17:16
To: Reingruber, Richard <richard.reingruber at sap.com>; hotspot-runtime-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
Subject: Re: Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ?

Hi Richard,

>> +    if ((_original_state == _thread_in_Java || _original_state == _thread_in_native) &&
>> +        _thread->has_special_runtime_exit_condition()) {
>> +      _thread->handle_special_runtime_exit_condition(!_thread->is_at_poll_safepoint());
>> +    }

You need to verify that async exception check is correct.
If we are returning to native it should not be delivered AFAIK.

Thanks, Robbin

>>      }
>>    
>>     public:
>>
>> Without that patch an issue could be that thread T continues executing bytecodes after it was
>> suspended by a JVMTI agent like this:
>>
>> - Handshake operation H is executed for T
>> - T calls ThreadSafepointState::handle_polling_page_exception()
>> - T arrives in HandshakeState::process_self_inner()
>> - T transitions from _thread_in_Java to _thread_in_vm
>> - but too late: the VM thread already claimed H
>> - T calls _semaphore.wait_with_safepoint_check()
>> - T transitions from _thread_in_vm to _thread_blocked
>> - The VM thread completes H and calls _semaphore.signal()
>> - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and
>>     executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T
>> - After the safepoint T transitions back to _thread_in_vm and then to _thread_in_Java.
>> - T continues executing an undefined number of bytecodes ...
>>
>> Cheers, Richard.
>>