Project Loom presentation at BangaloreJUG

[Alan Bateman]

On 17/12/2019 22:08, Volkan Yazıcı wrote:
> [To the best of my knowledge,] pinning a carrier thread means that the
> fiber will block the thread. In the current prototype, holding a
> monitor is still a blocking operation.
>
Yes, and here's a simple example:

synchronized (lock) {
     Socket s = new Socket("pluto.com", 7777);
}

A virtual thread executing this code will likely park twice when inside 
the synchronized block, once to resolve "pluto.com" to a network 
address, the second when trying to establish the TCP connection to the 
remote host. Virtual threads that park while holding monitors will pin 
the underlying carrier thread, this just means it's not available to 
help other virtual threads that waiting to continue. It's a limitation 
that we want to go away in the medium-to-long term of course.

The system property for the command line that I included in the other 
mail was just a diagnostic option to help track down cases like this. 
The output is a stack trace where the frames holding monitors are 
highlighted with a count of the number of monitors held. A good 
discussion for a meet-ups would be to identify cases like this in your 
code and to see how easy it would be replace with j.u.concurrent locks.

-Alan