RFR: 8305670: Performance regression in LockSupport.unpark with lots of idle threads [v2]

[David Holmes]

On Wed, 19 Apr 2023 17:08:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Store side do:
>> Store to threadslist
>> Store to eetop
>> 
>> Read side do:
>> Read eetop
>> Read threadslist
>> Read eetop again
>> 
>> We want them to stay in this order.
>
> Perhaps the comment should change to:
> 
>       ThreadsListHandle tlh; // Also is a barrier between the two JavaThread* queries.

I agree we need these ordering constraints, but I'm not clear what is actually guaranteeing them on either the reader or writer side. I imagine there are a number of "barriers" in relation to TLH construction, but as adding to the threadsList is done under a lock (as is setting eetop) then I'm not sure what explicit barriers exist there. Maybe `java_lang_Thread::set_thread` needs to use `release_address_field_put`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13519#discussion_r1171987653