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

[Coleen Phillimore]

On Fri, 5 Nov 2021 20:46:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 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;

Yes, this comment is good and it does explain why it's safe and why the TLH is there.  Thanks for doing the deep dive and explanation.

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

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