From cstein at openjdk.org Fri May 2 10:30:35 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 2 May 2025 10:30:35 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces Message-ID: _work in progress..._ Blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 ------------- Commit messages: - Update to use asmtools 8.1 - 7903081: Update asmtools and remove jcov traces Changes: https://git.openjdk.org/jtreg/pull/228/files Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=228&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903081 Stats: 14 lines in 3 files changed: 0 ins; 7 del; 7 mod Patch: https://git.openjdk.org/jtreg/pull/228.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/228/head:pull/228 PR: https://git.openjdk.org/jtreg/pull/228 From cstein at openjdk.org Fri May 2 10:30:35 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 2 May 2025 10:30:35 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 09:49:43 GMT, Christian Stein wrote: > _work in progress..._ > > Blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 Now also blocked by an unreleased bugfix in the Ant `build.xml` producing: /home/runner/work/jtreg/jtreg/build/deps/asmtools/src/asmtools-8.0-b09/build/build.xml:179: . Current java version is 21 The build should be started by java 17 or above @lkuskov would it be possible to release `asmtools` 8.1 with the updated regex (commit https://github.com/openjdk/asmtools/commit/949fb1dfcc54fd5bffbda012fe689ff059999c9f)? ------------- PR Comment: https://git.openjdk.org/jtreg/pull/228#issuecomment-2682170773 From lkuskov at openjdk.org Fri May 2 10:30:35 2025 From: lkuskov at openjdk.org (Leonid Kuskov) Date: Fri, 2 May 2025 10:30:35 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 09:49:43 GMT, Christian Stein wrote: > _work in progress..._ > > Blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 Hi Christian, Unfortunately, despite being the integrator of the commit, I can't set a tag `/tag at8.1` for it: [949fb1d](https://github.com/openjdk/asmtools/commit/279512c2c649f59a0c15f1ae2caa31b9ed695ea5) Any tips? Thanks, Leonid ------------- PR Comment: https://git.openjdk.org/jtreg/pull/228#issuecomment-2683574662 From jpai at openjdk.org Mon May 5 12:40:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 May 2025 12:40:18 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 09:49:43 GMT, Christian Stein wrote: > _work in progress..._ > > Blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 Hello Christian, the upgrade looks reasonable to me. Now that we enforce Java 17 for building jtreg, I think we should also update the `doc/building.md` which currently states: > It must be a recent build of JDK 11 or later. make/build-support/asmtools/version-numbers line 26: > 24: # > 25: > 26: DEFAULT_ASMTOOLS_SRC_TAG=8.1 The copyright year on this file will need an update. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/228#issuecomment-2850858951 PR Review Comment: https://git.openjdk.org/jtreg/pull/228#discussion_r2073361455 From cstein at openjdk.org Mon May 5 14:41:37 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 5 May 2025 14:41:37 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces [v2] In-Reply-To: References: Message-ID: <87aWqBDO5kcpVrJLrQ6RjQEOTlBTuhOJg4ooRW5452w=.8126ddc0-a302-4fdd-abaa-30529411bdf4@github.com> > _work in progress..._ > > Blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 Christian Stein has updated the pull request incrementally with two additional commits since the last revision: - Specify JDK 17 is required to build jtreg - Update copyright year ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/228/files - new: https://git.openjdk.org/jtreg/pull/228/files/0e88a367..34944da2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=228&range=01 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=228&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jtreg/pull/228.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/228/head:pull/228 PR: https://git.openjdk.org/jtreg/pull/228 From cstein at openjdk.org Mon May 5 14:41:37 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 5 May 2025 14:41:37 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces [v2] In-Reply-To: References:

Message-ID: On Mon, 5 May 2025 12:37:44 GMT, Jaikiran Pai wrote: >> Christian Stein has updated the pull request incrementally with two additional commits since the last revision: >> >> - Specify JDK 17 is required to build jtreg >> - Update copyright year > > make/build-support/asmtools/version-numbers line 26: > >> 24: # >> 25: >> 26: DEFAULT_ASMTOOLS_SRC_TAG=8.1 > > The copyright year on this file will need an update. Done. ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/228#discussion_r2073580091 From lujaniuk at openjdk.org Tue May 6 08:05:27 2025 From: lujaniuk at openjdk.org (Ludvig Janiuk) Date: Tue, 6 May 2025 08:05:27 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces [v2] In-Reply-To: <87aWqBDO5kcpVrJLrQ6RjQEOTlBTuhOJg4ooRW5452w=.8126ddc0-a302-4fdd-abaa-30529411bdf4@github.com> References: <87aWqBDO5kcpVrJLrQ6RjQEOTlBTuhOJg4ooRW5452w=.8126ddc0-a302-4fdd-abaa-30529411bdf4@github.com> Message-ID: On Mon, 5 May 2025 14:41:37 GMT, Christian Stein wrote: >> _work in progress..._ >> >> Blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 > > Christian Stein has updated the pull request incrementally with two additional commits since the last revision: > > - Specify JDK 17 is required to build jtreg > - Update copyright year Being able to test older JDK's with jtreg is important. Do I understand it right that this PR would make it impossible to run with a JDK pre-17, with no workaround possible? ------------- PR Comment: https://git.openjdk.org/jtreg/pull/228#issuecomment-2853629491 From duke at openjdk.org Tue May 6 09:55:08 2025 From: duke at openjdk.org (snake66) Date: Tue, 6 May 2025 09:55:08 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 Message-ID: This work is sponsored by The FreeBSD Foundation ------------- Commit messages: - 7904002: compile directives with args after file name fail after 7903955 Changes: https://git.openjdk.org/jtreg/pull/261/files Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=261&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904002 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jtreg/pull/261.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/261/head:pull/261 PR: https://git.openjdk.org/jtreg/pull/261 From cstein at openjdk.org Tue May 6 11:43:25 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 6 May 2025 11:43:25 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 In-Reply-To: References: Message-ID: On Tue, 6 May 2025 09:49:07 GMT, snake66 wrote: > This work is sponsored by The FreeBSD Foundation Please add a self-test covering the `@compile Test.java -XDrawDiagnostics` case. ------------- Changes requested by cstein (Reviewer). PR Review: https://git.openjdk.org/jtreg/pull/261#pullrequestreview-2817939846 From duke at openjdk.org Tue May 6 12:55:38 2025 From: duke at openjdk.org (snake66) Date: Tue, 6 May 2025 12:55:38 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD Message-ID: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. This work is sponsored by The FreeBSD Foundation. ------------- Commit messages: - 7904004: Run jtreg GHA workflows for FreeBSD Changes: https://git.openjdk.org/jtreg/pull/262/files Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=262&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904004 Stats: 27 lines in 1 file changed: 27 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jtreg/pull/262.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/262/head:pull/262 PR: https://git.openjdk.org/jtreg/pull/262 From duke at openjdk.org Tue May 6 13:27:42 2025 From: duke at openjdk.org (snake66) Date: Tue, 6 May 2025 13:27:42 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v2] In-Reply-To: References: Message-ID: > This work is sponsored by The FreeBSD Foundation snake66 has updated the pull request incrementally with one additional commit since the last revision: Add test case for @compile with trailing args ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/261/files - new: https://git.openjdk.org/jtreg/pull/261/files/37bd6ed6..2ef29f35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=261&range=01 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=261&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jtreg/pull/261.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/261/head:pull/261 PR: https://git.openjdk.org/jtreg/pull/261 From cstein at openjdk.org Tue May 6 15:50:30 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 6 May 2025 15:50:30 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v2] In-Reply-To: References:

Message-ID: <7iHTl38h-beM2y3w5V5W4ByASoP5fr6ay3jxXrK9FxY=.f29f6a41-bc8f-4ad5-9833-8778eb5d4b02@github.com> On Tue, 6 May 2025 13:27:42 GMT, snake66 wrote: >> This work is sponsored by The FreeBSD Foundation > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Add test case for @compile with trailing args test/javacVMOptions/Test.java line 28: > 26: * @compile Test.java > 27: * @compile -J-DmyProperty=123 -processor Test -proc:only Test.java > 28: * @compile Test.java -XDrawDiagnostic Please, also insert a line reading ` * @bug 7902510 7904002` under the ` * @test` line. And update the copyright years to read: `* Copyright (c) 2019, 2025, Oracle and/or its affiliates. All rights reserved.` ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/261#discussion_r2075768009 From cstein at openjdk.org Tue May 6 16:14:25 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 6 May 2025 16:14:25 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD In-Reply-To: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Tue, 6 May 2025 12:52:18 GMT, snake66 wrote: > GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. > > This work is sponsored by The FreeBSD Foundation. .github/workflows/test.yml line 73: > 71: sysctl hw.usermem > 72: pw user add -n action -m > 73: su action -c 'git config --global --add safe.directory /home/runner/work/jtreg/jtreg && bash make/build.sh --jdk /usr/local/openjdk21 && bash build/make.sh test' Could the `git` configuration and two make calls be split into dedicated lines? ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/262#discussion_r2075813241 From duke at openjdk.org Tue May 6 17:51:30 2025 From: duke at openjdk.org (snake66) Date: Tue, 6 May 2025 17:51:30 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: <3dosqTcJpJMTwDBUJDrkOsrfVvLZ9RN0rLIP3e5bDyI=.efabf470-1295-4aec-81a7-65a9db7862d1@github.com> On Tue, 6 May 2025 16:12:18 GMT, Christian Stein wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > .github/workflows/test.yml line 73: > >> 71: sysctl hw.usermem >> 72: pw user add -n action -m >> 73: su action -c 'git config --global --add safe.directory /home/runner/work/jtreg/jtreg && bash make/build.sh --jdk /usr/local/openjdk21 && bash build/make.sh test' > > Could the `git` configuration and two make calls be split into dedicated lines? Probably, I'll give it a try! ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/262#discussion_r2075980077 From duke at openjdk.org Tue May 6 17:53:26 2025 From: duke at openjdk.org (snake66) Date: Tue, 6 May 2025 17:53:26 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v2] In-Reply-To: <7iHTl38h-beM2y3w5V5W4ByASoP5fr6ay3jxXrK9FxY=.f29f6a41-bc8f-4ad5-9833-8778eb5d4b02@github.com> References:

<7iHTl38h-beM2y3w5V5W4ByASoP5fr6ay3jxXrK9FxY=.f29f6a41-bc8f-4ad5-9833-8778eb5d4b02@github.com> Message-ID: On Tue, 6 May 2025 15:48:07 GMT, Christian Stein wrote: >> snake66 has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case for @compile with trailing args > > test/javacVMOptions/Test.java line 28: > >> 26: * @compile Test.java >> 27: * @compile -J-DmyProperty=123 -processor Test -proc:only Test.java >> 28: * @compile Test.java -XDrawDiagnostic > > Please, also insert a line reading ` * @bug 7902510 7904002` under the ` * @test` line. > > And update the copyright years to read: `* Copyright (c) 2019, 2025, Oracle and/or its affiliates. All rights reserved.` Sure! Would it be better to add a separate test case for it instead of just adding another `@compile` line to this one? ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/261#discussion_r2075984063 From cstein at openjdk.org Wed May 7 05:32:24 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 May 2025 05:32:24 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v2] In-Reply-To: References:

<7iHTl38h-beM2y3w5V5W4ByASoP5fr6ay3jxXrK9FxY=.f29f6a41-bc8f-4ad5-9833-8778eb5d4b02@github.com> Message-ID: On Tue, 6 May 2025 17:51:08 GMT, snake66 wrote: >> test/javacVMOptions/Test.java line 28: >> >>> 26: * @compile Test.java >>> 27: * @compile -J-DmyProperty=123 -processor Test -proc:only Test.java >>> 28: * @compile Test.java -XDrawDiagnostic >> >> Please, also insert a line reading ` * @bug 7902510 7904002` under the ` * @test` line. >> >> And update the copyright years to read: `* Copyright (c) 2019, 2025, Oracle and/or its affiliates. All rights reserved.` > > Sure! > > Would it be better to add a separate test case for it instead of just adding another `@compile` line to this one? Doesn't have to be a dedicated test per issue; as long as the issue numbers are recorded via the `@bug` tag. Bonus points for adding `@comment` lines. ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/261#discussion_r2076816151 From duke at openjdk.org Wed May 7 09:44:41 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 09:44:41 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v3] In-Reply-To: References: Message-ID: > This work is sponsored by The FreeBSD Foundation snake66 has updated the pull request incrementally with two additional commits since the last revision: - Update copyright notice - Add @bug and @comment tags ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/261/files - new: https://git.openjdk.org/jtreg/pull/261/files/2ef29f35..23a1e2ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=261&range=02 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=261&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jtreg/pull/261.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/261/head:pull/261 PR: https://git.openjdk.org/jtreg/pull/261 From cstein at openjdk.org Wed May 7 10:05:29 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 May 2025 10:05:29 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v3] In-Reply-To: References:

Message-ID: On Wed, 7 May 2025 09:44:41 GMT, snake66 wrote: >> This work is sponsored by The FreeBSD Foundation > > snake66 has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright notice > - Add @bug and @comment tags Looks good to me ------------- Marked as reviewed by cstein (Reviewer). PR Review: https://git.openjdk.org/jtreg/pull/261#pullrequestreview-2821176854 From duke at openjdk.org Wed May 7 10:47:22 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 10:47:22 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v2] In-Reply-To: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: > GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. > > This work is sponsored by The FreeBSD Foundation. snake66 has updated the pull request incrementally with one additional commit since the last revision: Split long line in workflow ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/262/files - new: https://git.openjdk.org/jtreg/pull/262/files/0788637c..d8f66b75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=262&range=01 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=262&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jtreg/pull/262.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/262/head:pull/262 PR: https://git.openjdk.org/jtreg/pull/262 From duke at openjdk.org Wed May 7 10:49:25 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 10:49:25 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v3] In-Reply-To: References:

Message-ID: <89IxzU1y-FplCZk1m1SI7PqL3FfOQvnjORaHsi3PXEE=.1cef9f5a-308e-42f5-a487-105953c7c76e@github.com> On Wed, 7 May 2025 10:02:27 GMT, Christian Stein wrote: >> snake66 has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright notice >> - Add @bug and @comment tags > > Looks good to me @sormuras Thanks for the review and help! ------------- PR Comment: https://git.openjdk.org/jtreg/pull/261#issuecomment-2858082374 From duke at openjdk.org Wed May 7 10:49:26 2025 From: duke at openjdk.org (duke) Date: Wed, 7 May 2025 10:49:26 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v3] In-Reply-To: References:

Message-ID: <7GVYbDcBukZLvjrNdP4qD4QVysqZvGZdRuox-lWU-8U=.8b57eed6-4130-4b76-8b81-0234d41b01ab@github.com> On Wed, 7 May 2025 09:44:41 GMT, snake66 wrote: >> This work is sponsored by The FreeBSD Foundation > > snake66 has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright notice > - Add @bug and @comment tags @snake66 Your change (at version 23a1e2ef08ed4fa9cb1674d1640473666520b91a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/261#issuecomment-2858087632 From cstein at openjdk.org Wed May 7 10:54:39 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 May 2025 10:54:39 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v2] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 10:47:22 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Split long line in workflow .github/workflows/test.yml line 73: > 71: sysctl hw.usermem > 72: pw user add -n action -m > 73: su action -c 'git config --global --add safe.directory /home/runner/work/jtreg/jtreg' Looks much better now, thanks for splitting the line into three calls. Can the hard-coded `/home/runner/work/jtreg/jtreg` path be replaced with some inline `pwd` evaluation? Would make it more future-proof if parent paths are changed. .github/workflows/test.yml line 74: > 72: pw user add -n action -m > 73: su action -c 'git config --global --add safe.directory /home/runner/work/jtreg/jtreg' > 74: su action -c 'bash make/build.sh --jdk /usr/local/openjdk21' I assume that the hard-coded `/usr/local/openjdk21` is well-defined and stable for `pkg ... openjdk21 ...` calls. Or is there an environment variable (`JAVA_HOME`?) being set that can be read out and used here? ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/262#discussion_r2077354169 PR Review Comment: https://git.openjdk.org/jtreg/pull/262#discussion_r2077356931 From duke at openjdk.org Wed May 7 10:54:40 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 10:54:40 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v2] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com>

Message-ID: On Wed, 7 May 2025 10:50:03 GMT, Christian Stein wrote: >> snake66 has updated the pull request incrementally with one additional commit since the last revision: >> >> Split long line in workflow > > .github/workflows/test.yml line 73: > >> 71: sysctl hw.usermem >> 72: pw user add -n action -m >> 73: su action -c 'git config --global --add safe.directory /home/runner/work/jtreg/jtreg' > > Looks much better now, thanks for splitting the line into three calls. > > Can the hard-coded `/home/runner/work/jtreg/jtreg` path be replaced with some inline `pwd` evaluation? Would make it more future-proof if parent paths are changed. Good point! I'll look into it. Should probably be able to use `$(pwd)` or something. ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/262#discussion_r2077356545 From duke at openjdk.org Wed May 7 11:42:28 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 11:42:28 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v2] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com>

Message-ID: On Wed, 7 May 2025 10:51:58 GMT, Christian Stein wrote: >> snake66 has updated the pull request incrementally with one additional commit since the last revision: >> >> Split long line in workflow > > .github/workflows/test.yml line 74: > >> 72: pw user add -n action -m >> 73: su action -c 'git config --global --add safe.directory /home/runner/work/jtreg/jtreg' >> 74: su action -c 'bash make/build.sh --jdk /usr/local/openjdk21' > > I assume that the hard-coded `/usr/local/openjdk21` is well-defined and stable for `pkg ... openjdk21 ...` calls. Or is there an environment variable (`JAVA_HOME`?) being set that can be read out and used here? While it's technically possible to change the prefix from `/usr/local`, this is the default unless explicitly changed. There are ways to get the path without hardcoding it, but I'm not sure it's worth the effort here: % JAVAVM_DRYRUN=1 javavm 2>/dev/null |grep JAVA_HOME|cut -d '=' -f 2 /usr/local/openjdk21 ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/262#discussion_r2077434056 From duke at openjdk.org Wed May 7 12:31:11 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 12:31:11 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: > GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. > > This work is sponsored by The FreeBSD Foundation. snake66 has updated the pull request incrementally with one additional commit since the last revision: Use $(pwd) for path to checked out source dir ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/262/files - new: https://git.openjdk.org/jtreg/pull/262/files/d8f66b75..1e0623ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=262&range=02 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=262&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jtreg/pull/262.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/262/head:pull/262 PR: https://git.openjdk.org/jtreg/pull/262 From cstein at openjdk.org Wed May 7 12:38:28 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 May 2025 12:38:28 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v2] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com>

Message-ID: <0hwmpOWeodF5iXP_ZGkGDgBgnPIqvxyyVOScRdgFjEo=.9964471d-0378-4f8c-a9ef-d12426f076b1@github.com> On Wed, 7 May 2025 11:39:28 GMT, snake66 wrote: >> .github/workflows/test.yml line 74: >> >>> 72: pw user add -n action -m >>> 73: su action -c 'git config --global --add safe.directory /home/runner/work/jtreg/jtreg' >>> 74: su action -c 'bash make/build.sh --jdk /usr/local/openjdk21' >> >> I assume that the hard-coded `/usr/local/openjdk21` is well-defined and stable for `pkg ... openjdk21 ...` calls. Or is there an environment variable (`JAVA_HOME`?) being set that can be read out and used here? > > While it's technically possible to change the prefix from `/usr/local`, this is the default unless explicitly changed. > > There are ways to get the path without hardcoding it, but I'm not sure it's worth the effort here: > > > % JAVAVM_DRYRUN=1 javavm 2>/dev/null |grep JAVA_HOME|cut -d '=' -f 2 > /usr/local/openjdk21 The default is good-enough here, I guess. Otherwise, it would be more elegant to specify a custom location for the installation and then pass it later to subsequent processes. ------------- PR Review Comment: https://git.openjdk.org/jtreg/pull/262#discussion_r2077524883 From cstein at openjdk.org Wed May 7 13:28:40 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 May 2025 13:28:40 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 12:31:11 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Use $(pwd) for path to checked out source dir Running for almost an hour now and repeating `VM is booting` over and over. This does not bode well... ![image](https://github.com/user-attachments/assets/18c1a10b-746a-4461-819d-e275736fadbb) ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2858593282 From duke at openjdk.org Wed May 7 13:33:29 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 13:33:29 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com>

Message-ID: On Wed, 7 May 2025 13:25:49 GMT, Christian Stein wrote: > Running for almost an hour now and repeating `VM is booting` over and over. This does not bode well... No, tried restarting it. Not seen this happen before. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2858627101 From cstein at openjdk.org Wed May 7 13:48:28 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 May 2025 13:48:28 GMT Subject: RFR: 7904002: @compile directives with args after file name fail after 7903955 [v3] In-Reply-To: References:

Message-ID: On Wed, 7 May 2025 13:53:21 GMT, Christian Stein wrote: >> snake66 has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright notice >> - Add @bug and @comment tags > > Thank you, Harald! @sormuras Thank you! ------------- PR Comment: https://git.openjdk.org/jtreg/pull/261#issuecomment-2858700656 From duke at openjdk.org Wed May 7 13:57:30 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 13:57:30 GMT Subject: Integrated: 7904002: @compile directives with args after file name fail after 7903955 In-Reply-To: References: Message-ID: On Tue, 6 May 2025 09:49:07 GMT, snake66 wrote: > This work is sponsored by The FreeBSD Foundation This pull request has now been integrated. Changeset: 08368145 Author: Harald Eilertsen Committer: Christian Stein URL: https://git.openjdk.org/jtreg/commit/08368145d7114803bc6cabe2dec163b597f70fc4 Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod 7904002: @compile directives with args after file name fail after 7903955 Reviewed-by: cstein ------------- PR: https://git.openjdk.org/jtreg/pull/261 From ihse at openjdk.org Wed May 7 14:04:32 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 14:04:32 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 12:31:11 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Use $(pwd) for path to checked out source dir Seems fine to me. ------------- Marked as reviewed by ihse (Author). PR Review: https://git.openjdk.org/jtreg/pull/262#pullrequestreview-2821890071 From duke at openjdk.org Wed May 7 14:11:30 2025 From: duke at openjdk.org (snake66) Date: Wed, 7 May 2025 14:11:30 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 12:31:11 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Use $(pwd) for path to checked out source dir Seems to be a known issue, and happens now and again: https://github.com/vmactions/freebsd-vm/issues/91 I understand if that's a showstopper for now. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2858746524 From cstein at openjdk.org Wed May 7 14:20:39 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 May 2025 14:20:39 GMT Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash testing In-Reply-To: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com> References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com> Message-ID: On Wed, 6 Nov 2024 01:45:22 GMT, andrlos wrote: > provides SPI for enabling external status transformations of failed tests > > this is a continuation of efforts after https://github.com/openjdk/jtharness/pull/59 > > Requires newest jtharness build (not even tagged yet) that includes above mentioned change to be compiled succesfully > > The main idea is to provide a unified StatusTransformer interface, that can be externally implemented by users and added to a classpath in a separate jar to allow modifications of test execution status based on some elementary analysis. This can be easily used for crashtesting (filtering out only tests with jvm crashes). What I still don't get is that you want to address a global goal "basic crash testing" with a very local mechanism, like something similar to JUnit 4 "TestRule". I think a solution lies in between your lines: > it proved to be much harder to filter them after, as the `hs_err_pid` log is not being copied, plus we have many tests that run via a shell script, so a generic jvm watcher is not an option as would be the option with jvm agent that we use for junit testing.. we need to cover cases, where jvm crashes even tho it has been run via a shell script (or multiple levels of scripts) and watching for `hs_err_pid.log` proved to be the most reliable and universal approach. So, what about making sure that `jtreg` copies `hs_err_pid` files correctly? ------------- PR Comment: https://git.openjdk.org/jtreg/pull/235#issuecomment-2858774418 From duke at openjdk.org Tue May 13 14:25:08 2025 From: duke at openjdk.org (snake66) Date: Tue, 13 May 2025 14:25:08 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 12:31:11 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Use $(pwd) for path to checked out source dir Just to look at an alternative, I have made some tests using cirrus-ci instead of the vm based runner directly under GHA. That does seem a lot smoother, but I'm not sure how you would look at having another CI service for FreeBSD? It's naturally not as well integrated into GitHub as the runners they provide, but does reflect back success/failure status and hooks into the checks for pull requests. https://cirrus-ci.com/github/snake66/jtreg I'd be interested in hearing your opinions on such an approach. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2876737559 From ihse at openjdk.org Fri May 16 15:45:08 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 16 May 2025 15:45:08 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com>

Message-ID: On Wed, 7 May 2025 13:25:49 GMT, Christian Stein wrote: >> snake66 has updated the pull request incrementally with one additional commit since the last revision: >> >> Use $(pwd) for path to checked out source dir > > Running for almost an hour now and repeating `VM is booting` over and over. This does not bode well... > > ![image](https://github.com/user-attachments/assets/18c1a10b-746a-4461-819d-e275736fadbb) I think that sounds like a much worse solution. Let's stick to GHA. @sormuras Are there anything else you think needs to be done for this? Otherwise I believe this would be good to go. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2887085103 From cstein at openjdk.org Fri May 16 16:09:03 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 16 May 2025 16:09:03 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 12:31:11 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Use $(pwd) for path to checked out source dir Looks good to me. Will be observing the "boot loop" as a potential reason to back out. ------------- Marked as reviewed by cstein (Reviewer). PR Review: https://git.openjdk.org/jtreg/pull/262#pullrequestreview-2847065145 From cstein at openjdk.org Fri May 16 16:09:03 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 16 May 2025 16:09:03 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com>

Message-ID: On Fri, 16 May 2025 15:42:47 GMT, Magnus Ihse Bursie wrote: > Let's stick to GHA. Yes. > Are there anything else you think needs to be done for this? Otherwise I believe this would be good to go. Except for this "eternal boot loop" issue, no. If that happens too often, we can always disable or remove this new job. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2887132886 From duke at openjdk.org Fri May 16 17:51:06 2025 From: duke at openjdk.org (snake66) Date: Fri, 16 May 2025 17:51:06 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 12:31:11 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Use $(pwd) for path to checked out source dir Cool, so I'm ok to try to integrate this? ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2887341625 From duke at openjdk.org Sat May 17 09:12:14 2025 From: duke at openjdk.org (duke) Date: Sat, 17 May 2025 09:12:14 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 12:31:11 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Use $(pwd) for path to checked out source dir @snake66 Your change (at version 1e0623ced2a816a618a011f2335c2dcae2fc855b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2888241468 From cstein at openjdk.org Mon May 19 13:44:15 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 19 May 2025 13:44:15 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces [v2] In-Reply-To: <87aWqBDO5kcpVrJLrQ6RjQEOTlBTuhOJg4ooRW5452w=.8126ddc0-a302-4fdd-abaa-30529411bdf4@github.com> References: <87aWqBDO5kcpVrJLrQ6RjQEOTlBTuhOJg4ooRW5452w=.8126ddc0-a302-4fdd-abaa-30529411bdf4@github.com> Message-ID: <3_T4lzjlpwtkOzDozI8Zs4EsAcYStD7fZA-5KvnwDBM=.5b0e3866-1a44-43ce-98d3-17f920b3a79a@github.com> On Mon, 5 May 2025 14:41:37 GMT, Christian Stein wrote: >> _work in progress..._ >> >> Blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 > > Christian Stein has updated the pull request incrementally with two additional commits since the last revision: > > - Specify JDK 17 is required to build jtreg > - Update copyright year The `jtreg` tool itself requires Java 11 since 7.0; agents can be still on 8, same as today. Soon, tests using `asmtools` 8.x will require Java 17 - due to https://github.com/openjdk/asmtools/blob/279512c2c649f59a0c15f1ae2caa31b9ed695ea5/build/build.properties#L30-L31 ------------- PR Comment: https://git.openjdk.org/jtreg/pull/228#issuecomment-2891085482 From cstein at openjdk.org Mon May 19 13:50:48 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 19 May 2025 13:50:48 GMT Subject: RFR: 7903999: Release jtreg 7.5.2 Message-ID: Please review this change preparing the `7.5.2` release of jtreg. The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch is not required, yet. ------------- Commit messages: - 7903999: Release jtreg 7.5.2 Changes: https://git.openjdk.org/jtreg/pull/263/files Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=263&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903999 Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jtreg/pull/263.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/263/head:pull/263 PR: https://git.openjdk.org/jtreg/pull/263 From cstein at openjdk.org Mon May 19 14:25:07 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 19 May 2025 14:25:07 GMT Subject: RFR: 7904004: Run jtreg GHA workflows for FreeBSD [v3] In-Reply-To: References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Wed, 7 May 2025 12:31:11 GMT, snake66 wrote: >> GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. >> >> This work is sponsored by The FreeBSD Foundation. > > snake66 has updated the pull request incrementally with one additional commit since the last revision: > > Use $(pwd) for path to checked out source dir I'll sponsor this after - #263 is integrated. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/262#issuecomment-2891228131 From cstein at openjdk.org Mon May 19 14:52:45 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 19 May 2025 14:52:45 GMT Subject: RFR: 7903999: Release jtreg 7.5.2 [v2] In-Reply-To: References: Message-ID: > Please review this change preparing the `7.5.2` release of jtreg. > > The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch is not required, yet. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update CHANGELOG.md Fix typo ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/263/files - new: https://git.openjdk.org/jtreg/pull/263/files/59cbca3f..f18faf87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=263&range=01 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=263&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jtreg/pull/263.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/263/head:pull/263 PR: https://git.openjdk.org/jtreg/pull/263 From jlahoda at openjdk.org Mon May 19 14:57:08 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 May 2025 14:57:08 GMT Subject: RFR: 7903999: Release jtreg 7.5.2 [v2] In-Reply-To: References:

Message-ID: On Mon, 19 May 2025 14:52:45 GMT, Christian Stein wrote: >> Please review this change preparing the `7.5.2` release of jtreg. >> >> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch is not required, yet. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Update CHANGELOG.md > > Fix typo Looks good! ------------- Marked as reviewed by jlahoda (Lead). PR Review: https://git.openjdk.org/jtreg/pull/263#pullrequestreview-2851068550 From cstein at openjdk.org Mon May 19 16:00:12 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 19 May 2025 16:00:12 GMT Subject: Integrated: 7903999: Release jtreg 7.5.2 In-Reply-To: References: Message-ID: On Fri, 9 May 2025 09:31:02 GMT, Christian Stein wrote: > Please review this change preparing the `7.5.2` release of jtreg. > > The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch is not required, yet. This pull request has now been integrated. Changeset: 05c67a77 Author: Christian Stein URL: https://git.openjdk.org/jtreg/commit/05c67a77fa8ae98cacbba0f8012df8bdf04105a7 Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod 7903999: Release jtreg 7.5.2 Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jtreg/pull/263 From cstein at openjdk.org Mon May 19 19:48:40 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 19 May 2025 19:48:40 GMT Subject: RFR: 7904000: Update to build with JDK 17 Message-ID: Please review this change to update to build of `jtreg` with JDK 17. Note that we still keep the `--release 8` for agent classes, and `--release 11` for tool classes as-is. That means, the runtime required to launch `jtreg` is unchanged. Note also, that some tests may require (bundled) external libraries, such as AsmTools 8.1, which moved to Java 17 as their baseline. This change also sets the version of `jtreg` to `7.6`, the next release number. ------------- Commit messages: - 7904000: Update to build with JDK 17 Changes: https://git.openjdk.org/jtreg/pull/264/files Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=264&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904000 Stats: 8 lines in 5 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jtreg/pull/264.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/264/head:pull/264 PR: https://git.openjdk.org/jtreg/pull/264 From jlahoda at openjdk.org Tue May 20 07:17:05 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 20 May 2025 07:17:05 GMT Subject: RFR: 7904000: Update to build with JDK 17 In-Reply-To: References: Message-ID: <7j9L6Fk44tI0qq5I7s9ae6rkFaXC5-q_lJbuUs98zZY=.fabc27ce-75db-456a-ae01-d5fc647c33d7@github.com> On Mon, 19 May 2025 19:10:34 GMT, Christian Stein wrote: > Please review this change to update to build of `jtreg` with JDK 17. > > Note that we still keep the `--release 8` for agent classes, and `--release 11` for tool classes as-is. That means, the runtime required to launch `jtreg` is unchanged. > Note also, that some tests may require (bundled) external libraries, such as AsmTools 8.1, which moved to Java 17 as their baseline. > > This change also sets the version of `jtreg` to `7.6`, the next release number. Looks OK to me. ------------- Marked as reviewed by jlahoda (Lead). PR Review: https://git.openjdk.org/jtreg/pull/264#pullrequestreview-2852962799 From cstein at openjdk.org Tue May 20 10:25:02 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 20 May 2025 10:25:02 GMT Subject: Integrated: 7904000: Update to build with JDK 17 In-Reply-To: References: Message-ID: On Mon, 19 May 2025 19:10:34 GMT, Christian Stein wrote: > Please review this change to update to build of `jtreg` with JDK 17. > > Note that we still keep the `--release 8` for agent classes, and `--release 11` for tool classes as-is. That means, the runtime required to launch `jtreg` is unchanged. > Note also, that some tests may require (bundled) external libraries, such as AsmTools 8.1, which moved to Java 17 as their baseline. > > This change also sets the version of `jtreg` to `7.6`, the next release number. This pull request has now been integrated. Changeset: 170c3571 Author: Christian Stein URL: https://git.openjdk.org/jtreg/commit/170c35711b8cae076a6663c270306bd89526e051 Stats: 8 lines in 5 files changed: 1 ins; 0 del; 7 mod 7904000: Update to build with JDK 17 Reviewed-by: jlahoda ------------- PR: https://git.openjdk.org/jtreg/pull/264 From jvernee at openjdk.org Tue May 20 12:59:21 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 20 May 2025 12:59:21 GMT Subject: RFR: 7903990: IDEA plugin: Itemize junit test results [v2] In-Reply-To: References: Message-ID: > Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example: > > ![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d) > > Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: > > 1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. > 2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events. > > Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Make concurrent test output work ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/260/files - new: https://git.openjdk.org/jtreg/pull/260/files/d92de904..fad9f484 Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=260&range=01 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=260&range=00-01 Stats: 69 lines in 1 file changed: 57 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jtreg/pull/260.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/260/head:pull/260 PR: https://git.openjdk.org/jtreg/pull/260 From jvernee at openjdk.org Tue May 20 13:03:04 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 20 May 2025 13:03:04 GMT Subject: RFR: 7903990: IDEA plugin: Itemize junit test results [v2] In-Reply-To: References:

Message-ID: <3_-KI-zfyBYg9uAt1gFgm95s40710YG1Vnw4T7jXOTQ=.b425aa6e-aee7-4b8c-9943-3ddf3249d45f@github.com> On Tue, 20 May 2025 12:59:21 GMT, Jorn Vernee wrote: >> Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example: >> >> ![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d) >> >> Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: >> >> 1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. >> 2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events. >> >> Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Make concurrent test output work This fell off my radar for a bit, but I've now fixed concurrent test output (https://github.com/openjdk/jtreg/pull/260/commits/fad9f484c3b8c5e09dc915ab3b17cb64b46f0db7). When a test starts, it tries to grab a writer lock, and tries to write out the test start event immediately. but only 1 test is allowed to do this at a time, depending on which test grabbed the lock. For tests that failed to grab the lock, the start test event is deferred until the test is finished. This will allow multiple tests to run concurrently, but only 1 test can output test events at a time. I've tested this with concurrent and non-concurrent modes, and in either case we get immediate feedback when a test starts. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/260#issuecomment-2894315759 From duke at openjdk.org Tue May 20 13:19:12 2025 From: duke at openjdk.org (snake66) Date: Tue, 20 May 2025 13:19:12 GMT Subject: Integrated: 7904004: Run jtreg GHA workflows for FreeBSD In-Reply-To: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> References: <2_5Glpj26LKCaQkzVI5jYRMZ25L93dYGTRLq3D31kRI=.adcd75a7-bbad-48e7-b28b-15cce797e06b@github.com> Message-ID: On Tue, 6 May 2025 12:52:18 GMT, snake66 wrote: > GitHub Actions does not natively support FreeBSD, so we use the vmactions/freebsd-vm action as a base to run the tests in a VM under an Ubuntu runner. > > This work is sponsored by The FreeBSD Foundation. This pull request has now been integrated. Changeset: c6388c7e Author: Harald Eilertsen Committer: Christian Stein URL: https://git.openjdk.org/jtreg/commit/c6388c7eeb72af193dc7f5cd374658fd5ede885a Stats: 29 lines in 1 file changed: 29 ins; 0 del; 0 mod 7904004: Run jtreg GHA workflows for FreeBSD Reviewed-by: ihse, cstein ------------- PR: https://git.openjdk.org/jtreg/pull/262 From cstein at openjdk.org Tue May 20 13:20:09 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 20 May 2025 13:20:09 GMT Subject: RFR: 7903990: IDEA plugin: Itemize junit test results [v2] In-Reply-To: References:

Message-ID: <73AJ9M9-kkwLiZuEExFxhd7rItlIUIFc3-n887QSL28=.f5918d12-0711-436e-8fdb-b5602cd81643@github.com> On Tue, 20 May 2025 12:59:21 GMT, Jorn Vernee wrote: >> Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example: >> >> ![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d) >> >> Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: >> >> 1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. >> 2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events. >> >> Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Make concurrent test output work Looks good to me. ------------- Marked as reviewed by cstein (Reviewer). PR Review: https://git.openjdk.org/jtreg/pull/260#pullrequestreview-2854161034 From jvernee at openjdk.org Tue May 20 13:46:54 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 20 May 2025 13:46:54 GMT Subject: RFR: 7903990: IDEA plugin: Itemize junit test results [v2] In-Reply-To: References:

Message-ID: On Tue, 20 May 2025 12:59:21 GMT, Jorn Vernee wrote: >> Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example: >> >> ![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d) >> >> Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: >> >> 1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. >> 2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events. >> >> Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Make concurrent test output work I gave this a last look, and noticed I had accidentally included some spurious lines in the last commit, and there was a missing label in one of the loops. I've addressed both in https://github.com/openjdk/jtreg/pull/260/commits/603de523c4e34597698330c0945dfaa84d36e80d ------------- PR Comment: https://git.openjdk.org/jtreg/pull/260#issuecomment-2894466347 From jvernee at openjdk.org Tue May 20 13:46:51 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 20 May 2025 13:46:51 GMT Subject: RFR: 7903990: IDEA plugin: Itemize junit test results [v3] In-Reply-To: References: Message-ID: <757uWa2PmntpjGpprdHfHVVdiH6qfnOju4weyXtarFw=.0a1c0c7f-557a-4b57-802b-e57c0a371528@github.com> > Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example: > > ![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d) > > Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: > > 1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. > 2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events. > > Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/260/files - new: https://git.openjdk.org/jtreg/pull/260/files/fad9f484..603de523 Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=260&range=02 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=260&range=01-02 Stats: 8 lines in 1 file changed: 1 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jtreg/pull/260.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/260/head:pull/260 PR: https://git.openjdk.org/jtreg/pull/260 From cstein at openjdk.org Tue May 20 13:52:06 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 20 May 2025 13:52:06 GMT Subject: RFR: 7903990: IDEA plugin: Itemize junit test results [v3] In-Reply-To: <757uWa2PmntpjGpprdHfHVVdiH6qfnOju4weyXtarFw=.0a1c0c7f-557a-4b57-802b-e57c0a371528@github.com> References: <757uWa2PmntpjGpprdHfHVVdiH6qfnOju4weyXtarFw=.0a1c0c7f-557a-4b57-802b-e57c0a371528@github.com> Message-ID: On Tue, 20 May 2025 13:46:51 GMT, Jorn Vernee wrote: >> Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example: >> >> ![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d) >> >> Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: >> >> 1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. >> 2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events. >> >> Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Re-approved. ------------- Marked as reviewed by cstein (Reviewer). PR Review: https://git.openjdk.org/jtreg/pull/260#pullrequestreview-2854279467 From jvernee at openjdk.org Tue May 20 14:39:17 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 20 May 2025 14:39:17 GMT Subject: Integrated: 7903990: IDEA plugin: Itemize junit test results In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 20:48:35 GMT, Jorn Vernee wrote: > Itemize the results of jtreg tests containing junit sections. Each junit section will have a node in the test result tree, with each nested test class and test method having their own node as well. This also makes it possible to re-run just a single junit test (or a single iteration of a parameterized test), by right-clicking the corresponding item in the test result UI. See the below image as an example: > > ![image](https://github.com/user-attachments/assets/649b5899-47dd-451e-acda-7d5e21824f4d) > > Some implementation notes: jtharness/jtreg don't currently report results of individual junit tests to the test listener. There are currently 2 barriers to this that I can see: > > 1. the JUnitRunner communicates the test results back to the parent jtreg process by writing a summary to stderr, which the parent process than parses. The parent process does not parse the results of the individual tests. In order to have more 'live feedback' from the junit runner, one idea is to use a socket connection between the parent jtreg process and junit runner. Where instead of writing the test results to stderr, the junit runner would call back to the parent process over this socket connection to notify it when a test started/finished. The jtreg parent process can then in turn immediately notify an test listener. Alternatively, we could perhaps use (existing) junit JFR events that are streamed back to the parent process. > 2. jtreg does not report nested events of a test (such as junit tests) back to the harness observer that the plugin uses to listen for test events. In jtharness, a 'test' corresponds directly to a jtreg test, and there seems to be no support to attach additional nested events to a 'test', or for the JTRegTestListener to register a callback to listen for more nested events. > > Rather than solving these two issues, for now I've opted for a simpler approach. When a jtreg test finishes and the test listener is notified, we look for sections in the test result titled 'junit', and parse their stderr stream to find the tests results that jtreg's JUnitRunner prints to stderr. This works relatively well, with the caveat being that, if jtharness truncates the stderr output, some tests that ran will not be reported in the UI in an itemized way (but the test will still fail, and report the failure under the 'jtreg' test, accompanied by its jtr file). Given how useful this feature seems (and has been during testing), I think this is a reasonable tradeoff. This pull request has now been integrated. Changeset: 94460dc9 Author: Jorn Vernee URL: https://git.openjdk.org/jtreg/commit/94460dc9101ab39cc611760427090d79bbbe21ef Stats: 440 lines in 4 files changed: 381 ins; 16 del; 43 mod 7903990: IDEA plugin: Itemize junit test results Reviewed-by: cstein ------------- PR: https://git.openjdk.org/jtreg/pull/260 From jpai at openjdk.org Wed May 21 05:53:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 May 2025 05:53:02 GMT Subject: RFR: 7903081: Update asmtools and remove jcov traces [v2] In-Reply-To: <87aWqBDO5kcpVrJLrQ6RjQEOTlBTuhOJg4ooRW5452w=.8126ddc0-a302-4fdd-abaa-30529411bdf4@github.com> References: <87aWqBDO5kcpVrJLrQ6RjQEOTlBTuhOJg4ooRW5452w=.8126ddc0-a302-4fdd-abaa-30529411bdf4@github.com> Message-ID: On Mon, 5 May 2025 14:41:37 GMT, Christian Stein wrote: >> Please review this change to update asmtools to 8.1 - this change also removes traces of `jcov` from the documentation. >> >> No longer blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 since the integration of commit: https://github.com/openjdk/jtreg/commit/170c35711b8cae076a6663c270306bd89526e051 > > Christian Stein has updated the pull request incrementally with two additional commits since the last revision: > > - Specify JDK 17 is required to build jtreg > - Update copyright year The changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jtreg/pull/228#pullrequestreview-2856375205 From cstein at openjdk.org Wed May 21 05:58:05 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 21 May 2025 05:58:05 GMT Subject: Integrated: 7903081: Update asmtools and remove jcov traces In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 09:49:43 GMT, Christian Stein wrote: > Please review this change to update asmtools to 8.1 - this change also removes traces of `jcov` from the documentation. > > No longer blocked by AsmTools requiring JDK 17 (or above) to be built: https://github.com/openjdk/asmtools/blob/7ea57726a181b819c4b6331b19160c4fce238b11/build/build.properties#L30-L31 since the integration of commit: https://github.com/openjdk/jtreg/commit/170c35711b8cae076a6663c270306bd89526e051 This pull request has now been integrated. Changeset: 816e6d7a Author: Christian Stein URL: https://git.openjdk.org/jtreg/commit/816e6d7a5b5bfe2e1da7ceb076d0ec172529cf8f Stats: 15 lines in 3 files changed: 0 ins; 7 del; 8 mod 7903081: Update asmtools and remove jcov traces Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jtreg/pull/228 From lujaniuk at openjdk.org Wed May 21 12:02:23 2025 From: lujaniuk at openjdk.org (Ludvig Janiuk) Date: Wed, 21 May 2025 12:02:23 GMT Subject: RFR: 7904015: --verify-exclude fails to abort the test run when discovering failures Message-ID: Exit after discovering errors in exclude files ------------- Commit messages: - Exit after discovering errors in exclude files Changes: https://git.openjdk.org/jtreg/pull/265/files Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=265&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904015 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jtreg/pull/265.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/265/head:pull/265 PR: https://git.openjdk.org/jtreg/pull/265 From jpai at openjdk.org Fri May 23 08:50:03 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 May 2025 08:50:03 GMT Subject: RFR: 7904015: --verify-exclude fails to abort the test run when discovering failures In-Reply-To: References: Message-ID: On Wed, 21 May 2025 11:58:38 GMT, Ludvig Janiuk wrote: > Exit after discovering errors in exclude files Hello Ludvig, this looks reasonable to me, but I think we should have a self test for this to verify that it indeed exits with a non-zero exit code in situations like these. ------------- PR Review: https://git.openjdk.org/jtreg/pull/265#pullrequestreview-2863697421 From cstein at openjdk.org Fri May 23 08:55:06 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 23 May 2025 08:55:06 GMT Subject: RFR: 7904015: --verify-exclude fails to abort the test run when discovering failures In-Reply-To: References:

Message-ID: On Fri, 23 May 2025 08:47:33 GMT, Jaikiran Pai wrote: > Hello Ludvig, this looks reasonable to me, but I think we should have a self test for this to verify that it indeed exits with a non-zero exit code in situations like these. Maybe the logic in `VerifyExcludeTest.gmk` can be extend to check the exit code? ------------- PR Comment: https://git.openjdk.org/jtreg/pull/265#issuecomment-2903748998 From jpai at openjdk.org Fri May 23 09:00:10 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 May 2025 09:00:10 GMT Subject: RFR: 7904015: --verify-exclude fails to abort the test run when discovering failures In-Reply-To: References:

Message-ID: On Fri, 23 May 2025 08:52:13 GMT, Christian Stein wrote: > Maybe the logic in VerifyExcludeTest.gmk can be extend to check the exit code? Yes, that should be fine. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/265#issuecomment-2903760398 From lujaniuk at openjdk.org Fri May 23 11:54:44 2025 From: lujaniuk at openjdk.org (Ludvig Janiuk) Date: Fri, 23 May 2025 11:54:44 GMT Subject: RFR: 7904015: --verify-exclude fails to abort the test run when discovering failures [v2] In-Reply-To: References: Message-ID: > Exit after discovering errors in exclude files Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jtreg/pull/265/files - new: https://git.openjdk.org/jtreg/pull/265/files/4fa2e071..9095c8e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jtreg&pr=265&range=01 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=265&range=00-01 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jtreg/pull/265.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/265/head:pull/265 PR: https://git.openjdk.org/jtreg/pull/265 From lujaniuk at openjdk.org Fri May 23 11:54:45 2025 From: lujaniuk at openjdk.org (Ludvig Janiuk) Date: Fri, 23 May 2025 11:54:45 GMT Subject: RFR: 7904015: --verify-exclude fails to abort the test run when discovering failures In-Reply-To: References: Message-ID: On Wed, 21 May 2025 11:58:38 GMT, Ludvig Janiuk wrote: > Exit after discovering errors in exclude files Thank you for the suggestion, I have added the self test. Testing the exit code itself was cumbersome, as the return code also varies with test results. I opted to check for the "test results" string instead, hope this is okay. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/265#issuecomment-2904174571 From cstein at openjdk.org Mon May 26 05:38:04 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 26 May 2025 05:38:04 GMT Subject: RFR: 7904015: --verify-exclude fails to abort the test run when discovering failures [v2] In-Reply-To: References:

Message-ID: On Fri, 23 May 2025 11:54:44 GMT, Ludvig Janiuk wrote: >> Exit after discovering errors in exclude files > > Ludvig Janiuk has updated the pull request incrementally with one additional commit since the last revision: > > Add test Marked as reviewed by cstein (Reviewer). ------------- PR Review: https://git.openjdk.org/jtreg/pull/265#pullrequestreview-2867270303 From lujaniuk at openjdk.org Mon May 26 07:23:56 2025 From: lujaniuk at openjdk.org (Ludvig Janiuk) Date: Mon, 26 May 2025 07:23:56 GMT Subject: Integrated: 7904015: --verify-exclude fails to abort the test run when discovering failures In-Reply-To: References: Message-ID: On Wed, 21 May 2025 11:58:38 GMT, Ludvig Janiuk wrote: > Exit after discovering errors in exclude files This pull request has now been integrated. Changeset: 666453dc Author: Ludvig Janiuk URL: https://git.openjdk.org/jtreg/commit/666453dc24ce74ec081664c7d048721ad2a4da81 Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod 7904015: --verify-exclude fails to abort the test run when discovering failures Reviewed-by: cstein ------------- PR: https://git.openjdk.org/jtreg/pull/265 From duke at openjdk.org Tue May 27 14:15:20 2025 From: duke at openjdk.org (andrlos) Date: Tue, 27 May 2025 14:15:20 GMT Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash testing In-Reply-To: References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com> Message-ID: On Wed, 7 May 2025 14:18:00 GMT, Christian Stein wrote: >> provides SPI for enabling external status transformations of failed tests >> >> this is a continuation of efforts after https://github.com/openjdk/jtharness/pull/59 >> >> Requires newest jtharness build (not even tagged yet) that includes above mentioned change to be compiled succesfully >> >> The main idea is to provide a unified StatusTransformer interface, that can be externally implemented by users and added to a classpath in a separate jar to allow modifications of test execution status based on some elementary analysis. This can be easily used for crashtesting (filtering out only tests with jvm crashes). > > What I still don't get is that you want to address a global goal "basic crash testing" with a very local mechanism, like something similar to JUnit 4 "TestRule". > > I think a solution lies in between your lines: > >> it proved to be much harder to filter them after, as the `hs_err_pid` log is not being copied, plus we have many tests that run via a shell script, so a generic jvm watcher is not an option as would be the option with jvm agent that we use for junit testing.. we need to cover cases, where jvm crashes even tho it has been run via a shell script (or multiple levels of scripts) and watching for `hs_err_pid.log` proved to be the most reliable and universal approach. > > So, what about making sure that `jtreg` copies `hs_err_pid` files correctly? @sormuras can definitely be tried, I did want to do something with minimal code changes as I saw it as a best chance to get it approved. Plus the TestRule approach is a very powerful way of doing so much more and could be used for other purposed in the future as well. However I can definitely give hs_err_pid files copying a look and see. Hopefully this wont break anything else. Thanks for this short brainstorming, will get back to you, once I get a PoC working. ------------- PR Comment: https://git.openjdk.org/jtreg/pull/235#issuecomment-2912670151