RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v3]
    David Holmes 
    dholmes at openjdk.org
       
    Thu Oct 24 05:58:18 UTC 2024
    
    
  
On Wed, 23 Oct 2024 17:32:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 111:
>> 
>>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
>>> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter
>> 
>> Presumably this one means it acquired the monitor?
>
> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.
So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
RUNNING -> BLOCKING -> BLOCKED
BLOCKED -> UNBLOCKING -> RUNNABLE
I'm just trying to get a better sense of what we can infer if we see these "transition" states.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283
    
    
More information about the graal-dev
mailing list