On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer 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
On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer 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
On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer 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
On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer 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
On Thu, 22 Dec 2022 08:55:40 GMT, David Holmes wrote:
> I'm suggesting the test reports failure if the parallelism level is too low -
> with a message to go and change the launcher/binder code.
Are saying that in addition to the changes in this PR I should also change each
of the tests to add
On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer 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
On Thu, 22 Dec 2022 06:23:25 GMT, David Holmes wrote:
> 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.
I think I can
On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer 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
On Tue, 20 Dec 2022 05:21:21 GMT, David Holmes wrote:
>> 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
On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer 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
On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer 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
On Tue, 20 Dec 2022 02:19:31 GMT, David Holmes wrote:
> This sounds like a bug with the underlying executor. If the VT's pin their
> carrier threads then the executor should increase its parallelism level
> automatically to compensate for that.
It's probably best if @AlanBateman explains this
On Tue, 20 Dec 2022 02:04:01 GMT, Chris Plummer 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 beca
> 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 availabl
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 carrie
15 matches
Mail list logo
