On Tue, 20 Dec 2022 02:19:31 GMT, David Holmes <[email protected]> wrote:
> This sounds like a bug with the underlying executor. If the VT's pin their
> carrier threads then the executor should increase its parallelism level
> automatically to compensate for that.
It's probably best if @AlanBateman explains this. In the meantime, you might
find the following code in VirtualThread.createDefaultScheduler() useful:
String parallelismValue =
System.getProperty("jdk.virtualThreadScheduler.parallelism");
String maxPoolSizeValue =
System.getProperty("jdk.virtualThreadScheduler.maxPoolSize");
String minRunnableValue =
System.getProperty("jdk.virtualThreadScheduler.minRunnable");
if (parallelismValue != null) {
parallelism = Integer.parseInt(parallelismValue);
} else {
parallelism = Runtime.getRuntime().availableProcessors();
}
if (maxPoolSizeValue != null) {
maxPoolSize = Integer.parseInt(maxPoolSizeValue);
parallelism = Integer.min(parallelism, maxPoolSize);
} else {
maxPoolSize = Integer.max(parallelism, 256);
}
Also, Alan mentioned the following to me:
"There are two configuration knobs. One is parallelism, the other is
maxPoolSize. maxPoolSize is the maximum number of carrier threads.
parallelism is really the target parallelism. It's value is the number of
hardware threads but it might be increased temporarily during operations that
pin threads. So if you are monitoring the number of carriers on an 8 core
system then you might see 9 or 10 threads periodically, only to compensate for
threads that are pinned."
What's not clear of me is if the "pinning" that happens during synchronization
is taken into account with this strategy. I think it might not actually be
considered pinning (from an implementation point of view), but does have the
same affect of occupying the carrier thread.
-------------
PR: https://git.openjdk.org/jdk/pull/11735
