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. > in case you want to have a look at what was involved: > https://github.com/openjdk/jdk/pull/11762. Yeah that isn't nice. I was thinking a more simple check of the property value against the required number of threads. Though based on your comment "nthreads+1" is not always enough so the check would not be sufficient. ------------- PR: https://git.openjdk.org/jdk/pull/11735
