EA builds with changes to object monitor implementation to avoid pinning with virtual threads

[Alan Bateman]

Virtual threads became a permanent feature in JDK 21. This feature has 
been well received by developers and the Java eco system but there are a 
few pain points. Much has been written in articles and blogs about the 
so-called "pinning" issue that arises with synchronized methods or 
synchronized statements. The two most common cases are (a) a virtual 
thread parks (doing socket I/O for example) while in a synchronized 
method, and (b) a virtual thread blocks entering a synchronized method 
because the object's associated monitor is held by another thread. In 
both cases, the underlying carrier/native thread isn't "released" to do 
other work. Performance and scalability may suffer and in some cases, 
starvation and deadlock.

We've published early-access builds from the loom repo [1] that have 
changes to the object monitor implementation that do not pin for these 
two common cases. We need help to test these changes. Testing the 
changes means trying out the builds with code that you know is using 
virtual threads and with libraries that are heavily synchronized. We 
need to gauge both reliability and performance. The simplest way to 
report an issue or feedback is to just send a mail here. For the VM 
savvy, testing with both -XX:LockingMode=1 (current default) and 
-XX:LockingMode=2 would be super helpful as that would exercise the two 
locking mode currently mplemented by the HotSpot VM.

For now, Object.wait and class initializers continue to pin the carrier. 
These may be the focus of future work.

The diagnostics around pinning is changed in these builds compared to 
JDK 21/22. Running with the system property jdk.tracePinnedThreads set 
no longer prints anything. Instead, there are JFR events when a virtual 
threads waits in Object.wait, parks while in a class initializer, or 
parks with some other native frame on its stack.  (Use `jfr print 
--events jdk.VirtualThreadPinnedEvent <recording>` to print out the events).

In addition to changes to the object monitor implementation, the EA 
builds include an update to the ForkJoinPool implementation (the virtual 
thread scheduler is based on ForkJoinPool) that may help with under 
utilization that has been observed on a smaller systems, e.g. containers 
with 2 or 4 virtual cpus for example. We need help testing this too. So 
if you have workloads that are making use of virtual threads when it 
would be super helpful to do some performance testing of these builds 
compared to the JDK 23 EA builds.

-Alan

[1] https://jdk.java.net/loom/