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

[Daniel D.Daugherty]

On Fri, 5 Nov 2021 16:43:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The `ThreadsListHandle` protects `JavaThread` objects not `JvmtiThreadState` objects.
>> `JvmtiThreadState::first()` returns the head of the global list of `JvmtiThreadState`
>> objects for the system. Each `JvmtiThreadState` object contains a `JavaThread*` and
>> we have to protect use of the `JavaThread*` which can happen in the
>> `recompute_thread_enabled(state)` call below.
>
> 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