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

[David Holmes]

On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe.
>> 
>> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better comments.

The JEP defines pinning as expected:
> There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier:
>
>  When it executes code inside a synchronized block or method, or
>  When it executes a native method or a [foreign function](https://openjdk.java.net/jeps/424).
>
> Pinning does not make an application incorrect, but it might hinder its scalability. If a virtual thread performs a blocking operation such as I/O or BlockingQueue.take() while it is pinned, then its carrier and the underlying OS thread are blocked for the duration of the operation. Frequent pinning for long durations can harm the scalability of an application by capturing carriers.

But then also says:
> The scheduler does not compensate for pinning by expanding its parallelism.

which contradicts what you quoted from Alan above - though I prefer that behaviour as the JEP's behaviour seems a design flaw to me.

-------------

PR: https://git.openjdk.org/jdk/pull/11735