<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
Thanks for the background, Francesco.<br>
<br>
In that case I think Alan's suggestion is probably the right way to go—providing the number of threads to the default scheduler at startup to reduce the risk of starvation.<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Francesco Nigro <nigro.fra@gmail.com><br>
<b>Sent:</b> Monday, 6 March 2023 11:23<br>
<b>To:</b> Viktor Klang <viktor.klang@oracle.com>; Viktor Klang <viktor.klang@gmail.com><br>
<b>Cc:</b> Alan Bateman <alan.bateman@oracle.com>; Carl M <java@rkive.org>; loom-dev@openjdk.org <loom-dev@openjdk.org><br>
<b>Subject:</b> Re: Busy Polling</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi <a class="x_gmail_plusreply" id="x_plusReplyChip-0" href="mailto:viktor.klang@gmail.com" tabindex="-1">@Viktor Klang</a>
<div><br>
</div>
<div>probably is to get the benchmark method to run in a virtual thread and be able to measure "parking"/awake costs, thread local lookup and few other behaviours where the running thread context makes difference.</div>
<div>Conversely, a thread dispatch to the FJ specialized pool handling V thread is required, but can create noise that affects results.</div>
<div>My 2c (given that I've used it recently for a similar purpose).</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">Il giorno lun 6 mar 2023 alle ore 11:11 Viktor Klang <<a href="mailto:viktor.klang@oracle.com">viktor.klang@oracle.com</a>> ha scritto:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div class="x_msg-6901302329293967177">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255)">
Just for my understanding—what is he purpose of running JMH on top of VirtualThread?<br>
</div>
<div id="x_m_-6787361659014067804appendonsend"></div>
<hr style="display:inline-block; width:98%">
<div id="x_m_-6787361659014067804divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> loom-dev <<a href="mailto:loom-dev-retn@openjdk.org" target="_blank">loom-dev-retn@openjdk.org</a>> on behalf of Alan
Bateman <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>><br>
<b>Sent:</b> Monday, 6 March 2023 10:08<br>
<b>To:</b> Carl M <<a href="mailto:java@rkive.org" target="_blank">java@rkive.org</a>>;
<a href="mailto:loom-dev@openjdk.org" target="_blank">loom-dev@openjdk.org</a> <<a href="mailto:loom-dev@openjdk.org" target="_blank">loom-dev@openjdk.org</a>><br>
<b>Subject:</b> Re: Busy Polling</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>On 06/03/2023 07:12, Carl M wrote:<br>
> Hi Again,<br>
><br>
> I've been experimenting with Virtual threads some more and encountered a sharp corner when running with JMH. I am currently using JMH with a custom executor to run on Virtual threads, but ran into an issue when using a larger number of threads.<br>
><br>
> JMH works by spawning a small fixed number of threads which do a loop until a volatile boolean has been set. Once set, the threads continue on in the next part of the benchmark. However, When the number of Group threads exceeds the number of Carrier Thread
(which is typically the number of processors), the program will hang. For example, my machine has 8 processors, so I run 8 Group threads for my benchmark. JMH spawns 9 threads, 8 to do the benchmark, and 1 as a control. Since the first 8 threads get stuck
doing work, the control thread never gets scheduled to set the volatile boolean, and the benchmark never proceeds.<br>
><br>
> I tried calling Thread.yield() which does work, but spoils the benchmark numbers. As far as I can tell there isn't a way to control the parallelism of the Carrier thread pool (always FJP?). If it were possible to expand this by a thread, the benchmark
could proceed (at the cost of the number of worker buckets not being a nice power of 2. Lastly, it superficially seems like ManagedBlocker might fit in here some how, but I can't see how it would adapt exactly.<br>
><br>
> I'm wondering if y'all can provide some guidance on what to do here?<br>
<br>
The system properties for overriding parallelism and the max pool size <br>
of the carrier threads are jdk.virtualThreadScheduler.parallelism and <br>
jdk.virtualThreadScheduler.maxPoolSize. They are documented the <br>
"Implementation Note" section of the Thread's class description and the JEP.<br>
<br>
Off-hand, I don't know if there is a good recipe for configuring JMH + <br>
JDK to run a benchmark with a virtual thread. Such a setup might be <br>
useful for benchmark APIs or code that blocks a lot. I haven't seen JMH <br>
configuted with a custom executor so I assume what might be replacing <br>
platform threads with virtual threads and some/all of the first 8 are <br>
pinned so there is starvation. Maybe others that have explored this <br>
issue can reply, it might be worth checking the jmh-dev archives too in <br>
case this topic has been discussed already.<br>
<br>
-Alan<br>
</div>
</span></font></div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>