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
