Busy Polling
Carl M
java at rkive.org
Mon Mar 6 07:12:29 UTC 2023
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?
Carl
More information about the loom-dev
mailing list