On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can paralle
On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can paralle
On Wed, 8 Sep 2021 11:06:50 GMT, Arno Zeller wrote:
> Probably it could be a better solution to add the stress keyword for slow
> running or high load tests - like it is done in the hotspot part of the
> tests. Then automated test run can exclude or select these test by keyword.
Thought so too
On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can paralle
On Wed, 8 Sep 2021 11:34:10 GMT, Maurizio Cimadamore
wrote:
> Changes looks good. Whether we want to use `manual` or `@stress` I'm not
> sure. I guess it depends a lot on which parameters are typically used by CI
> to run those tests.
I note that, for instance, the makefile `make/RunTests.gmk
On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can paralle
On Wed, 8 Sep 2021 09:13:20 GMT, Aleksey Shipilev wrote:
> New commit: marked tests as `manual`, as per Maurizio's request. This forced
> me to drop the `timeout=` clauses, as those are incompatible with `manual`
> (jtreg plainly refuses to run these).
Ok, I am too late, but just for the reco
On Tue, 7 Sep 2021 16:54:11 GMT, Alan Bateman wrote:
>> you are right about /manual being for GUI - but @AlanBateman pointed me at
>> few tests with libzip using it for similar reasons (e.g. long running tests).
>
> I don't think /manual is strictly UI but its usage is discouraged as manual
> t
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
> parallelize the test configurations for this test to make it hurt less
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
> parallelize
On Tue, 7 Sep 2021 16:38:25 GMT, Maurizio Cimadamore
wrote:
>> I can, but it seems to me that `/manual` is for marking GUI tests that
>> require user interaction. Let me see if there are keywords we can use.
>> Something like "developer", so that you can pass `jtreg -k:developer` or
>> `JTREG
On Tue, 7 Sep 2021 15:53:20 GMT, Aleksey Shipilev wrote:
>> test/jdk/java/foreign/TestMatrix.java line 7:
>>
>>> 5: * @build NativeTestHelper CallGeneratorHelper TestUpcallHighArity
>>> 6: *
>>> 7: * @run testng/othervm/native
>>
>> can you please throw in a `/manual` in here as well - so th
On Tue, 7 Sep 2021 15:04:31 GMT, Maurizio Cimadamore
wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can par
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
> parallelize
On Tue, 7 Sep 2021 14:30:41 GMT, Maurizio Cimadamore
wrote:
> So, what is the policy for defining developers tests that are not meant to be
> ran on every build infra, but are meant to be run on a more casual basis by
> developers working in a particular area? When we added TestMatrix we made
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
> parallelize
On Tue, 7 Sep 2021 14:05:46 GMT, Maurizio Cimadamore
wrote:
> if you still want to pursue the improvement, we can do that too.
Yes, I still want to pursue this test improvement.
-
PR: https://git.openjdk.java.net/jdk/pull/5358
On Tue, 7 Sep 2021 13:58:48 GMT, Maurizio Cimadamore
wrote:
> How is this test executed? I think when this was added the idea was that this
> had to be an advanced test which had to be run explicitly by users, but would
> not be picked up in the various test groups/tiers. I'm defo not seeing i
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
> parallelize
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
> parallelize
This test runs a lot of configurations, and spends a lot of time serially. This
is especially pronounced when run in prospective tier4 runs (JDK-8273314).
There are reports of multi-hour runs (see JDK-8271613). We can parallelize the
test configurations for this test to make it hurt less. Also,
21 matches
Mail list logo