effectiveness of jdk.virtualThreadScheduler.maxPoolSize

[thurston N]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230106/eab24760/attachment.htm>