On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer <cjplum...@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
