RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING
Serguei Spitsyn
sspitsyn at openjdk.org
Sun Jun 4 08:30:04 UTC 2023
On Sun, 4 Jun 2023 08:05:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> When a virtual thread is mounted, the carrier thread should be reported as "waiting" until the virtual thread unmounts. Right now, GetThreadState reports a state based the JavaThread status when it should return JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY.
>> The fix adds:
>> - a special case for passive carrier threads
>> - necessary test coverage to the existing JVMTI test: `serviceability/jvmti/vthread/ThreadStateTest`.
>>
>> Testing:
>> - tested with the updated test: `serviceability/jvmti/vthread/ThreadStateTest`
>> - submitted mach5 tiers 1-5
>> - TBD: to submit mach5 tier 6
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 764:
>
>> 762:
>> 763: if (is_passive_carrier_thread(jt, thread_oop)) {
>> 764: state |= (JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY);
>
> This is testing if the jt is carrying thread_oop and it's okay for the JVMTI state to reported as WAITING when waiting for something other than Object.wait.
>
> One thing that is a bit confusing is the function name "is_passive_carrier_thread". A platform thread is either a carrier or not. Maybe for a different PR but I think is_passive_carrier_thread should be renamed to avoid the use of the word "passive".
The lines 763-764 are to correct the state exactly for passive carrier thread, a carrier thread which can't progress until the execution control has not been returned from a virtual thread executed on the top. It is never for a platform thread which is not a carrier thread. "Passive" is the best word I was able to find for this meaning. Do you have any other word/suggestion in mind?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1216390108
More information about the hotspot-dev
mailing list