RFR: 8272526: Cleanup ThreadStateTransition class [v2]

[David Holmes]

On Wed, 18 Aug 2021 13:48:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I kind of liked the trans states as indicators of unsafe states as it made the logic consistent and simple:
>> - advance to current state + 1 (trans state)
>> - check for safepoint
>> - advance to final state
>> 
>> and you didn't have to think too much about what the initial state was.
>> 
>> But I can see that logically any unsafe state works.
>
> Right, but whenever we are in safepoint/handshake code we are already in vm, that's why I actually think directly setting _thread_in_vm here makes more sense than having additional states just to make the poll. In fact using transitional states(along with the code in handle_polling_page_exception) forces us to need yet another transition wrapper for handshakes(ThreadInVMForHandshake) just to switch to vm and back. 
> Reading now the description of transition states in globalDefinitions.hpp I see they were more useful back then with the old safepoint logic:
> 
> "These extra states makes it possible for the safepoint code to handle certain thread_states without having to suspend the thread - making the safepoint code faster."
> 
> In SafepointSynchronize::block() there was a faster path for _thread_in_native_trans and _thread_blocked_trans (https://github.com/openjdk/jdk/blame/66aa45649ad36ed41c0241ded767d465248eda3c/src/hotspot/share/runtime/safepoint.cpp#L816).

Yes things have changed a lot :)

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

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