~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition()

[Reingruber, Richard]

Hi Robbin,

thanks for the review!

I'd need sponsoring for the fix as well, please.

Thanks, Richard.

-----Original Message-----
From: Robbin Ehn <robbin.ehn at oracle.com> 
Sent: Montag, 13. Mai 2019 09:35
To: Reingruber, Richard <richard.reingruber at sap.com>; hotspot-runtime-dev at openjdk.java.net
Cc: daniel.daugherty at oracle.com
Subject: Re: ~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition()

Hi Richard,

>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8223572/webrev.1/
> 
> Okay. Now I grok where the bug is and how your fix handles it.
> Thumbs up on the fix itself!

Agreed, thanks!

/Robbin

> 
> You don't mention how you tested this fix. You also don't say
> whether you have a test that reproduces this issue.
> 
> Obviously, we also need to hear from Robbin on this thread.
> 
> Dan
> 
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8223572
>>
>> A java thread T can continue executing bytecodes after it was suspended using 
>> the vm operation
>> VM_ThreadSuspend. This can happen in HandshakeState::process_self_inner() when 
>> T becomes safepoint
>> safe calling _semaphore.wait_with_safepoint_check(thread).
>>
>> Fix: poll has_special_runtime_exit_condition() and conditionally call
>> handle_special_runtime_exit_condition() as it is done in 
>> SafepointSynchronize::block(), too.
>>
>> Thanks, Richard.
>>
>> PS: see also mail thread 
>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-May/034144.html
>