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

[Daniel D. Daugherty]

On Fri, 21 Apr 2023 16:18:10 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> It's also possible to create a special version of ThreadsListHandle which takes an Thread object in constructor.
>> Do the eetop check and then safe fetch the ThreadsList.
>> If you call include() with the same JavaThread* as the eetop was before creating the ThreadsList, you can return true directly, i.e. quick mode.
>> 
>> 
>> SpecialThreadsListHandle::SpecialThreadsListHandle(oop thread_oop) {
>>   _javaThread_from_eetop = java_lang_Thread::thread(thread_oop);
>>   _threadList = ...
>> }
>> 
>> bool includes(JavaThread* jt) {
>>   if (jt == _javaThread_from_eetop && jt != nullptr) return true;
>>   return _threadsList->includes(jt);
>> }
>
> Yes, we could create a special version of ThreadsListHandle that would allow us
> to encapsulate this special purpose logic in threadsSMR source files where it
> belongs. Of course, because I can't stand the 'eetop' name, I'll use some other
> naming here. :-)

Hmmm... it occurs me that this special version of ThreadsListHandle will need a
way to communicate with the call-site that created it and return the protected
`JavaThread*`. If it returns `nullptr`, then the `thread_oop` couldn't be
converted into a protected `JavaThread*`.

Perhaps `stlh.protected_java_thread()`...

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

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