[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2]
From:       Alan Bateman <alanb () openjdk ! org>
Date:       2022-12-29 8:45:48
Message-ID: v-fAuxBwG-OnzMN8ox6Oypowp3C3kT4yXIsUQzuMggk=.842505d8-1844-4ad0-a5e0-5c7c59528530 () github ! com
[Download RAW message or body]

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

Marked as reviewed by alanb (Reviewer).

The proposed change looks okay and a lot more maintainable than adjusting specific \
tests.

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

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


[prev in list] [next in list] [prev in thread] [next in thread]