<div dir="ltr"><div><br></div><div>Hi Alan.</div>That is cool!<div><br><div>Does this build support file async io aka io_uring features?</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 10, 2024 at 11:34 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Virtual threads became a permanent feature in JDK 21. This feature has <br>
been well received by developers and the Java eco system but there are a <br>
few pain points. Much has been written in articles and blogs about the <br>
so-called "pinning" issue that arises with synchronized methods or <br>
synchronized statements. The two most common cases are (a) a virtual <br>
thread parks (doing socket I/O for example) while in a synchronized <br>
method, and (b) a virtual thread blocks entering a synchronized method <br>
because the object's associated monitor is held by another thread. In <br>
both cases, the underlying carrier/native thread isn't "released" to do <br>
other work. Performance and scalability may suffer and in some cases, <br>
starvation and deadlock.<br>
<br>
We've published early-access builds from the loom repo [1] that have <br>
changes to the object monitor implementation that do not pin for these <br>
two common cases. We need help to test these changes. Testing the <br>
changes means trying out the builds with code that you know is using <br>
virtual threads and with libraries that are heavily synchronized. We <br>
need to gauge both reliability and performance. The simplest way to <br>
report an issue or feedback is to just send a mail here. For the VM <br>
savvy, testing with both -XX:LockingMode=1 (current default) and <br>
-XX:LockingMode=2 would be super helpful as that would exercise the two <br>
locking mode currently mplemented by the HotSpot VM.<br>
<br>
For now, Object.wait and class initializers continue to pin the carrier. <br>
These may be the focus of future work.<br>
<br>
The diagnostics around pinning is changed in these builds compared to <br>
JDK 21/22. Running with the system property jdk.tracePinnedThreads set <br>
no longer prints anything. Instead, there are JFR events when a virtual <br>
threads waits in Object.wait, parks while in a class initializer, or <br>
parks with some other native frame on its stack.  (Use `jfr print <br>
--events jdk.VirtualThreadPinnedEvent <recording>` to print out the events).<br>
<br>
In addition to changes to the object monitor implementation, the EA <br>
builds include an update to the ForkJoinPool implementation (the virtual <br>
thread scheduler is based on ForkJoinPool) that may help with under <br>
utilization that has been observed on a smaller systems, e.g. containers <br>
with 2 or 4 virtual cpus for example. We need help testing this too. So <br>
if you have workloads that are making use of virtual threads when it <br>
would be super helpful to do some performance testing of these builds <br>
compared to the JDK 23 EA builds.<br>
<br>
-Alan<br>
<br>
[1] <a href="https://jdk.java.net/loom/" rel="noreferrer" target="_blank">https://jdk.java.net/loom/</a><br>
</blockquote></div>