Busy Polling

[Alan Bateman]

On 06/03/2023 07:12, Carl M wrote:
> Hi Again,
>
> 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.
>
> 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.
>
> 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.
>
> I'm wondering if y'all can provide some guidance on what to do here?

The system properties for overriding parallelism and the max pool size 
of the carrier threads are jdk.virtualThreadScheduler.parallelism and 
jdk.virtualThreadScheduler.maxPoolSize. They are documented the 
"Implementation Note" section of the Thread's class description and the JEP.

Off-hand, I don't know if there is a good recipe for configuring JMH + 
JDK to run a benchmark with a virtual thread. Such a setup might be 
useful for benchmark APIs or code that blocks a lot.  I haven't seen JMH 
configuted with a custom executor so I assume what might be replacing 
platform threads with virtual threads and some/all of the first 8 are 
pinned so there is starvation.  Maybe others that have explored this 
issue can reply, it might be worth checking the jmh-dev archives too in 
case this topic has been discussed already.

-Alan