RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v6]
Coleen Phillimore
coleenp at openjdk.java.net
Fri Nov 5 21:56:42 UTC 2021
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
More information about the serviceability-dev
mailing list