Experience using virtual threads in EA 23-loom+4-102

Alan Bateman Alan.Bateman at oracle.com
Fri Jun 21 18:47:35 UTC 2024



On 21/06/2024 18:05, Matthew Swift wrote:
> Hello again,
>
> As promised, here is my second (shorter I hope!) email sharing 
> feedback on the recent Loom EA build (23-loom+4-102).

Thank you for taking the time to write down your experiences, this is 
exactly the type of feedback that helps.


> :
>
> ### Experiment #1: read stress test

For #1 and #2, would it be correct to say that there is a lot of monitor 
contention? Your first mail talked about contention in the "multi-index 
write stress test" but I can't tell if this corresponds to #2 or #3 in 
thesecond mail.

This is currently a performance/latency issue with the unblocking of 
virtual threads that were blocked on monitors (or Object.wait). That is 
being looked into and may contribute to some of what you are seeing.


> :
>
>
> Comment:
>
> This test is intended to stress the internal locking mechanisms as 
> much as possible and expose any pinning problems.
> With JDK21 virtual threads the test would sometimes deadlock and 
> thread dumps would show 100+ fork join carrier threads.
> This is no longer the case with the EA build. It looks really solid.
That's good to see.


>
> :
>
> The outliers with virtual threads are much much higher. Could this be 
> due to potential starvation when rescheduling virtual threads in the 
> fork join pool?
>
It's hard to say. The current EA builds doesn't have the final 
ForkJoinPool change that went into JDK 23, we'll refresh the EA build 
soon. Another thing is that virtual threads that were blocked on a 
monitor are pushed to an unowned submission queue so they may not 
continue immediately if it a lot of other virtual thread 
parking/unparking going on - this might change with the monitor 
unblocking perf issue I mentioned. Another possibility is that 
unfairness that can happen when many threads are trying to enter. In 
your EA builds then the output from `jcmd <pid> 
Thread.vthread_scheduler` might help as it shows a count of the number 
of tasks (=threads) in the submission queues.

-Alan


More information about the loom-dev mailing list