RFR: 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes [v10]
Daniel D.Daugherty
dcubed at openjdk.java.net
Fri Nov 5 15:54:17 UTC 2021
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
More information about the serviceability-dev
mailing list