RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v12]

[Daniel D.Daugherty]

On Fri, 5 Nov 2021 15:43:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A fix to reduce ThreadsListHandle overhead in relation to handshakes and
>> we add sanity checks for ThreadsListHandles higher in the call stack.
>> 
>> This fix was tested with Mach5 Tier[1-8]; Tier8 is still running.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8249004.cr4.patch

> JvmtiThreadState objects point to JavaThread and vice versa, so I still don't see why you don't protect the first element.

I've written up a rather long analysis about how the use of JvmtiThreadState_lock
in JvmtiEventControllerPrivate::recompute_enabled() means that we can safely
traverse the JvmtiThreadState list returned by JvmtiThreadState::first() without
racing with an exiting JavaThread. I've sent it to you via direct email.

I could amend the comment above the ThreadsListHandle like this:

    // If we have a JvmtiThreadState, then we've reached the point where
    // threads can exist so create a ThreadsListHandle to protect them.
    // The held JvmtiThreadState_lock prevents exiting JavaThreads from
    // being removed from the JvmtiThreadState list we're about to walk
    // so this ThreadsListHandle exists just to satisfy the lower level sanity
    // checks that the target JavaThreads are protected.
    ThreadsListHandle tlh;

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

PR: https://git.openjdk.java.net/jdk/pull/4677