On Thu, 22 Oct 2020 06:50:37 GMT, Richard Reingruber <rr...@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
