From pavel.rappo at gmail.com Thu Jun 5 21:21:01 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Thu, 5 Jun 2025 22:21:01 +0100 Subject: Build failure on JDK 23 Message-ID: I've just cloned jcstress and tried to build it on my machine, which has JDK 23 installed. The build failed as follows: [WARNING] COMPILATION WARNING : [INFO] ------------------------------------------------------------- [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/Multimap.java:[25,1] documentation comment is not attached to any declaration [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/TreesetMultimap.java:[25,1] documentation comment is not attached to any declaration [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/TreeMultimap.java:[25,1] documentation comment is not attached to any declaration [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/HashMultiset.java:[25,1] documentation comment is not attached to any declaration [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/Multiset.java:[25,1] documentation comment is not attached to any declaration [INFO] 5 warnings [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/Multimap.java: warnings found and -Werror specified [INFO] 1 error The reason the build failed is that a new warning introduced in JDK 23 [^1] is being triggered on some files, and that warning is being treated as an error. There are a few ways to fix this. I would recommend fixing the offending files rather than silencing the warning. Firstly, these files have duplicating copyright headers. Secondly, these copyright headers use /** instead of /* as an opener for their comment. If either of these wasn't true, the files would not have triggered the warning. Maybe there are other suggestions? If not, I can file a pull request to fix the files. [^1]: https://bugs.openjdk.org/browse/JDK-8329137 From pavel.rappo at gmail.com Thu Jun 5 21:42:29 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Thu, 5 Jun 2025 22:42:29 +0100 Subject: Outdated mailing list Message-ID: README.md has this line: > concurrency-interest at cs.oswego.edu: general discussion on concurrency The bad news is that this list is no longer available. The good news is that there's a substitute [^1]: > concurrency-discuss at openjdk.org: General discussion about concurrency topics (e.g. java.util.concurrent API) [^1]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127856.html From jvanek at redhat.com Fri Jun 6 10:58:54 2025 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 6 Jun 2025 12:58:54 +0200 Subject: Build failure on JDK 23 In-Reply-To: References: Message-ID: hi! To remove the duplicated header and to unify /** in licenses to /* sounds like very correct fi to me. Please, continue with PR. I hit it recently too, and would be nice to have this fixed. TYVM! J On 6/5/25 23:21, Pavel Rappo wrote: > I've just cloned jcstress and tried to build it on my machine, which > has JDK 23 installed. The build failed as follows: > > [WARNING] COMPILATION WARNING : > [INFO] ------------------------------------------------------------- > [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/Multimap.java:[25,1] > documentation comment is not attached to any declaration > [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/TreesetMultimap.java:[25,1] > documentation comment is not attached to any declaration > [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/TreeMultimap.java:[25,1] > documentation comment is not attached to any declaration > [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/HashMultiset.java:[25,1] > documentation comment is not attached to any declaration > [WARNING] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/Multiset.java:[25,1] > documentation comment is not attached to any declaration > [INFO] 5 warnings > [INFO] ------------------------------------------------------------- > [INFO] ------------------------------------------------------------- > [ERROR] COMPILATION ERROR : > [INFO] ------------------------------------------------------------- > [ERROR] /Users/pavelrappo/repos/jcstress/jcstress-core/src/main/java/org/openjdk/jcstress/util/Multimap.java: > warnings found and -Werror specified > [INFO] 1 error > > The reason the build failed is that a new warning introduced in JDK 23 > [^1] is being triggered on some files, and that warning is being > treated as an error. > > There are a few ways to fix this. I would recommend fixing the > offending files rather than silencing the warning. Firstly, these > files have duplicating copyright headers. Secondly, these copyright > headers use /** instead of /* as an opener for their comment. If > either of these wasn't true, the files would not have triggered the > warning. > > Maybe there are other suggestions? If not, I can file a pull request > to fix the files. > > [^1]: https://bugs.openjdk.org/browse/JDK-8329137 > -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From jvanek at redhat.com Fri Jun 6 11:05:47 2025 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 6 Jun 2025 13:05:47 +0200 Subject: Outdated mailing list In-Reply-To: References: Message-ID: On 6/5/25 23:42, Pavel Rappo wrote: > README.md has this line: > >> concurrency-interest at cs.oswego.edu: general discussion on concurrency > > The bad news is that this list is no longer available. The good news > is that there's a substitute [^1]: > >> concurrency-discuss at openjdk.org: General discussion about concurrency topics (e.g. java.util.concurrent API) +1 for PR by me. TY! > > [^1]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127856.html > -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 From prappo at openjdk.org Fri Jun 6 14:20:46 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 6 Jun 2025 14:20:46 GMT Subject: RFR: 7904025: jcstress: Remove dangling doc comments which fail build on JDK 23+ Message-ID: See for details: https://mail.openjdk.org/pipermail/jcstress-dev/2025-June/001293.html ------------- Commit messages: - Delete dangling comments elsewhere - Delete comments that prevent mvn clean verify Changes: https://git.openjdk.org/jcstress/pull/162/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=162&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904025 Stats: 179 lines in 18 files changed: 0 ins; 168 del; 11 mod Patch: https://git.openjdk.org/jcstress/pull/162.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/162/head:pull/162 PR: https://git.openjdk.org/jcstress/pull/162 From shade at openjdk.org Fri Jun 6 14:48:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 6 Jun 2025 14:48:05 GMT Subject: RFR: 7904025: jcstress: Remove dangling doc comments which fail build on JDK 23+ In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 14:15:53 GMT, Pavel Rappo wrote: > See for details: https://mail.openjdk.org/pipermail/jcstress-dev/2025-June/001293.html Looks fine, thanks. ------------- Marked as reviewed by shade (Committer). PR Review: https://git.openjdk.org/jcstress/pull/162#pullrequestreview-2905157086 From prappo at openjdk.org Fri Jun 6 14:54:07 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 6 Jun 2025 14:54:07 GMT Subject: Integrated: 7904025: jcstress: Remove dangling doc comments which fail build on JDK 23+ In-Reply-To: References: Message-ID: On Fri, 6 Jun 2025 14:15:53 GMT, Pavel Rappo wrote: > See for details: https://mail.openjdk.org/pipermail/jcstress-dev/2025-June/001293.html This pull request has now been integrated. Changeset: 9ed7ac43 Author: Pavel Rappo Committer: Aleksey Shipilev URL: https://git.openjdk.org/jcstress/commit/9ed7ac43bacc6d998037156f61719fd2f5773d28 Stats: 179 lines in 18 files changed: 0 ins; 168 del; 11 mod 7904025: jcstress: Remove dangling doc comments which fail build on JDK 23+ Reviewed-by: shade ------------- PR: https://git.openjdk.org/jcstress/pull/162 From shade at openjdk.org Fri Jun 6 15:03:06 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 6 Jun 2025 15:03:06 GMT Subject: RFR: 7903671: jcstress: Update buffer tests for JDK-8318966 In-Reply-To: References: Message-ID: <7jEnxypEu_yR5K5z69iH3bAZ9DGBxUxXXNhFfe_c6BQ=.8ed3d526-579b-449a-9216-de5827e81072@github.com> On Wed, 26 Feb 2025 17:50:28 GMT, Ji?? Van?k wrote: > part 1: Detecting jdk of target VM and exuding illegible tests > > This is prequel to full fixing of CODETOOLS-7903671. This PR detects target JDK version and then disables illegible tests. > part 2 will be done in templates of affected tests and logic around generating the classes from them. In meantime this should server. > > The jdk detection will be most likely used anyway. WDYT? If we agree on similar approach, I will create a new bug for this PR only. Finally have time to look at this. No, we are not going to hard-code test names in generic harness code. The common way to "skip" the test that are incompatible with some JDKs is to record them as "soft errors", which make them skipped. This is what [CODETOOLS-7903695](https://bugs.openjdk.org/browse/CODETOOLS-7903695) did, and it is supposed to be enough. I think status quo with soft-failing alignment `8` tests, while inconvenient, is what we want. JDK 21 should be testing the heap buffers with strong alignment constraints. If anything, we should be looking whether to update the heap tests to _also_ include alignment `1`. ------------- PR Review: https://git.openjdk.org/jcstress/pull/159#pullrequestreview-2905202197 From shade at openjdk.org Fri Jun 6 15:10:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 6 Jun 2025 15:10:05 GMT Subject: RFR: 7903754: jcstress should die asap - with report - on broken jvm/hw, instead of waiting on kill [v4] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 12:33:40 GMT, Ji?? Van?k wrote: >> Initial PoC >> >> It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed. Should be finished soon > > Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: > > replaced incorrect System.out by output I am open for all-or-nothing `-foe` (fail-on-error) option like JMH has it. There is no point, IMO, in trying to introduce a whole lot of complexity that would track and deal with a particular failure rate. ------------- PR Review: https://git.openjdk.org/jcstress/pull/157#pullrequestreview-2905216198 From jvanek at openjdk.org Fri Jun 6 15:10:05 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 6 Jun 2025 15:10:05 GMT Subject: RFR: 7903754: jcstress should die asap - with report - on broken jvm/hw, instead of waiting on kill [v4] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 12:33:40 GMT, Ji?? Van?k wrote: >> Initial PoC >> >> It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed. Should be finished soon > > Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: > > replaced incorrect System.out by output Thanx! Will update.. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/157#issuecomment-2949557765 From jvanek at openjdk.org Fri Jun 6 15:28:07 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 6 Jun 2025 15:28:07 GMT Subject: RFR: 7903671: jcstress: Update buffer tests for JDK-8318966 In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 17:50:28 GMT, Ji?? Van?k wrote: > part 1: Detecting jdk of target VM and exuding illegible tests > > This is prequel to full fixing of CODETOOLS-7903671. This PR detects target JDK version and then disables illegible tests. > part 2 will be done in templates of affected tests and logic around generating the classes from them. In meantime this should server. > > The jdk detection will be most likely used anyway. WDYT? If we agree on similar approach, I will create a new bug for this PR only. hi! Thanx a lot for eyball! If this should be the way, that I would rather run it with `alignment 1` then stay with error. The error seem redundant here. JCStress is doing a lot of checks, and the final runs are based on this. Checking the java version or ByteBuffer impl seems more reasonable.. However as far as I can tell, the `alignment 1` is not triggering the parts it was with 8 and thus not testing what it should. Sorry to say that, but I have doubts that the ByteBuffer tests are handled as soft errors. If that would be the case I think I would not bother with PR. "api mismatch" would be good enough. But as you know much better, I will try and elaborate. If they are not returning `api mismatch`, then I will elaborate in this PR so they start to return `api mismatch`. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/159#issuecomment-2949603340 From shade at openjdk.org Fri Jun 6 15:36:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 6 Jun 2025 15:36:05 GMT Subject: RFR: 7903671: jcstress: Update buffer tests for JDK-8318966 In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 17:50:28 GMT, Ji?? Van?k wrote: > part 1: Detecting jdk of target VM and exuding illegible tests > > This is prequel to full fixing of CODETOOLS-7903671. This PR detects target JDK version and then disables illegible tests. > part 2 will be done in templates of affected tests and logic around generating the classes from them. In meantime this should server. > > The jdk detection will be most likely used anyway. WDYT? If we agree on similar approach, I will create a new bug for this PR only. To emphasize, my point is that `alignment(8)` is a behavior that _someone_ likely depends on in earlier JDKs. We need to continue testing that. So `alignment(8)` should stay until the last JDK that supports it, dies. Yes, it would make sense to make sure that `alignment(8)` return `API mismatch` when run with incompatible JDK. I thought it does. If it does not, that would definitely need improvement. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/159#issuecomment-2949632717 From jvanek at openjdk.org Fri Jun 6 15:42:08 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 6 Jun 2025 15:42:08 GMT Subject: RFR: 7903671: jcstress: Update buffer tests for JDK-8318966 In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 17:50:28 GMT, Ji?? Van?k wrote: > part 1: Detecting jdk of target VM and exuding illegible tests > > This is prequel to full fixing of CODETOOLS-7903671. This PR detects target JDK version and then disables illegible tests. > part 2 will be done in templates of affected tests and logic around generating the classes from them. In meantime this should server. > > The jdk detection will be most likely used anyway. WDYT? If we agree on similar approach, I will create a new bug for this PR only. Ack. Wdyt about keeping the java version check, and on newer jdks set it to 1 then? ------------- PR Comment: https://git.openjdk.org/jcstress/pull/159#issuecomment-2949657193 From jvanek at openjdk.org Fri Jun 6 15:48:02 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 6 Jun 2025 15:48:02 GMT Subject: RFR: 7903754: jcstress should die asap - with report - on broken jvm/hw, instead of waiting on kill [v4] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 12:33:40 GMT, Ji?? Van?k wrote: >> Initial PoC >> >> It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed. Should be finished soon > > Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: > > replaced incorrect System.out by output Although I understand that your main point is to get rid of complexity, but just one thought jcstress and jmh are not comparable suites. - -foe would be serving as shortcut to `FAIL_FAST_VARIANTS set to 1`, but the way the jcstress works, that the issue may be occurring "just sometimes" moreover enforces some higher tolerance then just " fail on first error". Wdyt? Also note that most of the complexity will stay, for the sake of report generation at the end. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/157#issuecomment-2949682654 PR Comment: https://git.openjdk.org/jcstress/pull/157#issuecomment-2949688120 From shade at openjdk.org Fri Jun 6 15:49:06 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 6 Jun 2025 15:49:06 GMT Subject: RFR: 7903671: jcstress: Update buffer tests for JDK-8318966 In-Reply-To: References: Message-ID: <1Id5sZBftmJM4aqffMDJKAdhp5H44aCgqoql78-vBDA=.94dfc45a-c2fd-4efc-9e21-7dbf2a53861b@github.com> On Fri, 6 Jun 2025 15:39:50 GMT, Ji?? Van?k wrote: > Ack. Wdyt about keeping the java version check, and on newer jdks set it to 1 then? Maybe, but likely not. I could see how JDK-specific test behavior would be confusing: you run _seemingly the same test_ on different JDKs, but you actually run _different_ tests? Bisecting for regressions would get extra fun. So, I would like all JDK versions attempt to run all the tests, and gracefully fail out some of them. So older JDKs would test _both_ `alignment(1)` and `alignment(8)`. Newer JDKs only run `alignment(8)` tests. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/159#issuecomment-2949697874 From jvanek at openjdk.org Fri Jun 6 15:56:07 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 6 Jun 2025 15:56:07 GMT Subject: RFR: 7903671: jcstress: Update buffer tests for JDK-8318966 In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 17:50:28 GMT, Ji?? Van?k wrote: > part 1: Detecting jdk of target VM and exuding illegible tests > > This is prequel to full fixing of CODETOOLS-7903671. This PR detects target JDK version and then disables illegible tests. > part 2 will be done in templates of affected tests and logic around generating the classes from them. In meantime this should server. > > The jdk detection will be most likely used anyway. WDYT? If we agree on similar approach, I will create a new bug for this PR only. You mean " So older JDKs would test both alignment(1) and alignment(8). Newer JDKs only run alignment(**1**) tests." right? Well that make sense to me. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/159#issuecomment-2949715890 From shade at openjdk.org Fri Jun 6 15:56:07 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 6 Jun 2025 15:56:07 GMT Subject: RFR: 7903671: jcstress: Update buffer tests for JDK-8318966 In-Reply-To: References: Message-ID: On Wed, 26 Feb 2025 17:50:28 GMT, Ji?? Van?k wrote: > part 1: Detecting jdk of target VM and exuding illegible tests > > This is prequel to full fixing of CODETOOLS-7903671. This PR detects target JDK version and then disables illegible tests. > part 2 will be done in templates of affected tests and logic around generating the classes from them. In meantime this should server. > > The jdk detection will be most likely used anyway. WDYT? If we agree on similar approach, I will create a new bug for this PR only. Yes. We strive to test everything that users would likely end up using. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/159#issuecomment-2949719341 From prappo at openjdk.org Sun Jun 8 12:51:42 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Sun, 8 Jun 2025 12:51:42 GMT Subject: RFR: 7904024: jcstress: Update concurrency mailing list in README.md Message-ID: In addition to updating the concurrency mailing list [^1], I also updated the address for this project's list [^2] [^3]. [^1]: https://mail.openjdk.org/pipermail/jcstress-dev/2025-June/001294.html [^2]: https://mail.openjdk.org/pipermail/announce/2022-May/000318.html [^3]: https://mail.openjdk.org/pipermail/announce/2022-June/000321.html ------------- Commit messages: - Update mailing lists Changes: https://git.openjdk.org/jcstress/pull/163/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=163&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904024 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jcstress/pull/163.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/163/head:pull/163 PR: https://git.openjdk.org/jcstress/pull/163 From prappo at openjdk.org Sun Jun 8 20:25:40 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Sun, 8 Jun 2025 20:25:40 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ Message-ID: In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jcstress/pull/164/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=164&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904029 Stats: 32 lines in 5 files changed: 6 ins; 24 del; 2 mod Patch: https://git.openjdk.org/jcstress/pull/164.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/164/head:pull/164 PR: https://git.openjdk.org/jcstress/pull/164 From prappo at openjdk.org Sun Jun 8 20:58:40 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Sun, 8 Jun 2025 20:58:40 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v2] In-Reply-To: References: Message-ID: > In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Initial commit ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/164/files - new: https://git.openjdk.org/jcstress/pull/164/files/3a979398..bffdb87b Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=164&range=01 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=164&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jcstress/pull/164.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/164/head:pull/164 PR: https://git.openjdk.org/jcstress/pull/164 From prappo at openjdk.org Sun Jun 8 21:03:44 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Sun, 8 Jun 2025 21:03:44 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v2] In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 20:58:40 GMT, Pavel Rappo wrote: >> In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. > > Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Initial commit Apologies for the force pushes. I guess I'm a bit inattentive on Sunday night. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/164#issuecomment-2954274093 From prappo at openjdk.org Sun Jun 8 21:03:43 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Sun, 8 Jun 2025 21:03:43 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v3] In-Reply-To: References: Message-ID: > In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Initial commit ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/164/files - new: https://git.openjdk.org/jcstress/pull/164/files/bffdb87b..2385cbd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=164&range=02 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=164&range=01-02 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jcstress/pull/164.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/164/head:pull/164 PR: https://git.openjdk.org/jcstress/pull/164 From prappo at openjdk.org Sun Jun 8 22:26:12 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Sun, 8 Jun 2025 22:26:12 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ Message-ID: Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jcstress/pull/165/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=165&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904028 Stats: 49 lines in 24 files changed: 49 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jcstress/pull/165.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/165/head:pull/165 PR: https://git.openjdk.org/jcstress/pull/165 From jvanek at openjdk.org Mon Jun 9 13:25:15 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 9 Jun 2025 13:25:15 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 22:22:37 GMT, Pavel Rappo wrote: > Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. > > In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. > > Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. > > I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. Is the `@SuppressWarnings("removal")` 's "removal" really good enough description? Maybe "replace by VarHandle" is better? Or link sone jdk jira issue? `"removal: CODETOOLS-..."` As for me, better to do this now, as yuo have it, and later fix it properly, as the issues in jdk 23+ are multiplying. Thanx! ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2955781345 From prappo at openjdk.org Mon Jun 9 14:11:15 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 9 Jun 2025 14:11:15 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ In-Reply-To: References: Message-ID: On Mon, 9 Jun 2025 13:21:50 GMT, Ji?? Van?k wrote: > Is the `@SuppressWarnings("removal")` 's "removal" really good enough description? Maybe "replace by VarHandle" is better? Or link sone jdk jira issue? `"removal: CODETOOLS-..."` As for me, better to do this now, as yuo have it, and later fix it properly, as the issues in jdk 23+ are multiplying. Thanx! If I understood you correctly, you are asking about the "removal" argument of the `@SuppressWarnings` annotation. If so, then this argument is not free-form, but one of a few [predefined values](https://docs.oracle.com/javase/specs/jls/se23/html/jls-9.html#jls-9.6.4.5). ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2955907855 From jvanek at openjdk.org Mon Jun 9 14:38:07 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 9 Jun 2025 14:38:07 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ In-Reply-To: References: Message-ID: <2V44gHqDc-LeBZsF2jOF4S5orXc9VhUn5IZfRU5aPAU=.78f66336-222a-4b20-869f-f7e6a574d705@github.com> On Sun, 8 Jun 2025 22:22:37 GMT, Pavel Rappo wrote: > Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. > > In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. > > Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. > > I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. Right. The predefined string constants should remain. The predefined set is not strict, may depend on compiler and may contain custom values which are ignored by compiler. Sorry for not being clear. `@SuppressWarnings({"removal", "CODETOOLS-..."})` is waht I would like to see there, bBut you are right, it is not exactly common habit. (note, I'm not even committer, so better to wait for a reviewer). ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2955988342 From jvanek at openjdk.org Mon Jun 9 15:12:18 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 9 Jun 2025 15:12:18 GMT Subject: RFR: 7903754: jcstress should die asap - with report - on broken jvm/hw, instead of waiting on kill [v4] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 12:33:40 GMT, Ji?? Van?k wrote: >> Initial PoC >> >> It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed. Should be finished soon > > Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: > > replaced incorrect System.out by output One more call before redoing it - I really think the ratio will be heavily missed in future QA runs. jcstress is not jmh. When jmh fails, it is usually deterministic and stable. With jcstress it is not the case. You **want to have failures**. The reason for this is to not waste cycles on machines, where it would lead to hundred, or even hundred of thousands ..well *all* tests failures. We have it on some 10% so we usually have all results, including failures, but if we get borked hw or jvm, it will fail in hour, and not in two days. Similarly, if the VM is broken jsut a bit, there are again full results, with *all* failures. That give us excelnt compromise. Simple fail on error will heavily downgrade the usability and usage of jcstress:( As i suggested - I can introduce -foe, which will default to --failFAST=1, or I can make the number optional, and it will default eg to those moreover verified 10%. I can remove the %%, as it as proved itself, but at the end was not used by us. Similarly I can remove the double failFAST/failFast. The failFast have advantage that you always have a set finished, but is missing fine-tuning which failFAST have. We are using failFast. wdyt? ------------- PR Comment: https://git.openjdk.org/jcstress/pull/157#issuecomment-2956083041 From shade at openjdk.org Tue Jun 10 07:00:59 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 10 Jun 2025 07:00:59 GMT Subject: RFR: 7904024: jcstress: Update concurrency mailing list in README.md In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 12:47:03 GMT, Pavel Rappo wrote: > In addition to updating the concurrency mailing list [^1], I also updated the address for this project's list [^2] [^3]. > > [^1]: https://mail.openjdk.org/pipermail/jcstress-dev/2025-June/001294.html > [^2]: https://mail.openjdk.org/pipermail/announce/2022-May/000318.html > [^3]: https://mail.openjdk.org/pipermail/announce/2022-June/000321.html Marked as reviewed by shade (Committer). ------------- PR Review: https://git.openjdk.org/jcstress/pull/163#pullrequestreview-2912221427 From shade at openjdk.org Tue Jun 10 07:02:42 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 10 Jun 2025 07:02:42 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v3] In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 21:03:43 GMT, Pavel Rappo wrote: >> In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. > > Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Initial commit Changes requested by shade (Committer). jcstress-core/src/main/resources/META-INF/services/javax.annotation.processing.Processor line 1: > 1: # Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. This should really stay to benefit JDKs < 23. ------------- PR Review: https://git.openjdk.org/jcstress/pull/164#pullrequestreview-2912224668 PR Review Comment: https://git.openjdk.org/jcstress/pull/164#discussion_r2137071097 From prappo at openjdk.org Tue Jun 10 08:23:44 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 10 Jun 2025 08:23:44 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v3] In-Reply-To: References: Message-ID: <7nm0DhpU-T31Dkbfv75WYDuyy4v7p7QpATgwBUhLMGI=.5cdc4964-50a4-48c7-9244-37ae1715066d@github.com> On Tue, 10 Jun 2025 06:59:39 GMT, Aleksey Shipilev wrote: >> Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> Initial commit > > jcstress-core/src/main/resources/META-INF/services/javax.annotation.processing.Processor line 1: > >> 1: # Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. > > This should really stay to benefit JDKs < 23. In what sense does it benefit pre JDK 23? FWIW, this patch seems to work fine on JDK 17 and JDK 21. ------------- PR Review Comment: https://git.openjdk.org/jcstress/pull/164#discussion_r2137238222 From shade at openjdk.org Tue Jun 10 08:28:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 10 Jun 2025 08:28:43 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v3] In-Reply-To: <7nm0DhpU-T31Dkbfv75WYDuyy4v7p7QpATgwBUhLMGI=.5cdc4964-50a4-48c7-9244-37ae1715066d@github.com> References: <7nm0DhpU-T31Dkbfv75WYDuyy4v7p7QpATgwBUhLMGI=.5cdc4964-50a4-48c7-9244-37ae1715066d@github.com> Message-ID: On Tue, 10 Jun 2025 08:21:34 GMT, Pavel Rappo wrote: >> jcstress-core/src/main/resources/META-INF/services/javax.annotation.processing.Processor line 1: >> >>> 1: # Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. >> >> This should really stay to benefit JDKs < 23. > > In what sense does it benefit pre JDK 23? FWIW, this patch seems to work fine on JDK 17 and JDK 21. Whichever project that consumes jcstress-core as the dependency on older JDKs would stop working if we stop shipping this service binding, AFAICS? They would need the same adjustment to enable annotation processors like the rest of this PR. _This_ would be a breaking change. ------------- PR Review Comment: https://git.openjdk.org/jcstress/pull/164#discussion_r2137247369 From prappo at openjdk.org Tue Jun 10 08:54:43 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 10 Jun 2025 08:54:43 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v3] In-Reply-To: References: <7nm0DhpU-T31Dkbfv75WYDuyy4v7p7QpATgwBUhLMGI=.5cdc4964-50a4-48c7-9244-37ae1715066d@github.com> Message-ID: On Tue, 10 Jun 2025 08:26:13 GMT, Aleksey Shipilev wrote: >> In what sense does it benefit pre JDK 23? FWIW, this patch seems to work fine on JDK 17 and JDK 21. > > Whichever project that consumes jcstress-core as the dependency on older JDKs would stop working if we stop shipping this service binding, AFAICS? They would need the same adjustment to enable annotation processors like the rest of this PR. _This_ would be a breaking change. I see. I've never thought someone would use jcstress as a dependency, to generate jcstress test cases outside jcstress itself. Is it a popular use case? I'll revert this bit of the change, of course. ------------- PR Review Comment: https://git.openjdk.org/jcstress/pull/164#discussion_r2137306255 From shade at openjdk.org Tue Jun 10 09:05:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 10 Jun 2025 09:05:49 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v3] In-Reply-To: References: <7nm0DhpU-T31Dkbfv75WYDuyy4v7p7QpATgwBUhLMGI=.5cdc4964-50a4-48c7-9244-37ae1715066d@github.com> Message-ID: <2nuy9CSnohyW00YmkBDyGMuJyR09XF-toT6i8SqQuGQ=.b4312390-044f-49a6-8c00-c56d7d375439@github.com> On Tue, 10 Jun 2025 08:52:23 GMT, Pavel Rappo wrote: >> Whichever project that consumes jcstress-core as the dependency on older JDKs would stop working if we stop shipping this service binding, AFAICS? They would need the same adjustment to enable annotation processors like the rest of this PR. _This_ would be a breaking change. > > I see. I've never thought someone would use jcstress as a dependency, to generate jcstress test cases outside jcstress itself. Is it a popular use case? I'll revert this bit of the change, of course. It is a popular use case: https://github.com/search?q=jcstress-core+path%3A*.xml&type=code -- JCStress is basically a sibling of JMH. ------------- PR Review Comment: https://git.openjdk.org/jcstress/pull/164#discussion_r2137327738 From prappo at openjdk.org Tue Jun 10 09:13:25 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 10 Jun 2025 09:13:25 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v4] In-Reply-To: References: Message-ID: <0_DsaDZEqiLEoL91s6UXZeXU9NojSDKgAv_-Fux5udM=.e25cb221-6879-46c7-a86e-6b5476fd6f26@github.com> > In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Respond to feedback Partially revert 2385cbd311cc5ca4f25e82da8162adb5a4577e0e, to return the annotation processor configuration. ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/164/files - new: https://git.openjdk.org/jcstress/pull/164/files/2385cbd3..c7eec5b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=164&range=03 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=164&range=02-03 Stats: 24 lines in 1 file changed: 24 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jcstress/pull/164.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/164/head:pull/164 PR: https://git.openjdk.org/jcstress/pull/164 From duke at openjdk.org Tue Jun 10 09:13:26 2025 From: duke at openjdk.org (duke) Date: Tue, 10 Jun 2025 09:13:26 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v3] In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 21:03:43 GMT, Pavel Rappo wrote: >> In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. > > Pavel Rappo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Initial commit @pavelrappo Your change (at version c7eec5b8454d61a468c230d01e71bba57a932778) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/164#issuecomment-2958308512 From shade at openjdk.org Tue Jun 10 09:13:25 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 10 Jun 2025 09:13:25 GMT Subject: RFR: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ [v4] In-Reply-To: <0_DsaDZEqiLEoL91s6UXZeXU9NojSDKgAv_-Fux5udM=.e25cb221-6879-46c7-a86e-6b5476fd6f26@github.com> References: <0_DsaDZEqiLEoL91s6UXZeXU9NojSDKgAv_-Fux5udM=.e25cb221-6879-46c7-a86e-6b5476fd6f26@github.com> Message-ID: On Tue, 10 Jun 2025 09:10:03 GMT, Pavel Rappo wrote: >> In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback > > Partially revert 2385cbd311cc5ca4f25e82da8162adb5a4577e0e, to return > the annotation processor configuration. Looks fine, thanks. ------------- Marked as reviewed by shade (Committer). PR Review: https://git.openjdk.org/jcstress/pull/164#pullrequestreview-2912644952 From prappo at openjdk.org Tue Jun 10 09:16:40 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 10 Jun 2025 09:16:40 GMT Subject: Integrated: 7904024: jcstress: Update concurrency mailing list in README.md In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 12:47:03 GMT, Pavel Rappo wrote: > In addition to updating the concurrency mailing list [^1], I also updated the address for this project's list [^2] [^3]. > > [^1]: https://mail.openjdk.org/pipermail/jcstress-dev/2025-June/001294.html > [^2]: https://mail.openjdk.org/pipermail/announce/2022-May/000318.html > [^3]: https://mail.openjdk.org/pipermail/announce/2022-June/000321.html This pull request has now been integrated. Changeset: 63a16db2 Author: Pavel Rappo Committer: Aleksey Shipilev URL: https://git.openjdk.org/jcstress/commit/63a16db2c6736bdc8165c172b7e1dce3f6ae2be3 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 7904024: jcstress: Update concurrency mailing list in README.md Reviewed-by: shade ------------- PR: https://git.openjdk.org/jcstress/pull/163 From prappo at openjdk.org Tue Jun 10 09:17:42 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 10 Jun 2025 09:17:42 GMT Subject: Integrated: 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 20:21:39 GMT, Pavel Rappo wrote: > In addition to fixing the annotation processing, I also fixed a few "dangling doc comment" warnings I missed earlier in #162. These comments cause build failure on their own. This pull request has now been integrated. Changeset: 74907b5b Author: Pavel Rappo Committer: Aleksey Shipilev URL: https://git.openjdk.org/jcstress/commit/74907b5bf04cd98eebb4ca6ebaa5ea7a60367d7b Stats: 10 lines in 6 files changed: 6 ins; 0 del; 4 mod 7904029: jcstress: Explicitly enable annotation processors to fix build artifacts on JDK 23+ Reviewed-by: shade ------------- PR: https://git.openjdk.org/jcstress/pull/164 From liach at openjdk.org Tue Jun 10 13:31:43 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 10 Jun 2025 13:31:43 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 22:22:37 GMT, Pavel Rappo wrote: > Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. > > In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. > > Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. > > I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. We might need to consider bumping the source and target of jcstress so we can move these fences to use the VarHandle ones. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2959272430 From jvanek at openjdk.org Fri Jun 13 14:30:45 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 13 Jun 2025 14:30:45 GMT Subject: RFR: 7903754: jcstress: Implement fail-on-error run option [v5] In-Reply-To: References: Message-ID: > Initial PoC > > It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed. Should be finished soon Ji?? Van?k has updated the pull request incrementally with two additional commits since the last revision: - Removed conting of groups. It do not fill its purpose in real life - Simplified to simpe -foe Both existing swithces with parameter changed to simngle -foe swithc, whcih do not have any parameter, and if used , jcstress ends as soon as possible after first error. Dropped the %% relative metric. Was good, but was never deployed afaik. Simplifed test counting, now only tests are counted (no longer group) Kept possibility to forbid exiting in the middle of group via property Kept posibility to set limit both for absolute and relative treshold, so user can still wait for more errors to appear before it is canceled. ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/157/files - new: https://git.openjdk.org/jcstress/pull/157/files/ddc606b9..a2721637 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=157&range=04 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=157&range=03-04 Stats: 145 lines in 4 files changed: 4 ins; 107 del; 34 mod Patch: https://git.openjdk.org/jcstress/pull/157.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/157/head:pull/157 PR: https://git.openjdk.org/jcstress/pull/157 From jvanek at openjdk.org Fri Jun 13 14:37:08 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 13 Jun 2025 14:37:08 GMT Subject: RFR: 7903754: jcstress: Implement fail-on-error run option [v6] In-Reply-To: References: Message-ID: > Initial PoC > > It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed. Should be finished soon Ji?? Van?k has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Removed counting of groups. It do not fill its purpose in real life ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/157/files - new: https://git.openjdk.org/jcstress/pull/157/files/a2721637..70ee4a84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=157&range=05 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=157&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jcstress/pull/157.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/157/head:pull/157 PR: https://git.openjdk.org/jcstress/pull/157 From jvanek at openjdk.org Fri Jun 13 14:37:08 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 13 Jun 2025 14:37:08 GMT Subject: RFR: 7903754: jcstress: Implement fail-on-error run option [v4] In-Reply-To: References: Message-ID: On Fri, 21 Mar 2025 12:33:40 GMT, Ji?? Van?k wrote: >> Initial PoC >> >> It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed. Should be finished soon > > Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: > > replaced incorrect System.out by output Hi! Simplifed as you wished, and as led from my usage in last half a year. So removed everything confusing, kept just one simple `-foe` which defautls to die after first error. However I kept in the property, which allows user to set custom treshold, both relative or absolute. Please, allow this to exists. I had it set everywhere in our infra, and it helps a lot to distinguish completely borked machine, from just a bit broken jdk. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/157#issuecomment-2970590532 From jvanek at openjdk.org Fri Jun 13 14:37:09 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Fri, 13 Jun 2025 14:37:09 GMT Subject: RFR: 7903754: jcstress: Implement fail-on-error run option [v2] In-Reply-To: References: Message-ID: On Mon, 3 Feb 2025 12:33:21 GMT, Ji?? Van?k wrote: >> Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix in logic > > jcstress-core/src/main/java/org/openjdk/jcstress/infra/grading/FailFastKiller.java line 133: > >> 131: >> 132: private void verifyState(TestResult r) { >> 133: long totalFailed = failed + hardErrors; > > Maybe the `softErrors`should be counted in? Maybe configurable by some property? wdyt? done ------------- PR Review Comment: https://git.openjdk.org/jcstress/pull/157#discussion_r2145231280 From shade at openjdk.org Tue Jun 17 10:44:40 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 10:44:40 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 22:22:37 GMT, Pavel Rappo wrote: > Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. > > In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. > > Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. > > I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. I am upgrading tests to `VarHandle` here: https://github.com/openjdk/jcstress/pull/166 -- there would be leftovers that would use `Unsafe`. This PR can then put the `@SuppressWarnings` over them. Please wait before I merge #166, and then rebase. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2979863318 From shade at openjdk.org Tue Jun 17 10:45:55 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 10:45:55 GMT Subject: RFR: 7904033: jcstress: Upgrade Unsafe tests to use VarHandles Message-ID: With Unsafe being deprecated, we need to rewrite some of the tests to VarHandles. Public samples and fences tests have been rewritten to VarHandles. VarHandle fences are simple wrappers over Unsafe, we expect no surprises. Other tests were copied and reimplemented with VarHandles to still have more coverage for Unsafe paths, until Unsafe is completely removed. ------------- Commit messages: - Drop unneccessary imports - Fixed Changes: https://git.openjdk.org/jcstress/pull/166/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=166&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904033 Stats: 1022 lines in 24 files changed: 799 ins; 183 del; 40 mod Patch: https://git.openjdk.org/jcstress/pull/166.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/166/head:pull/166 PR: https://git.openjdk.org/jcstress/pull/166 From shade at openjdk.org Tue Jun 17 11:15:19 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 11:15:19 GMT Subject: RFR: 7904033: jcstress: Upgrade Unsafe tests to use VarHandles [v2] In-Reply-To: References: Message-ID: > With Unsafe being deprecated, we need to rewrite some of the tests to VarHandles. > > Public samples and fences tests have been rewritten to VarHandles. VarHandle fences are simple wrappers over Unsafe, we expect no surprises. Other tests were copied and reimplemented with VarHandles to still have more coverage for Unsafe paths, until Unsafe is completely removed. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Touchups ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/166/files - new: https://git.openjdk.org/jcstress/pull/166/files/bfd3edfd..8a2328cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=166&range=01 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=166&range=00-01 Stats: 9 lines in 9 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jcstress/pull/166.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/166/head:pull/166 PR: https://git.openjdk.org/jcstress/pull/166 From shade at openjdk.org Tue Jun 17 11:44:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 11:44:50 GMT Subject: RFR: 7904036: jcstress: Enable annotation processors for all test projects Message-ID: [CODETOOLS-7904029](https://bugs.openjdk.org/browse/CODETOOLS-7904029) is incomplete. $ java -jar tests-all/target/jcstress.jar -l | grep "All matching" All matching tests - 158 Those are only the tests from jcstress-samples. We need to enable annotation processors for all tests projects. For reference, compiled with JDK 17: $ java -jar tests-all/target/jcstress.jar -l | grep "All matching" All matching tests - 4552 ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jcstress/pull/167/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=167&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904036 Stats: 8 lines in 2 files changed: 5 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jcstress/pull/167.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/167/head:pull/167 PR: https://git.openjdk.org/jcstress/pull/167 From shade at openjdk.org Tue Jun 17 11:44:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 11:44:51 GMT Subject: RFR: 7904036: jcstress: Enable annotation processors for all test projects In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 11:38:42 GMT, Aleksey Shipilev wrote: > [CODETOOLS-7904029](https://bugs.openjdk.org/browse/CODETOOLS-7904029) is incomplete. > > > $ java -jar tests-all/target/jcstress.jar -l | grep "All matching" > All matching tests - 158 > > > Those are only the tests from jcstress-samples. We need to enable annotation processors for all tests projects. > > For reference, compiled with JDK 17: > > > $ java -jar tests-all/target/jcstress.jar -l | grep "All matching" > All matching tests - 4552 FYI, @pavelrappo ;) ------------- PR Comment: https://git.openjdk.org/jcstress/pull/167#issuecomment-2980027027 From duke at openjdk.org Tue Jun 17 12:48:29 2025 From: duke at openjdk.org (duke) Date: Tue, 17 Jun 2025 12:48:29 GMT Subject: git: openjdk/jcstress: 2 new changesets Message-ID: <9ae0be2c-d67d-4df0-8ad9-147c367edb35@openjdk.org> Changeset: c273bf78 Branch: master Author: Aleksey Shipil?v Committer: GitHub Date: 2025-06-17 14:47:01 +0000 URL: https://git.openjdk.org/jcstress/commit/c273bf78504c0c232f34d87f3fbc776834135811 7904033: jcstress: Upgrade Unsafe tests to use VarHandles ! jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/advanced/AdvancedJMM_02_MultiCopyAtomic.java ! jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/advanced/AdvancedJMM_14_SynchronizedAreNotFences.java ! jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/advanced/AdvancedJMM_15_VolatilesAreNotFences.java ! jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/basic/BasicJMM_02_AccessAtomicity.java ! src/license/gpl_cpe/header.txt + tests-custom/src/main/java/org/openjdk/jcstress/tests/atomicity/crosscache/VarHandleIntAtomicityTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/fences/FencedAcquireReleaseTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/fences/FencedDekkerTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/fences/FencedPublicationTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/fences/FencedReadTwiceTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/fenced/BooleanFencedTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/fenced/ByteFencedTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/fenced/CharFencedTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/fenced/DoubleFencedTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/fenced/FloatFencedTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/fenced/IntFencedTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/fenced/LongFencedTest.java ! tests-custom/src/main/java/org/openjdk/jcstress/tests/init/primitives/fenced/ShortFencedTest.java + tests-custom/src/main/java/org/openjdk/jcstress/tests/interrupt/VarHandleBusyLoopTest.java + tests-custom/src/main/java/org/openjdk/jcstress/tests/tearing/VarHandleArrayInterleaveTest.java + tests-custom/src/main/java/org/openjdk/jcstress/tests/tearing/VarHandleIntTearingTest.java + tests-custom/src/main/java/org/openjdk/jcstress/tests/varhandles/AddLong1.java + tests-custom/src/main/java/org/openjdk/jcstress/tests/varhandles/AddLong42.java + tests-custom/src/main/java/org/openjdk/jcstress/tests/varhandles/ReadTwiceOverVolatileReadTest.java + tests-custom/src/main/java/org/openjdk/jcstress/tests/varhandles/SetReleaseTwice.java Changeset: fd67a29c Branch: master Author: Aleksey Shipil?v Committer: GitHub Date: 2025-06-17 14:47:29 +0000 URL: https://git.openjdk.org/jcstress/commit/fd67a29c30f2d342aaaaa3aff3b3acb51f94723e 7904036: jcstress: Enable annotation processors for all test projects ! jcstress-samples/pom.xml ! jcstress-test-base/pom.xml From shade at openjdk.org Tue Jun 17 12:49:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 12:49:49 GMT Subject: Withdrawn: 7904033: jcstress: Upgrade Unsafe tests to use VarHandles In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 10:41:27 GMT, Aleksey Shipilev wrote: > With Unsafe being deprecated, we need to rewrite some of the tests to VarHandles. > > Public samples and fences tests have been rewritten to VarHandles. VarHandle fences are simple wrappers over Unsafe, we expect no surprises. Other tests were copied and reimplemented with VarHandles to still have more coverage for Unsafe paths, until Unsafe is completely removed. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jcstress/pull/166 From shade at openjdk.org Tue Jun 17 12:49:48 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 12:49:48 GMT Subject: Withdrawn: 7904036: jcstress: Enable annotation processors for all test projects In-Reply-To: References: Message-ID: <1OKyqTn7DPcmO4t5CWN-GUpDeFfZKcKVep9p8Z5SG_c=.9f191a97-cf26-4c82-9722-9e73f9741d7c@github.com> On Tue, 17 Jun 2025 11:38:42 GMT, Aleksey Shipilev wrote: > [CODETOOLS-7904029](https://bugs.openjdk.org/browse/CODETOOLS-7904029) is incomplete. > > > $ java -jar tests-all/target/jcstress.jar -l | grep "All matching" > All matching tests - 158 > > > Those are only the tests from jcstress-samples. We need to enable annotation processors for all tests projects. > > For reference, compiled with JDK 17: > > > $ java -jar tests-all/target/jcstress.jar -l | grep "All matching" > All matching tests - 4552 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jcstress/pull/167 From prappo at openjdk.org Tue Jun 17 13:56:46 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 17 Jun 2025 13:56:46 GMT Subject: RFR: 7904036: jcstress: Enable annotation processors for all test projects In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 11:38:42 GMT, Aleksey Shipilev wrote: > [CODETOOLS-7904029](https://bugs.openjdk.org/browse/CODETOOLS-7904029) is incomplete. > > > $ java -jar tests-all/target/jcstress.jar -l | grep "All matching" > All matching tests - 158 > > > Those are only the tests from jcstress-samples. We need to enable annotation processors for all tests projects. > > For reference, compiled with JDK 17: > > > $ java -jar tests-all/target/jcstress.jar -l | grep "All matching" > All matching tests - 4552 That was the correct fix. Thanks, Aleksey. I wonder if there is a simple test for that. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/167#issuecomment-2980481812 From shade at openjdk.org Tue Jun 17 20:10:55 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 17 Jun 2025 20:10:55 GMT Subject: RFR: 7904034: jcstress: Run with global int/C1/C2 modes even with split compilation Message-ID: WIP. [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) shows there is a gap in current configuration coverage with jcstress. When split compilation is enabled, harness asks to int/C1/C2 each actor method separately. Unfortunately, there are cases in Hotspot where the barrier scheme depends on whether C2 is globally enabled. [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) would fail split int/C1 test with C2 globally disabled. Therefore, harness should run with global int/C1/C2 modes even with split compilation. This complicates testing matrix quite a bit, but it should capture bugs like [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) more reliably. ------------- Commit messages: - Filter C2 stress options - Something works - Work Changes: https://git.openjdk.org/jcstress/pull/168/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=168&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904034 Stats: 126 lines in 3 files changed: 92 ins; 12 del; 22 mod Patch: https://git.openjdk.org/jcstress/pull/168.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/168/head:pull/168 PR: https://git.openjdk.org/jcstress/pull/168 From shade at openjdk.org Wed Jun 18 08:30:22 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 08:30:22 GMT Subject: RFR: 7904034: jcstress: Run with global int/C1/C2 modes even with split compilation [v2] In-Reply-To: References: Message-ID: > WIP. > > [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) shows there is a gap in current configuration coverage with jcstress. When split compilation is enabled, harness asks to int/C1/C2 each actor method separately. Unfortunately, there are cases in Hotspot where the barrier scheme depends on whether C2 is globally enabled. [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) would fail split int/C1 test with C2 globally disabled. > > Therefore, harness should run with global int/C1/C2 modes even with split compilation. This complicates testing matrix quite a bit, but it should capture bugs like [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) more reliably. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Cleanups ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/168/files - new: https://git.openjdk.org/jcstress/pull/168/files/4c2fb25a..16ad3c03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=168&range=01 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=168&range=00-01 Stats: 46 lines in 2 files changed: 17 ins; 2 del; 27 mod Patch: https://git.openjdk.org/jcstress/pull/168.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/168/head:pull/168 PR: https://git.openjdk.org/jcstress/pull/168 From shade at openjdk.org Wed Jun 18 08:46:20 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 08:46:20 GMT Subject: RFR: 7904039: jcstress: Rework Dekker tests to include reference types Message-ID: [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) shows there is a gap in testing: we only verify Dekker-style scenarios over primitive volatiles. We need to extend this to reference types. There is a larger amendment to include reference types in seqcst-generator tests. ------------- Commit messages: - Whitespace - Missing test - More - Fix Changes: https://git.openjdk.org/jcstress/pull/169/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=169&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904039 Stats: 130 lines in 7 files changed: 53 ins; 70 del; 7 mod Patch: https://git.openjdk.org/jcstress/pull/169.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/169/head:pull/169 PR: https://git.openjdk.org/jcstress/pull/169 From shade at openjdk.org Wed Jun 18 09:25:28 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 09:25:28 GMT Subject: RFR: 7904039: jcstress: Rework Dekker tests to include reference types [v2] In-Reply-To: References: Message-ID: <4YGzqqPhRdru9cw4HCjgaYxwX0zONn4KATKeNEbhJH0=.3a911c3b-6ea9-4836-a076-31a78b4bab50@github.com> > [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) shows there is a gap in testing: we only verify Dekker-style scenarios over primitive volatiles. We need to extend this to reference types. > > There is a larger amendment to include reference types in seqcst-generator tests. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Fix the test name ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/169/files - new: https://git.openjdk.org/jcstress/pull/169/files/7c031ba8..90ed392b Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=169&range=01 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=169&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jcstress/pull/169.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/169/head:pull/169 PR: https://git.openjdk.org/jcstress/pull/169 From shade at openjdk.org Wed Jun 18 09:31:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 09:31:54 GMT Subject: RFR: 7904040: jcstress: Drop default stress-fork to 1 Message-ID: With incoming test changes, we have more configurations to run. To keep run time within reasonable bounds, it makes more sense to drop default -fsm to 1. Users could still re-define it to larger values to get more stress out of individual tests. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jcstress/pull/170/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=170&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904040 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jcstress/pull/170.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/170/head:pull/170 PR: https://git.openjdk.org/jcstress/pull/170 From duke at openjdk.org Wed Jun 18 10:19:59 2025 From: duke at openjdk.org (duke) Date: Wed, 18 Jun 2025 10:19:59 GMT Subject: git: openjdk/jcstress: 2 new changesets Message-ID: <79b3b6cf-1dbc-4da5-a862-abc45884a70e@openjdk.org> Changeset: a26f98a9 Branch: master Author: Aleksey Shipil?v Committer: GitHub Date: 2025-06-18 12:18:29 +0000 URL: https://git.openjdk.org/jcstress/commit/a26f98a9047c7e1826eba318707e925d672d172c 7904034: jcstress: Run with global int/C1/C2 modes even with split compilation ! jcstress-core/src/main/java/org/openjdk/jcstress/JCStress.java ! jcstress-core/src/main/java/org/openjdk/jcstress/vm/CompileMode.java ! jcstress-core/src/main/java/org/openjdk/jcstress/vm/VMSupport.java Changeset: cb4b8307 Branch: master Author: Aleksey Shipil?v Committer: GitHub Date: 2025-06-18 12:18:58 +0000 URL: https://git.openjdk.org/jcstress/commit/cb4b83071d4be2184a04d019ef8efdec188e2d33 7904039: jcstress: Rework Dekker tests to include reference types ! .github/workflows/pre-integration.yml = tests-custom/src/main/java/org/openjdk/jcstress/tests/dekker/DekkerRelaxation1Test.java = tests-custom/src/main/java/org/openjdk/jcstress/tests/dekker/DekkerRelaxation2Test.java = tests-custom/src/main/java/org/openjdk/jcstress/tests/dekker/FencedDekkerTest.java + tests-custom/src/main/java/org/openjdk/jcstress/tests/dekker/RefDekkerTest.java = tests-custom/src/main/java/org/openjdk/jcstress/tests/dekker/RelaxedDekkerTest.java = tests-custom/src/main/java/org/openjdk/jcstress/tests/dekker/VolatileDekkerTest.java - tests-custom/src/main/java/org/openjdk/jcstress/tests/varhandles/DekkerTest.java From shade at openjdk.org Wed Jun 18 10:20:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 10:20:43 GMT Subject: Withdrawn: 7904034: jcstress: Run with global int/C1/C2 modes even with split compilation In-Reply-To: References: Message-ID: <7OvecgwRiwxx_rdKlydY_k3ewZxalyA4C6e48p2eX6M=.4eebce5a-1b7d-4725-bc1f-f90218f4a993@github.com> On Tue, 17 Jun 2025 19:36:53 GMT, Aleksey Shipilev wrote: > WIP. > > [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) shows there is a gap in current configuration coverage with jcstress. When split compilation is enabled, harness asks to int/C1/C2 each actor method separately. Unfortunately, there are cases in Hotspot where the barrier scheme depends on whether C2 is globally enabled. [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) would fail split int/C1 test with C2 globally disabled. > > Therefore, harness should run with global int/C1/C2 modes even with split compilation. This complicates testing matrix quite a bit, but it should capture bugs like [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) more reliably. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jcstress/pull/168 From shade at openjdk.org Wed Jun 18 10:20:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 10:20:53 GMT Subject: RFR: 7904042: jcstress: Native access warnings when running with JDK 25 Message-ID: Current jcstress uses JNA for affinity setup. It causes lots of warnings when running with JDK 25. This PR tries to fix most of them. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jcstress/pull/171/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=171&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904042 Stats: 33 lines in 5 files changed: 30 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jcstress/pull/171.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/171/head:pull/171 PR: https://git.openjdk.org/jcstress/pull/171 From shade at openjdk.org Wed Jun 18 10:21:46 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 10:21:46 GMT Subject: Withdrawn: 7904039: jcstress: Rework Dekker tests to include reference types In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 08:41:33 GMT, Aleksey Shipilev wrote: > [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) shows there is a gap in testing: we only verify Dekker-style scenarios over primitive volatiles. We need to extend this to reference types. > > There is a larger amendment to include reference types in seqcst-generator tests. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jcstress/pull/169 From shade at openjdk.org Wed Jun 18 10:22:42 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 10:22:42 GMT Subject: Withdrawn: 7904040: jcstress: Drop default stress-fork to 1 In-Reply-To: References: Message-ID: <0zZmBTaEXjKBkuh-mwu98O-2xwQB_uIpaLjmp7A1iiQ=.8737c46a-20ea-4cdb-ac79-f0e1bf2cc6d8@github.com> On Wed, 18 Jun 2025 09:27:18 GMT, Aleksey Shipilev wrote: > With incoming test changes, we have more configurations to run. To keep run time within reasonable bounds, it makes more sense to drop default -fsm to 1. Users could still re-define it to larger values to get more stress out of individual tests. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jcstress/pull/170 From duke at openjdk.org Wed Jun 18 10:23:42 2025 From: duke at openjdk.org (duke) Date: Wed, 18 Jun 2025 10:23:42 GMT Subject: git: openjdk/jcstress: 7904040: jcstress: Drop default stress-fork to 1 Message-ID: <01776f70-6137-4173-a3eb-8316c1dc8ef0@openjdk.org> Changeset: 46f4cc3e Branch: master Author: Aleksey Shipil?v Committer: GitHub Date: 2025-06-18 12:19:51 +0000 URL: https://git.openjdk.org/jcstress/commit/46f4cc3e2da0a67e756d8df740db4d20d03372d2 7904040: jcstress: Drop default stress-fork to 1 ! jcstress-core/src/main/java/org/openjdk/jcstress/Options.java From shade at openjdk.org Wed Jun 18 10:26:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 10:26:14 GMT Subject: RFR: 7904041: jcstress: Amend seqcst tests with reference types Message-ID: [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) shows there is a gap in testing: we only verify seqcst scenarios over primitive volatiles. We need to extend this to reference types. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jcstress/pull/172/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=172&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904041 Stats: 39 lines in 3 files changed: 31 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jcstress/pull/172.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/172/head:pull/172 PR: https://git.openjdk.org/jcstress/pull/172 From duke at openjdk.org Wed Jun 18 12:21:34 2025 From: duke at openjdk.org (duke) Date: Wed, 18 Jun 2025 12:21:34 GMT Subject: git: openjdk/jcstress: 7904041: jcstress: Amend seqcst tests with reference types Message-ID: <6725c8d2-5bca-4ea1-a5f1-feb1870a0acb@openjdk.org> Changeset: ff031f1c Branch: master Author: Aleksey Shipil?v Committer: GitHub Date: 2025-06-18 14:20:02 +0000 URL: https://git.openjdk.org/jcstress/commit/ff031f1c864ae98fdac22394a975897939e64e28 7904041: jcstress: Amend seqcst tests with reference types ! jcstress-test-gen/src/main/java/org/openjdk/jcstress/chapters/Chapter0bTestGenerator.java ! jcstress-test-gen/src/main/java/org/openjdk/jcstress/generator/seqcst/SeqCstTraceGenerator.java ! jcstress-test-gen/src/main/java/org/openjdk/jcstress/generator/seqcst/Target.java From shade at openjdk.org Wed Jun 18 12:22:47 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 12:22:47 GMT Subject: Withdrawn: 7904041: jcstress: Amend seqcst tests with reference types In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 10:17:50 GMT, Aleksey Shipilev wrote: > [JDK-8351997](https://bugs.openjdk.org/browse/JDK-8351997) shows there is a gap in testing: we only verify seqcst scenarios over primitive volatiles. We need to extend this to reference types. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jcstress/pull/172 From shade at openjdk.org Wed Jun 18 19:11:22 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 18 Jun 2025 19:11:22 GMT Subject: RFR: 7904042: jcstress: Native access warnings when running with JDK 25 [v2] In-Reply-To: References: Message-ID: > Current jcstress uses JNA for affinity setup. It causes lots of warnings when running with JDK 25. > > This PR tries to fix most of them. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fix JNA unpacking - Merge branch 'master' into CODETOOLS-7904042-native-access-warnings - Fix ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/171/files - new: https://git.openjdk.org/jcstress/pull/171/files/66233003..dbf286f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=171&range=01 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=171&range=00-01 Stats: 372 lines in 16 files changed: 242 ins; 88 del; 42 mod Patch: https://git.openjdk.org/jcstress/pull/171.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/171/head:pull/171 PR: https://git.openjdk.org/jcstress/pull/171 From shade at openjdk.org Thu Jun 19 05:58:40 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Jun 2025 05:58:40 GMT Subject: Withdrawn: 7904042: jcstress: Native access warnings when running with JDK 25 In-Reply-To: References: Message-ID: On Wed, 18 Jun 2025 10:17:08 GMT, Aleksey Shipilev wrote: > Current jcstress uses JNA for affinity setup. It causes lots of warnings when running with JDK 25. > > This PR tries to fix most of them. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jcstress/pull/171 From duke at openjdk.org Thu Jun 19 05:59:02 2025 From: duke at openjdk.org (duke) Date: Thu, 19 Jun 2025 05:59:02 GMT Subject: git: openjdk/jcstress: 7904042: jcstress: Native access warnings when running with JDK 25 Message-ID: Changeset: aaca729f Branch: master Author: Aleksey Shipil?v Committer: GitHub Date: 2025-06-19 07:56:02 +0000 URL: https://git.openjdk.org/jcstress/commit/aaca729f5bf02d30c3c467377a79ef6b6d2f0659 7904042: jcstress: Native access warnings when running with JDK 25 ! jcstress-core/src/main/java/org/openjdk/jcstress/JCStress.java ! jcstress-core/src/main/java/org/openjdk/jcstress/TestExecutor.java + jcstress-core/src/main/java/org/openjdk/jcstress/os/AffinitySupportPrepareMain.java ! jcstress-core/src/main/java/org/openjdk/jcstress/os/OSSupport.java ! jcstress-core/src/main/java/org/openjdk/jcstress/util/StringUtils.java ! jcstress-core/src/main/java/org/openjdk/jcstress/vm/VMSupport.java From jvanek at openjdk.org Thu Jun 19 06:49:59 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Thu, 19 Jun 2025 06:49:59 GMT Subject: RFR: 7903819: jcstress do not print structuralised results In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 15:46:48 GMT, Ji?? Van?k wrote: > Jcstress are generating very good html report, which is however not exactly great for automated comapriosns over various systyems and architectures. This pr is adding junit-like, configurable report. Faith restored! ------------- PR Comment: https://git.openjdk.org/jcstress/pull/158#issuecomment-2986832527 From jvanek at openjdk.org Thu Jun 19 06:50:02 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Thu, 19 Jun 2025 06:50:02 GMT Subject: RFR: 7903889: jcstress: document used properites (and env variables) [v5] In-Reply-To: References: <_id_iOGQYGai8cFr-oaXer0R8UivNlj7-ZavmtRzetU=.1c07c8af-058d-4a9e-b83b-3a23bfb68776@github.com> Message-ID: On Sat, 25 Jan 2025 12:27:14 GMT, Ji?? Van?k wrote: >> The purpose of this PR is to move properties and properties based initializations to single place, and to document them, and to enable printing the listing with the documentation via help. >> >> No Env. vars were found. >> >> The verbose help can be removed, the individual properties with defaults are wrapped to its class. The OptionSpec and OptionFormatter can be used if needed > > Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: > > Moved declaration of individual proeprties to ceparate classes by family Faith restored! ------------- PR Comment: https://git.openjdk.org/jcstress/pull/156#issuecomment-2986832099 From jvanek at openjdk.org Thu Jun 19 06:52:33 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Thu, 19 Jun 2025 06:52:33 GMT Subject: RFR: 7903750: TimeBudget (-tb) does not fulfill its promisses [v7] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 14:01:37 GMT, Ji?? Van?k wrote: >> Added warning, when time budget is to small, and final run will run at least two times longer. > > Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: > > Removed duplicated construcion of timebudget Faith restored! ------------- PR Comment: https://git.openjdk.org/jcstress/pull/161#issuecomment-2986831624 From shade at openjdk.org Thu Jun 19 07:42:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Jun 2025 07:42:43 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 22:22:37 GMT, Pavel Rappo wrote: > Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. > > In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. > > Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. > > I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. I think this PR is the only (?) thing that keeps us from building on JDK 25 cleanly. Please complete it, as time allows. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2987070185 From prappo at openjdk.org Thu Jun 19 09:06:25 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 19 Jun 2025 09:06:25 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ [v2] In-Reply-To: References: Message-ID: > Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. > > In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. > > Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. > > I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into CODETOOLS-7904028 - Initial commit ------------- Changes: https://git.openjdk.org/jcstress/pull/165/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=165&range=01 Stats: 18 lines in 8 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jcstress/pull/165.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/165/head:pull/165 PR: https://git.openjdk.org/jcstress/pull/165 From shade at openjdk.org Thu Jun 19 09:09:05 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Jun 2025 09:09:05 GMT Subject: RFR: 7903750: TimeBudget (-tb) does not fulfill its promisses [v7] In-Reply-To: References: Message-ID: On Wed, 26 Mar 2025 14:01:37 GMT, Ji?? Van?k wrote: >> Added warning, when time budget is to small, and final run will run at least two times longer. > > Ji?? Van?k has updated the pull request incrementally with one additional commit since the last revision: > > Removed duplicated construcion of timebudget Please pull/rebase to current master :) ------------- PR Comment: https://git.openjdk.org/jcstress/pull/161#issuecomment-2987329884 From shade at openjdk.org Thu Jun 19 09:10:42 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Jun 2025 09:10:42 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 09:06:25 GMT, Pavel Rappo wrote: >> Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. >> >> In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. >> >> Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. >> >> I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into CODETOOLS-7904028 > - Initial commit Dang, I think your GHA workflows are not enabled. Please go to https://github.com/pavelrappo/jcstress/actions, enable the workflow, and trigger it on your PR branch. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2987334724 From shade at openjdk.org Thu Jun 19 09:22:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Jun 2025 09:22:49 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 09:06:25 GMT, Pavel Rappo wrote: >> Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. >> >> In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. >> >> Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. >> >> I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into CODETOOLS-7904028 > - Initial commit It is not very clear why sometimes we do `@SuppressWarnings` on the class, and sometimes on the fields/methods. I think doing all annotations on class-level is clean enough. Your call, though. ------------- Marked as reviewed by shade (Committer). PR Review: https://git.openjdk.org/jcstress/pull/165#pullrequestreview-2942237733 From prappo at openjdk.org Thu Jun 19 09:37:36 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 19 Jun 2025 09:37:36 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ [v2] In-Reply-To: References: Message-ID: On Thu, 19 Jun 2025 09:20:01 GMT, Aleksey Shipilev wrote: > It is not very clear why sometimes we do `@SuppressWarnings` on the class, and sometimes on the fields/methods. I think doing all annotations on class-level is clean enough. Your call, though. IIRC, `@SuppressWarnings` can be applied only in certain contexts. Sometimes the least broad context if the class. For example, these are declarations to which the annotation is applicable: * @SuppressWarnings("removal") public static final long ARRAY_BASE_OFFSET = UNSAFE.arrayBaseOffset(byte[].class); * @Actor public void actor2(BBBB_Result r) { @SuppressWarnings("removal") int t = UNSAFE.getInt(bytes, offset); * @SuppressWarnings("removal") @Actor public void actor1() { This is a declaration to which it is __NOT__ applicable: * static { try { offset = UNSAFE.objectFieldOffset(UnsafeBusyLoopTest.class.getDeclaredField("isStopped")); } catch (NoSuchFieldException e) { throw new IllegalStateException(e); } } ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2987413183 From shade at openjdk.org Thu Jun 19 09:37:37 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Jun 2025 09:37:37 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ [v2] In-Reply-To: References: Message-ID: <9NjRPapAdpFk3SjHMfeStmHRqTyKRiHR3y_lTxvvr8o=.53458bd2-229c-4794-92bd-98dcb4ee0b2b@github.com> On Thu, 19 Jun 2025 09:06:25 GMT, Pavel Rappo wrote: >> Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. >> >> In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. >> >> Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. >> >> I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into CODETOOLS-7904028 > - Initial commit Sure, OK. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2987420934 From prappo at openjdk.org Thu Jun 19 09:48:29 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 19 Jun 2025 09:48:29 GMT Subject: RFR: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ [v2] In-Reply-To: <9NjRPapAdpFk3SjHMfeStmHRqTyKRiHR3y_lTxvvr8o=.53458bd2-229c-4794-92bd-98dcb4ee0b2b@github.com> References: <9NjRPapAdpFk3SjHMfeStmHRqTyKRiHR3y_lTxvvr8o=.53458bd2-229c-4794-92bd-98dcb4ee0b2b@github.com> Message-ID: On Thu, 19 Jun 2025 09:35:03 GMT, Aleksey Shipilev wrote: > Sure, OK. Sorry, I answered your question only partially; my bad. This is an excerpt from that annotation doc comment: > As a matter of style, programmers should always use this annotation on the most deeply nested element where it is effective. For example, if you want to suppress a warning in a particular method, you should annotate that method rather than its class. I think that one of the reasons behind this recommendation is to minimise the chances that one day you _unknowingly_ suppress more than you think you do: in the future, something that you use in the class might be deprecated for removal, and you won't know it. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/165#issuecomment-2987449844 From shade at openjdk.org Thu Jun 19 09:50:45 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Jun 2025 09:50:45 GMT Subject: RFR: 7904043: jcstress: AdvancedJMM_15_VolatilesAreNotFences.Fences is failing after CODETOOLS-7904033 Message-ID: <9InroUCIFh4PGtnR3cCPlrkZsQhTsLU7Qm78l79uFaM=.d297b0bb-88fe-4ca1-80ec-c8a3ae228c9d@github.com> In [CODETOOLS-7904033](https://bugs.openjdk.org/browse/CODETOOLS-7904033), I made a little mistake of rewriting Unsafe.storeFence to VarHandle.acquireFence. It should be VarHandle.releaseFence. That subtest is currently failing on AArch64. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jcstress/pull/173/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=173&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904043 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jcstress/pull/173.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/173/head:pull/173 PR: https://git.openjdk.org/jcstress/pull/173 From prappo at openjdk.org Thu Jun 19 09:53:43 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 19 Jun 2025 09:53:43 GMT Subject: Integrated: 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ In-Reply-To: References: Message-ID: On Sun, 8 Jun 2025 22:22:37 GMT, Pavel Rappo wrote: > Here I propose a simple, symptomatic solution to fix build failures on JDK 23+ caused by treating "deprecated for removal" warnings as errors. > > In the patch, I tried to keep the scope of `@SuppressWarnings` to a minimum. However, in a few cases I had to broaden it. This is because this annotation cannot be applied to a static initializer or an assignment within it. > > Instead of extracting code into methods for the sake of annotating those, I annotated the smallest annotatable outer element, which was the top-level class. For example, see: `UnsafeBusyLoopTest`, `UnsafeAddLong1`, `UnsafeAddLong42`. > > I note that in JBS @shipilev suggested another approach to address the warnings. Namely, to move from `Unsafe` to `VarHandle`. However, such an approach is beyond my competence. And if chosen, it should be done by someone else. Thanks. This pull request has now been integrated. Changeset: 8563b0cd Author: Pavel Rappo Committer: Aleksey Shipilev URL: https://git.openjdk.org/jcstress/commit/8563b0cdfc14bfd5b8f231ad241869039d3af32f Stats: 18 lines in 8 files changed: 18 ins; 0 del; 0 mod 7904028: jcstress: Address s.m.Unsafe use warnings which fail build on JDK 23+ Reviewed-by: shade ------------- PR: https://git.openjdk.org/jcstress/pull/165 From duke at openjdk.org Thu Jun 19 10:02:01 2025 From: duke at openjdk.org (duke) Date: Thu, 19 Jun 2025 10:02:01 GMT Subject: git: openjdk/jcstress: 7904043: jcstress: AdvancedJMM_15_VolatilesAreNotFences.Fences is failing after CODETOOLS-7904033 Message-ID: Changeset: 1d143cbd Branch: master Author: Aleksey Shipil?v Committer: GitHub Date: 2025-06-19 11:58:40 +0000 URL: https://git.openjdk.org/jcstress/commit/1d143cbd430f4cca63a8f0c8c1fad3aabc065421 7904043: jcstress: AdvancedJMM_15_VolatilesAreNotFences.Fences is failing after CODETOOLS-7904033 ! jcstress-samples/src/main/java/org/openjdk/jcstress/samples/jmm/advanced/AdvancedJMM_15_VolatilesAreNotFences.java From shade at openjdk.org Thu Jun 19 10:02:44 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 19 Jun 2025 10:02:44 GMT Subject: Withdrawn: 7904043: jcstress: AdvancedJMM_15_VolatilesAreNotFences.Fences is failing after CODETOOLS-7904033 In-Reply-To: <9InroUCIFh4PGtnR3cCPlrkZsQhTsLU7Qm78l79uFaM=.d297b0bb-88fe-4ca1-80ec-c8a3ae228c9d@github.com> References: <9InroUCIFh4PGtnR3cCPlrkZsQhTsLU7Qm78l79uFaM=.d297b0bb-88fe-4ca1-80ec-c8a3ae228c9d@github.com> Message-ID: On Thu, 19 Jun 2025 09:46:23 GMT, Aleksey Shipilev wrote: > In [CODETOOLS-7904033](https://bugs.openjdk.org/browse/CODETOOLS-7904033), I made a little mistake of rewriting Unsafe.storeFence to VarHandle.acquireFence. It should be VarHandle.releaseFence. That subtest is currently failing on AArch64. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jcstress/pull/173 From jvanek at openjdk.org Mon Jun 23 08:21:56 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 23 Jun 2025 08:21:56 GMT Subject: RFR: 7903754: jcstress: Implement fail-on-error run option [v7] In-Reply-To: References: Message-ID: > Initial PoC > > It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed. Should be finished soon Ji?? Van?k has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Removed counting of groups. It do not fill its purpose in real life - Simplified to simpe -foe Both existing swithces with parameter changed to simngle -foe swithc, whcih do not have any parameter, and if used , jcstress ends as soon as possible after first error. Dropped the %% relative metric. Was good, but was never deployed afaik. Simplifed test counting, now only tests are counted (no longer group) Kept possibility to forbid exiting in the middle of group via property Kept posibility to set limit both for absolute and relative treshold, so user can still wait for more errors to appear before it is canceled. - replaced incorrect System.out by output - Experimental counting of softErrors through property - Fix in logic - Repalced list.size by counting collector - Implemented main terminating logic - Moved the dying message to correct place - Refactored ConsoleReport and Failfast to share test counting logic - typo - ... and 1 more: https://git.openjdk.org/jcstress/compare/1d143cbd...389dd675 ------------- Changes: https://git.openjdk.org/jcstress/pull/157/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=157&range=06 Stats: 250 lines in 6 files changed: 215 ins; 30 del; 5 mod Patch: https://git.openjdk.org/jcstress/pull/157.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/157/head:pull/157 PR: https://git.openjdk.org/jcstress/pull/157 From jvanek at openjdk.org Mon Jun 23 08:22:32 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 23 Jun 2025 08:22:32 GMT Subject: RFR: 7903750: TimeBudget (-tb) does not fulfill its promisses [v8] In-Reply-To: References: Message-ID: > Added warning, when time budget is to small, and final run will run at least two times longer. Ji?? Van?k has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Removed duplicated construcion of timebudget - directly return new instance without intermediate variable Co-authored-by: Galder Zamarre?o - Removed table like formatting for time budget warnning - Removed unnecesasary NPE check in getTimeBudget The NPE workaround was causing NPE to be only delayed for later - Removed unnecessary shortening of MS before next conversion - ms -= TimeUnit.HOURS.toMillis(hours); - ms -= TimeUnit.MINUTES.toMillis(minutes); - Used WARNING: and FATAL: instead of +++ WARNING - and +++ FATAL - - renamed getNiceMsTimeDate to formatMsToDaysAndTime - Replaced System.out by preset out - added warning if timebudget is to small - print time budfget also for listing Required two small refactorings to get nice code reused - ... and 1 more: https://git.openjdk.org/jcstress/compare/0b4df885...cbedff70 ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/161/files - new: https://git.openjdk.org/jcstress/pull/161/files/7b68f54b..cbedff70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=161&range=07 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=161&range=06-07 Stats: 1673 lines in 74 files changed: 1124 ins; 437 del; 112 mod Patch: https://git.openjdk.org/jcstress/pull/161.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/161/head:pull/161 PR: https://git.openjdk.org/jcstress/pull/161 From jvanek at openjdk.org Mon Jun 23 08:45:52 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 23 Jun 2025 08:45:52 GMT Subject: RFR: 7903774: make all tests combinations printing nicer and/or configurable [v10] In-Reply-To: <3wZeI91CX_iFefOZJdSxdmZFSyzjd8-w1PJXYufNxrM=.77abf5c8-c5ca-45b9-9b8b-e5c0a7e9b478@github.com> References: <3wZeI91CX_iFefOZJdSxdmZFSyzjd8-w1PJXYufNxrM=.77abf5c8-c5ca-45b9-9b8b-e5c0a7e9b478@github.com> Message-ID: > This is still WIP, but already on row what [CODETOOLS-7903774](https://bugs.openjdk.org/browse/CODETOOLS-7903774) suggested. > > It will be finished once all desired output combinations are included, but already now is doing the usage of listing much more comfortable and code readable. > > From: > > `TESTS` - as introduced by https://github.com/openjdk/jcstress/pull/149 > `COMBINATIONS` - as introduced in https://github.com/openjdk/jcstress/pull/149 verbose mode (thus surpassing the `-v` impact > `ALL_TESTS` - all tests as it was before https://github.com/openjdk/jcstress/pull/149 > `COMBINATIONS_GROUPED ` - as suggested in https://github.com/openjdk/jcstress/pull/149#discussion_r1668678910 > `COMBINATIONS_JSON` same as combinations, but a valid json > `COMBINATIONS_GROUPS` same as COMBINATIONS_GROUPED only instead of enumeration in each group, only count of members will be printed > > > * TESTS are already implemented as ALL_MATCHING > * COMBINATIONS as ALL_MATCHING_COMBINATIONS > * ALL_TESTS as ALL > > COMBINATIONS_GROUPED, and COMBINATIONS_GROUPS are under development. > The _JSON variants are tobe decided, but ability to JQL it sounds nice. > > Suggestion to better names welcomed. Ji?? Van?k has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Implemented proper json listings - id can be used both flatten (so equal to plaintext) or properly strcutured for JQ (default) - listing can be redirecd to stderr to use with `jq` directly - ALL now corectly return all tests - Added property to control json variants fragemnts if true, the key will be written as: "[actor1, actor2], spinLoopStyle: Thread.onSpinWait(), threads: 2, forkId: 0, maxFootprintMB: 64, compileMode: 7, shClass: (PG 0, CG 0), (PG 0, CG 0), strideSize: 256, strideCount: 40, cpuMap: null, [-XX:+UseBiasedLocking, -XX:+StressLCM, -XX:+StressGCM, -XX:+StressIGVN, -XX:+StressCCP, -XX:StressSeed=yyyyyyyy]" otherwise (default), it will be written as ... "actorNames": ["actor1", "actor2"], "spinLoopStyle": "Thread.onSpinWait()", "threads": 2, "forkId": 0, "maxFootprintMB": 64, "compileMode": 7, "shClass": "(PG 0, CG 0), (PG 0, CG 0)", "strideSize": 256, "strideCount": 40, "cpuMap": "null", "jvmArgs": [-XX:+UseBiasedLocking, -XX:+StressLCM, -XX:+StressGCM, -XX:+StressIGVN, -XX:+StressCCP, -XX:StressSeed=yyyyyyyy]" ... - Implemented naive json formatting To cut away the header one can use: | sed '0,/^All.*[0-9]\+$/d' - Implemented totaling of listing only - Fixed spacing in help - Removed redundnant hyphen - implemented MATCHING_(INVERTED)GROUPS(_COUNT) - Refactored lsiting so it takes proper argument instead of misusing verbose switch and thus returned the ability to print allavailable tetest - refactored listTests() to its own class ------------- Changes: https://git.openjdk.org/jcstress/pull/153/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=153&range=09 Stats: 430 lines in 6 files changed: 382 ins; 22 del; 26 mod Patch: https://git.openjdk.org/jcstress/pull/153.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/153/head:pull/153 PR: https://git.openjdk.org/jcstress/pull/153 From jvanek at openjdk.org Mon Jun 23 08:49:27 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 23 Jun 2025 08:49:27 GMT Subject: RFR: 7903889: jcstress: document used properites (and env variables) [v6] In-Reply-To: <_id_iOGQYGai8cFr-oaXer0R8UivNlj7-ZavmtRzetU=.1c07c8af-058d-4a9e-b83b-3a23bfb68776@github.com> References: <_id_iOGQYGai8cFr-oaXer0R8UivNlj7-ZavmtRzetU=.1c07c8af-058d-4a9e-b83b-3a23bfb68776@github.com> Message-ID: > The purpose of this PR is to move properties and properties based initializations to single place, and to document them, and to enable printing the listing with the documentation via help. > > No Env. vars were found. > > The verbose help can be removed, the individual properties with defaults are wrapped to its class. The OptionSpec and OptionFormatter can be used if needed Ji?? Van?k has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Moved declaration of individual proeprties to ceparate classes by family - Extracted properties encapsualted in objects - Removed autoformatted whitespaces - 7903889: jcstress: document used properites (and env variables) Known properties unifed in one class and printed in verbose help: The verbose help can be removed, the individual properties with defaults can be wrapped to its class. Even the OptionSpec and OptionFormatter can be used if needed ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/156/files - new: https://git.openjdk.org/jcstress/pull/156/files/cf4d4125..9702a5b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=156&range=05 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=156&range=04-05 Stats: 5331 lines in 116 files changed: 3978 ins; 1239 del; 114 mod Patch: https://git.openjdk.org/jcstress/pull/156.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/156/head:pull/156 PR: https://git.openjdk.org/jcstress/pull/156 From jvanek at openjdk.org Mon Jun 23 08:49:47 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 23 Jun 2025 08:49:47 GMT Subject: RFR: 7903750: TimeBudget (-tb) does not fulfill its promisses [v8] In-Reply-To: References: Message-ID: On Mon, 23 Jun 2025 08:22:32 GMT, Ji?? Van?k wrote: >> Added warning, when time budget is to small, and final run will run at least two times longer. > > Ji?? Van?k has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Removed duplicated construcion of timebudget > - directly return new instance without intermediate variable > > Co-authored-by: Galder Zamarre?o > - Removed table like formatting for time budget warnning > - Removed unnecesasary NPE check in getTimeBudget > > The NPE workaround was causing NPE to be only delayed for later > - Removed unnecessary shortening of MS before next conversion > > - ms -= TimeUnit.HOURS.toMillis(hours); > - ms -= TimeUnit.MINUTES.toMillis(minutes); > - Used WARNING: and FATAL: instead of +++ WARNING - and +++ FATAL - > - renamed getNiceMsTimeDate to formatMsToDaysAndTime > - Replaced System.out by preset out > - added warning if timebudget is to small > - print time budfget also for listing > > Required two small refactorings to get nice code reused > - ... and 1 more: https://git.openjdk.org/jcstress/compare/1d143cbd...cbedff70 hi! All my PRs rebased. ------------- PR Comment: https://git.openjdk.org/jcstress/pull/161#issuecomment-2995524592 From jvanek at openjdk.org Mon Jun 23 08:50:02 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 23 Jun 2025 08:50:02 GMT Subject: RFR: 7903819: jcstress do not print structuralised results [v2] In-Reply-To: References: Message-ID: <6FMz9T4k7cDvZyBPXZrnTG1YCh758jJXoxGAJpGYIro=.657b12f6-3cad-4920-a7c7-2723c3e2203e@github.com> > Jcstress are generating very good html report, which is however not exactly great for automated comapriosns over various systyems and architectures. This pr is adding junit-like, configurable report. Ji?? Van?k has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision: - Dropped the dom-based generation Without stream the serilializer was unnecessarily big - Started migration to proepr DOM - Revert "FIXME Added fast fake results generator REMOVE IT" This reverts commit 0d758a79012dcb11f2a98b74a326b58809a97599. The junit result looks good. Now testing on real data - Fixed few noted comments/variables - made default output xsd valid again and keeping option to enable the widely used, but not standart parts for higher readability - changed comments proeprty to comment out non-standart elements soem of the wide spread features like nested testsuites and properties are nmot part of xsd... those will be commented out b default, and moved to fail/err if possible - Unifide testcase print - Support for time attribute and removed some dnagling code - now prints correct summary stil not perfect... mia: interesting? time? and move to dom.... - Not printing the seed argument - ... and 15 more: https://git.openjdk.org/jcstress/compare/7be932d7...870f1605 ------------- Changes: - all: https://git.openjdk.org/jcstress/pull/158/files - new: https://git.openjdk.org/jcstress/pull/158/files/910b6ba5..870f1605 Webrevs: - full: https://webrevs.openjdk.org/?repo=jcstress&pr=158&range=01 - incr: https://webrevs.openjdk.org/?repo=jcstress&pr=158&range=00-01 Stats: 5331 lines in 116 files changed: 3978 ins; 1239 del; 114 mod Patch: https://git.openjdk.org/jcstress/pull/158.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/158/head:pull/158 PR: https://git.openjdk.org/jcstress/pull/158 From jvanek at openjdk.org Mon Jun 23 09:10:54 2025 From: jvanek at openjdk.org (=?UTF-8?B?SmnFmcOt?= =?UTF-8?B?IA==?= =?UTF-8?B?VmFuxJtr?=) Date: Mon, 23 Jun 2025 09:10:54 GMT Subject: RFR: 7903671: jcstress: Update buffer tests for JDK-8318966 [v2] In-Reply-To: References: Message-ID: > part 1: Detecting jdk of target VM and exuding illegible tests > > This is prequel to full fixing of CODETOOLS-7903671. This PR detects target JDK version and then disables illegible tests. > part 2 will be done in templates of affected tests and logic around generating the classes from them. In meantime this should server. > > The jdk detection will be most likely used anyway. WDYT? If we agree on similar approach, I will create a new bug for this PR only. Ji?? Van?k has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Excluding jdk23+ illegible tests on jdk23+ - Added detection on target JDK version ------------- Changes: https://git.openjdk.org/jcstress/pull/159/files Webrev: https://webrevs.openjdk.org/?repo=jcstress&pr=159&range=01 Stats: 125 lines in 3 files changed: 119 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jcstress/pull/159.diff Fetch: git fetch https://git.openjdk.org/jcstress.git pull/159/head:pull/159 PR: https://git.openjdk.org/jcstress/pull/159