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

[Daniel D.Daugherty]

On Fri, 5 Nov 2021 15:15:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Yes, ^ that might make the logic easier to follow. I can't figure out what checkTLSOnly means.  Could it be refactored into a different function like check_TLS() and then call it in the place where you pass true instead of is_JavaThread_protected?  Does checkTLSOnly skip a lot of these checks?
>
> I've changed `is_JavaThread_protected()` to materialize current_thread when it is declared
> to simplify the code paths.

> I can't figure out what checkTLSOnly means.

See the function's header comment:


// ... If checkTLHOnly is true (default is false), then we only check
// if the target JavaThread is protected by a ThreadsList (if any) associated
// with the calling Thread.


> Could it be refactored into a different function like check_TLS() and then
> call it in the place where you pass true instead of is_JavaThread_protected?

I had a copy of this logic in a separate function and @dholmes-ora suggested
that I add the `checkTLHOnly` parameter to this function and get rid of the
separate copy so I've been there and done that.

I could *move* the logic into a separate function and then call that new function
from here and from the other call sites that pass `true`, but then I'd have to
materialize current_thread in that new function and then on this code path we
would be materializing current_thread twice. I don't want to do that.

> Does checkTLSOnly skip a lot of these checks?

Please read the header comment to see what `checkTLHOnly` does.

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

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