EA builds with changes to object monitor implementation to avoid pinning with virtual threads

[Andrii Lomakin]

Hi Alan.
That is cool!

Does this build support file async io aka io_uring features?

On Sat, Feb 10, 2024 at 11:34 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
> 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 [1] 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.
>
> -Alan
>
> [1] https://jdk.java.net/loom/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240210/c46e3cd5/attachment.htm>