~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