The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of a regular communication sent to the projects involved. To learn more about the program, and how-to join, please check here.

Heads-up: Virtual Threads “Pinning” Issue

Virtual threads became a permanent feature in JDK 21. This feature has been extremely well received by the Java ecosystem but there are still a few pain points. Much has been written 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 (ex. doing socket I/O) 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 is not “released” to do other work. Performance and scalability may suffer and in some cases, starvation and deadlock might happen. This recent Virtual Threads Next Steps video explains in more details the why’s and discusses some potential solutions.

Call-to-Action

New Loom early-access builds haven been recently published. Those Loom EA builds have changes to the object monitor implementation that do not pin for these two common cases.

The Loom team needs your help to test these updated object monitors with code that you know is using virtual threads and with libraries that are heavily synchronized. The goal is to gauge both reliability and performance.

The simplest way to report an issue or feedback is to use the Loom mailing list. For the VM savvy, testing with both -XX:LockingMode=1 (current default) and -XX:LockingMode=2 would be extremely helpful as that would exercise the two locking modes currently implemented by the HotSpot VM.

~