RFR: 8266963: Reentrance condition for safepoint/handshake

[Yude Lin]

On Mon, 17 May 2021 14:25:49 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> We can just remove this:
> 
>     if (i != 0 && thread->is_Java_thread()) {
>       JavaThread* jt = thread->as_Java_thread();
>       if (jt->thread_state() == _thread_in_vm) {
>         // Since this JavaThread has looped at least once and is _thread_in_vm,
>         // we honor any pending blocking request.
>         ThreadBlockInVM tbivm(jt);
>       }
>     }
> 
> Under some wired circumstances it can prolong TTS.
> But it was me that found it. Reverting it wouldn't get any complains from anyone else.
> 
> (we have seen this in experimental code internally, and just remove code which goes to blocked was suggested then also)

In that case this is a solution I can get behind.

> The issue is that inside the handshake closure you would transition to
> the blocked state in ThreadBlockInVM(), which allows a safepoint to
> proceed. If in ~ThreadBlockInVM() we don't stop for the safepoint and
> just return in SafepointMechanism::process_if_requested_slow() then now
> you would have a safepoint and handshake executing at the same time.

Ah I see, there I was thinking a thread is only considered in safepoint by VM Thread when it's blocked in SafepointMechanism::process, but it actually happen when transitioned to the _thread_blocked state. Thanks for pointing it out!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4028