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

[David Holmes]

On Tue, 2 May 2023 21:25:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Address the performance regression in `LockSupport.unpark()` with the following changes:
>> - Add `FastThreadsListHandle` helper class to threadSMR.[ch]pp for quickly determining if a JavaThread* is protected by the ThreadsListHandle embedded in the new helper object.
>> - Update `Unsafe_Unpark()` to pass `java_lang_Thread::thread_acquire(thread_oop)` to a new instance of the `FastThreadsListHandle` object and only do the unpark work if the target JavaThread* is protected.
>
> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'JDK-8307068' into JDK-8305670
>  - Merge JDK-8305670 with code review changes in JDK-8307068.
>  - Merge branch 'JDK-8307068' into JDK-8305670
>  - Merge branch 'jdk-21+20' into JDK-8305670
>  - 8305670.with-rehn-quick-mode.cr3.patch
>  - Use optimized logic in Unsafe_Unpark() instead of cv_internal_thread_to_JavaThread().
>  - dholmes CR - add more comments.
>  - 8305670.with-rehn-quick-mode.cr0.patch

I still have reservations about the utility of FastTLH given it requires a load-acquire by the caller but can't check/enforce that. But I can live with this.

One nit below.

Thanks.

src/hotspot/share/runtime/threadSMR.cpp line 847:

> 845:     // We captured a non-nullptr JavaThread* before the _tlh was created
> 846:     // so that covers the early life stage of the target JavaThread.
> 847:     _protected_java_thread = java_lang_Thread::thread_acquire(thread_oop);

The caller must use `thread_acquire`  so it serves no purpose doing it again here.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13519#pullrequestreview-1412397160
PR Review Comment: https://git.openjdk.org/jdk/pull/13519#discussion_r1184610598