RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended [v3]
Robbin Ehn
rehn at openjdk.java.net
Thu Oct 22 08:07:30 UTC 2020
On Thu, 22 Oct 2020 06:50:37 GMT, Richard Reingruber <rrich at openjdk.org> wrote:
>> Agreed. @sspitsyn - This makes me wonder if the lack of
>> synchronization is the cause of some instability in the
>> JVM/TI ForceEarlyReturn() testing.
>>
>> Update: The old code only made the updates if the thread was fully
>> suspended so you won't have a race between the requesting thread
>> and the target thread in that case.
>
> Yes, I meant synchronization between racing agent threads. Surely a corner case.
Since we do not hold Threads_lock nor SR_lock nothing is stopping the resume at this point AFAICT.
Now this might be illegal, but it can happen if you are not really careful, specially in test like Kitchensink where two modules might use S/R on the same thread.
Also if two threads calling this, the second thread might have passed:
if (_state->is_earlyret_pending()) {
When we do the setting:
_state->set_earlyret_pending();
But now it's protected, even if this never manifested as bug, now we sure it will not.
-------------
PR: https://git.openjdk.java.net/jdk/pull/729
More information about the serviceability-dev
mailing list