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

Daniel D.Daugherty dcubed at openjdk.java.net
Fri Nov 5 23:47:41 UTC 2021


On Fri, 5 Nov 2021 21:54:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

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

Updated comment has been pushed to this PR.

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

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


More information about the serviceability-dev mailing list