~ThreadInVMForHandshake() should call handle_special_runtime_exit_condition()

Robbin Ehn robbin.ehn at oracle.com
Mon May 13 07:35:26 UTC 2019


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
> 


More information about the hotspot-runtime-dev mailing list