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

[Daniel D. Daugherty]

On Fri, 7 Apr 2023 20:08:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to only check the ThreadsList in a `ThreadsListHandle::cv_internal_thread_to_JavaThread()`
> call in fastdebug or slowdebug bits by default. The `-XX:+EnableThreadSMRExtraValidityChecks` option
> can enable the check in release bits and the `-XX:-EnableThreadSMRExtraValidityChecks` option can
> disable the check in fastdebug or slowdebug bits.
> 
> fastdebug or slowdebug bits will now fail an `assert()` if the `java_thread` is NOT found on the
> ThreadsList (which should never happen).

Did some manual testing with this fix by adding code that would set the
`is_on_list` variable to false when the `-XX:+UseNewCode` option was
specified. That allowed me to verify the right output for the assertion failure:


#  Internal Error (/System/Volumes/Data/work/shared/bug_hunt/XXXXXXX_for_jdk21.git/open/src/hotspot/share/runtime/threadSMR.cpp:841), pid=26005, tid=2146563
#  assert(is_on_list) failed: java_thread=0x00007fac2ac29810 is not on ThreadsList(0x00007fac2ed51240)


I verified that the target thread (0x00007fac2ac29810) is listed in the
"Threads class SMR info:" section of the hs_err_pid file and I verified that
the ThreadsList (0x00007fac2ed51240) matches the current system
ThreadsList.

Also testing with Mach5 Tier[1-3].

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

PR Comment: https://git.openjdk.org/jdk/pull/13393#issuecomment-1500616912