RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads

[Chris Plummer]

On Tue, 20 Dec 2022 02:19:31 GMT, David Holmes <dholmes at openjdk.org> 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