<div dir="ltr"><div><div><div>I have a question about the impact of setting jdk.virtualThreadScheduler.maxPoolSize (MAX) to some value > jdk.virtualThreadScheduler.parallelism (P)<br><br></div>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<br><br></div>Here's what I've observed (and can reliably reproduce):<br></div><div>In my simulation, the system can reach a state where:<br></div><div>A. each of the P CarrierThreads is running a continuation that is completely CPU-bound (reaching 100% CPU)<br></div><div>B. there are other runnable continuations that are enqueued to the FJP</div><div><br></div><div>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<br><br></div><div>I guess my question is: should I be surprised? (effectively, is this a bug in FJP?)<br></div><div>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?<br><br></div><div>-T<br></div><div><br></div><div><br></div><div><br></div></div>