From duke at openjdk.org  Mon Jan  1 20:09:04 2024
From: duke at openjdk.org (duke)
Date: Mon, 1 Jan 2024 20:09:04 GMT
Subject: Withdrawn: 7903289: the option '-tagspec' in jtreg doesn't work as
 expected
In-Reply-To: <HdNw9gje0vBQyRcxgYzGod3qlUicWUGuJllS3iqmfjE=.4f3fe23f-4e09-4f46-873d-1ff0b5f23ebc@github.com>
References: <HdNw9gje0vBQyRcxgYzGod3qlUicWUGuJllS3iqmfjE=.4f3fe23f-4e09-4f46-873d-1ff0b5f23ebc@github.com>
Message-ID: <yPkhQxCrukLCun38HAgCc2hk1NNGpGIN5BfN0Ziy9H8=.b8a73a9c-0e93-4af9-b1eb-b9de1318141f@github.com>

On Wed, 7 Sep 2022 13:02:50 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> When using the command `jtreg -tagspec`, jtreg replies `The Tag Specification is not available`. It is because the file `tag-spec.txt` has not exsited after commit [ae6b9001](https://github.com/openjdk/jtreg/commit/ae6b9001). This patch fixes it by providing the `tag-spec.html` file link.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Jan  1 20:12:03 2024
From: duke at openjdk.org (duke)
Date: Mon, 1 Jan 2024 20:12:03 GMT
Subject: Withdrawn: 7902831: Provide way to isolate tests from general
 concurrency
In-Reply-To: <vEk5Qls3hV4XK41eD4gRE7opZVqnKW9xbtybHHZsq_A=.c5963ba1-33f9-4702-b3f4-0c704823fe5c@github.com>
References: <vEk5Qls3hV4XK41eD4gRE7opZVqnKW9xbtybHHZsq_A=.c5963ba1-33f9-4702-b3f4-0c704823fe5c@github.com>
Message-ID: <6rtFC5t2jToJ82cQ-eku3m8LzMAKbG5Inmv2Sok-zmw=.262ad1b6-5e0b-4ff5-a49d-1018c6b3c8e1@github.com>

On Thu, 18 Feb 2021 20:13:20 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> a prototype solution of [CODETOOLS-7902831](https://bugs.openjdk.java.net/browse/CODETOOLS-7902831) which changes `exclusiveAccess` tests to behave like "nonconcurrent" tests, i.e. to be isolated from concurrent execution with any other tests. the prototype uses a read-write lock to achive that.

This pull request has been closed without being integrated.

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

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

From lmesnik at openjdk.org  Thu Jan  4 02:59:47 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 4 Jan 2024 02:59:47 GMT
Subject: RFR: 7903526: jtreg should handle all exceptions [v2]
In-Reply-To: <bmoSpd2TA6zdVPb9nmfvtIr5RW-X2uKMAFLchzT9GnU=.56692b21-b635-4c26-b6bc-351de3801847@github.com>
References: <svRj9A_ltUB5I9sJX_YMiXjOTyOWzTbQ89A7qHTiVSc=.0c7a4807-dea4-4897-800d-5b24eb44bed2@github.com>
 <bmoSpd2TA6zdVPb9nmfvtIr5RW-X2uKMAFLchzT9GnU=.56692b21-b635-4c26-b6bc-351de3801847@github.com>
Message-ID: <Te0iTqPIIzO0PPHTEMAvswxQDzKuLX0vCo7RNyumrKw=.a5ac28cd-e7ae-40da-98a8-10c013a6329e@github.com>

On Tue, 31 Oct 2023 20:02:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Currently, jtreg executes a test in MainThreadGroup and checks uncaught exceptions for this group. So it handles all exceptions if the test doesn't create new thread groups.
>> However, the virtual threads don't belong to MainThreadGroup and jtreg silently ignores all exceptions thrown by virtual threads.
>> 
>> The testing shows that we have already some problems in jdk/jdk and probably in UR releases. There are 13 test failures in tier1 and several tens in the execution of tests that use secutiry-manager and run with a virtual thread.
>> 
>> It wonder if it makes sense to have this check conditional using some java property and start fixing tests after jtreg is release and smoothly switch execution to the new version.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added sync ofr globalUncaughtThrowable.

any ideas about moving forward with this PR?

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

PR Comment: https://git.openjdk.org/jtreg/pull/172#issuecomment-1876242425

From jpai at openjdk.org  Fri Jan  5 01:43:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 Jan 2024 01:43:47 GMT
Subject: RFR: 7903580: Allow for re-attempting agent creation when an
 attempt fails [v7]
In-Reply-To: <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
 <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
Message-ID: <4_DzzeU42ZfUulqMDpLm9lMsx4tBo-RHZfzOs-eaTxU=.8dded060-a0dc-4bc6-a65a-7230b4948420@github.com>

On Thu, 7 Dec 2023 14:21:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/CODETOOLS-7903580?
>> 
>> Several times in our CI instances we have noticed that a test (action) fails because it is unable to create an `Agent` instance due to the socket connection not being established between the `AgentServer` and the `ServerSocket` running within the jtreg process. This causes the test itself to fail with `Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out`. It has also been noticed that most of the times this is intermittent and subsequent attempt for a different test (action) passes. 
>> 
>> The proposed change here introduces a new configuration parameter `--agent-attempts` under "Agent Pool Options", which allows for configuring the maximum number of attempts that are allowed for getting an agent for an action. This is an optional parameter and by default it has been set to a value of `2`, which by default then allows the agent creation to be retried once if the previous attempt fails. This then means that existing installations/usages of jtreg need not set a value for `--agent-attempts` to enroll for this feature. A value of `1` for this parameter implies that the agent creation attempt will be done only once, which is what currently happens in the absence of this proposed feature.
>> 
>> Inability to obtain an agent, for whatever reason, after attempting `--agent-attempts` times continues to result in test (action) failure, like it does today.
>> 
>> Some additional minor logging related changes have been done too, to help debugging some of the current observed failures.
>> 
>> This change has been tested in the following manners:
>> 
>> 1. This modified build of jtreg has been used to run tier1, tier2 and tier3 of JDK mainline and it has been verified that nothing regresses with this change. That however doesn't mean that agent creation re-attempt logic was tested in these runs (since the first attempt never failed).
>> 2. Locally this build was jtreg was additionally modified to selectively not connect to the `ServerSocket`'s port thus simulating a "Accept timed out" exception. That change then verified that the re-attempt logic does indeed correctly kick in and the test action passes after picking up the newly created agent.
>> 3. `--agent-attempts 1` was passed to the above modified build (from step 2) to verify that the re-attempt isn't attempted when `--agent-attempts 1` an...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments in faq

Please keep open, expecting further reviews.

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

PR Comment: https://git.openjdk.org/jtreg/pull/173#issuecomment-1877994061

From duke at openjdk.org  Mon Jan  8 23:29:51 2024
From: duke at openjdk.org (duke)
Date: Mon, 8 Jan 2024 23:29:51 GMT
Subject: Withdrawn: 7903011: Small tweaks to jtreg plugin documentation
In-Reply-To: <gSOXR5NHzAk8glfS5b9zxIjKgYlgZoAVH2hWYgkjxo4=.e7192fd1-3276-4f8e-afc0-066a3a7cb0ef@github.com>
References: <gSOXR5NHzAk8glfS5b9zxIjKgYlgZoAVH2hWYgkjxo4=.e7192fd1-3276-4f8e-afc0-066a3a7cb0ef@github.com>
Message-ID: <zoVezQ3GeiqnvJgYt7hAD5ZgTr6NGCIq6_FeaFxQAc8=.7a72b242-a3da-4787-a992-5ce41cf40637@github.com>

On Tue, 10 Aug 2021 09:06:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I fixed a couple of hiccups in the toplevel and plugin-level README (the issues are described in JBS).
> 
> The updated version of the document can be seen by visiting this branch:
> 
> https://github.com/mcimadamore/jtreg/tree/fix_readme

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.org  Thu Jan 11 21:47:54 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Jan 2024 21:47:54 GMT
Subject: RFR: CODETOOLS-7903622: Remove support for `jtdiff`
Message-ID: <Kn-3skAimKFKI1aZ2Up52JdSEBHaTmvFPCEJRP3u5Xc=.cca5d478-8853-4878-b2ac-b58c5dbae97f@github.com>

Please review a trivial PR to remove the code for the long-unused `jtdiff` utility.

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

Commit messages:
 - CODETOOLS-7903622: Remove support for `jtdiff`

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

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

From jjg at openjdk.org  Thu Jan 11 22:34:16 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Jan 2024 22:34:16 GMT
Subject: RFR: CODETOOLS-7903623: Test may fail depending on environment.
Message-ID: <Epq7dNDIoE48Qm3qy-DEQbE0FVJVhqW11_NMPFBQrDc=.10fba4d1-f262-4c77-bef8-8ecbb71848ab@github.com>

Please review a trivial patch to ignore the setting of `LC_CTYPE` (or lack thereof) when running the rerun tests.

For me, the variable is set in a terminal window in IDEA (and cannot be unset) and is not set in a normal Terminal window on macOS. The variable is not germane to the test and  is now ignored during the comparison.

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

Commit messages:
 - CODETOOLS-7903623: Test may fail depending on environment.

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

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

From iris at openjdk.org  Thu Jan 11 23:42:48 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 11 Jan 2024 23:42:48 GMT
Subject: RFR: CODETOOLS-7903623: Test may fail depending on environment.
In-Reply-To: <Epq7dNDIoE48Qm3qy-DEQbE0FVJVhqW11_NMPFBQrDc=.10fba4d1-f262-4c77-bef8-8ecbb71848ab@github.com>
References: <Epq7dNDIoE48Qm3qy-DEQbE0FVJVhqW11_NMPFBQrDc=.10fba4d1-f262-4c77-bef8-8ecbb71848ab@github.com>
Message-ID: <jPuiYhd50_R5LlYW8kSvq9vJjsQW7oy3JJ82FzxNgQ4=.2d1d97de-9765-47b2-82c2-a63bf3d63ba0@github.com>

On Thu, 11 Jan 2024 22:29:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial patch to ignore the setting of `LC_CTYPE` (or lack thereof) when running the rerun tests.
> 
> For me, the variable is set in a terminal window in IDEA (and cannot be unset) and is not set in a normal Terminal window on macOS. The variable is not germane to the test and  is now ignored during the comparison.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/179#pullrequestreview-1817023204

From jjg at openjdk.org  Thu Jan 11 23:51:47 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Jan 2024 23:51:47 GMT
Subject: Integrated: CODETOOLS-7903623: Test may fail depending on environment.
In-Reply-To: <Epq7dNDIoE48Qm3qy-DEQbE0FVJVhqW11_NMPFBQrDc=.10fba4d1-f262-4c77-bef8-8ecbb71848ab@github.com>
References: <Epq7dNDIoE48Qm3qy-DEQbE0FVJVhqW11_NMPFBQrDc=.10fba4d1-f262-4c77-bef8-8ecbb71848ab@github.com>
Message-ID: <l9KTN4hZcmjlSzx4mreFhPnJjp9XvizqA0u8ym_wf0s=.909f3b0a-52b1-448f-807a-944079aa6bc0@github.com>

On Thu, 11 Jan 2024 22:29:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial patch to ignore the setting of `LC_CTYPE` (or lack thereof) when running the rerun tests.
> 
> For me, the variable is set in a terminal window in IDEA (and cannot be unset) and is not set in a normal Terminal window on macOS. The variable is not germane to the test and  is now ignored during the comparison.

This pull request has now been integrated.

Changeset: 03d661d6
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/03d661d649fbf4d403972cf7c660bbeed9deb0d1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

7903623: Test may fail depending on environment.

Reviewed-by: iris

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

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

From iris at openjdk.org  Thu Jan 11 23:54:48 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 11 Jan 2024 23:54:48 GMT
Subject: RFR: CODETOOLS-7903622: Remove support for `jtdiff`
In-Reply-To: <Kn-3skAimKFKI1aZ2Up52JdSEBHaTmvFPCEJRP3u5Xc=.cca5d478-8853-4878-b2ac-b58c5dbae97f@github.com>
References: <Kn-3skAimKFKI1aZ2Up52JdSEBHaTmvFPCEJRP3u5Xc=.cca5d478-8853-4878-b2ac-b58c5dbae97f@github.com>
Message-ID: <IQ7pk50LWLsoJQ10U3bjgDtncKDHRWW6oq0s8oErsb4=.12b0d630-c89b-4646-8b18-aed1e8b377d9@github.com>

On Thu, 11 Jan 2024 21:42:19 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial PR to remove the code for the long-unused `jtdiff` utility.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/178#pullrequestreview-1817033996

From duke at openjdk.org  Fri Jan 12 12:20:51 2024
From: duke at openjdk.org (duke)
Date: Fri, 12 Jan 2024 12:20:51 GMT
Subject: Withdrawn: 7902831: Provide a way to isolate tests from general
 concurrency
In-Reply-To: <MO8fi5EayjHAyG0PMKehfLLs2qql1y89oPTiQdOngrg=.8cf77274-177e-4115-b0c3-41cf1559e967@github.com>
References: <MO8fi5EayjHAyG0PMKehfLLs2qql1y89oPTiQdOngrg=.8cf77274-177e-4115-b0c3-41cf1559e967@github.com>
Message-ID: <OJzqtZLSFCExxbsNUsB339EwoTAEQq911sX9psa03sc=.fccc0793-208e-4f3c-a382-bb3a7aabaeec@github.com>

On Mon, 29 Nov 2021 14:49:52 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> The PR expands the test isolation possibilities to the whole machine. Possibility to limit exclusiveness to the directory remains.
> There are two options now: "exclusiveAccess.dirs" (a directory list), and "exclusiveAccess.machine" (boolean).
> 
> The solution is based on the ReentrantReadWriteLock, Write lock is held by machine-exclusive executors while read lock is taken for directory-only and fully-concurrent tests. Directory-scoped isolation is achieved by an additional lock.
> 
> Testing: shell-based tests added, run locally.

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Fri Jan 12 15:58:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 12 Jan 2024 15:58:56 GMT
Subject: RFR: 7903624: Use openjdk.org instead of openjdk.java.net
Message-ID: <NEZZaL_genilLdlJ8N_Kh_7h5zRHwlnaFUt5hxzMxLQ=.2a3d90be-5336-4160-8dbf-c3b10861c704@github.com>

We should use openjdk.org instead of openjdk.java.net.

This bug was triggered by the fact that git.openjdk.java.net had problem resolving properly for GitHub Actions in the build script (and the theory is that git.openjdk.org would work better), but this should be fixed nevertheless.

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

Commit messages:
 - 7903624: Use openjdk.org instead of openjdk.java.net

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

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

From jjg at openjdk.org  Tue Jan 16 18:40:53 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Jan 2024 18:40:53 GMT
Subject: Integrated: CODETOOLS-7903622: Remove support for `jtdiff`
In-Reply-To: <Kn-3skAimKFKI1aZ2Up52JdSEBHaTmvFPCEJRP3u5Xc=.cca5d478-8853-4878-b2ac-b58c5dbae97f@github.com>
References: <Kn-3skAimKFKI1aZ2Up52JdSEBHaTmvFPCEJRP3u5Xc=.cca5d478-8853-4878-b2ac-b58c5dbae97f@github.com>
Message-ID: <F9JqpnvaiBHfdrPNNwDBIDE-5m5xK2KNw-R0uPvk_DE=.007b25f4-c4d8-4ae1-a4d7-a1c82c1494d0@github.com>

On Thu, 11 Jan 2024 21:42:19 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial PR to remove the code for the long-unused `jtdiff` utility.

This pull request has now been integrated.

Changeset: a8698b72
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/a8698b72b3695778c946752fe22c1f6fadfbe936
Stats:     3322 lines in 22 files changed: 0 ins; 3321 del; 1 mod

7903622: Remove support for `jtdiff`

Reviewed-by: iris

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

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

From jjg at openjdk.org  Tue Jan 16 18:54:52 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Jan 2024 18:54:52 GMT
Subject: RFR: CODETOOLS-7903568: Allow `-show:stream file.jtr`
In-Reply-To: <KFh-WZA_1LiRPaQ_J-pwUnPcmTuaRCN47pe3pamCpoU=.c59023d5-230d-4ff5-9682-faddbdb57a04@github.com>
References: <KFh-WZA_1LiRPaQ_J-pwUnPcmTuaRCN47pe3pamCpoU=.c59023d5-230d-4ff5-9682-faddbdb57a04@github.com>
Message-ID: <0TGJIn7Huz4tgyFswZ0MAJJ3DSwb60jCNeQMukpUuw0=.b0b263ed-fb7a-439f-898e-dc040f40d3f5@github.com>

On Fri, 8 Dec 2023 22:36:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to permit a new command-line form
> 
>      jtreg -show:stream path/to/test.jtr
> 
> Currently, the desired test can only be specified via the "standard" options for a test suite and path within a test suite.
> This change makes it possible to specify a single `.jtr` file directly. This may be particularly useful to extract the `rerun` output that is within each `.jtr` fie.

ping, to keep PR open

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

PR Comment: https://git.openjdk.org/jtreg/pull/176#issuecomment-1894329313

From jjg at openjdk.org  Tue Jan 16 18:56:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Jan 2024 18:56:13 GMT
Subject: RFR: CODETOOLS-7903604: Provide Build.java to (eventually) replace
 `build.sh`
Message-ID: <YAnEoeVuMvZwX5VAAy-W2Tw85QLdeQslApbg6mhh2Zk=.d3457dd8-237d-4766-88f6-34602d8e7b34@github.com>

Please review a new, alternative way to download the dependencies needed to build `jtreg`.

Currently, the generally recommended way to download or otherwise find the dependencies is to use the `make/build.sh` script.  This PR provides an essentially equivalent alternative written in Java: `make/Build.java`, which is a single source file and so can be run with the standard support for running single source file programs in the Java launcher.

    old: sh make/build.sh options...
    new: path/to/java make/Build.java options...

The configuration values are essentially the same; in particular, the default configuration values in `make/build-support/version-numbers` are exactly the same as for `build.sh`.  Configuration values may now also be given on the command-line or in a file specified on the command line. The primary configuration difference is that there is no longer support for downloading a version of JDK to build jtreg; the default is to use the same version of JDK as is used to run `Build.java` although an alternate version of JDK to build `jtreg` itself can be specified as an option to `Build.java`.

As with `build.sh`, the new `Build.java` writes and optionally executes a shell script to run `make` with variables set up to point to the local version of the dependencies. 

There is no change to the makefiles, or to the functionality of `jtreg` itself.

There are minor internal changes to the organization of the dependencies in the `build/deps` directory, and minor changes to the logging output written by the program.

The old `build.sh` and related shell files remain in place for now, but may be removed at some point in the future.

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

Commit messages:
 - Fix whitespace
 - address review feedback
 - collect all use of external commands and tools in a single new class `Tools` to facilitate use in different operating systems.
 - CODETOOLS-7903604: Provide Build.java to (eventually) replace `build.sh`.

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

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

From ihse at openjdk.org  Tue Jan 16 18:56:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 16 Jan 2024 18:56:20 GMT
Subject: RFR: CODETOOLS-7903604: Provide Build.java to (eventually) replace
 `build.sh`
In-Reply-To: <YAnEoeVuMvZwX5VAAy-W2Tw85QLdeQslApbg6mhh2Zk=.d3457dd8-237d-4766-88f6-34602d8e7b34@github.com>
References: <YAnEoeVuMvZwX5VAAy-W2Tw85QLdeQslApbg6mhh2Zk=.d3457dd8-237d-4766-88f6-34602d8e7b34@github.com>
Message-ID: <Y2PeiRbM_9njwFZcqpKTzqryUee4KJWGqlbEt2Nju2E=.052123df-446e-4ee7-b3b6-2dd7f347ecb1@github.com>

On Fri, 8 Dec 2023 23:20:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a new, alternative way to download the dependencies needed to build `jtreg`.
> 
> Currently, the generally recommended way to download or otherwise find the dependencies is to use the `make/build.sh` script.  This PR provides an essentially equivalent alternative written in Java: `make/Build.java`, which is a single source file and so can be run with the standard support for running single source file programs in the Java launcher.
> 
>     old: sh make/build.sh options...
>     new: path/to/java make/Build.java options...
> 
> The configuration values are essentially the same; in particular, the default configuration values in `make/build-support/version-numbers` are exactly the same as for `build.sh`.  Configuration values may now also be given on the command-line or in a file specified on the command line. The primary configuration difference is that there is no longer support for downloading a version of JDK to build jtreg; the default is to use the same version of JDK as is used to run `Build.java` although an alternate version of JDK to build `jtreg` itself can be specified as an option to `Build.java`.
> 
> As with `build.sh`, the new `Build.java` writes and optionally executes a shell script to run `make` with variables set up to point to the local version of the dependencies. 
> 
> There is no change to the makefiles, or to the functionality of `jtreg` itself.
> 
> There are minor internal changes to the organization of the dependencies in the `build/deps` directory, and minor changes to the logging output written by the program.
> 
> The old `build.sh` and related shell files remain in place for now, but may be removed at some point in the future.

make/Build.java line 824:

> 822:         void deleteDirectory(Path dir) throws Fault {
> 823:             if (isWindows) {
> 824:                 exec("rmdir", "\\Q", "\\S", dir.toString());

Options on Windows are like /S, not \S, right..?

make/Build.java line 879:

> 877:             config.out.flush();
> 878:             config.err.flush();
> 879: //            System.err.println("exec: " + cmd + " " + args);

Debug code

make/Build.java line 1605:

> 1603: 
> 1604:             try (PrintWriter out = new PrintWriter(Files.newBufferedWriter(file))) {
> 1605:                 out.println("#!/bin/sh");

Looks like a good place to use a text block instead...

make/Build.java line 1617:

> 1615:         }
> 1616:     }
> 1617: }

Why isn't jcheck complaining about the lack of newline at EOF? I thought it should do that.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/177#discussion_r1424142143
PR Review Comment: https://git.openjdk.org/jtreg/pull/177#discussion_r1424142990
PR Review Comment: https://git.openjdk.org/jtreg/pull/177#discussion_r1424147037
PR Review Comment: https://git.openjdk.org/jtreg/pull/177#discussion_r1424148183

From jjg at openjdk.org  Tue Jan 16 18:56:21 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Jan 2024 18:56:21 GMT
Subject: RFR: CODETOOLS-7903604: Provide Build.java to (eventually) replace
 `build.sh`
In-Reply-To: <Y2PeiRbM_9njwFZcqpKTzqryUee4KJWGqlbEt2Nju2E=.052123df-446e-4ee7-b3b6-2dd7f347ecb1@github.com>
References: <YAnEoeVuMvZwX5VAAy-W2Tw85QLdeQslApbg6mhh2Zk=.d3457dd8-237d-4766-88f6-34602d8e7b34@github.com>
 <Y2PeiRbM_9njwFZcqpKTzqryUee4KJWGqlbEt2Nju2E=.052123df-446e-4ee7-b3b6-2dd7f347ecb1@github.com>
Message-ID: <dEGgisTkPigJ4rp_I4JTTdPdw1nBw1yhsNvzc1RrMCg=.8dc6a6b7-db03-4bab-9ad7-df8ffb3a8077@github.com>

On Tue, 12 Dec 2023 15:10:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review a new, alternative way to download the dependencies needed to build `jtreg`.
>> 
>> Currently, the generally recommended way to download or otherwise find the dependencies is to use the `make/build.sh` script.  This PR provides an essentially equivalent alternative written in Java: `make/Build.java`, which is a single source file and so can be run with the standard support for running single source file programs in the Java launcher.
>> 
>>     old: sh make/build.sh options...
>>     new: path/to/java make/Build.java options...
>> 
>> The configuration values are essentially the same; in particular, the default configuration values in `make/build-support/version-numbers` are exactly the same as for `build.sh`.  Configuration values may now also be given on the command-line or in a file specified on the command line. The primary configuration difference is that there is no longer support for downloading a version of JDK to build jtreg; the default is to use the same version of JDK as is used to run `Build.java` although an alternate version of JDK to build `jtreg` itself can be specified as an option to `Build.java`.
>> 
>> As with `build.sh`, the new `Build.java` writes and optionally executes a shell script to run `make` with variables set up to point to the local version of the dependencies. 
>> 
>> There is no change to the makefiles, or to the functionality of `jtreg` itself.
>> 
>> There are minor internal changes to the organization of the dependencies in the `build/deps` directory, and minor changes to the logging output written by the program.
>> 
>> The old `build.sh` and related shell files remain in place for now, but may be removed at some point in the future.
>
> make/Build.java line 1605:
> 
>> 1603: 
>> 1604:             try (PrintWriter out = new PrintWriter(Files.newBufferedWriter(file))) {
>> 1605:                 out.println("#!/bin/sh");
> 
> Looks like a good place to use a text block instead...

1. The code is currently targeted as JDK 12 or later, so no text blocks.
2. More significantly, the computation on line 1606 (for the directory) is incompatible with text blocks

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/177#discussion_r1424466194

From iris at openjdk.org  Thu Jan 18 17:19:40 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Jan 2024 17:19:40 GMT
Subject: RFR: CODETOOLS-7903568: Allow `-show:stream file.jtr`
In-Reply-To: <KFh-WZA_1LiRPaQ_J-pwUnPcmTuaRCN47pe3pamCpoU=.c59023d5-230d-4ff5-9682-faddbdb57a04@github.com>
References: <KFh-WZA_1LiRPaQ_J-pwUnPcmTuaRCN47pe3pamCpoU=.c59023d5-230d-4ff5-9682-faddbdb57a04@github.com>
Message-ID: <yDyddA_yHKgaq9vkchh3e5A_rFxmeQ0c8lUbN8nZH28=.c229fa0c-95f8-47c3-8464-a2d8d1b1f91b@github.com>

On Fri, 8 Dec 2023 22:36:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to permit a new command-line form
> 
>      jtreg -show:stream path/to/test.jtr
> 
> Currently, the desired test can only be specified via the "standard" options for a test suite and path within a test suite.
> This change makes it possible to specify a single `.jtr` file directly. This may be particularly useful to extract the `rerun` output that is within each `.jtr` fie.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jtreg/pull/176#pullrequestreview-1830202968

From iris at openjdk.org  Thu Jan 18 17:33:44 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Jan 2024 17:33:44 GMT
Subject: RFR: CODETOOLS-7903604: Provide Build.java to (eventually) replace
 `build.sh`
In-Reply-To: <YAnEoeVuMvZwX5VAAy-W2Tw85QLdeQslApbg6mhh2Zk=.d3457dd8-237d-4766-88f6-34602d8e7b34@github.com>
References: <YAnEoeVuMvZwX5VAAy-W2Tw85QLdeQslApbg6mhh2Zk=.d3457dd8-237d-4766-88f6-34602d8e7b34@github.com>
Message-ID: <FFK2bkg_B9L9NUiQHigua7qMHl8GpfDkftD6va5ICCQ=.6c91db32-eafd-4ada-9bba-f99b1e71fba5@github.com>

On Fri, 8 Dec 2023 23:20:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a new, alternative way to download the dependencies needed to build `jtreg`.
> 
> Currently, the generally recommended way to download or otherwise find the dependencies is to use the `make/build.sh` script.  This PR provides an essentially equivalent alternative written in Java: `make/Build.java`, which is a single source file and so can be run with the standard support for running single source file programs in the Java launcher.
> 
>     old: sh make/build.sh options...
>     new: path/to/java make/Build.java options...
> 
> The configuration values are essentially the same; in particular, the default configuration values in `make/build-support/version-numbers` are exactly the same as for `build.sh`.  Configuration values may now also be given on the command-line or in a file specified on the command line. The primary configuration difference is that there is no longer support for downloading a version of JDK to build jtreg; the default is to use the same version of JDK as is used to run `Build.java` although an alternate version of JDK to build `jtreg` itself can be specified as an option to `Build.java`.
> 
> As with `build.sh`, the new `Build.java` writes and optionally executes a shell script to run `make` with variables set up to point to the local version of the dependencies. 
> 
> There is no change to the makefiles, or to the functionality of `jtreg` itself.
> 
> There are minor internal changes to the organization of the dependencies in the `build/deps` directory, and minor changes to the logging output written by the program.
> 
> The old `build.sh` and related shell files remain in place for now, but may be removed at some point in the future.

make/Build.java line 32:

> 30: #
> 31: # The program can be executed directly as a single source-file program
> 32: # by the Java launcher, using JDK 12 or later.

Just curious... why JDK 12?  I presume there's a goal to use the oldest release possible and there's a feature you need in 12?

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/177#discussion_r1457775933

From jjg at openjdk.org  Thu Jan 18 17:43:39 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Jan 2024 17:43:39 GMT
Subject: Integrated: CODETOOLS-7903568: Allow `-show:stream file.jtr`
In-Reply-To: <KFh-WZA_1LiRPaQ_J-pwUnPcmTuaRCN47pe3pamCpoU=.c59023d5-230d-4ff5-9682-faddbdb57a04@github.com>
References: <KFh-WZA_1LiRPaQ_J-pwUnPcmTuaRCN47pe3pamCpoU=.c59023d5-230d-4ff5-9682-faddbdb57a04@github.com>
Message-ID: <Hzjz7McyMabUzZiDQlj7KZrU-7byfmkboueMHVWiZwE=.4fe089bf-3466-4cb5-95c1-6a99c3fdd841@github.com>

On Fri, 8 Dec 2023 22:36:40 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to permit a new command-line form
> 
>      jtreg -show:stream path/to/test.jtr
> 
> Currently, the desired test can only be specified via the "standard" options for a test suite and path within a test suite.
> This change makes it possible to specify a single `.jtr` file directly. This may be particularly useful to extract the `rerun` output that is within each `.jtr` fie.

This pull request has now been integrated.

Changeset: fcaa9e84
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/fcaa9e8484ca988c3c2532f88382a75060701eea
Stats:     132 lines in 4 files changed: 96 ins; 30 del; 6 mod

7903568: Allow `-show:stream file.jtr`

Reviewed-by: iris

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

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

From jjg at openjdk.org  Fri Jan 19 23:17:54 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Jan 2024 23:17:54 GMT
Subject: RFR: 7903580: Allow for re-attempting agent creation when an
 attempt fails [v7]
In-Reply-To: <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
 <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
Message-ID: <hJKfWh6pnKQ-X0ONpS1Gym7fOXGyMhWfoJwZI9apETw=.343698f7-bd90-43d0-9b63-781a6b255fc0@github.com>

On Thu, 7 Dec 2023 14:21:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/CODETOOLS-7903580?
>> 
>> Several times in our CI instances we have noticed that a test (action) fails because it is unable to create an `Agent` instance due to the socket connection not being established between the `AgentServer` and the `ServerSocket` running within the jtreg process. This causes the test itself to fail with `Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out`. It has also been noticed that most of the times this is intermittent and subsequent attempt for a different test (action) passes. 
>> 
>> The proposed change here introduces a new configuration parameter `--agent-attempts` under "Agent Pool Options", which allows for configuring the maximum number of attempts that are allowed for getting an agent for an action. This is an optional parameter and by default it has been set to a value of `2`, which by default then allows the agent creation to be retried once if the previous attempt fails. This then means that existing installations/usages of jtreg need not set a value for `--agent-attempts` to enroll for this feature. A value of `1` for this parameter implies that the agent creation attempt will be done only once, which is what currently happens in the absence of this proposed feature.
>> 
>> Inability to obtain an agent, for whatever reason, after attempting `--agent-attempts` times continues to result in test (action) failure, like it does today.
>> 
>> Some additional minor logging related changes have been done too, to help debugging some of the current observed failures.
>> 
>> This change has been tested in the following manners:
>> 
>> 1. This modified build of jtreg has been used to run tier1, tier2 and tier3 of JDK mainline and it has been verified that nothing regresses with this change. That however doesn't mean that agent creation re-attempt logic was tested in these runs (since the first attempt never failed).
>> 2. Locally this build was jtreg was additionally modified to selectively not connect to the `ServerSocket`'s port thus simulating a "Accept timed out" exception. That change then verified that the re-attempt logic does indeed correctly kick in and the test action passes after picking up the newly created agent.
>> 3. `--agent-attempts 1` was passed to the above modified build (from step 2) to verify that the re-attempt isn't attempted when `--agent-attempts 1` an...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments in faq

src/share/classes/com/sun/javatest/regtest/exec/Agent.java line 93:

> 91:     static final boolean showAgent = Flags.get("showAgent");
> 92:     static final boolean traceAgent = Flags.get("traceAgent");
> 93: 

(minor) suggest adding a comment that this is to allow running `jtreg` on older JDKs that do not support the `pid` method.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/173#discussion_r1459971635

From jjg at openjdk.org  Fri Jan 19 23:21:54 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Jan 2024 23:21:54 GMT
Subject: RFR: 7903580: Allow for re-attempting agent creation when an
 attempt fails [v7]
In-Reply-To: <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
 <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
Message-ID: <7TuYU1DwaiANFoPtrq61TaEceQOmMhUFiJnC_4RV_uQ=.6e31e1f9-2d81-4a84-bb75-e0d573715d0a@github.com>

On Thu, 7 Dec 2023 14:21:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/CODETOOLS-7903580?
>> 
>> Several times in our CI instances we have noticed that a test (action) fails because it is unable to create an `Agent` instance due to the socket connection not being established between the `AgentServer` and the `ServerSocket` running within the jtreg process. This causes the test itself to fail with `Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out`. It has also been noticed that most of the times this is intermittent and subsequent attempt for a different test (action) passes. 
>> 
>> The proposed change here introduces a new configuration parameter `--agent-attempts` under "Agent Pool Options", which allows for configuring the maximum number of attempts that are allowed for getting an agent for an action. This is an optional parameter and by default it has been set to a value of `2`, which by default then allows the agent creation to be retried once if the previous attempt fails. This then means that existing installations/usages of jtreg need not set a value for `--agent-attempts` to enroll for this feature. A value of `1` for this parameter implies that the agent creation attempt will be done only once, which is what currently happens in the absence of this proposed feature.
>> 
>> Inability to obtain an agent, for whatever reason, after attempting `--agent-attempts` times continues to result in test (action) failure, like it does today.
>> 
>> Some additional minor logging related changes have been done too, to help debugging some of the current observed failures.
>> 
>> This change has been tested in the following manners:
>> 
>> 1. This modified build of jtreg has been used to run tier1, tier2 and tier3 of JDK mainline and it has been verified that nothing regresses with this change. That however doesn't mean that agent creation re-attempt logic was tested in these runs (since the first attempt never failed).
>> 2. Locally this build was jtreg was additionally modified to selectively not connect to the `ServerSocket`'s port thus simulating a "Accept timed out" exception. That change then verified that the re-attempt logic does indeed correctly kick in and the test action passes after picking up the newly created agent.
>> 3. `--agent-attempts 1` was passed to the above modified build (from step 2) to verify that the re-attempt isn't attempted when `--agent-attempts 1` an...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments in faq

Nice.

The FAQ entry is a nice addition, to explain the typical reason that launching an agent might fail, and so why it is reasonable to have a retry count.

src/share/doc/javatest/regtest/faq.md line 714:

> 712: This default behaviour can be overridden by passing the `--agent-attempts` option
> 713: to `jtreg` command. This option takes an integer value which represents the number
> 714: of attempts JTReg is allowed to make when attempting to get a agent for a test

(minor) remove `JTReg is allowed` so that it reads "the number of attempts to make..."

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

Marked as reviewed by jjg (Lead).

PR Review: https://git.openjdk.org/jtreg/pull/173#pullrequestreview-1833936131
PR Review Comment: https://git.openjdk.org/jtreg/pull/173#discussion_r1459975845

From jpai at openjdk.org  Sat Jan 20 01:14:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Jan 2024 01:14:06 GMT
Subject: RFR: 7903580: Allow for re-attempting agent creation when an
 attempt fails [v8]
In-Reply-To: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
Message-ID: <boWfu7snr1vEtLK-YpUu-ahM7bskYq4tvxvAZjf2YM8=.b56b14d8-c777-4cf2-8f9e-541492bf5cb6@github.com>

> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/CODETOOLS-7903580?
> 
> Several times in our CI instances we have noticed that a test (action) fails because it is unable to create an `Agent` instance due to the socket connection not being established between the `AgentServer` and the `ServerSocket` running within the jtreg process. This causes the test itself to fail with `Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out`. It has also been noticed that most of the times this is intermittent and subsequent attempt for a different test (action) passes. 
> 
> The proposed change here introduces a new configuration parameter `--agent-attempts` under "Agent Pool Options", which allows for configuring the maximum number of attempts that are allowed for getting an agent for an action. This is an optional parameter and by default it has been set to a value of `2`, which by default then allows the agent creation to be retried once if the previous attempt fails. This then means that existing installations/usages of jtreg need not set a value for `--agent-attempts` to enroll for this feature. A value of `1` for this parameter implies that the agent creation attempt will be done only once, which is what currently happens in the absence of this proposed feature.
> 
> Inability to obtain an agent, for whatever reason, after attempting `--agent-attempts` times continues to result in test (action) failure, like it does today.
> 
> Some additional minor logging related changes have been done too, to help debugging some of the current observed failures.
> 
> This change has been tested in the following manners:
> 
> 1. This modified build of jtreg has been used to run tier1, tier2 and tier3 of JDK mainline and it has been verified that nothing regresses with this change. That however doesn't mean that agent creation re-attempt logic was tested in these runs (since the first attempt never failed).
> 2. Locally this build was jtreg was additionally modified to selectively not connect to the `ServerSocket`'s port thus simulating a "Accept timed out" exception. That change then verified that the re-attempt logic does indeed correctly kick in and the test action passes after picking up the newly created agent.
> 3. `--agent-attempts 1` was passed to the above modified build (from step 2) to verify that the re-attempt isn't attempted when `--agent-attempts 1` and the test fails as currently ...

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - update faq entry
 - Jon's review comment - add a code comment about pid() usage

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

Changes:
  - all: https://git.openjdk.org/jtreg/pull/173/files
  - new: https://git.openjdk.org/jtreg/pull/173/files/18667904..50534b94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=173&range=07
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=173&range=06-07

  Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jtreg/pull/173.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/173/head:pull/173

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

From jpai at openjdk.org  Sat Jan 20 01:14:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Jan 2024 01:14:06 GMT
Subject: RFR: 7903580: Allow for re-attempting agent creation when an
 attempt fails [v7]
In-Reply-To: <hJKfWh6pnKQ-X0ONpS1Gym7fOXGyMhWfoJwZI9apETw=.343698f7-bd90-43d0-9b63-781a6b255fc0@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
 <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
 <hJKfWh6pnKQ-X0ONpS1Gym7fOXGyMhWfoJwZI9apETw=.343698f7-bd90-43d0-9b63-781a6b255fc0@github.com>
Message-ID: <p6kDO9kV3iN3K1MJRmxZnh4NuCRVsCJiebKA2c7hN84=.383f9c7a-a403-47aa-8546-fc17d226c866@github.com>

On Fri, 19 Jan 2024 23:14:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comments in faq
>
> src/share/classes/com/sun/javatest/regtest/exec/Agent.java line 93:
> 
>> 91:     static final boolean showAgent = Flags.get("showAgent");
>> 92:     static final boolean traceAgent = Flags.get("traceAgent");
>> 93: 
> 
> (minor) suggest adding a comment that this is to allow running `jtreg` on older JDKs that do not support the `pid` method.

Done - I've updated the PR to include a code comment for this line.

> src/share/doc/javatest/regtest/faq.md line 714:
> 
>> 712: This default behaviour can be overridden by passing the `--agent-attempts` option
>> 713: to `jtreg` command. This option takes an integer value which represents the number
>> 714: of attempts JTReg is allowed to make when attempting to get a agent for a test
> 
> (minor) remove `JTReg is allowed` so that it reads "the number of attempts to make..."

Done, updated the PR to remove that part.

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

PR Review Comment: https://git.openjdk.org/jtreg/pull/173#discussion_r1460109855
PR Review Comment: https://git.openjdk.org/jtreg/pull/173#discussion_r1460109556

From jpai at openjdk.org  Sat Jan 20 01:16:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Jan 2024 01:16:55 GMT
Subject: RFR: 7903580: Allow for re-attempting agent creation when an
 attempt fails [v7]
In-Reply-To: <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
 <6D0bwHfSyDAqegjZpf51zkOjYU2rIITYlDi5-Y98yqY=.0d16c20a-1dc4-4bcc-9458-f7cbba0f5e99@github.com>
Message-ID: <RUOFGT1bCt-xWWoT9gTaUxS4Q8nbrDI0x5npx7Xt3EM=.cc14c24b-f005-49b1-8550-79d247b54015@github.com>

On Thu, 7 Dec 2023 14:21:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/CODETOOLS-7903580?
>> 
>> Several times in our CI instances we have noticed that a test (action) fails because it is unable to create an `Agent` instance due to the socket connection not being established between the `AgentServer` and the `ServerSocket` running within the jtreg process. This causes the test itself to fail with `Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out`. It has also been noticed that most of the times this is intermittent and subsequent attempt for a different test (action) passes. 
>> 
>> The proposed change here introduces a new configuration parameter `--agent-attempts` under "Agent Pool Options", which allows for configuring the maximum number of attempts that are allowed for getting an agent for an action. This is an optional parameter and by default it has been set to a value of `2`, which by default then allows the agent creation to be retried once if the previous attempt fails. This then means that existing installations/usages of jtreg need not set a value for `--agent-attempts` to enroll for this feature. A value of `1` for this parameter implies that the agent creation attempt will be done only once, which is what currently happens in the absence of this proposed feature.
>> 
>> Inability to obtain an agent, for whatever reason, after attempting `--agent-attempts` times continues to result in test (action) failure, like it does today.
>> 
>> Some additional minor logging related changes have been done too, to help debugging some of the current observed failures.
>> 
>> This change has been tested in the following manners:
>> 
>> 1. This modified build of jtreg has been used to run tier1, tier2 and tier3 of JDK mainline and it has been verified that nothing regresses with this change. That however doesn't mean that agent creation re-attempt logic was tested in these runs (since the first attempt never failed).
>> 2. Locally this build was jtreg was additionally modified to selectively not connect to the `ServerSocket`'s port thus simulating a "Accept timed out" exception. That change then verified that the re-attempt logic does indeed correctly kick in and the test action passes after picking up the newly created agent.
>> 3. `--agent-attempts 1` was passed to the above modified build (from step 2) to verify that the re-attempt isn't attempted when `--agent-attempts 1` an...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments in faq

Thank you both Jon and Christian for these reviews. I'll go ahead and integrate this today or tomorrow (once I run one more run in CI).

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

PR Comment: https://git.openjdk.org/jtreg/pull/173#issuecomment-1901542703

From jjg at openjdk.org  Sat Jan 20 17:17:53 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 20 Jan 2024 17:17:53 GMT
Subject: RFR: 7903580: Allow for re-attempting agent creation when an
 attempt fails [v8]
In-Reply-To: <boWfu7snr1vEtLK-YpUu-ahM7bskYq4tvxvAZjf2YM8=.b56b14d8-c777-4cf2-8f9e-541492bf5cb6@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
 <boWfu7snr1vEtLK-YpUu-ahM7bskYq4tvxvAZjf2YM8=.b56b14d8-c777-4cf2-8f9e-541492bf5cb6@github.com>
Message-ID: <gNPKev_hHpU5FQr-0Jm2sBrmPhr3KtOjC2ogV2lQNd4=.c69f4c02-520c-4c04-9660-7f9335546be5@github.com>

On Sat, 20 Jan 2024 01:14:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/CODETOOLS-7903580?
>> 
>> Several times in our CI instances we have noticed that a test (action) fails because it is unable to create an `Agent` instance due to the socket connection not being established between the `AgentServer` and the `ServerSocket` running within the jtreg process. This causes the test itself to fail with `Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out`. It has also been noticed that most of the times this is intermittent and subsequent attempt for a different test (action) passes. 
>> 
>> The proposed change here introduces a new configuration parameter `--agent-attempts` under "Agent Pool Options", which allows for configuring the maximum number of attempts that are allowed for getting an agent for an action. This is an optional parameter and by default it has been set to a value of `2`, which by default then allows the agent creation to be retried once if the previous attempt fails. This then means that existing installations/usages of jtreg need not set a value for `--agent-attempts` to enroll for this feature. A value of `1` for this parameter implies that the agent creation attempt will be done only once, which is what currently happens in the absence of this proposed feature.
>> 
>> Inability to obtain an agent, for whatever reason, after attempting `--agent-attempts` times continues to result in test (action) failure, like it does today.
>> 
>> Some additional minor logging related changes have been done too, to help debugging some of the current observed failures.
>> 
>> This change has been tested in the following manners:
>> 
>> 1. This modified build of jtreg has been used to run tier1, tier2 and tier3 of JDK mainline and it has been verified that nothing regresses with this change. That however doesn't mean that agent creation re-attempt logic was tested in these runs (since the first attempt never failed).
>> 2. Locally this build was jtreg was additionally modified to selectively not connect to the `ServerSocket`'s port thus simulating a "Accept timed out" exception. That change then verified that the re-attempt logic does indeed correctly kick in and the test action passes after picking up the newly created agent.
>> 3. `--agent-attempts 1` was passed to the above modified build (from step 2) to verify that the re-attempt isn't attempted when `--agent-attempts 1` an...
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update faq entry
>  - Jon's review comment - add a code comment about pid() usage

Marked as reviewed by jjg (Lead).

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

PR Review: https://git.openjdk.org/jtreg/pull/173#pullrequestreview-1834707762

From jpai at openjdk.org  Mon Jan 22 10:25:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 22 Jan 2024 10:25:03 GMT
Subject: RFR: 7903580: Allow for re-attempting agent creation when an
 attempt fails [v8]
In-Reply-To: <boWfu7snr1vEtLK-YpUu-ahM7bskYq4tvxvAZjf2YM8=.b56b14d8-c777-4cf2-8f9e-541492bf5cb6@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
 <boWfu7snr1vEtLK-YpUu-ahM7bskYq4tvxvAZjf2YM8=.b56b14d8-c777-4cf2-8f9e-541492bf5cb6@github.com>
Message-ID: <LYd5ZRE2Xx6fO3GRJPA9DIUJkw4-fagrdliO441y1WE=.9b2fe08d-0366-43b6-b7f0-c14179223bf3@github.com>

On Sat, 20 Jan 2024 01:14:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/CODETOOLS-7903580?
>> 
>> Several times in our CI instances we have noticed that a test (action) fails because it is unable to create an `Agent` instance due to the socket connection not being established between the `AgentServer` and the `ServerSocket` running within the jtreg process. This causes the test itself to fail with `Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out`. It has also been noticed that most of the times this is intermittent and subsequent attempt for a different test (action) passes. 
>> 
>> The proposed change here introduces a new configuration parameter `--agent-attempts` under "Agent Pool Options", which allows for configuring the maximum number of attempts that are allowed for getting an agent for an action. This is an optional parameter and by default it has been set to a value of `2`, which by default then allows the agent creation to be retried once if the previous attempt fails. This then means that existing installations/usages of jtreg need not set a value for `--agent-attempts` to enroll for this feature. A value of `1` for this parameter implies that the agent creation attempt will be done only once, which is what currently happens in the absence of this proposed feature.
>> 
>> Inability to obtain an agent, for whatever reason, after attempting `--agent-attempts` times continues to result in test (action) failure, like it does today.
>> 
>> Some additional minor logging related changes have been done too, to help debugging some of the current observed failures.
>> 
>> This change has been tested in the following manners:
>> 
>> 1. This modified build of jtreg has been used to run tier1, tier2 and tier3 of JDK mainline and it has been verified that nothing regresses with this change. That however doesn't mean that agent creation re-attempt logic was tested in these runs (since the first attempt never failed).
>> 2. Locally this build was jtreg was additionally modified to selectively not connect to the `ServerSocket`'s port thus simulating a "Accept timed out" exception. That change then verified that the re-attempt logic does indeed correctly kick in and the test action passes after picking up the newly created agent.
>> 3. `--agent-attempts 1` was passed to the above modified build (from step 2) to verify that the re-attempt isn't attempted when `--agent-attempts 1` an...
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update faq entry
>  - Jon's review comment - add a code comment about pid() usage

No issues noticed with the recent run of CI job with these changes. I'll go ahead with the integration now (requires a sponsor).

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

PR Comment: https://git.openjdk.org/jtreg/pull/173#issuecomment-1903678440

From jpai at openjdk.org  Mon Jan 22 17:53:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 22 Jan 2024 17:53:59 GMT
Subject: Integrated: 7903580: Allow for re-attempting agent creation when an
 attempt fails
In-Reply-To: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
References: <sZyzVNDHDJPhY4NuBrcN06EwOYjnuWk3GQm9DB4AfqQ=.c2989a66-a901-420b-a8fe-f4d9dd4b056a@github.com>
Message-ID: <O-8EGL25FrVAwbjRgH_LzNm6P_7GL3tHlHJ6lmFtiUU=.24bcf222-d809-45d6-9f0d-5bc8f3cd9d1a@github.com>

On Mon, 13 Nov 2023 13:54:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to implement the enhancement request noted in https://bugs.openjdk.org/browse/CODETOOLS-7903580?
> 
> Several times in our CI instances we have noticed that a test (action) fails because it is unable to create an `Agent` instance due to the socket connection not being established between the `AgentServer` and the `ServerSocket` running within the jtreg process. This causes the test itself to fail with `Error. Cannot get VM for test: java.net.SocketTimeoutException: Accept timed out`. It has also been noticed that most of the times this is intermittent and subsequent attempt for a different test (action) passes. 
> 
> The proposed change here introduces a new configuration parameter `--agent-attempts` under "Agent Pool Options", which allows for configuring the maximum number of attempts that are allowed for getting an agent for an action. This is an optional parameter and by default it has been set to a value of `2`, which by default then allows the agent creation to be retried once if the previous attempt fails. This then means that existing installations/usages of jtreg need not set a value for `--agent-attempts` to enroll for this feature. A value of `1` for this parameter implies that the agent creation attempt will be done only once, which is what currently happens in the absence of this proposed feature.
> 
> Inability to obtain an agent, for whatever reason, after attempting `--agent-attempts` times continues to result in test (action) failure, like it does today.
> 
> Some additional minor logging related changes have been done too, to help debugging some of the current observed failures.
> 
> This change has been tested in the following manners:
> 
> 1. This modified build of jtreg has been used to run tier1, tier2 and tier3 of JDK mainline and it has been verified that nothing regresses with this change. That however doesn't mean that agent creation re-attempt logic was tested in these runs (since the first attempt never failed).
> 2. Locally this build was jtreg was additionally modified to selectively not connect to the `ServerSocket`'s port thus simulating a "Accept timed out" exception. That change then verified that the re-attempt logic does indeed correctly kick in and the test action passes after picking up the newly created agent.
> 3. `--agent-attempts 1` was passed to the above modified build (from step 2) to verify that the re-attempt isn't attempted when `--agent-attempts 1` and the test fails as currently ...

This pull request has now been integrated.

Changeset: 0cf6ed21
Author:    Jaikiran Pai <jpai at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/0cf6ed21edfca7aef6ac7b8a1fda06f0c39aec87
Stats:     159 lines in 6 files changed: 150 ins; 0 del; 9 mod

7903580: Allow for re-attempting agent creation when an attempt fails

Reviewed-by: jjg, cstein

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

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

From jjg at openjdk.org  Mon Jan 29 21:19:39 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Jan 2024 21:19:39 GMT
Subject: RFR: 7903624: Use openjdk.org instead of openjdk.java.net
In-Reply-To: <NEZZaL_genilLdlJ8N_Kh_7h5zRHwlnaFUt5hxzMxLQ=.2a3d90be-5336-4160-8dbf-c3b10861c704@github.com>
References: <NEZZaL_genilLdlJ8N_Kh_7h5zRHwlnaFUt5hxzMxLQ=.2a3d90be-5336-4160-8dbf-c3b10861c704@github.com>
Message-ID: <352MZdHgn7lMms9KMCOzL9WuPtIdx88rBQ99b_BhUpY=.4a040438-d5ee-45db-b54e-81495669caa8@github.com>

On Fri, 12 Jan 2024 15:54:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should use openjdk.org instead of openjdk.java.net.
> 
> This bug was triggered by the fact that git.openjdk.java.net had problem resolving properly for GitHub Actions in the build script (and the theory is that git.openjdk.org would work better), but this should be fixed nevertheless.

Marked as reviewed by jjg (Lead).

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

PR Review: https://git.openjdk.org/jtreg/pull/180#pullrequestreview-1849788889

From ihse at openjdk.org  Tue Jan 30 13:57:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 30 Jan 2024 13:57:39 GMT
Subject: RFR: 7903624: Use openjdk.org instead of openjdk.java.net
In-Reply-To: <352MZdHgn7lMms9KMCOzL9WuPtIdx88rBQ99b_BhUpY=.4a040438-d5ee-45db-b54e-81495669caa8@github.com>
References: <NEZZaL_genilLdlJ8N_Kh_7h5zRHwlnaFUt5hxzMxLQ=.2a3d90be-5336-4160-8dbf-c3b10861c704@github.com>
 <352MZdHgn7lMms9KMCOzL9WuPtIdx88rBQ99b_BhUpY=.4a040438-d5ee-45db-b54e-81495669caa8@github.com>
Message-ID: <tT7eQ7RCzRdKg1XljZgnQt2EwvziKaYphB08s9BafjA=.f5acdd17-19bb-4973-88fd-517cf3a5ade4@github.com>

On Mon, 29 Jan 2024 21:16:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> We should use openjdk.org instead of openjdk.java.net.
>> 
>> This bug was triggered by the fact that git.openjdk.java.net had problem resolving properly for GitHub Actions in the build script (and the theory is that git.openjdk.org would work better), but this should be fixed nevertheless.
>
> Marked as reviewed by jjg (Lead).

@jonathan-gibbons Can you sponsor?

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

PR Comment: https://git.openjdk.org/jtreg/pull/180#issuecomment-1916905302

From ihse at openjdk.org  Tue Jan 30 16:22:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 30 Jan 2024 16:22:45 GMT
Subject: Integrated: 7903624: Use openjdk.org instead of openjdk.java.net
In-Reply-To: <NEZZaL_genilLdlJ8N_Kh_7h5zRHwlnaFUt5hxzMxLQ=.2a3d90be-5336-4160-8dbf-c3b10861c704@github.com>
References: <NEZZaL_genilLdlJ8N_Kh_7h5zRHwlnaFUt5hxzMxLQ=.2a3d90be-5336-4160-8dbf-c3b10861c704@github.com>
Message-ID: <Ym9YyFaqHsJlDwFMommDDYX2SNp9VXdun4Gl8swbNwQ=.8e645213-2b69-4517-869b-0cd9648c9220@github.com>

On Fri, 12 Jan 2024 15:54:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We should use openjdk.org instead of openjdk.java.net.
> 
> This bug was triggered by the fact that git.openjdk.java.net had problem resolving properly for GitHub Actions in the build script (and the theory is that git.openjdk.org would work better), but this should be fixed nevertheless.

This pull request has now been integrated.

Changeset: af06ecfc
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/af06ecfc3dccd6baa50f53c0862b7ba2b2cbcbd3
Stats:     18 lines in 10 files changed: 0 ins; 0 del; 18 mod

7903624: Use openjdk.org instead of openjdk.java.net

Reviewed-by: jjg

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

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