On Fri, 5 Nov 2021 15:43:37 GMT, Daniel D. Daugherty <dcu...@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
