RFR: 8266963: Reentrance condition for safepoint/handshake

[Robbin Ehn]

On Tue, 18 May 2021 09:26:11 GMT, Yude Lin <github.com+16811675+linade 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)
>
>> 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!

@linade will you re-do the PR with that change instead?

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

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