EA builds with changes to object monitor implementation to avoid pinning with virtual threads
Alan.Bateman at oracle.com
Sat Feb 10 09:26:42 UTC 2024
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  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.
More information about the loom-dev