RFR: 8356222: Thread.print command reports waiting on the Class initialization monitor for both carrier and virtual threads

[Alan Bateman]

On Thu, 22 May 2025 11:58:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To me, in the pinned case, both threads are "really waiting". The carrier physically and the vthread "logically". This also indicates it is actually doing pinning.

The intended mental model has always been that the carrier is waiting for the virtual thread. The virtual thread may be blocked and waiting for something else of course. This is why, for example, ThreadMXBean and ThreadInfo::getLockedMonitors() with the ID of carrier report the identity hash of the virtual thread when there is a virtual thread mounted. There is some outstanding work on the thread state reported for carriers but once that is done then it will be much clearer.

There are changes in the loom repo to allow preemption when waiting for a class to be initialized. In that case, the virtual thread will unmount so it won't appear in the HotSpot VM thread dump. However, if pinned, then it will appear and we will get the same confusing output. So I think we should fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25367#issuecomment-2901014409