RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v2]

[Serguei Spitsyn]

On Sun, 4 Jun 2023 11:14:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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?
>
>> 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?
> 
> It's just a carrier. A platform thread becomes a carrier when a virtual thread is mounted, it ceases to be a carrier once the virtual thread is unmounted. The mental model is that the carrier is blocked so reporting its state as waiting indefinitely is correct. Maybe you don't want to rename it in this PR but renaming this function to something like is_carrying would convey that it's asking the question if a given JavaThread is carrying the given virtual thread oop.

Okay, I see you point. Unfortunately, I've always referred the platform thread with an executed FJP schedular as a carrier thread. The term 'carrier' with this meaning is everywhere in the JVMTI code. It looks very confusing to call a thread to be a carrier thread only during some phases of its execution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1218613536