RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5]

[Robbin Ehn]

On Fri, 9 Sep 2022 16:36:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed ws
>
> src/hotspot/share/runtime/handshake.cpp line 380:
> 
>> 378:   if (UseSystemMemoryBarrier) {
>> 379:     SystemMemoryBarrier::emit();
>> 380:   }
> 
> It's not clear to me why this emit() is here.

add_operation() arms poll.
try_process() reads JavaThread state.

Since are allowing the CPU to do reordering of instructions, try_process() can see e.g. state in_native after arming the poll.
Normally this would be safe, but since we now allow reordering it's not.
By emitting the system membar we know that if we see in_native that thread will see the armed poll.

Long comment from me above, but yes it's not clear that add_operation() and try_process() are effected by this race when using system membar.

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

PR: https://git.openjdk.org/jdk/pull/10123