RFR: 8318986: Improve GenericWaitBarrier performance [v3]

[Aleksey Shipilev]

On Tue, 7 Nov 2023 09:13:52 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/utilities/waitBarrier_generic.cpp line 192:
>> 
>>> 190:         return;
>>> 191:       }
>>> 192:       assert(s > 0, "Before wait: Should be armed. State: %d", s);
>> 
>> If we are context switched here until this cell is re-used ?
>> Hence we have the wrong barrier tag ?
>> 
>> For safepoint this can't happen since the safepoint id for this safepoint safe thread will be wrong.
>> Thus we can't re-use cells until this thread returns and change his safepoint id.
>> 
>> But it seems like this is what saves us, so if there was another use-case it could happen, no?
>
> I thinking adding the barrier tag into the _state(64), so it's a 32-bit tag, and as now sign bit for armed/disarmed plus the 31-bit counter.

Aw. Yes, there is a race condition here. It is plausible that waiter here can be stuck at previous barrier tag. I thought waiting for all threads to leave the cell on `arm()` saves us here, but it does not, because we might not know at `arm()` that we have a waiter waiting to enter.

Initially I thought to include `barrier_tag` into `_state`, so we can check for it before entering in this code, but somehow convinced myself it was not required. This counter-example directly shows that we want to encode `barrier_tag` into `_state` as well. Let me do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16404#discussion_r1384604709