Project Loom VirtualThreads hang

[robert engels]

Amazing. With that option disabled, the runtime falls from 36 seconds to 22 seconds. It also eliminated the significant overhead previously seen when running under the async profiler.

The system cpu is < 3% and the idle is < 3%. The system % is much closer to the ideal for a test like this. Somewhat unexpected, but any spinning for locks now has a detrimental effect on performance.

In the “real world” test, it didn’t seem to make much difference, but I haven’t fully reviewed that code in light of findings in the micro benchmarks.

The updated profiler shows:



which is interesting because the #1 consumer is still the ForkJoin pool parking while waiting for work - even though the system and idle percentages are so low.

Can you briefly describe what that runtime option does?


> On Jan 5, 2023, at 1:05 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 05/01/2023 00:54, robert engels wrote:
>> 
>> 
>>> On Jan 4, 2023, at 3:32 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>> 
>>> -XX:+UnlockExperimentalVMOptions -XX:+DoJVMTIVirtualThreadTransitions 
>> 
>> As an fyi, the above did not affect the async profiler trace that I could tell. I get similar profilers with both the Intellij profiler and the async profiler.
> 
> Oops, a typo in my mail, it should be -XX:-DoJVMTIVirtualThreadTransitions to disable (not '+' to enable).
> 
> -Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230105/a1d0e208/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-4.png
Type: image/png
Size: 326415 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230105/a1d0e208/PastedGraphic-4-0001.png>