Busy Polling

[Carl M]

> On 03/06/2023 2:23 AM PST Francesco Nigro <nigro.fra at gmail.com> wrote:
> 
> 
> Hi @Viktor Klang
> 
> 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.
> Conversely, a thread dispatch to the FJ specialized pool handling V thread is required, but can create noise that affects results.
> My 2c (given that I've used it recently for a similar purpose).

Yup, this is the reason.  I have been experimenting with ThreadLocals being disabled (though I understand this option is likely to be removed).  It's not well supported today, just due to how JMH does thread management, but I was hoping that my work-arounds could be upstreamed at some point, once Virtual Threads have stabilized. 


> 
> 
> Il giorno lun 6 mar 2023 alle ore 11:11 Viktor Klang <viktor.klang at oracle.com> ha scritto:
> > Just for my understanding—what is he purpose of running JMH on top of VirtualThread?
> > 
> > ------------------------------
> > From: loom-dev <loom-dev-retn at openjdk.org> on behalf of Alan Bateman <Alan.Bateman at oracle.com>
> > Sent: Monday, 6 March 2023 10:08
> > To: Carl M <java at rkive.org>; loom-dev at openjdk.org <loom-dev at openjdk.org>
> > Subject: Re: Busy Polling
> > 
> > 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