Should ~ThreadInVMForHandshake() call handle_special_runtime_exit_condition() ?

[Robbin Ehn]

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.
>>