From gziemski at openjdk.org  Thu Dec  1 19:26:01 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 1 Dec 2022 19:26:01 GMT
Subject: RFR: 7903217: jtreg could try killing descendants of stuck test, 
 before timing out the test [v4]
In-Reply-To: <XC6kJWG8Zr1D6mimhc79GUqMkUAqooy0eEmQEDi1JNM=.7c08d837-4599-402b-9c63-e6b5703fa7bb@github.com>
References: <EdrQ-aAmgSQVIN34XjqcMdlHJxpwhow0IDkxsBtGw-M=.6f881262-2039-49a7-8496-7f98caed6aa8@github.com>
 <XC6kJWG8Zr1D6mimhc79GUqMkUAqooy0eEmQEDi1JNM=.7c08d837-4599-402b-9c63-e6b5703fa7bb@github.com>
Message-ID: <YhSvKnd8sPLVvlOXC90BX_fSEqbNqouYlfyMzEWEjgA=.ae80fdb6-28f0-4cd8-aff7-08b9f2815090@github.com>

On Mon, 22 Aug 2022 20:54:36 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is an enhancement that aims to improve the robustness of the testing by attempting to quit any child processes (that are possibly stuck and are blocking the parent process from terminating) before timing out the target parent process.
>> 
>> Aborting a process will flush its stdout/stderr streams, which will hopefully get captured in the test's log and provide additional clues as to why a test was timing out.
>> 
>> This enhancement was locally tested with a handcrafted test that itself launched a child process that would get stuck on purpose and worked as intended.
>> 
>> Hopefully, this will help debug issues such as [JDK-8286345](https://bugs.openjdk.org/browse/JDK-8286345)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return exit code if we had to cancel any child processes

> _Mailing list message from [Jonathan Gibbons](mailto:jonathan.gibbons at oracle.com) on [jtreg-dev](mailto:jtreg-dev at mail.openjdk.org):_
> 
> On 11/17/22 12:50 PM, Gerard Ziemski wrote:
> 
> If it's not one test but many, that suggests putting the functionality in code in a test-library, that can be reused by any necessary tests.
> 
> Also, note the possibility of using `@run driver` which is intended as an extension mechanism for customized execution models, such as that you are describing. In conjunction with test library code, it allows you to have complex execution models, which can even be different for different kinds of tests.?? You described one particular model where a process might time out but the test should still be deemed to have passed;? that may be reasonable for the tests you have in mind, but it does not sound general enough or standard enough to be baked into mainline jtreg.
> 
> If you have trouble modelling the behavior you want in a test driver class, then that is a reason to come back here and propose or ask for any necessary enhancements.

The goal here was to "flush" any possible outstanding output, not to make the test finish (either as pass or fail).

And in order to flush any outstanding output, we need to quit any lingering child processes. The other consequence of doing that is that the main test might now be able to continue and possibly finish. In that scenario, you have earlier raised a question on whether we should consider that pass or fail. I said originally, that it should pass (assuming the test's asserts all pass). However, the pass/fail issue was never at the issue here.

I really just wanted to unblock the error/output pipelines here of hanging processes that were about to timeout. So the effects of this fix would only apply to those tests that were about to time out anyhow.

I also was trying to make a point that this timeout, where we are missing possible outputs, affects random tests in a variety of components, so it's not possible to anticipate which ones would need this new feature, and I was trying to argue that we need it system wide, and I still think that.

We can introduce a switch that would make this optional, but that switch should affect ALL the tests.

On my part I don't understand why you both think that such approach should not be part of jtreg. The timeout mechanism itself is part of jtreg. I think it makes a perfect sense to extend it to terminate any hanging child processes (jtreg has a knowledge and a built-in mechanism for doing that, which would need to be re-implemented in any client using jtreg)

Can we continue discussing this?

On my part I will look into `@run driver` feature...

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

PR: https://git.openjdk.org/jtreg/pull/97

From stuefe at openjdk.org  Thu Dec  1 19:40:00 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Dec 2022 19:40:00 GMT
Subject: RFR: 7903217: jtreg could try killing descendants of stuck test, 
 before timing out the test [v4]
In-Reply-To: <YhSvKnd8sPLVvlOXC90BX_fSEqbNqouYlfyMzEWEjgA=.ae80fdb6-28f0-4cd8-aff7-08b9f2815090@github.com>
References: <EdrQ-aAmgSQVIN34XjqcMdlHJxpwhow0IDkxsBtGw-M=.6f881262-2039-49a7-8496-7f98caed6aa8@github.com>
 <XC6kJWG8Zr1D6mimhc79GUqMkUAqooy0eEmQEDi1JNM=.7c08d837-4599-402b-9c63-e6b5703fa7bb@github.com>
 <YhSvKnd8sPLVvlOXC90BX_fSEqbNqouYlfyMzEWEjgA=.ae80fdb6-28f0-4cd8-aff7-08b9f2815090@github.com>
Message-ID: <fOdUqRkv1bFD2UdzYXWGu-Nvao2Tsed5ybQ_9ifb-Vo=.5667b6af-7a75-49c4-b762-f610aef7687c@github.com>

On Thu, 1 Dec 2022 19:22:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> > _Mailing list message from [Jonathan Gibbons](mailto:jonathan.gibbons at oracle.com) on [jtreg-dev](mailto:jtreg-dev at mail.openjdk.org):_
> > On 11/17/22 12:50 PM, Gerard Ziemski wrote:
> > If it's not one test but many, that suggests putting the functionality in code in a test-library, that can be reused by any necessary tests.
> > Also, note the possibility of using `@run driver` which is intended as an extension mechanism for customized execution models, such as that you are describing. In conjunction with test library code, it allows you to have complex execution models, which can even be different for different kinds of tests.?? You described one particular model where a process might time out but the test should still be deemed to have passed;? that may be reasonable for the tests you have in mind, but it does not sound general enough or standard enough to be baked into mainline jtreg.
> > If you have trouble modelling the behavior you want in a test driver class, then that is a reason to come back here and propose or ask for any necessary enhancements.
> 
> The goal here was to "flush" any possible outstanding output, not to make the test finish (either as pass or fail).
> 
> And in order to flush any outstanding output, we need to quit any lingering child processes. The other consequence of doing that is that the main test might now be able to continue and possibly finish. In that scenario, you have earlier raised a question on whether we should consider that pass or fail. I said originally, that it should pass (assuming the test's asserts all pass). However, the pass/fail issue was never at the issue here.
> 
> I really just wanted to unblock the error/output pipelines here of hanging processes that were about to timeout. So the effects of this fix would only apply to those tests that were about to time out anyhow.
> 
> I also was trying to make a point that this timeout, where we are missing possible outputs, affects random tests in a variety of components, so it's not possible to anticipate which ones would need this new feature, and I was trying to argue that we need it system wide, and I still think that.
> 
> We can introduce a switch that would make this optional, but that switch should affect ALL the tests.
> 
> On my part I don't understand why you both think that such approach should not be part of jtreg. The timeout mechanism itself is part of jtreg. I think it makes a perfect sense to extend it to terminate any hanging child processes (jtreg has a knowledge and a built-in mechanism for doing that, which would need to be re-implemented in any client using jtreg)
> 
> Can we continue discussing this?
> 
> On my part I will look into `@run driver` feature...

Hi Gerard,

sorry for the delay.

I am fine with adding it to jtreg as an optional feature. I don't know enough about jtreg to review this in detail though.

What would be nice is if you were to send SIGQUIT to the processes which are java processes, to have a chance to get thread dumps.

Cheers, Thomas

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

PR: https://git.openjdk.org/jtreg/pull/97

From cstein at openjdk.org  Fri Dec  2 06:48:34 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 2 Dec 2022 06:48:34 GMT
Subject: RFR: 7903390: Summary reporter getter not thread-safe
Message-ID: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>

Prevent `ConcurrentModificationException` by making the two static methods that populate the instance map `synchronized`.

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

Commit messages:
 - 7903390: Summary reporter getter not thread-safe

Changes: https://git.openjdk.org/jtreg/pull/139/files
 Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=139&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903390
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/139.diff
  Fetch: git fetch https://git.openjdk.org/jtreg pull/139/head:pull/139

PR: https://git.openjdk.org/jtreg/pull/139

From dholmes at openjdk.org  Fri Dec  2 07:01:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Dec 2022 07:01:42 GMT
Subject: RFR: 7903390: Summary reporter getter not thread-safe
In-Reply-To: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
References: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
Message-ID: <s0ajKlAC6wPI5a2ZVoyJ4cNyYv7xiwqmPyDWbRG7jhE=.24f60b30-8dc5-4361-ba6b-85cdcfb7934a@github.com>

On Fri, 2 Dec 2022 06:41:42 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prevent `ConcurrentModificationException` by making the two static methods that populate the instance map `synchronized`.

Looks reasonable to me.

I have to be concerned about how this new found concurrency bug arises though - was one of the reporter types just added?

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

Marked as reviewed by dholmes (no project role).

PR: https://git.openjdk.org/jtreg/pull/139

From cstein at openjdk.org  Fri Dec  2 07:05:44 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 2 Dec 2022 07:05:44 GMT
Subject: RFR: 7903390: Summary reporter getter not thread-safe
In-Reply-To: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
References: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
Message-ID: <6gMSqn8jVwxRt5YJY_Vu0QnjMZrC_PBt_7fR-WCFX8o=.2a349a08-1fa5-4771-a6b6-f065264a60fa@github.com>

On Fri, 2 Dec 2022 06:41:42 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prevent `ConcurrentModificationException` by making the two static methods that populate the instance map `synchronized`.

Yes, a reporter for JUnit was added by https://github.com/openjdk/jtreg/commit/2bddb406f907072b6951b8b02a0c1a7cf640d7bf (https://bugs.openjdk.org/browse/CODETOOLS-7903264).

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

PR: https://git.openjdk.org/jtreg/pull/139

From dcubed at openjdk.org  Fri Dec  2 17:14:51 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 2 Dec 2022 17:14:51 GMT
Subject: RFR: 7903390: Summary reporter getter not thread-safe
In-Reply-To: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
References: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
Message-ID: <gDh51a10ZRpXsRR8gWch1Gu9tjvdea9TtwFRM6dypvQ=.549fc53e-c801-4662-858e-99b9ed451e77@github.com>

On Fri, 2 Dec 2022 06:41:42 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prevent `ConcurrentModificationException` by making the two static methods that populate the instance map `synchronized`.

Thumbs up!

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

Marked as reviewed by dcubed (no project role).

PR: https://git.openjdk.org/jtreg/pull/139

From jjg at openjdk.org  Fri Dec  2 17:23:44 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 2 Dec 2022 17:23:44 GMT
Subject: RFR: 7903390: Summary reporter getter not thread-safe
In-Reply-To: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
References: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
Message-ID: <GkLNYtdk7B3m56ehFYxHMBaWAH0I4vMh2zsJA-IuJr0=.7219dacf-fd82-4585-a6db-a230a0f21f37@github.com>

On Fri, 2 Dec 2022 06:41:42 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prevent `ConcurrentModificationException` by making the two static methods that populate the instance map `synchronized`.

Ideally we should have a test, but this might be a hard one to test

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

Marked as reviewed by jjg (Lead).

PR: https://git.openjdk.org/jtreg/pull/139

From cstein at openjdk.org  Fri Dec  2 18:20:23 2022
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 2 Dec 2022 18:20:23 GMT
Subject: Integrated: 7903390: Summary reporter getter not thread-safe
In-Reply-To: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
References: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
Message-ID: <whFJznoU-4lXe6-dH8VHZwGVqm6SL1nOEl8LQO_z2hg=.90555712-dade-4505-8e2e-13ca7ab6df63@github.com>

On Fri, 2 Dec 2022 06:41:42 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prevent `ConcurrentModificationException` by making the two static methods that populate the instance map `synchronized`.

This pull request has now been integrated.

Changeset: 16db696c
Author:    Christian Stein <cstein at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/16db696cae847fe16a55adccee9851c9c484cc08
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

7903390: Summary reporter getter not thread-safe

Reviewed-by: dholmes, dcubed, jjg

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

PR: https://git.openjdk.org/jtreg/pull/139

From jjg at openjdk.org  Fri Dec  2 19:50:55 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 2 Dec 2022 19:50:55 GMT
Subject: RFR: CODETOOLS-7903393: Compile jtreg with -g
Message-ID: <nFyqa_t3Osh2gHdGDot5rMjTWcOkD158UH9C_4s_WRY=.b92ff26d-1705-419d-8021-237eefbf16c2@github.com>

Please review a simple makefile change to compile jtreg with `-g`

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

Commit messages:
 - CODETOOLS-7903393: Compile jtreg with -g

Changes: https://git.openjdk.org/jtreg/pull/140/files
 Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=140&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903393
  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jtreg/pull/140.diff
  Fetch: git fetch https://git.openjdk.org/jtreg pull/140/head:pull/140

PR: https://git.openjdk.org/jtreg/pull/140

From dcubed at openjdk.org  Fri Dec  2 20:04:50 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 2 Dec 2022 20:04:50 GMT
Subject: RFR: 7903390: Summary reporter getter not thread-safe
In-Reply-To: <GkLNYtdk7B3m56ehFYxHMBaWAH0I4vMh2zsJA-IuJr0=.7219dacf-fd82-4585-a6db-a230a0f21f37@github.com>
References: <mPgRsilycMKNFfWowr_KreBwVJbidCo_9ja-ba5soWU=.df8ae40c-43d0-465c-929b-5d87e3066148@github.com>
 <GkLNYtdk7B3m56ehFYxHMBaWAH0I4vMh2zsJA-IuJr0=.7219dacf-fd82-4585-a6db-a230a0f21f37@github.com>
Message-ID: <PUms2EmdocA5eTwnV8bRRRq_1R5r0jmI4Bkqar2_rg0=.5c8db424-c169-4197-aa86-0dc7194f909c@github.com>

On Fri, 2 Dec 2022 17:21:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Prevent `ConcurrentModificationException` by making the two static methods that populate the instance map `synchronized`.
>
> Ideally we should have a test, but this might be a hard one to test

@jonathan-gibbons - So how do we get the fixed jtreg into use in the jdk/jdk CI?

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

PR: https://git.openjdk.org/jtreg/pull/139

From iris at openjdk.org  Fri Dec  2 20:29:50 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 2 Dec 2022 20:29:50 GMT
Subject: RFR: CODETOOLS-7903393: Compile jtreg with -g
In-Reply-To: <nFyqa_t3Osh2gHdGDot5rMjTWcOkD158UH9C_4s_WRY=.b92ff26d-1705-419d-8021-237eefbf16c2@github.com>
References: <nFyqa_t3Osh2gHdGDot5rMjTWcOkD158UH9C_4s_WRY=.b92ff26d-1705-419d-8021-237eefbf16c2@github.com>
Message-ID: <vBgSrWxs2YkeUjj3QTVFa2QAnk3vK_BFmvJgd7PChe0=.e0d2d5a1-2f0c-4870-946d-20ed9f53f82a@github.com>

On Fri, 2 Dec 2022 19:45:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple makefile change to compile jtreg with `-g`

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jtreg/pull/140

From jjg at openjdk.org  Fri Dec  2 21:42:31 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 2 Dec 2022 21:42:31 GMT
Subject: Integrated: CODETOOLS-7903393: Compile jtreg with -g
In-Reply-To: <nFyqa_t3Osh2gHdGDot5rMjTWcOkD158UH9C_4s_WRY=.b92ff26d-1705-419d-8021-237eefbf16c2@github.com>
References: <nFyqa_t3Osh2gHdGDot5rMjTWcOkD158UH9C_4s_WRY=.b92ff26d-1705-419d-8021-237eefbf16c2@github.com>
Message-ID: <W0sxK5t0x-08yk3tFqQpOgPZLxKvp9nNrZ5ephIVfrE=.1fb9b979-2e0e-481e-b803-80538d6184e1@github.com>

On Fri, 2 Dec 2022 19:45:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple makefile change to compile jtreg with `-g`

This pull request has now been integrated.

Changeset: 0bb8367d
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/0bb8367d17d4f83a83b2d680badb9c25011534d4
Stats:     8 lines in 1 file changed: 8 ins; 0 del; 0 mod

7903393: Compile jtreg with -g

Reviewed-by: iris

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

PR: https://git.openjdk.org/jtreg/pull/140

From cstein at openjdk.org  Mon Dec  5 19:51:53 2022
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 5 Dec 2022 19:51:53 GMT
Subject: RFR: 7903394: Update version to 7.1.1
Message-ID: <GVE3oRZ_UxxhOGZq8S33wXgA0LLa7rdlcRkoI6BfFGc=.efc3abc6-02a6-48a2-9f17-048e0794e847@github.com>

This PR updates jtreg's version to 7.1.1 and contains the cherry-picked bugfix for:
- [7903390: Summary reporter getter not thread-safe](https://github.com/openjdk/jtreg/commit/c7df9b59d243a8526de9121a2d58a90ef98fe034)

It also updates the CHANGELOG.md accordingly.

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

Commit messages:
 - 7903390: Summary reporter getter not thread-safe
 - 7903394: Update version to 7.1.1
 - 7903386: Update changelog for jtreg 7.1

Changes: https://git.openjdk.org/jtreg/pull/141/files
 Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=141&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903394
  Stats: 13 lines in 3 files changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jtreg/pull/141.diff
  Fetch: git fetch https://git.openjdk.org/jtreg pull/141/head:pull/141

PR: https://git.openjdk.org/jtreg/pull/141

From jjg at openjdk.org  Mon Dec  5 19:51:54 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 5 Dec 2022 19:51:54 GMT
Subject: RFR: 7903394: Update version to 7.1.1
In-Reply-To: <GVE3oRZ_UxxhOGZq8S33wXgA0LLa7rdlcRkoI6BfFGc=.efc3abc6-02a6-48a2-9f17-048e0794e847@github.com>
References: <GVE3oRZ_UxxhOGZq8S33wXgA0LLa7rdlcRkoI6BfFGc=.efc3abc6-02a6-48a2-9f17-048e0794e847@github.com>
Message-ID: <ogF6cWz23DOFf8eVk4JVzZYZ0EA335u80hkGxTOa1UU=.59cfc8dd-122d-40c7-897c-cf07d447277a@github.com>

On Mon, 5 Dec 2022 19:10:13 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR updates jtreg's version to 7.1.1 and contains the cherry-picked bugfix for:
> - [7903390: Summary reporter getter not thread-safe](https://github.com/openjdk/jtreg/commit/c7df9b59d243a8526de9121a2d58a90ef98fe034)
> 
> It also updates the CHANGELOG.md accordingly.

Looks good.

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

Marked as reviewed by jjg (Lead).

PR: https://git.openjdk.org/jtreg/pull/141

From cstein at openjdk.org  Tue Dec  6 10:19:41 2022
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 6 Dec 2022 10:19:41 GMT
Subject: Integrated: 7903394: Update version to 7.1.1
In-Reply-To: <GVE3oRZ_UxxhOGZq8S33wXgA0LLa7rdlcRkoI6BfFGc=.efc3abc6-02a6-48a2-9f17-048e0794e847@github.com>
References: <GVE3oRZ_UxxhOGZq8S33wXgA0LLa7rdlcRkoI6BfFGc=.efc3abc6-02a6-48a2-9f17-048e0794e847@github.com>
Message-ID: <XSINR-L46Wv1ySbxPr4U6tr1GVmTcmTGvE6DVbwltoM=.b16098b9-2cdd-4155-b69e-72910b6a2ce5@github.com>

On Mon, 5 Dec 2022 19:10:13 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR updates jtreg's version to 7.1.1 and contains the cherry-picked bugfix for:
> - [7903390: Summary reporter getter not thread-safe](https://github.com/openjdk/jtreg/commit/c7df9b59d243a8526de9121a2d58a90ef98fe034)
> 
> It also updates the CHANGELOG.md accordingly.

This pull request has now been integrated.

Changeset: 3ea7f9f8
Author:    Christian Stein <cstein at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/3ea7f9f8fe7389d0eadc8cd02df38431043dd6fe
Stats:     13 lines in 3 files changed: 9 ins; 0 del; 4 mod

7903394: Update version to 7.1.1
7903386: Update changelog for jtreg 7.1
7903390: Summary reporter getter not thread-safe

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jtreg/pull/141

From jjg at openjdk.org  Tue Dec  6 23:35:54 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Dec 2022 23:35:54 GMT
Subject: RFR: 7903373: Add ability to customize test execution using main
 wrapper plugin [v5]
In-Reply-To: <Cs23i9LvesVSH8QLJi9wJgZoDGbPBDgz_9CWdImWw_o=.13df4619-75c2-4c31-99a3-a081af939d73@github.com>
References: <W7YiZqRxZ7N-A0lk8e2NlEr4OgoTaBpdtu0gHt-zpb8=.08ae47e5-d8a1-49c6-89d1-27d3d18fa388@github.com>
 <Cs23i9LvesVSH8QLJi9wJgZoDGbPBDgz_9CWdImWw_o=.13df4619-75c2-4c31-99a3-a081af939d73@github.com>
Message-ID: <lqBiz0M9gQDw-7nqSC0EMpFqmjaK8qeXqt6QantqRkA=.99a2d1d8-944f-4927-b804-8ff96579b2f9@github.com>

On Thu, 10 Nov 2022 00:00:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The fix adds support of a plugin that customizes test execution.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty lines removed.

I think there should be more documentation for this feature, both internal and for end users.

Generally, I find the naming based on "main wrapper" and "custom main wrapper" to be confusing and/or misleading, although you might be able to work around that with better documentation.

At the core, the name `CustomMainWrapper` suggests a variant, perhaps a subtype, of `MainWrapper`, but that's not the case.`MainWrapper` delegates to `CustomMainWrapper`,
and (somewhat more weirdly) `MainActionHelper` uses `CustomMainWrapper` as well.

In fact, `CustomMainWrapper` doesn't seem to be a custom main-wrapper at all; it is really just a custom thread factory, as can be seen by the only uses in the two instances of the expression `CustomMainWrapper.getInstance(...).createThread()`.  Indeed, `createThread` is the only real abstract method on the interface; `setAction` is just there for use during initialization, since the instance of `CMW.getInstance` is discarded after a thread has been created.

In terms of documentation, I suggest:

* better, more accurate, more specific documentation on the new `CustomMainWrapper` class. In particular, this documentation should indicate that the class just provides the ability to specify a thread factory to be used by the standard `MainWrapper` class

* more info in the i18.properties file (which is used to generate the command-line help.)
 In particular, although I have not compiled and run the code, I suspect that the command-line help for the `-mainwrapper` option will look something like
       `-mw <classname>, -mainwrapper <classname>   Main wrapper classname.`
which is essentially content-free, giving no useful info at all to the reader

* in the tag spec, in the appropriate Appendix, you should list any system properties that are set during this feature.

src/share/classes/com/sun/javatest/regtest/agent/CustomMainWrapper.java line 38:

> 36: /**
> 37:  * Interface which should be implemented to customize execution of test.
> 38:  * It is used by main and driver actions to execute test.

This comment needs a lot of work. More than anywhere else, this seems like the place to document this feature.  In particular, the only aspect of the execution that can be customized is the thread that is created to run the test.

src/share/classes/com/sun/javatest/regtest/agent/CustomMainWrapper.java line 44:

> 42:         String[] args = mainWrapper.split(":", 2);
> 43:         String className = args[0];
> 44:         String actionName = args[1].split("=")[1];

It would help if somewhere there was a comment or info on the proposed format for the `mainWrapper` string, illustrating the use of the colon and equals separators.

I don't (yet) see the overall significance of `args[1]` beyond the `actionName`

src/share/classes/com/sun/javatest/regtest/agent/CustomMainWrapper.java line 61:

> 59:             Constructor<? extends CustomMainWrapper> ctor = clz.getDeclaredConstructor();
> 60:             CustomMainWrapper wrapper = ctor.newInstance();
> 61:             wrapper.setAction(actionName);

Is the `actionName` ever going to be useful?   Di you use it in the Loom implementation?  Why would the thread created by `createThread` depend on the difference between `main` and `driver` actions?

(In general, a `driver` action is handled much earlier in the execution, when `RegressionScript` decides what VM options (if any) should be used for the agent.

src/share/classes/com/sun/javatest/regtest/agent/CustomMainWrapper.java line 63:

> 61:             wrapper.setAction(actionName);
> 62:             return wrapper;
> 63:         } catch (Exception e) {

What's the rationale for catching all exceptions here, instead of just checked exceptions?

src/share/classes/com/sun/javatest/regtest/agent/CustomMainWrapper.java line 70:

> 68:     /**
> 69:      * This method should be implemented to run test task.
> 70:      * Default jtreg implementation is return new Thread(tg, task);

This line, about the default jtreg implementation, is confusing, because the default jtreg behavior is not an implementation of this class or method.

src/share/classes/com/sun/javatest/regtest/agent/CustomMainWrapper.java line 80:

> 78:      * @param actionName name of action
> 79:      */
> 80:     default void setAction(String actionName) {

The comment says "get information" but the method name is "setAction". What am I missing?

src/share/classes/com/sun/javatest/regtest/config/RegressionParameters.java line 634:

> 632: 
> 633:     private static final String CUSTOM_MAIN_WRAPPER = ".customMainWrapper";
> 634: 

maybe remove this blank line, to group the customMainWrapper properties together

src/share/classes/com/sun/javatest/regtest/exec/MainAction.java line 489:

> 487:         if (script.getCustomWrapperPath() != null) {
> 488:             javaProps.put(MainWrapper.MAIN_WRAPPER_PATH, script.getCustomWrapperPath());
> 489:         }

these properties should probably be documented in the appendix at the end of the tag spec

src/share/classes/com/sun/javatest/regtest/exec/MainAction.java line 630:

> 628:         Agent agent;
> 629:         try {
> 630:             String wrapper = script.getCustomWrapper() == null ? null : script.getCustomWrapper() + ":" + "action=" + this.getName();

Is this the other side of the parsing done in CustomMainWrapper:44?
Is there any need for the `action=` part of the string, since it does not appear to be checked later on

src/share/classes/com/sun/javatest/regtest/tool/i18n.properties line 177:

> 175: help.main.mw.desc=Main wrapper classname.
> 176: help.main.mwp.arg=<path>
> 177: help.main.mwp.desc=Specifies classspath with custom main wrapper implementation.

There should be more documentation, at least somewhere, about what this mechanism is for and how to use it.

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

PR: https://git.openjdk.org/jtreg/pull/136

From cstein at openjdk.org  Wed Dec  7 15:44:31 2022
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 7 Dec 2022 15:44:31 GMT
Subject: RFR: 7903397: Update changelog for jtreg 7.1.1
Message-ID: <bVPc8nJgsFX83vFxW1FOu762Q_Akz35nuIPFq_K6ehU=.2a5def81-4fb4-4be2-894a-2f3aaf816060@github.com>

Please review this commit that updates the changelog file to include a section for jtreg 7.1.1

It also adds the entry to the list of noteworthy unreleased changes of the upcoming jtreg 7.2 release.

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

Commit messages:
 - 7903397: Update changelog for jtreg 7.1.1

Changes: https://git.openjdk.org/jtreg/pull/142/files
 Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=142&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903397
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/142.diff
  Fetch: git fetch https://git.openjdk.org/jtreg pull/142/head:pull/142

PR: https://git.openjdk.org/jtreg/pull/142

From jjg at openjdk.org  Wed Dec  7 16:19:49 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Dec 2022 16:19:49 GMT
Subject: RFR: 7903397: Update changelog for jtreg 7.1.1
In-Reply-To: <bVPc8nJgsFX83vFxW1FOu762Q_Akz35nuIPFq_K6ehU=.2a5def81-4fb4-4be2-894a-2f3aaf816060@github.com>
References: <bVPc8nJgsFX83vFxW1FOu762Q_Akz35nuIPFq_K6ehU=.2a5def81-4fb4-4be2-894a-2f3aaf816060@github.com>
Message-ID: <l1xDogPqmSkZlyyGt9-z9lFz6skew_UyCT-sJDvDAfE=.78aecb8f-071d-4cbc-8d32-540981472924@github.com>

On Wed, 7 Dec 2022 15:36:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this commit that updates the changelog file to include a section for jtreg 7.1.1
> 
> It also adds the entry to the list of noteworthy unreleased changes of the upcoming jtreg 7.2 release.

The tags for 7.1.1 seem incorrect

CHANGELOG.md line 3:

> 1: 
> 2: 
> 3: ## [Unreleased](https://git.openjdk.org/jtreg/compare/7.1.1+1...master)

You dropped the `jtreg-` ... that seems wrong...

CHANGELOG.md line 8:

> 6:   * [CODETOOLS-7903390](https://bugs.openjdk.org/browse/CODETOOLS-7903390)
> 7: 
> 8: ## [7.1.1+1](https://git.openjdk.org/jtreg/compare/jtreg-7.1+1...7.1.1+1)

should there be a `jtreg-` after the `...`

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

Changes requested by jjg (Lead).

PR: https://git.openjdk.org/jtreg/pull/142

From jjg at openjdk.org  Wed Dec  7 22:51:11 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Dec 2022 22:51:11 GMT
Subject: RFR: CODETOOLS-7903398: Incorrect format for version in error message
Message-ID: <HzoeYtuqWPNFUEuAqrluvaoZ2nKm9v6W90KgfsPEZZQ=.41e886e1-1e1f-419b-ac7f-db1b9aae40b2@github.com>

Please review a simple update to use the new format for version strings, for use in an error message.

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

Commit messages:
 - CODETOOLS-7903398: Incorrect format for version in error message

Changes: https://git.openjdk.org/jtreg/pull/143/files
 Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=143&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903398
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/143.diff
  Fetch: git fetch https://git.openjdk.org/jtreg pull/143/head:pull/143

PR: https://git.openjdk.org/jtreg/pull/143

From cstein at openjdk.org  Thu Dec  8 02:36:29 2022
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 8 Dec 2022 02:36:29 GMT
Subject: RFR: CODETOOLS-7903398: Incorrect format for version in error
 message
In-Reply-To: <HzoeYtuqWPNFUEuAqrluvaoZ2nKm9v6W90KgfsPEZZQ=.41e886e1-1e1f-419b-ac7f-db1b9aae40b2@github.com>
References: <HzoeYtuqWPNFUEuAqrluvaoZ2nKm9v6W90KgfsPEZZQ=.41e886e1-1e1f-419b-ac7f-db1b9aae40b2@github.com>
Message-ID: <8iY7rukaoByGHTZS_NVdXiWzYsoj7AjZsmVW5Kxv1u4=.48920d76-9af2-4166-a379-087ac7f27e6d@github.com>

On Wed, 7 Dec 2022 22:46:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple update to use the new format for version strings, for use in an error message.

Looks good to me

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

Marked as reviewed by cstein (Committer).

PR: https://git.openjdk.org/jtreg/pull/143

From dzhang at openjdk.org  Thu Dec  8 06:41:16 2022
From: dzhang at openjdk.org (Dingli Zhang)
Date: Thu, 8 Dec 2022 06:41:16 GMT
Subject: RFR: 7903138: os.simpleArch is x64 for linux-riscv64 in @require
 context [v4]
In-Reply-To: <7QB5jCn0fkgPyd2JqXYfosAGmyocLID0z7dW_zWaYa8=.96b47cbb-550c-45b1-96fb-88bdcb92ed16@github.com>
References: <eiC8QuVInYOP6q9IDsakQGTfY3p5efP2OQTwKuc3VV0=.871e27a7-cd2d-4963-8310-cd4527d55a57@github.com>
 <7QB5jCn0fkgPyd2JqXYfosAGmyocLID0z7dW_zWaYa8=.96b47cbb-550c-45b1-96fb-88bdcb92ed16@github.com>
Message-ID: <uAQinIjnnkh1h9TH6PuEd2Vej7R2bp-ZOwvXrfFO0sU=.633e278e-2060-43bc-896d-f210eea4ccef@github.com>

On Tue, 17 May 2022 02:34:22 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> RISC-V Port has been integrated into JDK mainline recently ([JDK-8276799](https://bugs.openjdk.java.net/browse/JDK-8276799)). Set simpleArch to riscv64 when os.arch is riscv64
>> 
>> Tested on  Linux riscv64. With the patch, [test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java](https://github.com/openjdk/jdk/blob/jdk-19%2B13/test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java) was successfully skipped.
>
> Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jtreg into riscv64-simplearch
>  - remove riscv in comment
>  - update comments
>  - os.simpleArch is x64 for linux-riscv64 in @require context

It's a very useful patch for me, thanks! : )

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

PR: https://git.openjdk.org/jtreg/pull/66

From cstein at openjdk.org  Thu Dec  8 12:21:55 2022
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 8 Dec 2022 12:21:55 GMT
Subject: RFR: 7903397: Update changelog for jtreg 7.1.1 [v2]
In-Reply-To: <bVPc8nJgsFX83vFxW1FOu762Q_Akz35nuIPFq_K6ehU=.2a5def81-4fb4-4be2-894a-2f3aaf816060@github.com>
References: <bVPc8nJgsFX83vFxW1FOu762Q_Akz35nuIPFq_K6ehU=.2a5def81-4fb4-4be2-894a-2f3aaf816060@github.com>
Message-ID: <_kXX6ypWrwY8L7zbih1ITZzh2NYRQAWkdIUmJ6cIjw8=.3ad860e4-36e5-4dea-bbb8-5be4e4dfcebf@github.com>

> Please review this commit that updates the changelog file to include a section for jtreg 7.1.1
> 
> It also adds the entry to the list of noteworthy unreleased changes of the upcoming jtreg 7.2 release.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Fix tag names

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/142/files
  - new: https://git.openjdk.org/jtreg/pull/142/files/e7b06032..b015d57e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=142&range=01
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=142&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/142.diff
  Fetch: git fetch https://git.openjdk.org/jtreg pull/142/head:pull/142

PR: https://git.openjdk.org/jtreg/pull/142

From cstein at openjdk.org  Thu Dec  8 12:21:58 2022
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 8 Dec 2022 12:21:58 GMT
Subject: RFR: 7903397: Update changelog for jtreg 7.1.1 [v2]
In-Reply-To: <l1xDogPqmSkZlyyGt9-z9lFz6skew_UyCT-sJDvDAfE=.78aecb8f-071d-4cbc-8d32-540981472924@github.com>
References: <bVPc8nJgsFX83vFxW1FOu762Q_Akz35nuIPFq_K6ehU=.2a5def81-4fb4-4be2-894a-2f3aaf816060@github.com>
 <l1xDogPqmSkZlyyGt9-z9lFz6skew_UyCT-sJDvDAfE=.78aecb8f-071d-4cbc-8d32-540981472924@github.com>
Message-ID: <O3fASZedx7Dq2At-2ButFOMkXEjnLX0Jqbj-VHGpjp8=.fe394793-d279-4bf2-abce-eda1b9b207a9@github.com>

On Wed, 7 Dec 2022 16:14:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix tag names
>
> CHANGELOG.md line 3:
> 
>> 1: 
>> 2: 
>> 3: ## [Unreleased](https://git.openjdk.org/jtreg/compare/7.1.1+1...master)
> 
> You dropped the `jtreg-` ... that seems wrong...

Fixed.

> CHANGELOG.md line 8:
> 
>> 6:   * [CODETOOLS-7903390](https://bugs.openjdk.org/browse/CODETOOLS-7903390)
>> 7: 
>> 8: ## [7.1.1+1](https://git.openjdk.org/jtreg/compare/jtreg-7.1+1...7.1.1+1)
> 
> should there be a `jtreg-` after the `...`

Fixed.

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

PR: https://git.openjdk.org/jtreg/pull/142

From fjiang at openjdk.org  Sat Dec 10 14:56:14 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sat, 10 Dec 2022 14:56:14 GMT
Subject: RFR: 7903138: os.simpleArch is x64 for linux-riscv64 in @require
 context [v5]
In-Reply-To: <eiC8QuVInYOP6q9IDsakQGTfY3p5efP2OQTwKuc3VV0=.871e27a7-cd2d-4963-8310-cd4527d55a57@github.com>
References: <eiC8QuVInYOP6q9IDsakQGTfY3p5efP2OQTwKuc3VV0=.871e27a7-cd2d-4963-8310-cd4527d55a57@github.com>
Message-ID: <99QfW5Chn3J9o1QVLY3VX-EE5UNDC17kdHMBdH4RRLs=.00a2539c-3773-4e5a-bb51-a43a64c5639a@github.com>

> RISC-V Port has been integrated into JDK mainline recently ([JDK-8276799](https://bugs.openjdk.java.net/browse/JDK-8276799)). Set simpleArch to riscv64 when os.arch is riscv64
> 
> Tested on  Linux riscv64. With the patch, [test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java](https://github.com/openjdk/jdk/blob/jdk-19%2B13/test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java) was successfully skipped.

Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' of https://github.com/openjdk/jtreg into riscv64-simplearch
 - Merge branch 'master' of https://github.com/openjdk/jtreg into riscv64-simplearch
 - remove riscv in comment
 - update comments
 - os.simpleArch is x64 for linux-riscv64 in @require context

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

Changes: https://git.openjdk.org/jtreg/pull/66/files
 Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=66&range=04
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jtreg/pull/66.diff
  Fetch: git fetch https://git.openjdk.org/jtreg pull/66/head:pull/66

PR: https://git.openjdk.org/jtreg/pull/66

From fjiang at openjdk.org  Sat Dec 10 14:56:14 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sat, 10 Dec 2022 14:56:14 GMT
Subject: RFR: 7903138: os.simpleArch is x64 for linux-riscv64 in @require
 context [v5]
In-Reply-To: <99QfW5Chn3J9o1QVLY3VX-EE5UNDC17kdHMBdH4RRLs=.00a2539c-3773-4e5a-bb51-a43a64c5639a@github.com>
References: <eiC8QuVInYOP6q9IDsakQGTfY3p5efP2OQTwKuc3VV0=.871e27a7-cd2d-4963-8310-cd4527d55a57@github.com>
 <99QfW5Chn3J9o1QVLY3VX-EE5UNDC17kdHMBdH4RRLs=.00a2539c-3773-4e5a-bb51-a43a64c5639a@github.com>
Message-ID: <BpxDDs1riHhpurA1--L5AZIXNs0_gRVuRZ8DLd4ljTA=.2441ce98-0e97-47a8-a502-416d2a609fc1@github.com>

On Sat, 10 Dec 2022 14:50:07 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> RISC-V Port has been integrated into JDK mainline recently ([JDK-8276799](https://bugs.openjdk.java.net/browse/JDK-8276799)). Set simpleArch to riscv64 when os.arch is riscv64
>> 
>> Tested on  Linux riscv64. With the patch, [test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java](https://github.com/openjdk/jdk/blob/jdk-19%2B13/test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java) was successfully skipped.
>
> Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jtreg into riscv64-simplearch
>  - Merge branch 'master' of https://github.com/openjdk/jtreg into riscv64-simplearch
>  - remove riscv in comment
>  - update comments
>  - os.simpleArch is x64 for linux-riscv64 in @require context

Merged master, could someone help me to sponsor this PR?

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

PR: https://git.openjdk.org/jtreg/pull/66

From jjg at openjdk.org  Sat Dec 10 18:31:19 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 10 Dec 2022 18:31:19 GMT
Subject: RFR: 7903138: os.simpleArch is x64 for linux-riscv64 in @require
 context [v5]
In-Reply-To: <99QfW5Chn3J9o1QVLY3VX-EE5UNDC17kdHMBdH4RRLs=.00a2539c-3773-4e5a-bb51-a43a64c5639a@github.com>
References: <eiC8QuVInYOP6q9IDsakQGTfY3p5efP2OQTwKuc3VV0=.871e27a7-cd2d-4963-8310-cd4527d55a57@github.com>
 <99QfW5Chn3J9o1QVLY3VX-EE5UNDC17kdHMBdH4RRLs=.00a2539c-3773-4e5a-bb51-a43a64c5639a@github.com>
Message-ID: <sSrSoM66fN8DzJ_lBUgW2RxjGpGxhgurs-geY5f2kKI=.dabc6294-2187-4a49-9b1a-90cb5ad2effc@github.com>

On Sat, 10 Dec 2022 14:56:14 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> RISC-V Port has been integrated into JDK mainline recently ([JDK-8276799](https://bugs.openjdk.java.net/browse/JDK-8276799)). Set simpleArch to riscv64 when os.arch is riscv64
>> 
>> Tested on  Linux riscv64. With the patch, [test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java](https://github.com/openjdk/jdk/blob/jdk-19%2B13/test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java) was successfully skipped.
>
> Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jtreg into riscv64-simplearch
>  - Merge branch 'master' of https://github.com/openjdk/jtreg into riscv64-simplearch
>  - remove riscv in comment
>  - update comments
>  - os.simpleArch is x64 for linux-riscv64 in @require context

Skara has dropped the `sponsor` label.

@feilongjiang needs to enter `/integrate` again, before this can be sponsored.

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

PR: https://git.openjdk.org/jtreg/pull/66

From fjiang at openjdk.org  Mon Dec 12 02:10:47 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 12 Dec 2022 02:10:47 GMT
Subject: RFR: 7903138: os.simpleArch is x64 for linux-riscv64 in @require
 context [v5]
In-Reply-To: <sSrSoM66fN8DzJ_lBUgW2RxjGpGxhgurs-geY5f2kKI=.dabc6294-2187-4a49-9b1a-90cb5ad2effc@github.com>
References: <eiC8QuVInYOP6q9IDsakQGTfY3p5efP2OQTwKuc3VV0=.871e27a7-cd2d-4963-8310-cd4527d55a57@github.com>
 <99QfW5Chn3J9o1QVLY3VX-EE5UNDC17kdHMBdH4RRLs=.00a2539c-3773-4e5a-bb51-a43a64c5639a@github.com>
 <sSrSoM66fN8DzJ_lBUgW2RxjGpGxhgurs-geY5f2kKI=.dabc6294-2187-4a49-9b1a-90cb5ad2effc@github.com>
Message-ID: <LM2xUeHfc_mQ6FGFwzNurG-IMiT92puhtv2O0oSjQHM=.7aa98129-2905-4162-9e6d-4d26a7bb3f05@github.com>

On Sat, 10 Dec 2022 18:28:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Skara has dropped the `sponsor` label.
> 
> @feilongjiang needs to enter `/integrate` again, before this can be sponsored.

Hi @jonathan-gibbons, `sponsor` is back, could you please sponsor this PR?

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

PR: https://git.openjdk.org/jtreg/pull/66

From duke at openjdk.org  Mon Dec 19 06:46:06 2022
From: duke at openjdk.org (Jan Kratochvil)
Date: Mon, 19 Dec 2022 06:46:06 GMT
Subject: RFR: 7903191: Fix build with "MAKEFLAGS=-j32". [v4]
In-Reply-To: <nbcXhX3Wj-2-J3x0SYcgBooLnWbjQUVFWNHOwLPOl2Q=.f8f072c1-ec69-4ca8-997c-23856109fbd4@github.com>
References: <6uobKd-93s4HhfaGizx9KIx5b0wintpeeEEWwNbOebk=.dda8c3c9-7e4d-413c-9360-a712e973636e@github.com>
 <nbcXhX3Wj-2-J3x0SYcgBooLnWbjQUVFWNHOwLPOl2Q=.f8f072c1-ec69-4ca8-997c-23856109fbd4@github.com>
Message-ID: <TVKmTYQC-yDWwvMCCIeofqxYvGXVD46f7YHWDwoysUY=.68c3a255-ee68-4abd-a371-15d381c04ab4@github.com>

On Fri, 23 Sep 2022 17:31:06 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

>> A parallel build needlessly errors out:
>
> Jan Kratochvil has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fix build with "MAKEFLAGS=-j32".
>   
>   /bin/sh: line 5: jtreg/build/classes/com/sun/javatest/regtest/tool/jars.properties: No such file or directory
>   make: *** [jtreg.gmk:98: jtreg/build/classes/com/sun/javatest/regtest/tool/jars.properties] Error 1

The builds are still failing with commit 0bb8367d17d4f83a83b2d680badb9c25011534d4 = 2022-12-02

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

PR: https://git.openjdk.org/jtreg/pull/72

From gziemski at openjdk.org  Mon Dec 19 15:56:18 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 19 Dec 2022 15:56:18 GMT
Subject: RFR: 7903217: jtreg could try killing descendants of stuck test, 
 before timing out the test [v4]
In-Reply-To: <XC6kJWG8Zr1D6mimhc79GUqMkUAqooy0eEmQEDi1JNM=.7c08d837-4599-402b-9c63-e6b5703fa7bb@github.com>
References: <EdrQ-aAmgSQVIN34XjqcMdlHJxpwhow0IDkxsBtGw-M=.6f881262-2039-49a7-8496-7f98caed6aa8@github.com>
 <XC6kJWG8Zr1D6mimhc79GUqMkUAqooy0eEmQEDi1JNM=.7c08d837-4599-402b-9c63-e6b5703fa7bb@github.com>
Message-ID: <7tgctuzP50PlYu1SPaap-Ymskl6l-pd3D93NWjImSLk=.6b139305-6b97-4e5a-8b6e-ba3a6acc52e2@github.com>

On Mon, 22 Aug 2022 20:54:36 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is an enhancement that aims to improve the robustness of the testing by attempting to quit any child processes (that are possibly stuck and are blocking the parent process from terminating) before timing out the target parent process.
>> 
>> Aborting a process will flush its stdout/stderr streams, which will hopefully get captured in the test's log and provide additional clues as to why a test was timing out.
>> 
>> This enhancement was locally tested with a handcrafted test that itself launched a child process that would get stuck on purpose and worked as intended.
>> 
>> Hopefully, this will help debug issues such as [JDK-8286345](https://bugs.openjdk.org/browse/JDK-8286345)
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   return exit code if we had to cancel any child processes

I'm going to withdraw this issue and see if I can do this with a custom timeout handler mechanism.

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

PR: https://git.openjdk.org/jtreg/pull/97

From gziemski at openjdk.org  Mon Dec 19 15:56:18 2022
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 19 Dec 2022 15:56:18 GMT
Subject: Withdrawn: 7903217: jtreg could try killing descendants of stuck test, 
 before timing out the test
In-Reply-To: <EdrQ-aAmgSQVIN34XjqcMdlHJxpwhow0IDkxsBtGw-M=.6f881262-2039-49a7-8496-7f98caed6aa8@github.com>
References: <EdrQ-aAmgSQVIN34XjqcMdlHJxpwhow0IDkxsBtGw-M=.6f881262-2039-49a7-8496-7f98caed6aa8@github.com>
Message-ID: <N8H8TTuodW4_NQ8p5JT3N9VvczqTvrq5ck3iRGVQ21k=.3b741add-11a0-417f-bbd7-d75b361e0809@github.com>

On Thu, 28 Jul 2022 18:58:41 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> This is an enhancement that aims to improve the robustness of the testing by attempting to quit any child processes (that are possibly stuck and are blocking the parent process from terminating) before timing out the target parent process.
> 
> Aborting a process will flush its stdout/stderr streams, which will hopefully get captured in the test's log and provide additional clues as to why a test was timing out.
> 
> This enhancement was locally tested with a handcrafted test that itself launched a child process that would get stuck on purpose and worked as intended.
> 
> Hopefully, this will help debug issues such as [JDK-8286345](https://bugs.openjdk.org/browse/JDK-8286345)

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jtreg/pull/97