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

[Daniel D. Daugherty]

On Fri, 21 Apr 2023 09:57:16 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Before we went down the road of creating this `quick_mode` variant of the
>> conversion function, I added this comment about "API indigestion" to the bug report:
>> 
>> https://bugs.openjdk.org/browse/JDK-8305670?focusedCommentId=14573647&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14573647
>> 
>> @robehn's proposed `quick_mode` changes were an attempt to make the indigestion
>> a little less bothersome (Tums anyone?), but @dholmes-ora's comments have made a
>> good case here for what we've done is jump thru hoops to keep a call to the (slightly
>> modified) conversion function when it's clear that the general purpose conversion
>> function just isn't the right tool for this particular job.
>> 
>> I'm going to take another look at backing out portions of the `quick_mode` fix while
>> trying to keep the performance improvements. This will result in `Unsafe_Unpark()`
>> not trying to use the general purpose conversion function.
>> 
>> On a related note, we're having a bit of trouble trying to reproduce the performance
>> improvements on the machines in our performance lab.
>
> 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. :-)

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

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