On Tue, 20 Dec 2022 02:04:01 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.

This pull request has now been integrated.

Changeset: d6e9f015
Author:    Chris Plummer <cjplum...@openjdk.org>
URL:       
https://git.openjdk.org/jdk/commit/d6e9f01584ef84d6390c356fd3b342d9d79899ab
Stats:     31 lines in 3 files changed: 6 ins; 25 del; 0 mod

8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads
8282383: [LOOM] 6 nsk JDI and JDB tests sometimes failing with vthread wrapper 
due to running out of carrier threads

Reviewed-by: dholmes, sspitsyn, alanb, lmesnik

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

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

Reply via email to