JDK 22 Release Candidates & Virtual Threads pinning heads-up
Welcome to the latest OpenJDK Quality Outreach update! The first JDK 22 Release Candidates builds are now available [1]. At this stage, only P1 issues will still be evaluated. And with the JDK 22 General Availability set for March 19th, it is now time to fully focus on JDK 23. At the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But new JEP candidates [3][4] have recently been announced, so things should evolve rapidly. I'd like to thank those of you who have already provided feedback on the JDK 22 EA builds. Feedback is always extremely useful, even more, when it comes early in the development cycle. Another area where we need your help is Loom. So, please make sure to check the heads-up below that discusses the so-called Virtual Threads "pinning" issue. [1] https://openjdk.org/projects/jdk/22/ [2] https://openjdk.org/jeps/455 [3] https://openjdk.org/jeps/465 [4] https://openjdk.org/jeps/466 ## 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 [5] explains in more details the why's and discusses some potential solutions. New Loom early-access builds haven been recently published [6]. 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 [7]. 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. [5] https://inside.java/2024/02/17/virtual-threads-next-steps/ [6] https://jdk.java.net/loom/ [7] https://mail.openjdk.org/pipermail/loom-dev/ ## JDK 22 Release Candidates The JDK 22 Release Candidate builds (builds 36) are available [8] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [9], and the javadocs here [10]. [8] https://jdk.java.net/22/ [9] https://jdk.java.net/22/release-notes [10] https://download.java.net/java/early_access/jdk22/docs/api/ ## JDK 23 Early-Access Builds The JDK 23 Early-Access builds 10 are available [11], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [12]. ### Changes in recent JDK 23 builds that may be of interest: - JDK-8324287: Record total and free swap space in JFR - JDK-8275338: Add JFR events for notable serialization situations - JDK-8324665: Loose matching of space separators in the lenient date/time parsing mode - JDK-8324066: "clhsdb jstack" should not by default scan for j.u.c locks because it can be very slow - JDK-8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern - JDK-8325221: Obsolete TLABStats - JDK-8322535: Change default AArch64 SpinPause instruction - JDK-8323746: Add PathElement hashCode and equals - JDK-8325570: Update to Graphviz 9.0.0 - JDK-8303866: Allow ZipInputStream.readEnd to parse small Zip64 ZIP files - JDK-8320458: Improve structural navigation in API documentation - JDK-8324068: Improve references to tags in the Doc Comment Spec - JDK-8322366: Add IEEE rounding mode corruption check to JNI checks - JDK-8321545: Override toString() for Format subclasses - JDK-8324301: Obsolete MaxGCMinorPauseMillis - JDK-8324632: Update Zlib Data Compression Library to Version 1.3.1 - JDK-8324771: Obsolete RAMFraction related flags - JDK-8323645: Remove unused internal sun.net.www.protocol.jar.URLJarFileCa… - JDK-8325150: (tz) Update Timezone Data to 2024a - JDK-8324571: JDK 23 L10n resource files update Note: Complete list of changes can be found here [13]. [11] https://jdk.java.net/23/ [12] https://jdk.java.net/23/release-notes [13] https://github.com/openjdk/jdk/compare/jdk-23+6...jdk-23+10 ## JavaFX Early-Access Builds: These are early access builds of the JavaFX 22 & 23 Runtime bui
Re: JDK 22 Release Candidates & Virtual Threads pinning heads-up
All, On 2/20/24 03:05, David Delabassee wrote: Welcome to the latest OpenJDK Quality Outreach update! The first JDK 22 Release Candidates builds are now available [1]. At this stage, only P1 issues will still be evaluated. And with the JDK 22 General Availability set for March 19th, it is now time to fully focus on JDK 23. At the time of writing, one JEP has already been integrated in JDK 23, i.e., JEP 455: 'Primitive Types in Patterns, instanceof, and switch (Preview)' [2]. But new JEP candidates [3][4] have recently been announced, so things should evolve rapidly. I'd like to thank those of you who have already provided feedback on the JDK 22 EA builds. Feedback is always extremely useful, even more, when it comes early in the development cycle. Another area where we need your help is Loom. So, please make sure to check the heads-up below that discusses the so-called Virtual Threads "pinning" issue. [1] https://openjdk.org/projects/jdk/22/ [2] https://openjdk.org/jeps/455 [3] https://openjdk.org/jeps/465 [4] https://openjdk.org/jeps/466 ## 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 [5] explains in more details the why's and discusses some potential solutions. New Loom early-access builds haven been recently published [6]. 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. This has the potential to make a real positive impact on real-world applications. Most applications I know use network connections during most request-processing activities e.g. contacting a database where the JDBC driver has lots of synchronized blocks. For those who have tried using Virtual Threads and found that there was either no observable performance improvement or, worse, a significant performance *drop* should consider testing this out. I haven't set up a test environment to exercise Virtual Threads so I'm not in a great position to reply about this, but I know there have been some posts to this mailing-list. I hope those who have been trying it out are able to re-try with Java 22 and confirm that (a) you get a performance benefit of some kind and (b) your application doesn't crash all over the place with this new locking strategy. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org