RFR: 8308614: Enabling JVMTI ClassLoad event slows down vthread creation by factor 10 [v3]
Serguei Spitsyn
sspitsyn at openjdk.org
Sat Nov 18 12:24:57 UTC 2023
On Fri, 17 Nov 2023 21:19:05 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>>
>> review: add comment for new ThreadsListHandle use
>
> src/hotspot/share/prims/jvmtiEventController.cpp line 374:
>
>> 372: // Protects any existing JavaThread's from being terminated while it is set.
>> 373: // The FJP carrier thread compensating mechanism can create carrier threads concurrently.
>> 374: ThreadsListHandle tlh(current);
>
> A ThreadsListHandle does not prevent a JavaThread from being terminated. It
> prevents a JavaThread from exiting and being freed. The JavaThread is able to
> set the terminated state on itself, but will not be able to complete exiting while
> it is on a ThreadsListHandle. There is a subtle difference.
>
> There's a `target` JavaThread that is fetched from a `JvmtiThreadState` object
> and that `target` JavaThread is only protected by this `tlh` if `target` is included
> in the ThreadsList that was captured by this `tlh`. In all likelihood, there should be
> a ThreadsListHandle farther up the stack that's protecting the JavaThread from
> which the `JvmtiThreadState` object was extracted and passed to this function.
>
> As for carrier threads, if they are created _after_ this `tlh` was created, then this
> `tlh` cannot protect them because they won't be on this `tlh`'s ThreadsList.
Thank you for the comment, Dan!
Agreed, the comment needs to be corrected in two aspects.
I tried to simplify it but failed to do it correctly.
It is interesting that there is a `ThreadsListHandle` farther up the stack but it does not help sometimes.
It is observed that a `JavaThread` (of a carrier thread) referenced from the `JvmtiThreadState` object can be just created, so we need a `ThreadsListHandle` to avoid possible asserts. With this fix in place I do not see the asserts fired anymore.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16686#discussion_r1398200015
More information about the serviceability-dev
mailing list