RFR: 8263191: Consolidate ThreadInVMfromJavaNoAsyncException and ThreadBlockInVMWithDeadlockCheck with existing wrappers [v2]

[Daniel D.Daugherty]

On Tue, 9 Mar 2021 15:50:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add asserts for thread state + check_asyncs name
>
> I think there are non-trivial differences between the old ThreadBlockInVM
> and the new ThreadBlockInVM. Maybe I'm wrong, but they do not look
> equivalent to me.

I think you're missing my point about the equivalence of the old ThreadBlockInVM()
and the new ThreadBlockInVM(). The old version did this in trans()/transition():

    // Change to transition state and ensure it is seen by the VM thread.
    thread->set_thread_state_fence((JavaThreadState)(from + 1));

    SafepointMechanism::process_if_requested(thread);
    thread->set_thread_state(to);

which means that when we were in (`_thread_blocked`+1) we did a
`process_if_requested(thread)` call before we changed the thread's
state to `_thread_blocked`. In the new code, we just got straight to
`_thread_blocked` without processing any pending request. I think the
only case that matters is that we won't process a pending handshake
request. As you say, a pending safepoint will be allowed to proceed
once we've reached `_thread_blocked`.

It could be that this change in behavior doesn't make any real difference,
but I want to be sure.

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

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