On Sun, 4 Jun 2023 11:14:06 GMT, Alan Bateman <al...@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
