effectiveness of jdk.virtualThreadScheduler.maxPoolSize

[Ron Pressler]

> On 6 Jan 2023, at 19:24, thurston N <thurston.nomagicsoftware at gmail.com> wrote:
> 
> I have a question about the impact of setting jdk.virtualThreadScheduler.maxPoolSize (MAX) to some value > jdk.virtualThreadScheduler.parallelism (P)
> 
> I'll add the caveat that my particular scenario is *not* the target scenario of virtual threads, but I think it might have relevance for more realistic scenarios
> 
> Here's what I've observed (and can reliably reproduce):
> In my simulation, the system can reach a state where:
> A. each of the P CarrierThreads is running a continuation that is completely CPU-bound (reaching 100% CPU)
> B. there are other runnable continuations that are enqueued to the FJP
> 
> but the FJP never spawns other worker CarrierThread(s), even though the total # of CarrierThreads is well below MAX - this was an unexpected and unpleasant surprise
> 
> I guess my question is: should I be surprised? (effectively, is this a bug in FJP?)
> and if not, is there anything I can do about it (in accessible user-level code) to help trigger FJP to spawn more CarrierThreads (workers) up to MAX so that (because of *OS* preemptive scheduling), the other runnable continuations (described in B) will get run?
> 
> -T
> 
> 
> 

It’s not a bug, and increasing maxPoolSize won’t help, since if your CPU is exhausted, adding more threads won’t add more CPU. Parallel streams behave in the exact same way. maxPoolSize refers to compensation by the scheduler for some operations listed in the JEP, which include filesystem IO, where additional threads can actually help.

You could increase parallelism, but the first thing to understand here is why problem are you trying to solve with virtual threads? What is it that you’d like to see happen, why, and why do you think virtual threads are the mechanism to solve it (i.e. we do offer a thread scheduler that offers time-sharing — the kernel scheduler)?

— Ron