From duke at openjdk.org Wed Jan 1 03:35:54 2025 From: duke at openjdk.org (duke) Date: Wed, 1 Jan 2025 03:35:54 GMT Subject: Withdrawn: 8339890: javax/script/ProviderTest.sh ignore vm flags In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 20:16:09 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8339890](https://bugs.openjdk.org/browse/JDK-8339890) where vm flags specified via javaopts were getting ignored. I added the flags to the test. > > Thanks, > Sonia This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21915 From simonis at openjdk.org Wed Jan 1 17:23:45 2025 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 1 Jan 2025 17:23:45 GMT Subject: Integrated: 8346101: [JVMCI] Export jdk.internal.misc to jdk.graal.compiler In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 14:40:17 GMT, Volker Simonis wrote: > In the past, the Graal Compiler used `sun.misc.Unsafe` but these usages were recently changed to `jdk.internal.misc.Unsafe` [1]. We should therefor export `jdk.internal.misc` to `jdk.graal.compiler` which is an upgradeable module in the JDK. > > [1] Remove sun.misc.Unsafe plugins (https://github.com/oracle/graal/commit/5c67d1a6eb8ecf717) This pull request has now been integrated. Changeset: d3abf01c Author: Volker Simonis URL: https://git.openjdk.org/jdk/commit/d3abf01c3e8236d37ec369429e17f35afeb7ab88 Stats: 7 lines in 3 files changed: 2 ins; 0 del; 5 mod 8346101: [JVMCI] Export jdk.internal.misc to jdk.graal.compiler Reviewed-by: dnsimon, phh ------------- PR: https://git.openjdk.org/jdk/pull/22714 From mbaesken at openjdk.org Thu Jan 2 08:54:34 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 2 Jan 2025 08:54:34 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Mon, 30 Dec 2024 21:25:20 GMT, Alexey Semenyuk wrote: > Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. > alexeysemenyukoracle I added the patch to our build/test queue . ------------- PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2567443287 From viktor.klang at oracle.com Thu Jan 2 11:26:08 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Thu, 2 Jan 2025 11:26:08 +0000 Subject: [External] : Gatherers.fold() In-Reply-To: <1153836575.30181367.1734687598838.JavaMail.zimbra@univ-eiffel.fr> References: <1153836575.30181367.1734687598838.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hi R?mi, >Thinking a little more, i do not understand why fold takes a Supplier as first parameter and not just a value given that the Gatherer is created with ofSequential(). If it didn't take a supplier then the resulting Gatherer could never be reused (including composition). I.e. The use of Supplier for the state type is not primarily/only about parallelizability, but rather reuse (which subsumes parallelizability). Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Remi Forax Sent: Friday, 20 December 2024 10:39 To: core-libs-dev Cc: Viktor Klang Subject: [External] : Gatherers.fold() Hello Victor, for the Advent of code of yesterday [1], i've this code golfing solution (the full code is here [2]) var input = ...; class Node { final HashMap map = new HashMap<>(); boolean end; } var root = new Node(); Arrays.stream(input.substring(0, input.indexOf('\n')).split(", ")) .forEach(w -> w.chars().boxed().gather(Gatherers.fold(() -> root, (n, c) -> n.map.computeIfAbsent(c, _ -> new Node()))).findFirst().orElseThrow().end = true); println(input.lines().skip(2).filter(w -> w.chars().boxed().>gather(Gatherers.fold(() -> new HashSet<>(Set.of(root)), (ms, c) -> ms.stream().flatMap(m -> Stream.ofNullable(m.map.get(c))) .flatMap(n -> n != null && n.end ? Stream.of(n, root) : Stream.ofNullable(n)).collect(Collectors.toSet()))) .findFirst().orElseThrow().stream().anyMatch(n -> n.end)).count()); As you can see, the second call to Gatherers.fold() requires to specify the type argument, the > in front because the supplier is not declared as a Supplier Thinking a little more, i do not understand why fold takes a Supplier as first parameter and not just a value given that the Gatherer is created with ofSequential(). regards, R?mi [1] https://urldefense.com/v3/__https://adventofcode.com/2024/day/19__;!!ACWV5N9M2RV99hQ!J6APK3GQDbT-T1edAyWssnGHideZ-3rnwBQ39CsaHnc0y6OLh0fpSub1gPWjXsfzHl4OfAtxfQvA1k3dUfis$ [2] https://urldefense.com/v3/__https://github.com/forax/advent-of-code-2024__;!!ACWV5N9M2RV99hQ!J6APK3GQDbT-T1edAyWssnGHideZ-3rnwBQ39CsaHnc0y6OLh0fpSub1gPWjXsfzHl4OfAtxfQvA1n-w8kEG$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Thu Jan 2 12:36:25 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 2 Jan 2025 13:36:25 +0100 (CET) Subject: [External] : Gatherers.fold() In-Reply-To: References: <1153836575.30181367.1734687598838.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <526623236.37018213.1735821385233.JavaMail.zimbra@univ-eiffel.fr> > From: "Viktor Klang" > To: "Remi Forax" , "core-libs-dev" > > Sent: Thursday, January 2, 2025 12:26:08 PM > Subject: Re: [External] : Gatherers.fold() > Hi R?mi, Happy new year, >>Thinking a little more, i do not understand why fold takes a Supplier as first >>parameter and not just a value given that the Gatherer is created with > >ofSequential(). > If it didn't take a supplier then the resulting Gatherer could never be reused > (including composition). I.e. The use of Supplier for the state type is not > primarily/only about parallelizability, but rather reuse (which subsumes > parallelizability). yes, it makes sense. Okay, so there is just a missing wildcard when the Supplier is declared in fold, thanks to the erasure (it's not something you often write :) ), it's a backward compatible change. > Cheers, > ? regards, R?mi > Viktor Klang > Software Architect, Java Platform Group > Oracle > From: Remi Forax > Sent: Friday, 20 December 2024 10:39 > To: core-libs-dev > Cc: Viktor Klang > Subject: [External] : Gatherers.fold() > Hello Victor, > for the Advent of code of yesterday [1], i've this code golfing solution (the > full code is here [2]) > var input = ...; > class Node { > final HashMap map = new HashMap<>(); > boolean end; > } > var root = new Node(); > Arrays.stream(input.substring(0, input.indexOf('\n')).split(", ")) > .forEach(w -> w.chars().boxed().gather(Gatherers.fold(() -> root, > (n, c) -> n.map.computeIfAbsent(c, _ -> new > Node()))).findFirst().orElseThrow().end = true); > println(input.lines().skip(2).filter(w -> > w.chars().boxed().>gather(Gatherers.fold(() -> new > HashSet<>(Set.of(root)), > (ms, c) -> ms.stream().flatMap(m -> Stream.ofNullable(m.map.get(c))) > .flatMap(n -> n != null && n.end ? Stream.of(n, root) : > Stream.ofNullable(n)).collect(Collectors.toSet()))) > .findFirst().orElseThrow().stream().anyMatch(n -> n.end)).count()); > As you can see, the second call to Gatherers.fold() requires to specify the type > argument, the > in front because the supplier is not declared as a > Supplier > Thinking a little more, i do not understand why fold takes a Supplier as first > parameter and not just a value given that the Gatherer is created with > ofSequential(). > regards, > R?mi > [1] [ > https://urldefense.com/v3/__https://adventofcode.com/2024/day/19__;!!ACWV5N9M2RV99hQ!J6APK3GQDbT-T1edAyWssnGHideZ-3rnwBQ39CsaHnc0y6OLh0fpSub1gPWjXsfzHl4OfAtxfQvA1k3dUfis$ > | > https://urldefense.com/v3/__https://adventofcode.com/2024/day/19__;!!ACWV5N9M2RV99hQ!J6APK3GQDbT-T1edAyWssnGHideZ-3rnwBQ39CsaHnc0y6OLh0fpSub1gPWjXsfzHl4OfAtxfQvA1k3dUfis$ > ] > [2] [ > https://urldefense.com/v3/__https://github.com/forax/advent-of-code-2024__;!!ACWV5N9M2RV99hQ!J6APK3GQDbT-T1edAyWssnGHideZ-3rnwBQ39CsaHnc0y6OLh0fpSub1gPWjXsfzHl4OfAtxfQvA1n-w8kEG$ > | > https://urldefense.com/v3/__https://github.com/forax/advent-of-code-2024__;!!ACWV5N9M2RV99hQ!J6APK3GQDbT-T1edAyWssnGHideZ-3rnwBQ39CsaHnc0y6OLh0fpSub1gPWjXsfzHl4OfAtxfQvA1n-w8kEG$ > ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.org Thu Jan 2 16:25:44 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 2 Jan 2025 16:25:44 GMT Subject: RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v8] In-Reply-To: References: Message-ID: <-xPyM0yeIeIk6Z5Egw1bOhik0rakDfZwUPpnj-Ssrjs=.a7b12f1a-452a-48ff-b61e-d4ec15dbd6f9@github.com> On Mon, 2 Dec 2024 16:50:20 GMT, Liam Miller-Cushon wrote: >> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`. > > Liam Miller-Cushon 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 12 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent > - Update test/jdk/java/util/Collection/MOAT.java > > Co-authored-by: Chen Liang > - Update copyright year > > and add the bug number to the modified test > - Update unmodifiable map javadoc > - Also throw UOE for mutators on keySet() and values() > > and add more test coverage to MOAT. > - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent > - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent > - Check m.entrySet().hashCode() in MOAT > - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent > - Use AbstractImmutableSet > - ... and 2 more: https://git.openjdk.org/jdk/compare/722ffe70...223164c4 Let's keep this open ------------- PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2568033082 From duke at openjdk.org Thu Jan 2 17:16:42 2025 From: duke at openjdk.org (David M. Lloyd) Date: Thu, 2 Jan 2025 17:16:42 GMT Subject: RFR: 8346439: Allow late binding of module services in custom layers [v3] In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 18:03:50 GMT, David M. Lloyd wrote: >> Custom module layers allow for lazy loading, late binding, and full customization of module dependencies through the `Controller` API. However, it is not possible for custom layer users to late-bind services, which has prevented some popular application containers from moving to use Java modules. >> >> Add an API to `ModuleLayer.Controller` to allow adding `uses` and `provides` relationships after a module has been defined for custom layers. > > David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision: > > Add some validation and fix some javadoc wording Bug was rejected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22796#issuecomment-2568103757 From duke at openjdk.org Thu Jan 2 17:16:42 2025 From: duke at openjdk.org (David M. Lloyd) Date: Thu, 2 Jan 2025 17:16:42 GMT Subject: Withdrawn: 8346439: Allow late binding of module services in custom layers In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 16:29:13 GMT, David M. Lloyd wrote: > Custom module layers allow for lazy loading, late binding, and full customization of module dependencies through the `Controller` API. However, it is not possible for custom layer users to late-bind services, which has prevented some popular application containers from moving to use Java modules. > > Add an API to `ModuleLayer.Controller` to allow adding `uses` and `provides` relationships after a module has been defined for custom layers. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22796 From duke at openjdk.org Thu Jan 2 17:21:10 2025 From: duke at openjdk.org (David M. Lloyd) Date: Thu, 2 Jan 2025 17:21:10 GMT Subject: RFR: 8346946: Allow class loaders to bind to layers for service loading Message-ID: <0BSZVYQ1bTJbPjGfcmK8OWw4hWl10_0ooq3EZuubNvg=.c68a7dc6-1801-48c4-b610-2cff1ddd4635@github.com> When loading services by class loader (`ServiceLoader.load(Class,ClassLoader)`), the module layers bound to the given class loader are searched for services, along with the layers bound to class loader's parent, and so on. For non-hierarchical class loader arrangements, this breaks down because the parent class loader of non-hierarchical class loaders is typically `null` (i.e. the boot class loader), while the class loader might have multiple dependency class loaders which replace the role of parent. Add an API to `ClassLoader` which allows additional layers to be bound to the class loader for the purpose of service loading by class loader, without affecting reliable configuration of modules (see [JDK-8346439](https://bugs.openjdk.org/browse/JDK-8346439)), which allows non-hierarchical class loaders to resolve service providers in dependency class loaders. ------------- Commit messages: - 8346946: Allow class loaders to bind to layers for service loading Changes: https://git.openjdk.org/jdk/pull/22905/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22905&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346946 Stats: 26 lines in 2 files changed: 15 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/22905.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22905/head:pull/22905 PR: https://git.openjdk.org/jdk/pull/22905 From alanb at openjdk.org Thu Jan 2 17:52:35 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 2 Jan 2025 17:52:35 GMT Subject: RFR: 8346946: Allow class loaders to bind to layers for service loading In-Reply-To: <0BSZVYQ1bTJbPjGfcmK8OWw4hWl10_0ooq3EZuubNvg=.c68a7dc6-1801-48c4-b610-2cff1ddd4635@github.com> References: <0BSZVYQ1bTJbPjGfcmK8OWw4hWl10_0ooq3EZuubNvg=.c68a7dc6-1801-48c4-b610-2cff1ddd4635@github.com> Message-ID: On Thu, 2 Jan 2025 17:13:17 GMT, David M. Lloyd wrote: > When loading services by class loader (`ServiceLoader.load(Class,ClassLoader)`), the module layers bound to the given class loader are searched for services, along with the layers bound to class loader's parent, and so on. For non-hierarchical class loader arrangements, this breaks down because the parent class loader of non-hierarchical class loaders is typically `null` (i.e. the boot class loader), while the class loader might have multiple dependency class loaders which replace the role of parent. > > Add an API to `ClassLoader` which allows additional layers to be bound to the class loader for the purpose of service loading by class loader, without affecting reliable configuration of modules (see [JDK-8346439](https://bugs.openjdk.org/browse/JDK-8346439)), which allows non-hierarchical class loaders to resolve service providers in dependency class loaders. It's not the role of a custom ClassLoader to establish this relationship. So I think too premature to propose a PR with an API like this. Instead, I think it will require continuing the discussion on jigsaw-dev to try to get some consensus that there is a problem worth spending time on. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22905#issuecomment-2568147313 From naoto at openjdk.org Thu Jan 2 17:56:35 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Jan 2025 17:56:35 GMT Subject: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v3] In-Reply-To: References: Message-ID: On Mon, 30 Dec 2024 17:44:11 GMT, Brett Okken wrote: >> Indeed, just noticed that both `computeIfAbsent` and `putIfAbsent` may acquire the lock when the key is present, while `get` never acquires a lock for read-only access. >> >> Maybe the implementation was written back when locking was less costly (with biased locking, etc.). Now we might have to reconsider locking until we know for sure a plain get fails. > > This scenario is discussed in Effective Java by Joshua Block. His observation then (java 5/6 time frame?) was optimistically calling `get` first and only calling `putIfAbsent` or `computeIfAbsent` if the `get` returned `null` was 250% faster, and this is because calls to put/compute ifAbsent have contention. There have been changes made to those methods since then to try to avoid synchronization when the key is already present, but the observation seems to confirm that the optimistic `get` call first is still faster (though a much smaller difference). > > My comment was not to revert back to the prior change of just calling `computeIfAbsent`, but rather just to change the (expected rare) case when the first `get` returns `null` to replace the `putIfAbsent` and second `get` call with a single `computeIfAbsent` (or utilize the result of `putIfAbsent` to avoid the second call to `get`). Thanks for your observations. I think Archie's analysis sounds right, although have not confirmed. Will use the result from `putIfAbsent()` for all cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22854#discussion_r1901121904 From naoto at openjdk.org Thu Jan 2 17:56:36 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Jan 2025 17:56:36 GMT Subject: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v3] In-Reply-To: <5bjf0rolvoU_PbPLWY7F2OLgeHiN46goT3tPyqzmM0g=.0d6dafd5-e045-4b79-ac5e-76a256a910d7@github.com> References: <5bjf0rolvoU_PbPLWY7F2OLgeHiN46goT3tPyqzmM0g=.0d6dafd5-e045-4b79-ac5e-76a256a910d7@github.com> Message-ID: <2UXQ12fLRdYu5x7Xkou7X1ccE3KMgwwb97u_ItsK40Y=.dd0396f7-0914-4d89-ad80-6d6952b87f13@github.com> On Sat, 21 Dec 2024 00:59:53 GMT, Chen Liang wrote: >> test/micro/org/openjdk/bench/java/time/ZoneOffsetBench.java line 49: >> >>> 47: public void ofTotalSeconds() { >>> 48: for (int i = 0; i < 1_000; i++) { >>> 49: ZoneOffset.ofTotalSeconds(0); >> >> This benchmark method should accept a `Blackhole`, and the return value of `ofTotalSeconds` must be sent to the `Blackhole.consume` method. > > This benchmark currently works probably because the cache interactions in `ofTotalSeconds`, which means JIT compilation cannot prove it is side-effect free. Had it been as simple as a decimal computation or if the cache becomes a stable map, JIT compilation can eliminate the static factory method call entirely, and the benchmark would be measuring the performance of no-op invocation. I decided to remove this benchmark, as the fix is merely to revert the previous fix and not providing any performance improvement (to the original). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22854#discussion_r1901120868 From naoto at openjdk.org Thu Jan 2 18:11:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Jan 2025 18:11:53 GMT Subject: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v4] In-Reply-To: References: Message-ID: > The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous, but it caused this performance regression. Partially reverting the change (ones that involve `computeIfAbsent()`) to the original. Provided a benchmark that iterates the call to `ZoneOffset.ofTotalSeconds(0)` 1,000 times, which improves the operation time from 3,946ns to 2,241ns. Naoto Sato 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 five additional commits since the last revision: - Addresses review comments - Merge branch 'master' into JDK-8345668-ofTotalSeconds-perf-regression - Fixed compile error - Update src/java.base/share/classes/java/time/ZoneOffset.java Co-authored-by: Roger Riggs - initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22854/files - new: https://git.openjdk.org/jdk/pull/22854/files/8dca103a..4dac7bac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22854&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22854&range=02-03 Stats: 15609 lines in 368 files changed: 12421 ins; 1981 del; 1207 mod Patch: https://git.openjdk.org/jdk/pull/22854.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22854/head:pull/22854 PR: https://git.openjdk.org/jdk/pull/22854 From acobbs at openjdk.org Thu Jan 2 18:26:16 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 2 Jan 2025 18:26:16 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v3] In-Reply-To: References: Message-ID: > The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding. > > However, while `DeflaterOutputStream` provides constructors that take a custom `Deflater` argument supplied by the caller, `GZIPOutputStream` has no such constructors. > > As a result, it's not possible to do entirely reasonable customization, such as configuring a `GZIPOutputStream` for a non-default compression level. > > This change adds a new `GZIPOutputStream` constructor that accepts a custom `Deflater`, and also adds a basic unit test for it and all of the other `GZIPOutputStream` constructors, based on the existing test `BasicGZIPInputStreamTest.java` which does the same thing for `GZIPInputStream`. Archie Cobbs 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 six additional commits since the last revision: - Bump copyright year to 2025. - Merge branch 'master' into JDK-4452735 - Address review comments. - Merge branch 'master' into JDK-4452735 - Merge branch 'master' into JDK-4452735 - Add a GZIPOutputStream() constructor that takes a Deflator. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20226/files - new: https://git.openjdk.org/jdk/pull/20226/files/ab16e47d..b3a40b1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20226&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20226&range=01-02 Stats: 172062 lines in 5031 files changed: 118773 ins; 36525 del; 16764 mod Patch: https://git.openjdk.org/jdk/pull/20226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20226/head:pull/20226 PR: https://git.openjdk.org/jdk/pull/20226 From rriggs at openjdk.org Thu Jan 2 18:28:36 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Jan 2025 18:28:36 GMT Subject: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v4] In-Reply-To: References: Message-ID: <57SAzPneEe2728m4qa1XWQtaf0Rb6sHZRcHktqczSws=.2dbd18f5-54de-4bfb-b1f8-16265e2b18ce@github.com> On Thu, 2 Jan 2025 18:11:53 GMT, Naoto Sato wrote: >> The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous, but it caused this performance regression. Partially reverting the change (ones that involve `computeIfAbsent()`) to the original. Provided a benchmark that iterates the call to `ZoneOffset.ofTotalSeconds(0)` 1,000 times, which improves the operation time from 3,946ns to 2,241ns. > > Naoto Sato 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 five additional commits since the last revision: > > - Addresses review comments > - Merge branch 'master' into JDK-8345668-ofTotalSeconds-perf-regression > - Fixed compile error > - Update src/java.base/share/classes/java/time/ZoneOffset.java > > Co-authored-by: Roger Riggs > - initial commit Looks good to me. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22854#pullrequestreview-2528032253 From rriggs at openjdk.org Thu Jan 2 18:34:38 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 2 Jan 2025 18:34:38 GMT Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3] In-Reply-To: References: Message-ID: On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing wrote: >> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages. > > Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision: > > Revert fix in the CTW Makefile. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2528039527 From henryjen at openjdk.org Thu Jan 2 18:46:47 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 2 Jan 2025 18:46:47 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v2] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 17:45:32 GMT, Mandy Chung wrote: >> --style argument still could be a real jlink argument, better check would be to see if that's a valid jlink option rather than just "--". >> The other alternative would be like what proposed by @YaSuenag, simply take the next token as value. > > I would expect the next token would be parsed as the value. I suggest to explore that and see how complex it would be. > > It seems awkward if the following are accepted: > > --add-options "--add-modules jdk.incubator.concurrent" > --add-options=--add-modules=jdk.incubator.concurrent > > > but not this: > > --add-options "--add-modules=jdk.incubator.concurrent" I agree it's a little bit awkward, unfortunately we cannot look at the quotation as that had been decoded by shell. Just take next token as value would be simpler, see the origin PR from @YaSuenag at https://github.com/openjdk/jdk/pull/19987. The other alternative would be that, we can check next token against known options of jlink, and treat it as value without match. That would limited the potential ambiguous conflicts but would be even more mysterious to user? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22526#discussion_r1901163086 From acobbs at openjdk.org Thu Jan 2 19:05:53 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 2 Jan 2025 19:05:53 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v9] In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> Message-ID: > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Bump copyright year to 2025. - Merge branch 'master' into SuppressWarningsCleanup-core-libs - Remove more unnecessary suppressions. - Merge branch 'master' into SuppressWarningsCleanup-core-libs - Remove more unnecessary @SuppressWarnings annotations. - Merge branch 'master' into SuppressWarningsCleanup-core-libs - Remove more unnecessary warning suppressions. - Merge branch 'master' into SuppressWarningsCleanup-core-libs - Put back @SuppressWarnings annotations to be fixed by JDK-8343286. - Merge branch 'master' into SuppressWarningsCleanup-core-libs - ... and 7 more: https://git.openjdk.org/jdk/compare/a77ed30f...40b143c0 ------------- Changes: https://git.openjdk.org/jdk/pull/21852/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=08 Stats: 231 lines in 99 files changed: 0 ins; 106 del; 125 mod Patch: https://git.openjdk.org/jdk/pull/21852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852 PR: https://git.openjdk.org/jdk/pull/21852 From naoto at openjdk.org Thu Jan 2 19:19:37 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Jan 2025 19:19:37 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v9] In-Reply-To: References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> Message-ID: <7mW7RDVbl_6nNk0mxOuoWzaw2MNklR_yTClYZniCdZE=.a1e2ca63-2eab-438a-866c-2bc199cfb9f0@github.com> On Thu, 2 Jan 2025 19:05:53 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Bump copyright year to 2025. > - Merge branch 'master' into SuppressWarningsCleanup-core-libs > - Remove more unnecessary suppressions. > - Merge branch 'master' into SuppressWarningsCleanup-core-libs > - Remove more unnecessary @SuppressWarnings annotations. > - Merge branch 'master' into SuppressWarningsCleanup-core-libs > - Remove more unnecessary warning suppressions. > - Merge branch 'master' into SuppressWarningsCleanup-core-libs > - Put back @SuppressWarnings annotations to be fixed by JDK-8343286. > - Merge branch 'master' into SuppressWarningsCleanup-core-libs > - ... and 7 more: https://git.openjdk.org/jdk/compare/a77ed30f...40b143c0 Changes related to i18n look good. Looks like some files in `java.desktop` package are also modified. Just wondering they may not be seen by client folks as the title mentions core-libs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2568252374 From aturbanov at openjdk.org Thu Jan 2 19:42:42 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 2 Jan 2025 19:42:42 GMT Subject: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v4] In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 18:11:53 GMT, Naoto Sato wrote: >> The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous, but it caused this performance regression. Partially reverting the change (ones that involve `computeIfAbsent()`) to the original. Provided a benchmark that iterates the call to `ZoneOffset.ofTotalSeconds(0)` 1,000 times, which improves the operation time from 3,946ns to 2,241ns. > > Naoto Sato 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 five additional commits since the last revision: > > - Addresses review comments > - Merge branch 'master' into JDK-8345668-ofTotalSeconds-perf-regression > - Fixed compile error > - Update src/java.base/share/classes/java/time/ZoneOffset.java > > Co-authored-by: Roger Riggs > - initial commit Marked as reviewed by aturbanov (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22854#pullrequestreview-2528121990 From aturbanov at openjdk.org Thu Jan 2 19:54:00 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 2 Jan 2025 19:54:00 GMT Subject: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v4] In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 18:11:53 GMT, Naoto Sato wrote: >> The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous, but it caused this performance regression. Partially reverting the change (ones that involve `computeIfAbsent()`) to the original. Provided a benchmark that iterates the call to `ZoneOffset.ofTotalSeconds(0)` 1,000 times, which improves the operation time from 3,946ns to 2,241ns. > > Naoto Sato 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 five additional commits since the last revision: > > - Addresses review comments > - Merge branch 'master' into JDK-8345668-ofTotalSeconds-perf-regression > - Fixed compile error > - Update src/java.base/share/classes/java/time/ZoneOffset.java > > Co-authored-by: Roger Riggs > - initial commit src/java.base/share/classes/java/time/ZoneOffset.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved. Shouldn't be 2025 too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22854#discussion_r1901210626 From acobbs at openjdk.org Thu Jan 2 19:56:16 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 2 Jan 2025 19:56:16 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v9] In-Reply-To: <7mW7RDVbl_6nNk0mxOuoWzaw2MNklR_yTClYZniCdZE=.a1e2ca63-2eab-438a-866c-2bc199cfb9f0@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> <7mW7RDVbl_6nNk0mxOuoWzaw2MNklR_yTClYZniCdZE=.a1e2ca63-2eab-438a-866c-2bc199cfb9f0@github.com> Message-ID: <2GrurB7a0i-AzuGT-5pepQWBU8F8-Opo09ilUEYMmmc=.5cfa028e-8192-4ee3-ae3d-320e475f3f21@github.com> On Thu, 2 Jan 2025 19:16:41 GMT, Naoto Sato wrote: > Looks like some files in java.desktop package are also modified. Just wondering they may not be seen by client folks as the title mentions core-libs. Yeah my attempt to split this up was not perfect. I did have a separate, earlier PR (#21850) for the `client` label stuff, but somehow some of it still spilled over into this one... bleh. But this is easy to fix - I am going to revert the changes under `src/java.destktop` and put them into a new PR. Thanks for the prodding. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2568294020 From acobbs at openjdk.org Thu Jan 2 19:56:16 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 2 Jan 2025 19:56:16 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v10] In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> Message-ID: > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Revert changes under src/java.desktop (to be moved into a separate PR). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21852/files - new: https://git.openjdk.org/jdk/pull/21852/files/40b143c0..1102421d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=08-09 Stats: 27 lines in 9 files changed: 18 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/21852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852 PR: https://git.openjdk.org/jdk/pull/21852 From naoto at openjdk.org Thu Jan 2 20:13:47 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 2 Jan 2025 20:13:47 GMT Subject: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v4] In-Reply-To: References: Message-ID: <3XCKp4TILqiqFrFXzSOrVADD6Nop313cTCGiR-vWZJ0=.afb6e17a-cd03-424a-b0a8-c68f6891e42d@github.com> On Thu, 2 Jan 2025 19:51:19 GMT, Andrey Turbanov wrote: >> Naoto Sato 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 five additional commits since the last revision: >> >> - Addresses review comments >> - Merge branch 'master' into JDK-8345668-ofTotalSeconds-perf-regression >> - Fixed compile error >> - Update src/java.base/share/classes/java/time/ZoneOffset.java >> >> Co-authored-by: Roger Riggs >> - initial commit > > src/java.base/share/classes/java/time/ZoneOffset.java line 2: > >> 1: /* >> 2: * Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved. > > Shouldn't be 2025 too? This PR was published last year and `ZoneOffset` has not changed since then. So I think 2024 is fine ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22854#discussion_r1901223750 From joehw at openjdk.org Thu Jan 2 20:44:40 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 2 Jan 2025 20:44:40 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v10] In-Reply-To: References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> Message-ID: On Thu, 2 Jan 2025 19:56:16 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes under src/java.desktop (to be moved into a separate PR). java.xml changes look good. Please note though, the @LastModified tag needs to be updated as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2528191206 From acobbs at openjdk.org Thu Jan 2 21:11:04 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 2 Jan 2025 21:11:04 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v11] In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> Message-ID: <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com> > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Update @LastModified tags. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21852/files - new: https://git.openjdk.org/jdk/pull/21852/files/1102421d..2049463f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=09-10 Stats: 9 lines in 9 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/21852.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852 PR: https://git.openjdk.org/jdk/pull/21852 From acobbs at openjdk.org Thu Jan 2 21:11:04 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 2 Jan 2025 21:11:04 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v10] In-Reply-To: References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> Message-ID: On Thu, 2 Jan 2025 19:56:16 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes under src/java.desktop (to be moved into a separate PR). > java.xml changes look good. Please note though, the @lastmodified tag needs to be updated as well. Thanks, didn't know about those. Should be fixed in 2049463f18f. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2568379841 From joehw at openjdk.org Thu Jan 2 21:56:40 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 2 Jan 2025 21:56:40 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v11] In-Reply-To: <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com> Message-ID: On Thu, 2 Jan 2025 21:11:04 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Update @LastModified tags. Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2528266594 From almatvee at openjdk.org Fri Jan 3 00:01:34 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Jan 2025 00:01:34 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Mon, 30 Dec 2024 21:25:20 GMT, Alexey Semenyuk wrote: > Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. Looks good. Did you check behavior of jpackage when it is executed without support for DOS file names from command line by user? For example what error message will be? Should we make it user friendly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2568535451 From duke at openjdk.org Fri Jan 3 00:40:42 2025 From: duke at openjdk.org (duke) Date: Fri, 3 Jan 2025 00:40:42 GMT Subject: Withdrawn: 8343559: Optimize Class.getMethod(String, Class...) for methods with no-arg In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 14:15:42 GMT, jengebr wrote: > This change optimizes the runtime of `Class.getMethod(String, Class[])` by reducing the cost of the existing search logic. Specifically, while iterating across each Method to find a match (existing logic) it now compares parameter count before checking method name. This check is substantially faster. > > A benchmark and unit tests are included; benchmark results (below) show an improvement in all cases, and an especially large gain when the immediate class contains the no-arg target. > > Base: > > Benchmark Mode Cnt Score Error Units > ClassGetMethod.getConcreteFiveArg avgt 6 94.586 ? 0.733 ns/op > ClassGetMethod.getConcreteNoArg avgt 6 75.587 ? 11.300 ns/op > ClassGetMethod.getIntfFiveArg avgt 6 215.794 ? 7.713 ns/op > ClassGetMethod.getIntfNoArg avgt 6 200.418 ? 4.352 ns/op > ClassGetMethod.getNoSuchMethod avgt 10 2207.928 ? 49.767 ns/op > ClassGetMethod.getSuperFiveArg avgt 6 190.142 ? 1.995 ns/op > ClassGetMethod.getSuperNoArg avgt 6 153.943 ? 7.491 ns/op > > > Modified: > > Benchmark Mode Cnt Score Error Units > ClassGetMethod.getConcreteFiveArg avgt 6 94.409 ? 1.642 ns/op > ClassGetMethod.getConcreteNoArg avgt 6 77.748 ? 11.618 ns/op > ClassGetMethod.getIntfFiveArg avgt 6 193.816 ? 4.250 ns/op > ClassGetMethod.getIntfNoArg avgt 6 205.565 ? 9.140 ns/op > ClassGetMethod.getNoSuchMethod avgt 10 2231.248 ? 67.711 ns/op > ClassGetMethod.getSuperFiveArg avgt 6 169.971 ? 0.883 ns/op > ClassGetMethod.getSuperNoArg avgt 6 129.188 ? 8.421 ns/op This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21929 From qxing at openjdk.org Fri Jan 3 01:36:51 2025 From: qxing at openjdk.org (Qizheng Xing) Date: Fri, 3 Jan 2025 01:36:51 GMT Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3] In-Reply-To: References: Message-ID: <7dv3Q8SJD7soOx8rgXMB2_ZOf3RbwtcI7zuzybFjJoQ=.b875ea95-9e62-41b8-9898-0d7d21a14b5e@github.com> On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing wrote: >> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages. > > Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision: > > Revert fix in the CTW Makefile. Thank you all for your suggestions and reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2568590393 From duke at openjdk.org Fri Jan 3 01:36:51 2025 From: duke at openjdk.org (duke) Date: Fri, 3 Jan 2025 01:36:51 GMT Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3] In-Reply-To: References: Message-ID: <6jso7rCfR9hvxiCw9z222ueaJQxQol9ELecOcr5BQxQ=.d399c10e-79bd-4f4f-9ed1-91f777c3cb8a@github.com> On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing wrote: >> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages. > > Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision: > > Revert fix in the CTW Makefile. @MaxXSoft Your change (at version 7f85c5e30ab69fe2f94d4604073eb8e610bfc6c2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2568591104 From mchung at openjdk.org Fri Jan 3 01:52:49 2025 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 3 Jan 2025 01:52:49 GMT Subject: RFR: 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image [v15] In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 06:15:58 GMT, Henry Jen wrote: >> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those. >> >> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created. >> >> Another is for random set, such as packages, thus we put those request into a queue to amend the class later. >> >> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time. >> >> So we make this build in advance, and use a static array for values referred more than once. >> >> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments This looks good to me. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Snippets.java line 346: > 344: * ... > 345: * ar[pageSize-1] = elements[pageSize - 1]; > 346: * methodNamePrefix1(ar); Suggestion: * methodNamePrefix_1(ar); src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Snippets.java line 397: > 395: } > 396: > 397: // each helper function is T[] methodNamePrefix{pageNo}(T[]) Suggestion: // each helper function is T[] methodNamePrefix_{pageNo}(T[]) test/jdk/tools/jlink/JLink20000Packages.java line 106: > 104: "--module-source-path", src.toString(), > 105: "--module", "bug8321413x" > 106: }); FYI. You can consider using `jdk.test.lib.compiler.CompilerUtils::compile` method to invoke javac in-process. test/jdk/tools/jlink/SnippetsTest.java line 2: > 1: /* > 2: * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. ------------- Marked as reviewed by mchung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21022#pullrequestreview-2528467896 PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1901409464 PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1901409680 PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1901412049 PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1901412151 From duke at openjdk.org Fri Jan 3 05:02:36 2025 From: duke at openjdk.org (pcoperatr) Date: Fri, 3 Jan 2025 05:02:36 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v11] In-Reply-To: <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com> Message-ID: On Thu, 2 Jan 2025 21:11:04 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Update @LastModified tags. Marked as reviewed by pcoperatr at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2528550907 From duke at openjdk.org Fri Jan 3 05:11:36 2025 From: duke at openjdk.org (pcoperatr) Date: Fri, 3 Jan 2025 05:11:36 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v11] In-Reply-To: <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> <0qTT32Y0AklvnRCJtUWPfYJurR6OrT0ZDXjJ4qVbyYA=.004c2f7e-65b5-4e01-8b9c-f2a93b3f3e52@github.com> Message-ID: On Thu, 2 Jan 2025 21:11:04 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Update @LastModified tags. Marked as reviewed by pcoperatr at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2528555278 From mbaesken at openjdk.org Fri Jan 3 08:07:34 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 3 Jan 2025 08:07:34 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Mon, 30 Dec 2024 21:25:20 GMT, Alexey Semenyuk wrote: > Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. After adding it to our build/test queue, this fails with #section:build ----------messages:(3/144)---------- command: build jtreg.SkippedException reason: User specified action: run build jtreg.SkippedException started: Fri Jan 03 00:10:16 CET 2025 result: Not run. Test running... test result: Error. can't find jtreg.SkippedException in test directory or libraries Maybe you need now `* @library /test/lib` too ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2568823753 From epeter at openjdk.org Fri Jan 3 08:51:37 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 3 Jan 2025 08:51:37 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v6] In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> <9uGYNmVdvCXvyYSOAfwmvD70nWkimOFIlQJolQWa_Z4=.c6ffbfa0-5eb1-40a4-83a4-b657f57c9836@github.com> Message-ID: On Fri, 20 Dec 2024 16:08:51 GMT, Andrew Haley wrote: >> test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 135: >> >>> 133: @IR(applyIf = {"SuperWordReductions", "true"}, >>> 134: applyIfCPUFeatureOr = { "avx512", "true" }, >>> 135: counts = {IRNode.MIN_REDUCTION_V, " > 0"}) >> >>> @eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further. >> >> Hi @galderz , may I ask if these long-reduction cases can't work even with `sve`? It might be related with the limitation [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566). Some `sve` machines have only 128 bits. > > That's right. Neoverse V2 is 4 pipes of 128 bits, V1 is 2 pipes of 256 bits. > That comment is "interesting". Maybe it should be tunable by the back end. Given that Neoverse V2 can issue 4 SVE operations per clock cycle, it might still be a win. > > Galder, how about you disable that line and give it another try? FYI: I'm working on removing the line [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566). The issue is that on some platforms 2-element vectors are somehow really slower, and we need a cost-model to give us a better heuristic, rather than the hard "no". See my draft https://github.com/openjdk/jdk/pull/20964. But yes: why don't you remove the line, and see if that makes it work. If so, then don't worry about this case for now, and maybe leave a comment in the test. We can then fix that later. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1901576209 From epeter at openjdk.org Fri Jan 3 09:01:57 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 3 Jan 2025 09:01:57 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v7] In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 06:54:34 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja 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: > > Review comments resolutions src/hotspot/share/opto/type.cpp line 1465: > 1463: //------------------------------meet------------------------------------------- > 1464: // Compute the MEET of two types. It returns a new Type object. > 1465: const Type *TypeH::xmeet( const Type *t ) const { Suggestion: const Type* TypeH::xmeet( const Type* t ) const { Please check all other occurances. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1901578736 From mbaesken at openjdk.org Fri Jan 3 10:33:53 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 3 Jan 2025 10:33:53 GMT Subject: RFR: 8345676: [ubsan] ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer on macOS aarch64 Message-ID: When starting :tier1 jdk jtreg tests with /jtreg_latest/bin/jtreg this error is show when running ubsanized binaries on macOS aarch64 (XCode 13.1 and 15.4 show this) src/java.base/unix/native/libjava/ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer #0 0x102a6552c in startChild ProcessImpl_md.c:621 #1 0x102a64480 in Java_java_lang_ProcessImpl_forkAndExec ProcessImpl_md.c:721 #2 0x13f53c4fc () #3 0x13f5387cc () #4 0x13f53894c () #5 0x13f5386dc () #6 0x13f5386dc () #7 0x13f5386dc () #8 0x13f53894c () #9 0x13f53894c () #10 0x13f534110 () #11 0x107de60e0 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:416 #12 0x107ebf778 in jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) jni.cpp:885 #13 0x107ec2778 in jni_CallStaticVoidMethod jni.cpp:1714 #14 0x102e86210 in invokeStaticMainWithArgs java.c:392 #15 0x102e884e8 in JavaMain java.c:640 #16 0x102e8d79c in ThreadJavaMain java_md_macosx.m:679 #17 0x19d38ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) #18 0x19d389d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) Looks similar to https://www.reddit.com/r/C_Programming/comments/133oxnc/null_0_is_ub_this_is_not_what_you_would_expect/?rdt=41590 and https://trac.ffmpeg.org/changeset/9c0b3eddf4262f9dcea479091f1307444e614e88/ffmpeg ------------- Commit messages: - JDK-8345676 Changes: https://git.openjdk.org/jdk/pull/22910/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22910&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345676 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22910.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22910/head:pull/22910 PR: https://git.openjdk.org/jdk/pull/22910 From asotona at openjdk.org Fri Jan 3 12:12:07 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Jan 2025 12:12:07 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages Message-ID: This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. Please review. Thanks, Adam ------------- Commit messages: - 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages Changes: https://git.openjdk.org/jdk/pull/22912/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22912&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346981 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22912/head:pull/22912 PR: https://git.openjdk.org/jdk/pull/22912 From asotona at openjdk.org Fri Jan 3 12:41:26 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Jan 2025 12:41:26 GMT Subject: RFR: 8346983: Remove ASM-based transforms from Class-File API tests Message-ID: This patch removes obsolete ASM-based transformations from Class-File API tests. Please review. Thanks, Adam ------------- Commit messages: - 8346983: Remove ASM-based transforms from Class-File API tests Changes: https://git.openjdk.org/jdk/pull/22913/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22913&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346983 Stats: 351 lines in 2 files changed: 0 ins; 349 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22913/head:pull/22913 PR: https://git.openjdk.org/jdk/pull/22913 From asotona at openjdk.org Fri Jan 3 12:50:56 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 3 Jan 2025 12:50:56 GMT Subject: RFR: 8346984: Remove ASM-based benchmarks from Class-File API benchmarks Message-ID: ASM-based benchmarks were useful to directly compare performance of ASM and Class-File API. However Class-File API performance history is now continuously tracked and direct comparison to ASM becomes obsolete. This patch removes ASM-based benchmarks from test/micro/org/openjdk/bench/jdk/classfile. Please review. Thanks, Adam ------------- Commit messages: - ASM removal from JMH exports - 8346984: Remove ASM-based benchmarks from Class-File API benchmarks Changes: https://git.openjdk.org/jdk/pull/22914/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22914&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346984 Stats: 548 lines in 7 files changed: 0 ins; 548 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22914/head:pull/22914 PR: https://git.openjdk.org/jdk/pull/22914 From redestad at openjdk.org Fri Jan 3 14:34:45 2025 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 3 Jan 2025 14:34:45 GMT Subject: RFR: 8346984: Remove ASM-based benchmarks from Class-File API benchmarks In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 12:46:27 GMT, Adam Sotona wrote: > ASM-based benchmarks were useful to directly compare performance of ASM and Class-File API. > However Class-File API performance history is now continuously tracked and direct comparison to ASM becomes obsolete. > > This patch removes ASM-based benchmarks from test/micro/org/openjdk/bench/jdk/classfile. > > Please review. > > Thanks, > Adam LGTM ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22914#pullrequestreview-2529175576 From asemenyuk at openjdk.org Fri Jan 3 14:39:53 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 3 Jan 2025 14:39:53 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails [v2] In-Reply-To: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: > Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Add missing `@library /test/lib` and update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22896/files - new: https://git.openjdk.org/jdk/pull/22896/files/2984a6b5..e3d0a991 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22896&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22896&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22896.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22896/head:pull/22896 PR: https://git.openjdk.org/jdk/pull/22896 From asemenyuk at openjdk.org Fri Jan 3 14:39:53 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 3 Jan 2025 14:39:53 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Fri, 3 Jan 2025 08:05:11 GMT, Matthias Baesken wrote: > Maybe you need now > * @library /test/lib > > too ? Yes. This was the missing part ------------- PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2569314321 From asemenyuk at openjdk.org Fri Jan 3 14:43:44 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 3 Jan 2025 14:43:44 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Thu, 2 Jan 2025 23:58:29 GMT, Alexander Matveev wrote: > Did you check behavior of jpackage when it is executed without support for DOS file names from command line by user? Yes, I did. But I ran it without jtreg and didn't catch missing `@library /test/lib`. > For example what error message will be? Should we make it user friendly? The skipped test message will be "The volume C:\ owning the test work directory doesn't support DOS paths". ------------- PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2569332492 From rriggs at openjdk.org Fri Jan 3 15:16:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 3 Jan 2025 15:16:44 GMT Subject: RFR: 8345676: [ubsan] ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer on macOS aarch64 In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 10:29:31 GMT, Matthias Baesken wrote: > When starting :tier1 jdk jtreg tests with > /jtreg_latest/bin/jtreg > this error is show when running ubsanized binaries on macOS aarch64 (XCode 13.1 and 15.4 show this) > > src/java.base/unix/native/libjava/ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer > #0 0x102a6552c in startChild ProcessImpl_md.c:621 > #1 0x102a64480 in Java_java_lang_ProcessImpl_forkAndExec ProcessImpl_md.c:721 > #2 0x13f53c4fc () > #3 0x13f5387cc () > #4 0x13f53894c () > #5 0x13f5386dc () > #6 0x13f5386dc () > #7 0x13f5386dc () > #8 0x13f53894c () > #9 0x13f53894c () > #10 0x13f534110 () > #11 0x107de60e0 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:416 > #12 0x107ebf778 in jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) jni.cpp:885 > #13 0x107ec2778 in jni_CallStaticVoidMethod jni.cpp:1714 > #14 0x102e86210 in invokeStaticMainWithArgs java.c:392 > #15 0x102e884e8 in JavaMain java.c:640 > #16 0x102e8d79c in ThreadJavaMain java_md_macosx.m:679 > #17 0x19d38ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #18 0x19d389d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > Looks similar to > https://www.reddit.com/r/C_Programming/comments/133oxnc/null_0_is_ub_this_is_not_what_you_would_expect/?rdt=41590 > and > https://trac.ffmpeg.org/changeset/9c0b3eddf4262f9dcea479091f1307444e614e88/ffmpeg looks good, thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22910#pullrequestreview-2529247700 From liach at openjdk.org Fri Jan 3 16:32:40 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Jan 2025 16:32:40 GMT Subject: RFR: 8346983: Remove ASM-based transforms from Class-File API tests In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 12:19:54 GMT, Adam Sotona wrote: > This patch removes obsolete ASM-based transformations from Class-File API tests. > > Please review. > > Thanks, > Adam Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22913#pullrequestreview-2529374938 From liach at openjdk.org Fri Jan 3 16:34:36 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Jan 2025 16:34:36 GMT Subject: RFR: 8346984: Remove ASM-based benchmarks from Class-File API benchmarks In-Reply-To: References: Message-ID: <8vPPklMq-UsKxHyFM_T-8ojKCvYnLt0x2RF09wC0QP0=.14310f93-857a-45fc-93c6-4aa9db2a30a1@github.com> On Fri, 3 Jan 2025 12:46:27 GMT, Adam Sotona wrote: > ASM-based benchmarks were useful to directly compare performance of ASM and Class-File API. > However Class-File API performance history is now continuously tracked and direct comparison to ASM becomes obsolete. > > This patch removes ASM-based benchmarks from test/micro/org/openjdk/bench/jdk/classfile. > > Please review. > > Thanks, > Adam Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22914#pullrequestreview-2529378098 From liach at openjdk.org Fri Jan 3 16:35:39 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Jan 2025 16:35:39 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona wrote: > This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. > > Please review. > > Thanks, > Adam Looks good; waiting for a JFR reviewer. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2529380039 From yujige at gmail.com Fri Jan 3 16:53:27 2025 From: yujige at gmail.com (Jige Yu) Date: Fri, 3 Jan 2025 08:53:27 -0800 Subject: mapConcurrent() with InterruptedException Message-ID: Hi Java Experts, I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list. The question is about the behavior of mapConcurrent() when the thread is interrupted. Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return. This strikes me as a surprising behavior, because for example if I'm running: Stream.of(1, 2, 3) .gather(mapConcurrent(i -> i * 2)) .toList() and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6]. Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect. In the Reddit thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks. There had been discussion about alternative strategies: 1. Don't respond to interruption and just keep running to completion. 2. Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?). I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope. Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action). My arguments for option 2: 1. InterruptedException is more error prone than traditional checked exceptions for *users* to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are *supposed to* re-interrupt the thread. 2. With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users. 3. With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher. 4. Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join() for example). 5. Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked. There is also a side discussion about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread? Thank you and cheers! Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From henryjen at openjdk.org Fri Jan 3 16:55:24 2025 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 3 Jan 2025 16:55:24 GMT Subject: RFR: 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image [v16] In-Reply-To: References: Message-ID: > This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those. > > In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created. > > Another is for random set, such as packages, thus we put those request into a queue to amend the class later. > > To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time. > > So we make this build in advance, and use a static array for values referred more than once. > > All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21022/files - new: https://git.openjdk.org/jdk/pull/21022/files/8fc4e2f4..760f6672 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=14-15 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21022.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21022/head:pull/21022 PR: https://git.openjdk.org/jdk/pull/21022 From liach at openjdk.org Fri Jan 3 17:06:39 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 3 Jan 2025 17:06:39 GMT Subject: RFR: 8344168: Change Unsafe base offset from int to long [v4] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 18:05:44 GMT, Shaojin Wen wrote: >> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed. >> >> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea. > > Shaojin Wen has updated the pull request incrementally with three additional commits since the last revision: > > - Typos > - Fix type expectations > - Make base offset method and invalid offset long Bringing this to attention again; by using the long type, this patch avoids potentially erroneous integer arithmetic used in memory address calculations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2569548797 From alanb at openjdk.org Fri Jan 3 17:18:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Jan 2025 17:18:34 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages In-Reply-To: References: Message-ID: <0dGBK1WiJqZwu6ornKPZRv6GG4ZN_Qi_9ueqw0OBICM=.08113b29-4905-43f7-991e-d8b2378f11cf@github.com> On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona wrote: > This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. > > Please review. > > Thanks, > Adam Good cleanup, these qualified exports should probably have been removed in JDK 22 when the instrumentation moved to the class file API. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2529437512 From viktor.klang at oracle.com Fri Jan 3 17:18:48 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Fri, 3 Jan 2025 17:18:48 +0000 Subject: mapConcurrent() with InterruptedException In-Reply-To: References: Message-ID: Hi Ben, Thanks for raising these questions?getting feedback is crucial in the Preview stage of features. I wrote a reply to the Reddit thread so I'll just summarize here: It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes. I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays. Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated. As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s). Again, thanks for your feedback! Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev on behalf of Jige Yu Sent: Friday, 3 January 2025 17:53 To: core-libs-dev at openjdk.org Subject: mapConcurrent() with InterruptedException Hi Java Experts, I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list. The question is about the behavior of mapConcurrent() when the thread is interrupted. Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return. This strikes me as a surprising behavior, because for example if I'm running: Stream.of(1, 2, 3) .gather(mapConcurrent(i -> i * 2)) .toList() and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6]. Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect. In the Reddit thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks. There had been discussion about alternative strategies: 1. Don't respond to interruption and just keep running to completion. 2. Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?). I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope. Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action). My arguments for option 2: 1. InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread. 2. With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users. 3. With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher. 4. Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join() for example). 5. Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked. There is also a side discussion about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread? Thank you and cheers! Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Fri Jan 3 17:42:39 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 3 Jan 2025 17:42:39 GMT Subject: RFR: 8346984: Remove ASM-based benchmarks from Class-File API benchmarks In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 12:46:27 GMT, Adam Sotona wrote: > ASM-based benchmarks were useful to directly compare performance of ASM and Class-File API. > However Class-File API performance history is now continuously tracked and direct comparison to ASM becomes obsolete. > > This patch removes ASM-based benchmarks from test/micro/org/openjdk/bench/jdk/classfile. > > Please review. > > Thanks, > Adam Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22914#pullrequestreview-2529470719 From mchung at openjdk.org Fri Jan 3 18:39:41 2025 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 3 Jan 2025 18:39:41 GMT Subject: RFR: 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image [v16] In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 16:55:24 GMT, Henry Jen wrote: >> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those. >> >> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created. >> >> Another is for random set, such as packages, thus we put those request into a queue to amend the class later. >> >> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time. >> >> So we make this build in advance, and use a static array for values referred more than once. >> >> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Clean up Marked as reviewed by mchung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21022#pullrequestreview-2529544986 From jbhateja at openjdk.org Fri Jan 3 20:36:21 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 3 Jan 2025 20:36:21 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v8] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja 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 nine additional commits since the last revision: - Updating copyright year of modified files. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103 - Review suggestions incorporated. - Review comments resolutions - Addressing review comments - Fixing obfuscation due to intrinsic entries - Adding more test points - Adding missed check in container type detection. - C2 compiler support for float16 scalar operations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22754/files - new: https://git.openjdk.org/jdk/pull/22754/files/dd444c44..d3cbf2c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=06-07 Stats: 17820 lines in 567 files changed: 13308 ins; 2583 del; 1929 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From jbhateja at openjdk.org Fri Jan 3 20:42:15 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 3 Jan 2025 20:42:15 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja 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: Updating copyright year of modified files. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22754/files - new: https://git.openjdk.org/jdk/pull/22754/files/d3cbf2c4..175f4ed2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From asemenyuk at openjdk.org Fri Jan 3 21:33:17 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 3 Jan 2025 21:33:17 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails [v3] In-Reply-To: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: > Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. Alexey Semenyuk 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: - Merge branch 'master' into JDK-8346872 - Add missing `@library /test/lib` and update copyright year - 8346872: tools/jpackage/windows/WinLongPathTest.java fails ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22896/files - new: https://git.openjdk.org/jdk/pull/22896/files/e3d0a991..6e19800a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22896&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22896&range=01-02 Stats: 538 lines in 26 files changed: 116 ins; 328 del; 94 mod Patch: https://git.openjdk.org/jdk/pull/22896.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22896/head:pull/22896 PR: https://git.openjdk.org/jdk/pull/22896 From almatvee at openjdk.org Fri Jan 3 21:33:18 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Jan 2025 21:33:18 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails [v2] In-Reply-To: References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Fri, 3 Jan 2025 14:39:53 GMT, Alexey Semenyuk wrote: >> Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Add missing `@library /test/lib` and update copyright year Sorry, I was not clear in my question. What I mean is what will happen if following command run manually by user from terminal without DOS file names support: `java.lang.AssertionError: Expected [0]. Actual [1]: Check command [C:\\testuser\\output_openjdk25_dev_dbgU_ntamd64\\testee-vm\\bin\\jpackage.exe --input .\\test.a5cf5d26\\input --dest .\\test.a5cf5d26\\output --name WinLongPathTest --type app-image --main-jar hello.jar --main-class Hello --win-console --temp .\\test.a5cf5d26\\long-path\\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\\bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\\ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc -J-Djlink.debug=true --verbose](18) exited with 0 code` Based on call stack in JBS jpackage will fail, but it is not clear why and what error message from jpackage is displayed in such case. If error message is not user friendly I think we should make it user friendly and explain reason for failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2569842074 From asemenyuk at openjdk.org Fri Jan 3 21:53:44 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 3 Jan 2025 21:53:44 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails [v2] In-Reply-To: References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Fri, 3 Jan 2025 21:30:02 GMT, Alexander Matveev wrote: > What I mean is what will happen if following command run manually by user from terminal without DOS file names support If file conversion fails, jpackage will show `Failed to get short version of path` error message, where `` is an absolute path requested to be converted into DOS path. See [src/jdk.jpackage/windows/classes/jdk/jpackage/internal/ShortPathUtils.java](https://github.com/openjdk/jdk/blob/07c9f7138affdf0d42ecdc30adcb854515569985/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/ShortPathUtils.java#L70) and [WinResources.properties](https://github.com/openjdk/jdk/blob/07c9f7138affdf0d42ecdc30adcb854515569985/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties#L59) PS The question is unrelated to the subject of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2569863802 From almatvee at openjdk.org Fri Jan 3 22:45:41 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 3 Jan 2025 22:45:41 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails [v3] In-Reply-To: References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: <1i-LiqayQkREjidQH9WBOB_ODpmPzLD5BCZc_lTaIzQ=.7dc976a8-932d-4e8c-a80d-eef87adb7c21@github.com> On Fri, 3 Jan 2025 21:33:17 GMT, Alexey Semenyuk wrote: >> Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. > > Alexey Semenyuk 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: > > - Merge branch 'master' into JDK-8346872 > - Add missing `@library /test/lib` and update copyright year > - 8346872: tools/jpackage/windows/WinLongPathTest.java fails Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22896#pullrequestreview-2529801694 From liach at openjdk.org Sat Jan 4 01:58:00 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 4 Jan 2025 01:58:00 GMT Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API [v4] In-Reply-To: References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com> Message-ID: On Thu, 5 Dec 2024 19:48:49 GMT, Chen Liang wrote: >> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well. >> >> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8333377: Migrate Generic Signature parsing to ClassFile API Keep alive. One day there will be a reviewer... ------------- PR Comment: https://git.openjdk.org/jdk/pull/19281#issuecomment-2569998402 From godmlzkf1 at naver.com Sat Jan 4 03:29:22 2025 From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=) Date: Sat, 04 Jan 2025 12:29:22 +0900 Subject: =?utf-8?B?SSB3YW50IHRvIFN1YnNjcmliZSB0byBjb3JlLWxpYnMtZGV2J3MgbWFpbA==?= Message-ID: <94c049afec4c37c0a2ad08de2bc00@cweb003.nm> hello. Previously, I asked Iris Clark at ekfdmlzkf at gmail.com how to contribute to open jdk. I am contacting you after seeing a message asking me to subscribe to core-libs-dev's mail and send it to you. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Sat Jan 4 04:46:22 2025 From: liangchenblue at gmail.com (Chen Liang) Date: Fri, 3 Jan 2025 20:46:22 -0800 Subject: I want to Subscribe to core-libs-dev's mail In-Reply-To: <94c049afec4c37c0a2ad08de2bc00@cweb003.nm> References: <94c049afec4c37c0a2ad08de2bc00@cweb003.nm> Message-ID: Hi, You can subscribe to openjdk mailing lists on https://mail.openjdk.org And core-libs-dev is on the list of mailing lists there. Regards On Fri, Jan 3, 2025, 7:30?PM ??? wrote: > hello. Previously, I asked Iris Clark at ekfdmlzkf at gmail.com how to > contribute to open jdk. > > I am contacting you after seeing a message asking me to subscribe to > core-libs-dev's mail and send it to you. > > thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From godmlzkf1 at naver.com Sat Jan 4 06:23:28 2025 From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=) Date: Sat, 04 Jan 2025 15:23:28 +0900 Subject: =?utf-8?B?SSB3YW50IHRvIGNvbnRyaWJ1dGUgb3BlbmpkayBkYXRhIHN0cnVjdHVyZShsaWtlLiBhcg==?= =?utf-8?B?cmF5TGlzdCk=?= Message-ID: hello. In order to contribute to openJDK, I had to subscribe to the email. Can I know what happens after that? I would like to participate in the process of raising issues and contributing. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus at headcrashing.eu Sat Jan 4 10:21:15 2025 From: markus at headcrashing.eu (Markus KARG) Date: Sat, 4 Jan 2025 11:21:15 +0100 Subject: I want to contribute openjdk data structure(like. arrayList) In-Reply-To: References: Message-ID: <0b0ec11f-6808-4f70-ae75-075bf335e540@headcrashing.eu> Welcome to OpenJDK! Your next step should be reading this document: https://openjdk.org/guide/ :-) Regards -Markus Am 04.01.2025 um 07:23 schrieb ???: > hello. > In order to contribute to openJDK, I had to subscribe to the email. > Can I know what happens after that? > > I would like to participate in the process of raising issues and > contributing. > > thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sat Jan 4 10:51:22 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 4 Jan 2025 10:51:22 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong Message-ID: This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. ------------- Commit messages: - optimize parseInt & parseLong - optimize parseInt & parseLong - reuse isDigit - optimize parseInt - optimize parseLong - add benchmark Changes: https://git.openjdk.org/jdk/pull/22919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347009 Stats: 141 lines in 4 files changed: 65 ins; 16 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From swen at openjdk.org Sat Jan 4 11:33:22 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 4 Jan 2025 11:33:22 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v2] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: bug fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/f555dae2..5801b171 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From swen at openjdk.org Sat Jan 4 12:09:04 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 4 Jan 2025 12:09:04 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v3] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: use String::value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/5801b171..9ea08455 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=01-02 Stats: 11 lines in 2 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From swen at openjdk.org Sat Jan 4 12:26:38 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 4 Jan 2025 12:26:38 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v3] In-Reply-To: References: Message-ID: On Sat, 4 Jan 2025 12:09:04 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > use String::value Below are the performance numbers on each platform ## 1. Script git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao #master git checkout 5bb9644202a8b961faad02439c95a81ca6862168 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" # current git checkout 9ea084555792fb3c870f6393ce53873e9bde73e6 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" ## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa) -Benchmark (size) Mode Cnt Score Error Units -Longs.parseLong 500 avgt 15 3.542 ? 0.022 us/op -Integers.parseInt 500 avgt 15 3.269 ? 0.015 us/op +Benchmark (size) Mode Cnt Score Error Units +Longs.parseLong 500 avgt 15 3.240 ? 0.037 us/op +9.32% +Integers.parseInt 500 avgt 15 3.208 ? 0.004 us/op +1.90% ## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids) -Benchmark (size) Mode Cnt Score Error Units -Longs.parseLong 500 avgt 15 3.477 ? 0.009 us/op -Integers.parseInt 500 avgt 15 3.138 ? 0.006 us/op +Benchmark (size) Mode Cnt Score Error Units +Longs.parseLong 500 avgt 15 3.023 ? 0.028 us/op +15.01% +Integers.parseInt 500 avgt 15 2.847 ? 0.005 us/op +10.22% ## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710 ARM) -Benchmark (size) Mode Cnt Score Error Units -Longs.parseLong 500 avgt 15 3.819 ? 0.044 us/op -Integers.parseInt 500 avgt 15 3.639 ? 0.075 us/op +Benchmark (size) Mode Cnt Score Error Units +Longs.parseLong 500 avgt 15 3.347 ? 0.015 us/op +14.10% +Integers.parseInt 500 avgt 15 3.192 ? 0.010 us/op +14.03% ## 5. MacBook M1 Pro (aarch64) -Benchmark (size) Mode Cnt Score Error Units -Longs.parseLong 500 avgt 15 2.608 ? 0.035 us/op -Integers.parseInt 500 avgt 15 2.325 ? 0.005 us/op +Benchmark (size) Mode Cnt Score Error Units +Longs.parseLong 500 avgt 15 2.291 ? 0.018 us/op +13.83% +Integers.parseInt 500 avgt 15 2.079 ? 0.011 us/op +11.83% ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2571272942 From godmlzkf1 at naver.com Sat Jan 4 14:15:32 2025 From: godmlzkf1 at naver.com (=?utf-8?B?7J6E66+87IiY?=) Date: Sat, 04 Jan 2025 23:15:32 +0900 Subject: =?utf-8?B?SSB3b3VsZCBsaWtlIHRvIGNvbnRyaWJ1dGUgdG8gdGhlIGdpdC4=?= Message-ID: <5d9c2e35608b332ff49194cff7741e98@cweb001.nm> https://github.com/openjdk/jdk I would like to contribute to the git. I went to the address https://mail.openjdk.org/pipermail/core-libs-dev/ and completed the subscription. How should I write about the issue and commit contents and proceed? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Amit.Kumar220 at ibm.com Sat Jan 4 15:06:31 2025 From: Amit.Kumar220 at ibm.com (Amit Kumar) Date: Sat, 4 Jan 2025 15:06:31 +0000 Subject: I would like to contribute to the git. In-Reply-To: <7AC1E514-2078-48A3-A41F-57A6A511CF44@ibm.com> References: <5d9c2e35608b332ff49194cff7741e98@cweb001.nm> <7AC1E514-2078-48A3-A41F-57A6A511CF44@ibm.com> Message-ID: There exist a dedicated page for this kind of information, please go through it: https://openjdk.org/guide/#contributing-to-an-openjdk-project Moreover you can?t create issue, instead you can describe the issue here and someone will open a bug on JBS for you, for which you can raise the PR (refer above link for more information about raising the PR) - Amit On 4 Jan 2025, at 8:33?PM, Amit Kumar wrote: ? There exist a dedicated page for this kind of information, please go through it: https://openjdk.org/guide/#contributing-to-an-openjdk-project Moreover you can?t create issue, instead you can describe the issue here and someone will open a bug on JBS for you, for which you can raise the PR (refer above link for more information about raising the PR) - Amit On 4 Jan 2025, at 7:45?PM, ??? wrote: ? https:?//github.?com/openjdk/jdk I would like to contribute to the git. I went to the address https:?//mail.?openjdk.?org/pipermail/core-libs-dev/ and completed the subscription. How should I write about the issue and commit contents and proceed? https://github.com/openjdk/jdk I would like to contribute to the git. I went to the address https://mail.openjdk.org/pipermail/core-libs-dev/ and completed the subscription. How should I write about the issue and commit contents and proceed? Thank you. [https://mail.naver.com/readReceipt/notify/?img=Fe%2BPWz9vWr%2BvFxmsK6pOa6KZpxK9Fog%2FMoKqK4p4FAvwax3op4MXFqtwpxv%2FtzFXp6UmKAu5W4dQarFTb4ERWz0SbZ9vpBpgWXI0W4Gv1ZlTb4b%3D.gif] -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sun Jan 5 07:10:08 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 5 Jan 2025 07:10:08 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v4] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with 11 additional commits since the last revision: - emptyInput -> nullInput - use CharacterDataLatin1.instance::isDigit - add comments - reduce codeSize - bug fix for bound check - reduce codeSize - remove unused code - code format - bug fix - bug fix - ... and 1 more: https://git.openjdk.org/jdk/compare/9ea08455...fd51c1ce ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/9ea08455..fd51c1ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=02-03 Stats: 67 lines in 3 files changed: 17 ins; 12 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From duke at openjdk.org Sun Jan 5 07:10:08 2025 From: duke at openjdk.org (j3graham) Date: Sun, 5 Jan 2025 07:10:08 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v3] In-Reply-To: References: Message-ID: On Sat, 4 Jan 2025 12:09:04 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > use String::value Some other thoughts that might help here; except for leading zeros, 9 (or 18 for a long) or fewer digits cannot overflow. So something like this might work: - read first char and check if it is a sign character. - skip leading zeros - loop over up to 9 digits, performing the calculation without needing to check for overflow. I think it would be enough to do this 1 digit at a time. - If there are any digits left, take only the next digit, and incorporate it into the result while doing the overflow check. - If there are still more digits left it is too big to fit. This approach could also be taken for the more general parse methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2571374257 From swen at openjdk.org Sun Jan 5 07:10:08 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 5 Jan 2025 07:10:08 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v3] In-Reply-To: References: Message-ID: <1WvhKrTHga3V7AallUoMErhgkJ2AUxWummdtC64-JGE=.456e0b4b-2111-41a3-a4c9-c10f3dbedfb6@github.com> On Sat, 4 Jan 2025 18:18:47 GMT, j3graham wrote: > Some other thoughts that might help here; except for leading zeros, 9 (or 18 for a long) or fewer digits cannot overflow. So something like this might work: > > * read first char and check if it is a sign character. > * skip leading zeros > * loop over up to 9 digits, performing the calculation without needing to check for overflow. I think it would be enough to do this 1 digit at a time. > * If there are any digits left, take only the next digit, and incorporate it into the result while doing the overflow check. > * If there are still more digits left it is too big to fit. > > This approach could also be taken for the more general parse methods. Thanks for your advice! 1. The current implementation is to determine whether the first character is `+/-`, but the writing method is to reduce the CodeSize, which is not easy to read, but I added a comment. int neg; if ((neg = (c = value[0]) - '-') != 0 && neg + 2 != 0 // firstChar != '+' ) { 2. The leading zero scenario is not common, and there is no need to optimize this scenario. 3. The current cost of judging result < MULT_MIN_10 or result < MULT_MIN_100 is not high. 4. It is necessary to control codeSize <= 325 to enable inline. The code here is written with the minimum codeSize ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2571447521 From duke at openjdk.org Sun Jan 5 07:10:08 2025 From: duke at openjdk.org (j3graham) Date: Sun, 5 Jan 2025 07:10:08 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v3] In-Reply-To: <1WvhKrTHga3V7AallUoMErhgkJ2AUxWummdtC64-JGE=.456e0b4b-2111-41a3-a4c9-c10f3dbedfb6@github.com> References: <1WvhKrTHga3V7AallUoMErhgkJ2AUxWummdtC64-JGE=.456e0b4b-2111-41a3-a4c9-c10f3dbedfb6@github.com> Message-ID: <_3IdDPx_F_7mwTnPxUQGYpjLhKk-wSJtUHM7LQ2Sjc0=.eb79edee-9819-494f-97be-c4669b1f83f1@github.com> On Sun, 5 Jan 2025 00:12:03 GMT, Shaojin Wen wrote: > 2. The leading zero scenario is not common, and there is no need to optimize this scenario. Another approach would be to limit the ?fast? path to the case where the overall string length is 9 or less. That would allow overflow-free calculation without the extra bytecode weight of skipping leading zeros, possibly still with simpler code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2571479762 From swen at openjdk.org Sun Jan 5 07:10:08 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 5 Jan 2025 07:10:08 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v3] In-Reply-To: <_3IdDPx_F_7mwTnPxUQGYpjLhKk-wSJtUHM7LQ2Sjc0=.eb79edee-9819-494f-97be-c4669b1f83f1@github.com> References: <1WvhKrTHga3V7AallUoMErhgkJ2AUxWummdtC64-JGE=.456e0b4b-2111-41a3-a4c9-c10f3dbedfb6@github.com> <_3IdDPx_F_7mwTnPxUQGYpjLhKk-wSJtUHM7LQ2Sjc0=.eb79edee-9819-494f-97be-c4669b1f83f1@github.com> Message-ID: On Sun, 5 Jan 2025 02:50:34 GMT, j3graham wrote: > > 2. The leading zero scenario is not common, and there is no need to optimize this scenario. > > Another approach would be to limit the ?fast? path to the case where the overall string length is 9 or less. That would allow overflow-free calculation without the extra bytecode weight of skipping leading zeros, possibly still with simpler code. If we want to reach the fastest limit, we need to construct a cache array DIGITS for decimal integers, such as this: https://github.com/wenshao/jdk/tree/refs/heads/optim_parse_int_long_202501_x1 ( commit https://github.com/wenshao/jdk/commit/c2e2c7e8fe8cd662db97d713f4043622de21f1d0 ) @Stable private static final byte[] DECIMAL_DIGITS = new byte[] { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, -1, -1, ... // 256 }; static int digit(byte ch) { return DECIMAL_DIGITS[ch & 0xFF]; } public static int parseInt(String s, int radix) // ... ... int result = 0, d0, d1; boolean inRange; byte firstChar = value[0]; if (firstChar != '-' && firstChar != '+') { if (inRange = ((d0 = digit(firstChar)) != -1)) { result = -d0; } } else { inRange = len != 1; } int limit = MIN_VALUE + (firstChar != '-' ? 1 : 0); int i = 1; while (inRange && i + 1 < len && (d0 = digit(value[i ])) != -1 && (d1 = digit(value[i + 1])) != -1 ) { d1 = d0 * 10 + d1; // max digits is 19, no need to check inRange (result == MULT_MIN_100 && digit <= (MULT_MIN_100 * 100 - limit)) if (inRange = (result >= MULT_MIN_100)) { result = result * 100 - d1; i += 2; } } if (inRange && result <= 0) { if (i + 1 == len && (d0 = digit(value[i])) != -1) { if (result > MULT_MIN_10 || (result == MULT_MIN_10 && d0 <= (MULT_MIN_10 * 10 - limit))) { result = result * 10 - d0; i++; } } if (i == len) { return firstChar != '-' ? -result : result; } } throw NumberFormatException.forInputString(s); } This will be faster, but there may be cache misses in some cases and performance will decrease. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2571517185 From duke at openjdk.org Sun Jan 5 07:10:08 2025 From: duke at openjdk.org (j3graham) Date: Sun, 5 Jan 2025 07:10:08 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v4] In-Reply-To: References: Message-ID: On Sun, 5 Jan 2025 07:07:15 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with 11 additional commits since the last revision: > > - emptyInput -> nullInput > - use CharacterDataLatin1.instance::isDigit > - add comments > - reduce codeSize > - bug fix for bound check > - reduce codeSize > - remove unused code > - code format > - bug fix > - bug fix > - ... and 1 more: https://git.openjdk.org/jdk/compare/9ea08455...fd51c1ce src/java.base/share/classes/java/lang/Integer.java line 576: > 574: throw NumberFormatException.forInputString(s); > 575: } > 576: return parseInt(s, 0, len, radix); I think this call will result in different exception messages in some cases. Consolidating the exception messages between the String and the CharSequence parsing methods would likely allow for even more code simplification, but currently it appears there was effort to preserve the exact message text in exceptions. src/java.base/share/classes/java/lang/NumberFormatException.java line 96: > 94: } > 95: > 96: static NumberFormatException emptyInput() { A better method name might be nullInput, since an empty (but non null) string doesn?t use this ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1903186757 PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1903186179 From swen at openjdk.org Sun Jan 5 07:10:09 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 5 Jan 2025 07:10:09 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v4] In-Reply-To: References: Message-ID: On Sun, 5 Jan 2025 02:57:37 GMT, j3graham wrote: >> Shaojin Wen has updated the pull request incrementally with 11 additional commits since the last revision: >> >> - emptyInput -> nullInput >> - use CharacterDataLatin1.instance::isDigit >> - add comments >> - reduce codeSize >> - bug fix for bound check >> - reduce codeSize >> - remove unused code >> - code format >> - bug fix >> - bug fix >> - ... and 1 more: https://git.openjdk.org/jdk/compare/9ea08455...fd51c1ce > > src/java.base/share/classes/java/lang/Integer.java line 576: > >> 574: throw NumberFormatException.forInputString(s); >> 575: } >> 576: return parseInt(s, 0, len, radix); > > I think this call will result in different exception messages in some cases. Consolidating the exception messages between the String and the CharSequence parsing methods would likely allow for even more code simplification, but currently it appears there was effort to preserve the exact message text in exceptions. If we want to keep the original error message completely, we need to keep the original implementation, which will lead to code duplication. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1903193687 From fabian at buildbuddy.io Sun Jan 5 10:20:06 2025 From: fabian at buildbuddy.io (Fabian Meumertzheim) Date: Sun, 5 Jan 2025 11:20:06 +0100 Subject: Docs for ExecutorService#close and canceled tasks Message-ID: Hi, I recently traced a race in an application (https://github.com/bazelbuild/bazel/issues/21773) down to a particular behavior of ExecutorService#close that, to me, doesn't seem to be obvious from its documentation: If a task that has been submitted to the executor is canceled while it is already executing, ExecutorService#close will not wait for the associated Runnable to return. Consider the following example: var taskRunning = new AtomicBoolean(true); try (var executorService = Executors.newVirtualThreadPerTaskExecutor()) { var taskStarted = new CountDownLatch(1); var task = executorService.submit( () -> { // Uninterruptibly wait for a second. taskStarted.countDown(); long end = System.currentTimeMillis() + 1000; long remaining; while ((remaining = end - System.currentTimeMillis()) > 0) { try { Thread.sleep(remaining); } catch (InterruptedException e) { } } taskRunning.set(false); }); // Cancel the task after it has started execution. try { taskStarted.await(); } catch (InterruptedException e) { throw new IllegalStateException(e); } task.cancel(false); } System.err.println("Task still running: " + taskRunning.get()); This will print "Task still running: true" and exit immediately instead of waiting for a second. It would have been helpful to me if the phrase "completed execution" in the docs for #awaitTermination and #close had mentioned that canceled tasks are always considered to have completed execution, even if their Runnable hasn't returned yet. Would a change that more clearly documents this behavior be welcome? Is there a clear definition of "completed execution" in some other parts of the j.u.c docs that specifies this behavior? Fabian From swen at openjdk.org Sun Jan 5 11:01:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 5 Jan 2025 11:01:18 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v5] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: vector digit2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/fd51c1ce..f97093d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=03-04 Stats: 64 lines in 3 files changed: 55 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From swen at openjdk.org Sun Jan 5 11:42:35 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 5 Jan 2025 11:42:35 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v5] In-Reply-To: References: Message-ID: <8LZD1-m-RUHZluAuEGZHZvkxrnoCiQ5eCrQVCYovOUA=.40b8c683-a225-4b12-9053-715945ba2ee4@github.com> On Sun, 5 Jan 2025 11:01:18 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > vector digit2 The performance is improved again by calculating two characters at a time in the DecimalDigit::digit2 method. The performance numbers are as follows: ## 1. Script git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao #master git checkout 5bb9644202a8b961faad02439c95a81ca6862168 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" # current git checkout f97093d324fbb7de322c86d52db11cafcff2de87 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" ## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa) -Benchmark (size) Mode Cnt Score Error Units (master 5bb9644) -Longs.parseLong 500 avgt 15 3.539 ? 0.031 us/op -Integers.parseInt 500 avgt 15 3.270 ? 0.028 us/op +Benchmark (size) Mode Cnt Score Error Units (current f97093d) +Longs.parseLong 500 avgt 15 3.029 ? 0.033 us/op +16.83% +Integers.parseInt 500 avgt 15 3.120 ? 0.004 us/op +4.80% ## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids) -Benchmark (size) Mode Cnt Score Error Units (master 5bb9644) -Longs.parseLong 500 avgt 15 3.469 ? 0.011 us/op -Integers.parseInt 500 avgt 15 3.136 ? 0.005 us/op +Benchmark (size) Mode Cnt Score Error Units (current f97093d) +Longs.parseLong 500 avgt 15 2.999 ? 0.024 us/op +15.67% +Integers.parseInt 500 avgt 15 2.819 ? 0.004 us/op +11.24% ## 4. orange_pi5_aarch64 (CPU RK3588S) -Benchmark (size) Mode Cnt Score Error Units (master 5bb9644) -Longs.parseLong 500 avgt 15 9.903 ? 0.064 us/op -Integers.parseInt 500 avgt 15 9.527 ? 0.678 us/op +Benchmark (size) Mode Cnt Score Error Units (current f97093d) +Longs.parseLong 500 avgt 15 8.702 ? 1.287 us/op +13.80% +Integers.parseInt 500 avgt 15 6.117 ? 0.046 us/op +55.74% # 5. MacBook M1 Pro (aarch64) -Benchmark (size) Mode Cnt Score Error Units (master 5bb9644) -Longs.parseLong 500 avgt 15 2.617 ? 0.040 us/op -Integers.parseInt 500 avgt 15 2.344 ? 0.027 us/op +Benchmark (size) Mode Cnt Score Error Units (current f97093d) +Longs.parseLong 500 avgt 15 2.262 ? 0.014 us/op +15.69% +Integers.parseInt 500 avgt 15 2.033 ? 0.007 us/op +15.29% ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2571595624 From alan.bateman at oracle.com Sun Jan 5 17:32:03 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sun, 5 Jan 2025 17:32:03 +0000 Subject: Docs for ExecutorService#close and canceled tasks In-Reply-To: References: Message-ID: <53aa1009-4edd-453a-8148-8b5b50fb32ed@oracle.com> On 05/01/2025 10:20, Fabian Meumertzheim wrote: > Hi, > > I recently traced a race in an application > (https://github.com/bazelbuild/bazel/issues/21773) down to a > particular behavior of ExecutorService#close that, to me, doesn't seem > to be obvious from its documentation: If a task that has been > submitted to the executor is canceled while it is already executing, > ExecutorService#close will not wait for the associated Runnable to > return. Thanks for bringing this up. TPTE interpreted "all tasks have completed execution" to mean all tasks done (Future::isDone) whereas it may have been better to have followed TPE and FJP and wait for all threads to have completed the tasks. So yes, some spec clarification may be needed here but it will need to take into account other ExecutorService implementation that may exist elsewhere. In addition, we need to think about changing TPTE to avoid the surprising behavior. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Mon Jan 6 04:32:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 6 Jan 2025 04:32:44 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 09:12:55 GMT, Joakim Nordstr?m wrote: > Could I get a review of this fix to refine the warnings printed by `libjsig` when using the deprecated `signal()`/`sigset()` functions? > > Currently the libjsig library supports chaining `signal()` and `sigset()`. With these functions being deprecated, `libjsig` warns when a program calls either function when the it's LD_PRELOADed. The warning is supposed to warn that when the support for `signal()` and `sigset()` is removed, the application might stop working as expected. > >> VM warning: the use of signal() and sigset() for signal chaining was deprecated in version 16.0 and will be removed in a future release. Use sigaction() instead. > > The warning is however printed in a few cases when its unnecessary, and also fails to catch some usages where it should be printed. With this fix the warning is printed (in order as they appear in jsig.c): > 1. when `signal()` or `sigset()` is called for a JVM-used signal, after the JVM has installed its signals > 2. when the JVM installs its signals (using `sigaction()`), and libjsig sees that `signal()` or `sigset()` has been used for a JVM-used signal > > ### Changes > * The printing is removed from `call_os_signal()`. This warning was only correct if `signal()` or `sigset()` was called for a JVM-used signal before the JVM was installed. This is now instead covered by step 1 above. > * If the JVM was installed first, the `signal()`/`sigset()` calls were effectively translated to `sigaction()`, and the warning was _not_ printed. When the `signal()`/`sigset()` support is dropped, this behaviour will change and the warning should be printed. This is now covered by step 2. > > ## Testing > - [x] Test `open/test/hotspot/jtreg/runtime/signal` has added checks for the deprecation warning, and passes with the fix > - [x] Tier1-3 in progress Thanks for taking this on @jaokim and apologies I did not get to this before the Xmas/NY break. The changes look good and I agree with the updated conditions as to when the deprecation warning is, and isn't, printed. A couple of minor suggestions and a query about the test. Copyright years will need updating to 2025. test/hotspot/jtreg/runtime/signal/SigTestDriver.java line 131: > 129: if (deprecatedSigFunctionUsed && jvmInvolved && sigUsedByJVM) { > 130: if (!warningPrinted) { > 131: failureMessage = "FAILED Missing deprecation warning for mode " + mode + Suggestion: failureMessage = "FAILED: Missing deprecation warning for mode " + mode + test/hotspot/jtreg/runtime/signal/SigTestDriver.java line 136: > 134: } > 135: } else if (warningPrinted) { > 136: failureMessage = "FAILED Deprecation warning shouldn't be printed for mode " + mode + Suggestion: failureMessage = "FAILED: Deprecation warning shouldn't be printed for mode " + mode + test/hotspot/jtreg/runtime/signal/SigTestDriver.java line 176: > 174: /** > 175: * Return true for all signals used by the JVM. This only covers the > 176: * case where the JVM is started normally, and not with -Xrs. The VM also uses SIGUSR2 (`SR_signum`), SIGINT, and SIGQUIT. Though the latter two only if no `-Xrs` is given. ------------- PR Review: https://git.openjdk.org/jdk/pull/22806#pullrequestreview-2531291539 PR Review Comment: https://git.openjdk.org/jdk/pull/22806#discussion_r1903630765 PR Review Comment: https://git.openjdk.org/jdk/pull/22806#discussion_r1903630936 PR Review Comment: https://git.openjdk.org/jdk/pull/22806#discussion_r1903636877 From dholmes at openjdk.org Mon Jan 6 06:26:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 6 Jan 2025 06:26:47 GMT Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3] In-Reply-To: References: Message-ID: On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing wrote: >> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages. > > Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision: > > Revert fix in the CTW Makefile. LGTM2. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2531429430 From qxing at openjdk.org Mon Jan 6 06:26:47 2025 From: qxing at openjdk.org (Qizheng Xing) Date: Mon, 6 Jan 2025 06:26:47 GMT Subject: Integrated: 8346773: Fix unmatched brackets in some misc files In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing wrote: > This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages. This pull request has now been integrated. Changeset: f1d85ab3 Author: Qizheng Xing URL: https://git.openjdk.org/jdk/commit/f1d85ab3e61f923b4e120cf30e16109e04505b53 Stats: 10 lines in 7 files changed: 0 ins; 0 del; 10 mod 8346773: Fix unmatched brackets in some misc files Reviewed-by: kbarrett, alanb, rriggs, dholmes, erikj, liach ------------- PR: https://git.openjdk.org/jdk/pull/22861 From asotona at openjdk.org Mon Jan 6 08:45:48 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 08:45:48 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages [v2] In-Reply-To: References: Message-ID: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> > This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: updated copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22912/files - new: https://git.openjdk.org/jdk/pull/22912/files/06ec27bf..f8fe6546 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22912&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22912&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22912/head:pull/22912 PR: https://git.openjdk.org/jdk/pull/22912 From alanb at openjdk.org Mon Jan 6 08:48:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 6 Jan 2025 08:48:38 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages [v2] In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> References: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> Message-ID: On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona wrote: >> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2531645108 From asotona at openjdk.org Mon Jan 6 08:51:49 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 08:51:49 GMT Subject: RFR: 8346984: Remove ASM-based benchmarks from Class-File API benchmarks [v2] In-Reply-To: References: Message-ID: > ASM-based benchmarks were useful to directly compare performance of ASM and Class-File API. > However Class-File API performance history is now continuously tracked and direct comparison to ASM becomes obsolete. > > This patch removes ASM-based benchmarks from test/micro/org/openjdk/bench/jdk/classfile. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: updated copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22914/files - new: https://git.openjdk.org/jdk/pull/22914/files/fea29a38..8d9bd0c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22914&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22914&range=00-01 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/22914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22914/head:pull/22914 PR: https://git.openjdk.org/jdk/pull/22914 From asotona at openjdk.org Mon Jan 6 08:56:09 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 08:56:09 GMT Subject: RFR: 8346983: Remove ASM-based transforms from Class-File API tests [v2] In-Reply-To: References: Message-ID: > This patch removes obsolete ASM-based transformations from Class-File API tests. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: updated copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22913/files - new: https://git.openjdk.org/jdk/pull/22913/files/8112cd3b..e810f049 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22913&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22913&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22913/head:pull/22913 PR: https://git.openjdk.org/jdk/pull/22913 From syan at openjdk.org Mon Jan 6 09:21:06 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 6 Jan 2025 09:21:06 GMT Subject: RFR: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate fails NoClassDefFoundError Message-ID: Hi all, This PR add JVM option `jvmArgs={"--add-modules=jdk.incubator.vector"}` for test/micro/org/openjdk/bench/jdk/incubator/vector/SpiltReplicate.java, to fix test bug which cause jmh test fails 'java.lang.NoClassDefFoundError: jdk/incubator/vector/FloatVector'. Change has been verified locally, test-fix only, no risk. ------------- Commit messages: - 8347038: [JMH] jdk.incubator.vector.SpiltReplicate.testFloat fails java.lang.NoClassDefFoundError: jdk/incubator/vector/FloatVector Changes: https://git.openjdk.org/jdk/pull/22923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22923&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347038 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22923/head:pull/22923 PR: https://git.openjdk.org/jdk/pull/22923 From amitkumar at openjdk.org Mon Jan 6 13:29:40 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 6 Jan 2025 13:29:40 GMT Subject: [jdk24] RFR: 8346069: Add missing Classpath exception statements In-Reply-To: <_lfzgi1B4zrZA7D9_J0nXVm6NEoFs7XUuOeElhRSPIo=.daf511dd-7330-42fe-83c8-e3071cac440b@github.com> References: <_lfzgi1B4zrZA7D9_J0nXVm6NEoFs7XUuOeElhRSPIo=.daf511dd-7330-42fe-83c8-e3071cac440b@github.com> Message-ID: On Tue, 17 Dec 2024 08:04:25 GMT, Sorna Sarathi N wrote: > Hi all, > > This pull request contains a backport of [openjdk/jdk#22704](https://github.com/openjdk/jdk/pull/22704.) > > The commit being backported was authored by Sorna Sarathi on 13 Dec 2024 and was reviewed by Amit Kumar, Alexey Semenyuk, Iris Clark and Kevin Rushforth. > > Thanks! Marked as reviewed by amitkumar (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22785#pullrequestreview-2532137249 From ssarathi at openjdk.org Mon Jan 6 13:29:41 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Mon, 6 Jan 2025 13:29:41 GMT Subject: [jdk24] Integrated: 8346069: Add missing Classpath exception statements In-Reply-To: <_lfzgi1B4zrZA7D9_J0nXVm6NEoFs7XUuOeElhRSPIo=.daf511dd-7330-42fe-83c8-e3071cac440b@github.com> References: <_lfzgi1B4zrZA7D9_J0nXVm6NEoFs7XUuOeElhRSPIo=.daf511dd-7330-42fe-83c8-e3071cac440b@github.com> Message-ID: On Tue, 17 Dec 2024 08:04:25 GMT, Sorna Sarathi N wrote: > Hi all, > > This pull request contains a backport of [openjdk/jdk#22704](https://github.com/openjdk/jdk/pull/22704.) > > The commit being backported was authored by Sorna Sarathi on 13 Dec 2024 and was reviewed by Amit Kumar, Alexey Semenyuk, Iris Clark and Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: 33971ecb Author: Sorna Sarathi N Committer: Amit Kumar URL: https://git.openjdk.org/jdk/commit/33971ecb6e9c371c9110c1c17252f0a5e881c56b Stats: 33 lines in 11 files changed: 22 ins; 0 del; 11 mod 8346069: Add missing Classpath exception statements Reviewed-by: kcr, iris, amitkumar Backport-of: 09c29d1d4274d9c36e1af98f02e6fc5b3f35133f ------------- PR: https://git.openjdk.org/jdk/pull/22785 From liach at openjdk.org Mon Jan 6 14:10:46 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 14:10:46 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages [v2] In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> References: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> Message-ID: On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona wrote: >> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2532210782 From asotona at openjdk.org Mon Jan 6 14:10:47 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 14:10:47 GMT Subject: RFR: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages [v2] In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> References: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com> Message-ID: On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona wrote: >> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22912#issuecomment-2573185292 From asotona at openjdk.org Mon Jan 6 14:10:47 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 14:10:47 GMT Subject: Integrated: 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona wrote: > This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: e0695e0e Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/e0695e0ef0dd1bfacbaac32edda055ba852a2421 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod 8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages Reviewed-by: liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/22912 From liach at openjdk.org Mon Jan 6 14:11:48 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 14:11:48 GMT Subject: RFR: 8346983: Remove ASM-based transforms from Class-File API tests [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 08:56:09 GMT, Adam Sotona wrote: >> This patch removes obsolete ASM-based transformations from Class-File API tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22913#pullrequestreview-2532212131 From asotona at openjdk.org Mon Jan 6 14:11:49 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 14:11:49 GMT Subject: RFR: 8346983: Remove ASM-based transforms from Class-File API tests [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 08:56:09 GMT, Adam Sotona wrote: >> This patch removes obsolete ASM-based transformations from Class-File API tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright year Thank you for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22913#issuecomment-2573186515 From asotona at openjdk.org Mon Jan 6 14:11:50 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 14:11:50 GMT Subject: Integrated: 8346983: Remove ASM-based transforms from Class-File API tests In-Reply-To: References: Message-ID: <-XhVIEwkq2HnPTaGyJaGtNnUuEBhrK54LqWrnU1j1o0=.150b8618-5dbd-4ec6-bd0a-fe3845f35ea1@github.com> On Fri, 3 Jan 2025 12:19:54 GMT, Adam Sotona wrote: > This patch removes obsolete ASM-based transformations from Class-File API tests. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: c027f2ed Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/c027f2ed1d77f34bbd1db8418156322d3a13ab81 Stats: 352 lines in 2 files changed: 0 ins; 349 del; 3 mod 8346983: Remove ASM-based transforms from Class-File API tests Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/22913 From asotona at openjdk.org Mon Jan 6 14:13:49 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 14:13:49 GMT Subject: RFR: 8346984: Remove ASM-based benchmarks from Class-File API benchmarks [v2] In-Reply-To: References: Message-ID: <4B5LjCf9J326e5ikaTM0P2NKmMNqIHoq3po-DTxvu2E=.c409e14f-ae9a-4671-b66d-2cfe2b40d321@github.com> On Mon, 6 Jan 2025 08:51:49 GMT, Adam Sotona wrote: >> ASM-based benchmarks were useful to directly compare performance of ASM and Class-File API. >> However Class-File API performance history is now continuously tracked and direct comparison to ASM becomes obsolete. >> >> This patch removes ASM-based benchmarks from test/micro/org/openjdk/bench/jdk/classfile. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright years Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22914#issuecomment-2573188489 From asotona at openjdk.org Mon Jan 6 14:13:50 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 6 Jan 2025 14:13:50 GMT Subject: Integrated: 8346984: Remove ASM-based benchmarks from Class-File API benchmarks In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 12:46:27 GMT, Adam Sotona wrote: > ASM-based benchmarks were useful to directly compare performance of ASM and Class-File API. > However Class-File API performance history is now continuously tracked and direct comparison to ASM becomes obsolete. > > This patch removes ASM-based benchmarks from test/micro/org/openjdk/bench/jdk/classfile. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 594e5196 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/594e5196481fd3f9ba21f56120d4377a901f52ec Stats: 555 lines in 7 files changed: 0 ins; 548 del; 7 mod 8346984: Remove ASM-based benchmarks from Class-File API benchmarks Reviewed-by: liach, redestad, erikj ------------- PR: https://git.openjdk.org/jdk/pull/22914 From liach at openjdk.org Mon Jan 6 14:13:49 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 14:13:49 GMT Subject: RFR: 8346984: Remove ASM-based benchmarks from Class-File API benchmarks [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 08:51:49 GMT, Adam Sotona wrote: >> ASM-based benchmarks were useful to directly compare performance of ASM and Class-File API. >> However Class-File API performance history is now continuously tracked and direct comparison to ASM becomes obsolete. >> >> This patch removes ASM-based benchmarks from test/micro/org/openjdk/bench/jdk/classfile. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright years Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22914#pullrequestreview-2532214497 From rriggs at openjdk.org Mon Jan 6 16:36:35 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 6 Jan 2025 16:36:35 GMT Subject: RFR: 8346468: SM cleanup of common test library [v3] In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 21:07:14 GMT, Roger Riggs wrote: >> SM Cleanup of common test library test/lib/...: >> >> Remove unnecessary catches of SecurityException >> Remove AccessController and doPrivileged from SimpleSSLContext and ProcessTools. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed more references to WhiteBox$Permission Ping, a bit more cleanup to review! Tnx ------------- PR Comment: https://git.openjdk.org/jdk/pull/22814#issuecomment-2573473543 From naoto at openjdk.org Mon Jan 6 17:06:42 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 6 Jan 2025 17:06:42 GMT Subject: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v4] In-Reply-To: References: Message-ID: <4adDdG4RwYsEy2WwbMmZcPm4vtOsPyi063dTZQ4COwQ=.eb55fcbf-5c0b-4059-b134-0f1fa2593635@github.com> On Thu, 2 Jan 2025 18:11:53 GMT, Naoto Sato wrote: >> The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous, but it caused this performance regression. Partially reverting the change (ones that involve `computeIfAbsent()`) to the original. Provided a benchmark that iterates the call to `ZoneOffset.ofTotalSeconds(0)` 1,000 times, which improves the operation time from 3,946ns to 2,241ns. > > Naoto Sato 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 five additional commits since the last revision: > > - Addresses review comments > - Merge branch 'master' into JDK-8345668-ofTotalSeconds-perf-regression > - Fixed compile error > - Update src/java.base/share/classes/java/time/ZoneOffset.java > > Co-authored-by: Roger Riggs > - initial commit Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22854#issuecomment-2573530009 From naoto at openjdk.org Mon Jan 6 17:06:43 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 6 Jan 2025 17:06:43 GMT Subject: Integrated: 8345668: ZoneOffset.ofTotalSeconds performance regression In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 19:55:06 GMT, Naoto Sato wrote: > The change made in [JDK-8288723](https://bugs.openjdk.org/browse/JDK-8288723) seems innocuous, but it caused this performance regression. Partially reverting the change (ones that involve `computeIfAbsent()`) to the original. Provided a benchmark that iterates the call to `ZoneOffset.ofTotalSeconds(0)` 1,000 times, which improves the operation time from 3,946ns to 2,241ns. This pull request has now been integrated. Changeset: 9a60f445 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/9a60f4457bb56d0f5039a97e6b943e62a8a2c3ee Stats: 31 lines in 3 files changed: 22 ins; 0 del; 9 mod 8345668: ZoneOffset.ofTotalSeconds performance regression Reviewed-by: rriggs, aturbanov ------------- PR: https://git.openjdk.org/jdk/pull/22854 From bpb at openjdk.org Mon Jan 6 17:54:41 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 6 Jan 2025 17:54:41 GMT Subject: RFR: 8343342: java/io/File/GetXSpace.java fails on Windows with CD-ROM drive [v8] In-Reply-To: References: <6ms1FZCjS-AMQ8T4EJFY9vmNR2Y4-x2-qYrX3CONECA=.12553387-a199-4145-b316-b151fd57e7fd@github.com> Message-ID: On Tue, 24 Dec 2024 11:46:44 GMT, Taizo Kurashige wrote: > After applying the patch you provided, I confirmed that the test using the mounted ISO file passes. I'm sorry I haven't been able to see the results of the physical CD drive test myself, but I think I'll commit this patch. Thank you for suggesting a patch. During the next few days, I will try to test the latest version of this patch for all cases. > I understood about your holidays. Have a nice holiday. Thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21799#issuecomment-2573615653 From liach at openjdk.org Mon Jan 6 18:31:46 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 18:31:46 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history Message-ID: `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. ------------- Commit messages: - CFFV evolution comments Changes: https://git.openjdk.org/jdk/pull/22934/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22934&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347063 Stats: 36 lines in 1 file changed: 35 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22934/head:pull/22934 PR: https://git.openjdk.org/jdk/pull/22934 From psandoz at openjdk.org Mon Jan 6 19:18:35 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 6 Jan 2025 19:18:35 GMT Subject: RFR: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate fails NoClassDefFoundError In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 09:12:01 GMT, SendaoYan wrote: > Hi all, > This PR add JVM option `jvmArgs={"--add-modules=jdk.incubator.vector"}` for test/micro/org/openjdk/bench/jdk/incubator/vector/SpiltReplicate.java, to fix test bug which cause jmh test fails 'java.lang.NoClassDefFoundError: jdk/incubator/vector/FloatVector'. Change has been verified locally, test-fix only, no risk. Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22923#pullrequestreview-2532805058 From darcy at openjdk.org Mon Jan 6 19:47:35 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 6 Jan 2025 19:47:35 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 18:26:54 GMT, Chen Liang wrote: > `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. Generally looks fine and the changes per release look plausible; I didn't double-check them. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22934#pullrequestreview-2532849326 From iris at openjdk.org Mon Jan 6 20:23:39 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 6 Jan 2025 20:23:39 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 18:26:54 GMT, Chen Liang wrote: > `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. Verified via consultation of the various platform JSRs. Though this isn't done in SourceVersion, I'm wondering if it would be helpful to reference the associated JEPs which describe these changes (e.g. JEP 12 for Preview Features, 359 for Records (Preview), 384 Records (Second Preview), 395 Records, etc.). src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 69: > 67: * type annotations (Runtime(Inv/V)isibleTypeAnnotations); > 68: * MethodParameters > 69: * 9: modules (Module, ModuleMainClass, ModulePackages, CONSTANT_Module, Consider referencing JSR 376 for the introduction of Modules. JEP 261 describes the changes to class files. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22934#pullrequestreview-2532900096 PR Review Comment: https://git.openjdk.org/jdk/pull/22934#discussion_r1904596057 From duke at openjdk.org Mon Jan 6 21:06:55 2025 From: duke at openjdk.org (duke) Date: Mon, 6 Jan 2025 21:06:55 GMT Subject: Withdrawn: 8334048: -Xbootclasspath can not read some ZIP64 zip files In-Reply-To: References: Message-ID: <9iQHX2ilEqw8GmLtpxy5jCwwAB2bC9z8gRby9_OBRWo=.1624dd85-b59c-482b-99f6-cf86725a0d79@github.com> On Wed, 12 Jun 2024 14:02:58 GMT, Thomas Fitzsimmons wrote: > 8334048: -Xbootclasspath can not read some ZIP64 zip files This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19678 From liach at openjdk.org Mon Jan 6 21:20:58 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 21:20:58 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v2] In-Reply-To: References: Message-ID: > `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Add JEP/JSR numbers, clarify if something is attribute/modifier/etc. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22934/files - new: https://git.openjdk.org/jdk/pull/22934/files/77a723b8..13396297 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22934&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22934&range=00-01 Stats: 26 lines in 1 file changed: 6 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/22934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22934/head:pull/22934 PR: https://git.openjdk.org/jdk/pull/22934 From liach at openjdk.org Mon Jan 6 21:25:47 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 21:25:47 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 21:20:58 GMT, Chen Liang wrote: >> `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Add JEP/JSR numbers, clarify if something is attribute/modifier/etc. I have added the JEP and JSR numbers for some of the features, and clarified if the changed features are attributes, modifiers, constant pool entries, or instructions/opcodes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22934#issuecomment-2573950541 From liach at openjdk.org Mon Jan 6 21:41:17 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 21:41:17 GMT Subject: RFR: 8342468: Improve API documentation for java.lang.classfile.constantpool [v3] In-Reply-To: <3vFQsVbVNWwkMmujMjMqpMA-ZvbxbWqRp5W-4XrycYM=.c60d6f08-74eb-4874-bbee-aa2d0365e8f3@github.com> References: <3vFQsVbVNWwkMmujMjMqpMA-ZvbxbWqRp5W-4XrycYM=.c60d6f08-74eb-4874-bbee-aa2d0365e8f3@github.com> Message-ID: > Improve documentation for constant pool entries. This include some models for those entries, symbolic descriptors, and some general guidance in package summary. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-consts/ > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-consts/ > > Please review the associated CSR as well. > > Companion PRs: #21625 Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - BSMEntry and copyright year - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool - Minor cleanups - Stage more doc changes - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool - More concise message about exceptions - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool - Improve api docs for constantpool ------------- Changes: https://git.openjdk.org/jdk/pull/22217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22217&range=02 Stats: 1139 lines in 31 files changed: 768 ins; 69 del; 302 mod Patch: https://git.openjdk.org/jdk/pull/22217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22217/head:pull/22217 PR: https://git.openjdk.org/jdk/pull/22217 From iris at openjdk.org Mon Jan 6 21:50:40 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 6 Jan 2025 21:50:40 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 21:20:58 GMT, Chen Liang wrote: >> `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Add JEP/JSR numbers, clarify if something is attribute/modifier/etc. Looks good. Note that changes in JDK 7 and earlier pre-date JEPs, so no reference of that type is possible. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22934#pullrequestreview-2533029445 From liach at openjdk.org Mon Jan 6 22:08:38 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 6 Jan 2025 22:08:38 GMT Subject: RFR: 8342468: Improve API documentation for java.lang.classfile.constantpool [v3] In-Reply-To: References: <3vFQsVbVNWwkMmujMjMqpMA-ZvbxbWqRp5W-4XrycYM=.c60d6f08-74eb-4874-bbee-aa2d0365e8f3@github.com> Message-ID: On Mon, 6 Jan 2025 21:41:17 GMT, Chen Liang wrote: >> Improve documentation for constant pool entries. This include some models for those entries, symbolic descriptors, and some general guidance in package summary. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-consts/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-consts/ >> >> Please review the associated CSR as well. >> >> Companion PRs: #21625 > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - BSMEntry and copyright year > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Minor cleanups > - Stage more doc changes > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - More concise message about exceptions > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Improve api docs for constantpool I have fixed the missing BootstrapMethodEntry and updated APIDiff/Javadoc and copyright year. Please review the associated CSR as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22217#issuecomment-2574009664 From dholmes at openjdk.org Tue Jan 7 04:33:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Jan 2025 04:33:36 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 21:20:58 GMT, Chen Liang wrote: >> `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Add JEP/JSR numbers, clarify if something is attribute/modifier/etc. src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 58: > 56: * 2: ACC_STRICT modifier > 57: * 3: no changes > 58: * 4: no changes The version mapping can be tricky here: is "1" 1.0 plus 1.1? I presume "2" is 1.2, "3" is 1.3.x, "4" is 1.4.x Might be useful to include the actual JVMS classfile version numbers for ease of reference back to JVMS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22934#discussion_r1904892789 From darcy at openjdk.org Tue Jan 7 04:46:36 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 7 Jan 2025 04:46:36 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v2] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 04:30:50 GMT, David Holmes wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Add JEP/JSR numbers, clarify if something is attribute/modifier/etc. > > src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 58: > >> 56: * 2: ACC_STRICT modifier >> 57: * 3: no changes >> 58: * 4: no changes > > The version mapping can be tricky here: is "1" 1.0 plus 1.1? I presume "2" is 1.2, "3" is 1.3.x, "4" is 1.4.x > > Might be useful to include the actual JVMS classfile version numbers for ease of reference back to JVMS. I assume the wording implicitly is referring to the enum position, which uses a "RELEASE_$N" convention. However, I agree that adding the major version in some form would aid people more familiar with those numbers. One possibility: 3 (47.0) no changes 4 (48.0) no changes If that is adopted, perhaps the preview features could be listed with the minor version set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22934#discussion_r1904899671 From mbaesken at openjdk.org Tue Jan 7 08:17:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 7 Jan 2025 08:17:40 GMT Subject: RFR: 8345676: [ubsan] ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer on macOS aarch64 In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 10:29:31 GMT, Matthias Baesken wrote: > When starting :tier1 jdk jtreg tests with > /jtreg_latest/bin/jtreg > this error is show when running ubsanized binaries on macOS aarch64 (XCode 13.1 and 15.4 show this) > > src/java.base/unix/native/libjava/ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer > #0 0x102a6552c in startChild ProcessImpl_md.c:621 > #1 0x102a64480 in Java_java_lang_ProcessImpl_forkAndExec ProcessImpl_md.c:721 > #2 0x13f53c4fc () > #3 0x13f5387cc () > #4 0x13f53894c () > #5 0x13f5386dc () > #6 0x13f5386dc () > #7 0x13f5386dc () > #8 0x13f53894c () > #9 0x13f53894c () > #10 0x13f534110 () > #11 0x107de60e0 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:416 > #12 0x107ebf778 in jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) jni.cpp:885 > #13 0x107ec2778 in jni_CallStaticVoidMethod jni.cpp:1714 > #14 0x102e86210 in invokeStaticMainWithArgs java.c:392 > #15 0x102e884e8 in JavaMain java.c:640 > #16 0x102e8d79c in ThreadJavaMain java_md_macosx.m:679 > #17 0x19d38ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #18 0x19d389d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > Looks similar to > https://www.reddit.com/r/C_Programming/comments/133oxnc/null_0_is_ub_this_is_not_what_you_would_expect/?rdt=41590 > and > https://trac.ffmpeg.org/changeset/9c0b3eddf4262f9dcea479091f1307444e614e88/ffmpeg Hi Roger, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22910#issuecomment-2574641996 From mbaesken at openjdk.org Tue Jan 7 08:17:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 7 Jan 2025 08:17:40 GMT Subject: Integrated: 8345676: [ubsan] ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer on macOS aarch64 In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 10:29:31 GMT, Matthias Baesken wrote: > When starting :tier1 jdk jtreg tests with > /jtreg_latest/bin/jtreg > this error is show when running ubsanized binaries on macOS aarch64 (XCode 13.1 and 15.4 show this) > > src/java.base/unix/native/libjava/ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer > #0 0x102a6552c in startChild ProcessImpl_md.c:621 > #1 0x102a64480 in Java_java_lang_ProcessImpl_forkAndExec ProcessImpl_md.c:721 > #2 0x13f53c4fc () > #3 0x13f5387cc () > #4 0x13f53894c () > #5 0x13f5386dc () > #6 0x13f5386dc () > #7 0x13f5386dc () > #8 0x13f53894c () > #9 0x13f53894c () > #10 0x13f534110 () > #11 0x107de60e0 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) javaCalls.cpp:416 > #12 0x107ebf778 in jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) jni.cpp:885 > #13 0x107ec2778 in jni_CallStaticVoidMethod jni.cpp:1714 > #14 0x102e86210 in invokeStaticMainWithArgs java.c:392 > #15 0x102e884e8 in JavaMain java.c:640 > #16 0x102e8d79c in ThreadJavaMain java_md_macosx.m:679 > #17 0x19d38ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #18 0x19d389d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > Looks similar to > https://www.reddit.com/r/C_Programming/comments/133oxnc/null_0_is_ub_this_is_not_what_you_would_expect/?rdt=41590 > and > https://trac.ffmpeg.org/changeset/9c0b3eddf4262f9dcea479091f1307444e614e88/ffmpeg This pull request has now been integrated. Changeset: 0285020c Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/0285020c7ea01f32b32efe166a0a5dae39957216 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8345676: [ubsan] ProcessImpl_md.c:561:40: runtime error: applying zero offset to null pointer on macOS aarch64 Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/22910 From jpai at openjdk.org Tue Jan 7 09:33:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Jan 2025 09:33:09 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v13] In-Reply-To: References: Message-ID: > Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? > > The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: > > https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html > > To summarize those discussions, we had concluded that: > - `Deflater` and `Inflater` will implement the `AutoCloseable` interface > - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). > - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. > - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. > - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. > > New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. > > I'll file a CSR shortly. Jaikiran Pai 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 26 additional commits since the last revision: - test code comment improvement - Roger's review - improve class level javadoc text of Inflater/Deflater - merge latest from master branch - merge latest from master branch - provide guidance to subclasses on which method to override for cleaning up resources - Revert "Roger's suggestion - Make Inflater.close() and Deflater.close() final, also update the new tests to match this change" This reverts commit b60181bbb4be9fac294b16820cd02017de71783e. - merge latest from master branch - update end() to remove mention of other methods throwing IllegalStateException - update the class level documentation of Inflater to match the updates in Deflater - merge latest from master branch - ... and 16 more: https://git.openjdk.org/jdk/compare/8e90cf7d...2266b5c5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19675/files - new: https://git.openjdk.org/jdk/pull/19675/files/42ff9059..2266b5c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=11-12 Stats: 92121 lines in 4045 files changed: 68076 ins; 14391 del; 9654 mod Patch: https://git.openjdk.org/jdk/pull/19675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675 PR: https://git.openjdk.org/jdk/pull/19675 From jpai at openjdk.org Tue Jan 7 09:33:12 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Jan 2025 09:33:12 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v12] In-Reply-To: References: <4OyRSf3vfhs8gAAzEQJQbuCIY30Wnfv1UnJKfbd66eY=.052f5c6a-7275-4a2e-b41e-2eeed503d4fc@github.com> Message-ID: On Mon, 2 Dec 2024 16:55:23 GMT, Roger Riggs wrote: >> Jaikiran Pai 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 22 additional commits since the last revision: >> >> - provide guidance to subclasses on which method to override for cleaning up resources >> - Revert "Roger's suggestion - Make Inflater.close() and Deflater.close() final, also update the new tests to match this change" >> >> This reverts commit b60181bbb4be9fac294b16820cd02017de71783e. >> - merge latest from master branch >> - update end() to remove mention of other methods throwing IllegalStateException >> - update the class level documentation of Inflater to match the updates in Deflater >> - merge latest from master branch >> - improve Deflater class level doc >> - Stuart's review - improve end() API doc >> - merge latest from master branch >> - missed a few methods for specifying IllegalStateException >> - ... and 12 more: https://git.openjdk.org/jdk/compare/ec8a7574...42ff9059 > > src/java.base/share/classes/java/util/zip/Inflater.java line 58: > >> 56: * To release resources used by the {@code Inflater}, applications must call the >> 57: * {@link #end()} method. After {@code end()} has been called, subsequent calls >> 58: * to several methods of the {@code Inflater} will throw an {@link IllegalStateException}. > > Since `close()` is not mentioned here, there may be some come confusion about whether `end()` still needs to be called within T-W-R. I think that's a good point. I've now updated the PR to reword this part of the text both in `Inflater` and `Deflater`. Does the change look OK? > test/jdk/java/util/zip/DeflaterClose.java line 43: > >> 41: >> 42: /** >> 43: * Closes the Deflater multiple times and then expects close() and end() to be called that > > Should this be "close() *or* end()"? Hello Roger, calling `close()` on Inflater/Deflater will just call `end()` on the instance. So I believe "close() and end()" in the test comment here is correct. I now pushed a very minor change just to make it more clear. Let me know if you think we should improve the comment further. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1905158732 PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1905161112 From sgehwolf at openjdk.org Tue Jan 7 10:43:35 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 7 Jan 2025 10:43:35 GMT Subject: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 07:53:07 GMT, Matthias Baesken wrote: >> Please review this fairly simple change to improve how the `JimageDiffGenerator` works. The original implementation is pretty naive and read all bytes into memory and then compared them. This improved version only reads bytes on a bound buffer into memory compares those bytes and if equal continues on to reading the next bytes (`2k` at most) at a time. Previously it was `2*N` (where `N` is the file size of a file in bytes) part of the JDK. Ouch. >> >> There is still the off-chance of reading a full file into memory when the generator detects a change, but this shouldn't happen for large files since the total diff should be around `600K` as of today. >> >> This also reverts changes from [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036) other than the `/timeout` change to the test, which is preserved as I think this bump is no longer needed. >> >> Testing: >> - [x] GHA >> - [x] jlink tests on a fastdebug build with `--with-native-debug-symbols=internal` (so as to have a large libjvm.so). >> - [x] Manual reproducer from the bug which fails with OOM before the patch and passes after >> >> Thoughts? > > Hi Severin, I added it to our build/test queue. Thanks for the review @MBaesken! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22835#issuecomment-2574957834 From jpai at openjdk.org Tue Jan 7 10:45:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Jan 2025 10:45:09 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v14] In-Reply-To: References: Message-ID: > Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? > > The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: > > https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html > > To summarize those discussions, we had concluded that: > - `Deflater` and `Inflater` will implement the `AutoCloseable` interface > - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). > - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. > - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. > - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. > > New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. > > I'll file a CSR shortly. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: change "@since" to 25 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19675/files - new: https://git.openjdk.org/jdk/pull/19675/files/2266b5c5..618ccc4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=12-13 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675 PR: https://git.openjdk.org/jdk/pull/19675 From pminborg at openjdk.org Tue Jan 7 10:48:42 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Jan 2025 10:48:42 GMT Subject: RFR: 8347047: cleanup action passed to MemorySegment::reinterpret keeps old segment alive Message-ID: This PR proposes to eliminate the capturing of `this` in the cleanup action of `AbstractMemorySegment::reinterpretInternal`. ------------- Commit messages: - Prevent capturing of _this_ Changes: https://git.openjdk.org/jdk/pull/22943/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22943&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347047 Stats: 11 lines in 1 file changed: 7 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22943/head:pull/22943 PR: https://git.openjdk.org/jdk/pull/22943 From sgehwolf at openjdk.org Tue Jan 7 11:06:36 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 7 Jan 2025 11:06:36 GMT Subject: [jdk24] RFR: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 18:18:48 GMT, Mandy Chung wrote: >> Clean backport of [JDK-8345259](https://bugs.openjdk.org/browse/JDK-8345259) to JDK 24 which has JEP 493. > > I created https://bugs.openjdk.org/browse/JDK-8345259. Looks like the tests need update. I think the bug you mean @mlchung is https://bugs.openjdk.org/browse/JDK-8346739, right? Would it be OK to get both into the `jdk24` branch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22849#issuecomment-2575003662 From pminborg at openjdk.org Tue Jan 7 11:30:13 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Jan 2025 11:30:13 GMT Subject: RFR: 8346609: Improve MemorySegment.toString [v2] In-Reply-To: References: Message-ID: > This PR proposes to improve the current `MemorySegment.toString()` method from: > > `MemorySegment{ address: 0x60000264c540, byteSize: 8 }` > > to > > `MemorySegment{ native, address: 0x60000264c540, byteSize: 8}` > > Tests passes tier1-tier3 Per Minborg 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: - Reduce elements in toString - Merge branch 'master' into ms-tostring-improvement2 - Implement an alternate MS::toString - Improve MemorySegment::toString ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22826/files - new: https://git.openjdk.org/jdk/pull/22826/files/73efff46..d960678e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=00-01 Stats: 12435 lines in 343 files changed: 8418 ins; 2966 del; 1051 mod Patch: https://git.openjdk.org/jdk/pull/22826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22826/head:pull/22826 PR: https://git.openjdk.org/jdk/pull/22826 From mcimadamore at openjdk.org Tue Jan 7 11:32:36 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Jan 2025 11:32:36 GMT Subject: RFR: 8347047: cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 10:44:22 GMT, Per Minborg wrote: > This PR proposes to eliminate the capturing of `this` in the cleanup action of `AbstractMemorySegment::reinterpretInternal`. Looks good. ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22943#pullrequestreview-2534105748 From mcimadamore at openjdk.org Tue Jan 7 11:38:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Jan 2025 11:38:39 GMT Subject: RFR: 8347047: cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 10:44:22 GMT, Per Minborg wrote: > This PR proposes to eliminate the capturing of `this` in the cleanup action of `AbstractMemorySegment::reinterpretInternal`. Please test this extensively. There is a non-zero chance that some tests (esp. in later tiers) might be relying on the current (bogus) behavior. So it might be possible for this fix to uncover more use-after-free issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22943#issuecomment-2575067126 From mcimadamore at openjdk.org Tue Jan 7 11:50:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Jan 2025 11:50:47 GMT Subject: RFR: 8346609: Improve MemorySegment.toString [v2] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 11:30:13 GMT, Per Minborg wrote: >> This PR proposes to improve the current `MemorySegment.toString()` method from: >> >> `MemorySegment{ address: 0x60000264c540, byteSize: 8 }` >> >> to >> >> `MemorySegment{ native, address: 0x60000264c540, byteSize: 8}` >> >> Tests passes tier1-tier3 > > Per Minborg 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: > > - Reduce elements in toString > - Merge branch 'master' into ms-tostring-improvement2 > - Implement an alternate MS::toString > - Improve MemorySegment::toString src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 490: > 488: public String toString() { > 489: return "MemorySegment{ " + > 490: heapBase().map(hb -> "heapBase: " + hb).orElse(isMapped() ? "mapped" : "native") + This is not correct. Heap base can be empty for read-only segments. Have we considered printing one of: * HeapMemorySegment * NativeMemorySegment * MappedMemorySegment E.g. add the heap/native/mapped as part of the "class" qualifier, before the `{` ? That seems more readable (of course the drawback is that it might suggest that these classes exist somewhere, which they don't. A possible compromise would be: MemorySegment{ kind: heap/native/mapped, [heapBase: xyz ], address: xyz, size: xyz} This is consistent with the terminology found in the javadoc: > There are two kinds of memory segments: ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22826#discussion_r1905337003 From pminborg at openjdk.org Tue Jan 7 12:17:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Jan 2025 12:17:15 GMT Subject: RFR: 8346609: Improve MemorySegment.toString [v3] In-Reply-To: References: Message-ID: > This PR proposes to improve the current `MemorySegment.toString()` method from: > > `MemorySegment{ address: 0x60000264c540, byteSize: 8 }` > > to > > `MemorySegment{ native, address: 0x60000264c540, byteSize: 8}` > > Tests passes tier1-tier3 Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update segment type logic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22826/files - new: https://git.openjdk.org/jdk/pull/22826/files/d960678e..08ed7c75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=01-02 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22826/head:pull/22826 PR: https://git.openjdk.org/jdk/pull/22826 From pminborg at openjdk.org Tue Jan 7 12:20:26 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Jan 2025 12:20:26 GMT Subject: RFR: 8346609: Improve MemorySegment.toString [v4] In-Reply-To: References: Message-ID: > This PR proposes to improve the current `MemorySegment.toString()` method from: > > `MemorySegment{ address: 0x60000264c540, byteSize: 8 }` > > to > > `MemorySegment{ native, address: 0x60000264c540, byteSize: 8}` > > Tests passes tier1-tier3 Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add 'kind' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22826/files - new: https://git.openjdk.org/jdk/pull/22826/files/08ed7c75..6253e0e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22826/head:pull/22826 PR: https://git.openjdk.org/jdk/pull/22826 From pminborg at openjdk.org Tue Jan 7 12:54:59 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Jan 2025 12:54:59 GMT Subject: RFR: 8346609: Improve MemorySegment.toString [v5] In-Reply-To: References: Message-ID: > This PR proposes to improve the current `MemorySegment.toString()` method from: > > `MemorySegment{ address: 0x60000264c540, byteSize: 8 }` > > to > > `MemorySegment{ native, address: 0x60000264c540, byteSize: 8}` > > Tests passes tier1-tier3 Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Fix extraoneous comma ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22826/files - new: https://git.openjdk.org/jdk/pull/22826/files/6253e0e8..dea2fc31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22826/head:pull/22826 PR: https://git.openjdk.org/jdk/pull/22826 From pminborg at openjdk.org Tue Jan 7 12:58:12 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Jan 2025 12:58:12 GMT Subject: RFR: 8346609: Improve MemorySegment.toString [v6] In-Reply-To: References: Message-ID: <2UiqAnB98v71SKHuInLE-fNClFRn2mPMV3zZGWyw0Xw=.e69d1fcb-037b-408b-a490-4d3f61a55376@github.com> > This PR proposes to improve the current `MemorySegment.toString()` method from: > > `MemorySegment{ address: 0x60000264c540, byteSize: 8 }` > > to > > `MemorySegment{ native, address: 0x60000264c540, byteSize: 8}` > > Tests passes tier1-tier3 Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rename variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22826/files - new: https://git.openjdk.org/jdk/pull/22826/files/dea2fc31..ad0fd941 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22826&range=04-05 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22826/head:pull/22826 PR: https://git.openjdk.org/jdk/pull/22826 From mcimadamore at openjdk.org Tue Jan 7 13:02:52 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Jan 2025 13:02:52 GMT Subject: RFR: 8346609: Improve MemorySegment.toString [v6] In-Reply-To: <2UiqAnB98v71SKHuInLE-fNClFRn2mPMV3zZGWyw0Xw=.e69d1fcb-037b-408b-a490-4d3f61a55376@github.com> References: <2UiqAnB98v71SKHuInLE-fNClFRn2mPMV3zZGWyw0Xw=.e69d1fcb-037b-408b-a490-4d3f61a55376@github.com> Message-ID: On Tue, 7 Jan 2025 12:58:12 GMT, Per Minborg wrote: >> This PR proposes to improve the current `MemorySegment.toString()` method from: >> >> `MemorySegment{ address: 0x60000264c540, byteSize: 8 }` >> >> to >> >> `MemorySegment{ native, address: 0x60000264c540, byteSize: 8}` >> >> Tests passes tier1-tier3 > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rename variable Marked as reviewed by mcimadamore (Reviewer). src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 490: > 488: public String toString() { > 489: final String kind; > 490: if (this instanceof HeapMemorySegmentImpl) { could also be a "virtual" method ------------- PR Review: https://git.openjdk.org/jdk/pull/22826#pullrequestreview-2534281439 PR Review Comment: https://git.openjdk.org/jdk/pull/22826#discussion_r1905422287 From sgehwolf at openjdk.org Tue Jan 7 14:05:19 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 7 Jan 2025 14:05:19 GMT Subject: RFR: 8345185: Update jpackage to not include service bindings by default [v4] In-Reply-To: References: Message-ID: > Please review these changes to jpackage in light of [JEP 493](https://openjdk.org/jeps/493). When this feature is enabled, then some of the `jpackage` tests fail. The failures fall into the following categories: > > - `ALL-DEFAULT` notion from `jpackage` which includes all modules that export an API, which includes `jdk.jlink`, which is prevented from being included when linking from the run-time image (see the [JEP 493](https://openjdk.org/jeps/493) restrictions). The proposal is to change module resolution from `Configuration.resolveAndBind()` to `Configuration.resolve()`. I.e. don't perform service binding which is in line what [JEP 392](https://openjdk.org/jeps/392) and [JEP 343](https://openjdk.org/jeps/343) claim. That is, this patch brings the implementation aligned to what it says on the JEPs > - `ALL-MODULE-PATH` changes: `BasicTest.java` verifies the `--add-modules` argument to `jpackage`. Using `ALL-MODULE-PATH` for JDK modules won't be supported for JEP 493-enabled builds. So I've changed this test to skip the test using `ALL-MODULE-PATH` when we have such an enabled build. Other tests, such as `RuntimeImageTest.java` and `RuntimeImageSymbolicLinksTest.java` tests verify something else not related to `ALL-MODULE-PATH` or `--add-modules`. It seems more appropriate to use the smaller set of modules to use for the runtime JDK image. > - `JLinkOptionsTest.java`: That test verifies options passed to `jlink` via the `ToolProvider` API. For some reason, it uses `--bind-services` extensively and that - in turn - and, when not limited with the `--limit-modules` option as well, will include `jdk.jlink` in the resulting image, again running afoul the JEP 493 restriction of not allowing `jdk.jlink` for now. I propose to use suitable options including `--limit-modules` which would then no longer include `jdk.jlink` in the runtime image and the link from a run-time image works as well. These changes depend on [JDK-8345573](https://bugs.openjdk.org/browse/JDK-8345573) for it to work fully. > > Testing: > - [x] GHA > - [x] running tests in `test/jdk/tools/jpackage` on a JEP 493 enabled JDK. As far as I could see the failures that I was seeing weren't any more related to JEP 493 (some RPM requirements showing up that it didn't expect to). > > Thoughts? Opinions? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Adjust BasicTest for ALL-MODULE-PATH and JDK-8345259 - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix - Use TKit.trace() - Refactor BasicTest.java according to review - Don't resolve service bindings by default - Revert "Handle ALL-DEFAULT in jpackage tool" This reverts commit ca506f85f67f495cd29e8f9ff1a7004c9888aaaf. - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix - Adjust JLinkOptionsTest.java after JEP 493 - Fix tests for JEP 493 enabled JDKs - ... and 1 more: https://git.openjdk.org/jdk/compare/3f7052ed...478427f5 ------------- Changes: https://git.openjdk.org/jdk/pull/22644/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22644&range=03 Stats: 60 lines in 7 files changed: 36 ins; 11 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/22644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22644/head:pull/22644 PR: https://git.openjdk.org/jdk/pull/22644 From sgehwolf at openjdk.org Tue Jan 7 14:08:41 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 7 Jan 2025 14:08:41 GMT Subject: RFR: 8345185: Update jpackage to not include service bindings by default [v4] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 14:05:19 GMT, Severin Gehwolf wrote: >> Please review these changes to jpackage in light of [JEP 493](https://openjdk.org/jeps/493). When this feature is enabled, then some of the `jpackage` tests fail. The failures fall into the following categories: >> >> - `ALL-DEFAULT` notion from `jpackage` which includes all modules that export an API, which includes `jdk.jlink`, which is prevented from being included when linking from the run-time image (see the [JEP 493](https://openjdk.org/jeps/493) restrictions). The proposal is to change module resolution from `Configuration.resolveAndBind()` to `Configuration.resolve()`. I.e. don't perform service binding which is in line what [JEP 392](https://openjdk.org/jeps/392) and [JEP 343](https://openjdk.org/jeps/343) claim. That is, this patch brings the implementation aligned to what it says on the JEPs >> - `ALL-MODULE-PATH` changes: `BasicTest.java` verifies the `--add-modules` argument to `jpackage`. Using `ALL-MODULE-PATH` for JDK modules won't be supported for JEP 493-enabled builds. So I've changed this test to skip the test using `ALL-MODULE-PATH` when we have such an enabled build. Other tests, such as `RuntimeImageTest.java` and `RuntimeImageSymbolicLinksTest.java` tests verify something else not related to `ALL-MODULE-PATH` or `--add-modules`. It seems more appropriate to use the smaller set of modules to use for the runtime JDK image. >> - `JLinkOptionsTest.java`: That test verifies options passed to `jlink` via the `ToolProvider` API. For some reason, it uses `--bind-services` extensively and that - in turn - and, when not limited with the `--limit-modules` option as well, will include `jdk.jlink` in the resulting image, again running afoul the JEP 493 restriction of not allowing `jdk.jlink` for now. I propose to use suitable options including `--limit-modules` which would then no longer include `jdk.jlink` in the runtime image and the link from a run-time image works as well. These changes depend on [JDK-8345573](https://bugs.openjdk.org/browse/JDK-8345573) for it to work fully. >> >> Testing: >> - [x] GHA >> - [x] running tests in `test/jdk/tools/jpackage` on a JEP 493 enabled JDK. As far as I could see the failures that I was seeing weren't any more related to JEP 493 (some RPM requirements showing up that it didn't expect to). >> >> Thoughts? Opinions? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Adjust BasicTest for ALL-MODULE-PATH and JDK-8345259 > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Use TKit.trace() > - Refactor BasicTest.java according to review > - Don't resolve service bindings by default > - Revert "Handle ALL-DEFAULT in jpackage tool" > > This reverts commit ca506f85f67f495cd29e8f9ff1a7004c9888aaaf. > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Adjust JLinkOptionsTest.java after JEP 493 > - Fix tests for JEP 493 enabled JDKs > - ... and 1 more: https://git.openjdk.org/jdk/compare/3f7052ed...478427f5 The latest version of the patch includes updates due to https://github.com/openjdk/jdk/pull/22853 (reverts some of the changes). `BasicTest.java` now explicitly adds `--module-path` for the the `ALL-MODULE-PATH` call. Please take another look. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22644#issuecomment-2575376493 From jnordstrom at openjdk.org Tue Jan 7 14:28:36 2025 From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=) Date: Tue, 7 Jan 2025 14:28:36 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 04:27:23 GMT, David Holmes wrote: >> Could I get a review of this fix to refine the warnings printed by `libjsig` when using the deprecated `signal()`/`sigset()` functions? >> >> Currently the libjsig library supports chaining `signal()` and `sigset()`. With these functions being deprecated, `libjsig` warns when a program calls either function when the it's LD_PRELOADed. The warning is supposed to warn that when the support for `signal()` and `sigset()` is removed, the application might stop working as expected. >> >>> VM warning: the use of signal() and sigset() for signal chaining was deprecated in version 16.0 and will be removed in a future release. Use sigaction() instead. >> >> The warning is however printed in a few cases when its unnecessary, and also fails to catch some usages where it should be printed. With this fix the warning is printed (in order as they appear in jsig.c): >> 1. when `signal()` or `sigset()` is called for a JVM-used signal, after the JVM has installed its signals >> 2. when the JVM installs its signals (using `sigaction()`), and libjsig sees that `signal()` or `sigset()` has been used for a JVM-used signal >> >> ### Changes >> * The printing is removed from `call_os_signal()`. This warning was only correct if `signal()` or `sigset()` was called for a JVM-used signal before the JVM was installed. This is now instead covered by step 1 above. >> * If the JVM was installed first, the `signal()`/`sigset()` calls were effectively translated to `sigaction()`, and the warning was _not_ printed. When the `signal()`/`sigset()` support is dropped, this behaviour will change and the warning should be printed. This is now covered by step 2. >> >> ## Testing >> - [x] Test `open/test/hotspot/jtreg/runtime/signal` has added checks for the deprecation warning, and passes with the fix >> - [x] Tier1-3 in progress > > test/hotspot/jtreg/runtime/signal/SigTestDriver.java line 176: > >> 174: /** >> 175: * Return true for all signals used by the JVM. This only covers the >> 176: * case where the JVM is started normally, and not with -Xrs. > > The VM also uses SIGUSR2 (`SR_signum`), SIGINT, and SIGQUIT. Though the latter two only if no `-Xrs` is given. The test is skipped for SIGUSR2 on Linux and MacOS, and Windows skips all signal testing. So I guess that leaves aix, which seems to use signals_poxis.cpp... so perhaps the SIGUSR2 test should be skipped for aix too? But I'll add the signals for clarity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22806#discussion_r1905534105 From asotona at openjdk.org Tue Jan 7 15:02:43 2025 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Jan 2025 15:02:43 GMT Subject: RFR: 8342468: Improve API documentation for java.lang.classfile.constantpool [v3] In-Reply-To: References: <3vFQsVbVNWwkMmujMjMqpMA-ZvbxbWqRp5W-4XrycYM=.c60d6f08-74eb-4874-bbee-aa2d0365e8f3@github.com> Message-ID: On Mon, 6 Jan 2025 21:41:17 GMT, Chen Liang wrote: >> Improve documentation for constant pool entries. This include some models for those entries, symbolic descriptors, and some general guidance in package summary. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-consts/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-consts/ >> >> Please review the associated CSR as well. >> >> Companion PRs: #21625 > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - BSMEntry and copyright year > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Minor cleanups > - Stage more doc changes > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - More concise message about exceptions > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Improve api docs for constantpool Looks good to me, thanks. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22217#pullrequestreview-2534561215 From duke at openjdk.org Tue Jan 7 15:10:38 2025 From: duke at openjdk.org (pcoperatr) Date: Tue, 7 Jan 2025 15:10:38 GMT Subject: RFR: 8345185: Update jpackage to not include service bindings by default [v4] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 14:05:19 GMT, Severin Gehwolf wrote: >> Please review these changes to jpackage in light of [JEP 493](https://openjdk.org/jeps/493). When this feature is enabled, then some of the `jpackage` tests fail. The failures fall into the following categories: >> >> - `ALL-DEFAULT` notion from `jpackage` which includes all modules that export an API, which includes `jdk.jlink`, which is prevented from being included when linking from the run-time image (see the [JEP 493](https://openjdk.org/jeps/493) restrictions). The proposal is to change module resolution from `Configuration.resolveAndBind()` to `Configuration.resolve()`. I.e. don't perform service binding which is in line what [JEP 392](https://openjdk.org/jeps/392) and [JEP 343](https://openjdk.org/jeps/343) claim. That is, this patch brings the implementation aligned to what it says on the JEPs >> - `ALL-MODULE-PATH` changes: `BasicTest.java` verifies the `--add-modules` argument to `jpackage`. Using `ALL-MODULE-PATH` for JDK modules won't be supported for JEP 493-enabled builds. So I've changed this test to skip the test using `ALL-MODULE-PATH` when we have such an enabled build. Other tests, such as `RuntimeImageTest.java` and `RuntimeImageSymbolicLinksTest.java` tests verify something else not related to `ALL-MODULE-PATH` or `--add-modules`. It seems more appropriate to use the smaller set of modules to use for the runtime JDK image. >> - `JLinkOptionsTest.java`: That test verifies options passed to `jlink` via the `ToolProvider` API. For some reason, it uses `--bind-services` extensively and that - in turn - and, when not limited with the `--limit-modules` option as well, will include `jdk.jlink` in the resulting image, again running afoul the JEP 493 restriction of not allowing `jdk.jlink` for now. I propose to use suitable options including `--limit-modules` which would then no longer include `jdk.jlink` in the runtime image and the link from a run-time image works as well. These changes depend on [JDK-8345573](https://bugs.openjdk.org/browse/JDK-8345573) for it to work fully. >> >> Testing: >> - [x] GHA >> - [x] running tests in `test/jdk/tools/jpackage` on a JEP 493 enabled JDK. As far as I could see the failures that I was seeing weren't any more related to JEP 493 (some RPM requirements showing up that it didn't expect to). >> >> Thoughts? Opinions? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Adjust BasicTest for ALL-MODULE-PATH and JDK-8345259 > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Use TKit.trace() > - Refactor BasicTest.java according to review > - Don't resolve service bindings by default > - Revert "Handle ALL-DEFAULT in jpackage tool" > > This reverts commit ca506f85f67f495cd29e8f9ff1a7004c9888aaaf. > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Adjust JLinkOptionsTest.java after JEP 493 > - Fix tests for JEP 493 enabled JDKs > - ... and 1 more: https://git.openjdk.org/jdk/compare/3f7052ed...478427f5 Marked as reviewed by pcoperatr at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/22644#pullrequestreview-2534582439 From syan at openjdk.org Tue Jan 7 15:13:44 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 7 Jan 2025 15:13:44 GMT Subject: RFR: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate fails NoClassDefFoundError In-Reply-To: References: Message-ID: <8n3iNbblREFVx7uSvdjhhwhOLR4s4k1vgDSvgcIZFNQ=.0dd1d4c3-3f5f-423e-b172-f20755a5f6d0@github.com> On Mon, 6 Jan 2025 09:12:01 GMT, SendaoYan wrote: > Hi all, > This PR add JVM option `jvmArgs={"--add-modules=jdk.incubator.vector"}` for test/micro/org/openjdk/bench/jdk/incubator/vector/SpiltReplicate.java, to fix test bug which cause jmh test fails 'java.lang.NoClassDefFoundError: jdk/incubator/vector/FloatVector'. Change has been verified locally, test-fix only, no risk. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22923#issuecomment-2575530186 From syan at openjdk.org Tue Jan 7 15:13:45 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 7 Jan 2025 15:13:45 GMT Subject: Integrated: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate fails NoClassDefFoundError In-Reply-To: References: Message-ID: On Mon, 6 Jan 2025 09:12:01 GMT, SendaoYan wrote: > Hi all, > This PR add JVM option `jvmArgs={"--add-modules=jdk.incubator.vector"}` for test/micro/org/openjdk/bench/jdk/incubator/vector/SpiltReplicate.java, to fix test bug which cause jmh test fails 'java.lang.NoClassDefFoundError: jdk/incubator/vector/FloatVector'. Change has been verified locally, test-fix only, no risk. This pull request has now been integrated. Changeset: 4d8fb807 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/4d8fb80732fd17352c36254c6dfc1be5dbfbacf1 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8347038: [JMH] jdk.incubator.vector.SpiltReplicate fails NoClassDefFoundError Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk/pull/22923 From syan at openjdk.org Tue Jan 7 15:19:56 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 7 Jan 2025 15:19:56 GMT Subject: [jdk24] RFR: 8347038: [JMH] jdk.incubator.vector.SpiltReplicate fails NoClassDefFoundError Message-ID: Hi all, This pull request contains a backport of commit [4d8fb807](https://github.com/openjdk/jdk/commit/4d8fb80732fd17352c36254c6dfc1be5dbfbacf1) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by SendaoYan on 7 Jan 2025 and was reviewed by Paul Sandoz. Thanks! ------------- Commit messages: - Backport 4d8fb80732fd17352c36254c6dfc1be5dbfbacf1 Changes: https://git.openjdk.org/jdk/pull/22949/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22949&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347038 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22949.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22949/head:pull/22949 PR: https://git.openjdk.org/jdk/pull/22949 From pminborg at openjdk.org Tue Jan 7 15:20:41 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 7 Jan 2025 15:20:41 GMT Subject: Integrated: 8346609: Improve MemorySegment.toString In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 09:48:23 GMT, Per Minborg wrote: > This PR proposes to improve the current `MemorySegment.toString()` method from: > > `MemorySegment{ address: 0x60000264c540, byteSize: 8 }` > > to > > `MemorySegment{ native, address: 0x60000264c540, byteSize: 8}` > > Tests passes tier1-tier3 This pull request has now been integrated. Changeset: c8a9dd3a Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/c8a9dd3a027781d006850c028714a62903c487d5 Stats: 18 lines in 3 files changed: 12 ins; 0 del; 6 mod 8346609: Improve MemorySegment.toString Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/22826 From mcimadamore at openjdk.org Tue Jan 7 15:41:44 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 7 Jan 2025 15:41:44 GMT Subject: RFR: 8346610: Make all imports conformant in the FFM API In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 10:46:03 GMT, Per Minborg wrote: > This PR proposes to clean up all the imports in the FFM lib (excluding tests). > > Passes tier1-tier3 copyrights should say 2025 Do we have a sense on how easy would it be, moving forward, to preserve the "correct" order of imports? E.g. if I add a new one using IntelliJ autocompletion, where would it end up? Has this patch been generated using the IDE's own import reorganization? Perhaps doing something like that might be preferrable/more maintainable longer term? ------------- PR Review: https://git.openjdk.org/jdk/pull/22827#pullrequestreview-2534666684 PR Comment: https://git.openjdk.org/jdk/pull/22827#issuecomment-2575604034 From asemenyuk at openjdk.org Tue Jan 7 16:40:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 7 Jan 2025 16:40:54 GMT Subject: RFR: 8345185: Update jpackage to not include service bindings by default [v4] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 14:05:19 GMT, Severin Gehwolf wrote: >> Please review these changes to jpackage in light of [JEP 493](https://openjdk.org/jeps/493). When this feature is enabled, then some of the `jpackage` tests fail. The failures fall into the following categories: >> >> - `ALL-DEFAULT` notion from `jpackage` which includes all modules that export an API, which includes `jdk.jlink`, which is prevented from being included when linking from the run-time image (see the [JEP 493](https://openjdk.org/jeps/493) restrictions). The proposal is to change module resolution from `Configuration.resolveAndBind()` to `Configuration.resolve()`. I.e. don't perform service binding which is in line what [JEP 392](https://openjdk.org/jeps/392) and [JEP 343](https://openjdk.org/jeps/343) claim. That is, this patch brings the implementation aligned to what it says on the JEPs >> - `ALL-MODULE-PATH` changes: `BasicTest.java` verifies the `--add-modules` argument to `jpackage`. Using `ALL-MODULE-PATH` for JDK modules won't be supported for JEP 493-enabled builds. So I've changed this test to skip the test using `ALL-MODULE-PATH` when we have such an enabled build. Other tests, such as `RuntimeImageTest.java` and `RuntimeImageSymbolicLinksTest.java` tests verify something else not related to `ALL-MODULE-PATH` or `--add-modules`. It seems more appropriate to use the smaller set of modules to use for the runtime JDK image. >> - `JLinkOptionsTest.java`: That test verifies options passed to `jlink` via the `ToolProvider` API. For some reason, it uses `--bind-services` extensively and that - in turn - and, when not limited with the `--limit-modules` option as well, will include `jdk.jlink` in the resulting image, again running afoul the JEP 493 restriction of not allowing `jdk.jlink` for now. I propose to use suitable options including `--limit-modules` which would then no longer include `jdk.jlink` in the runtime image and the link from a run-time image works as well. These changes depend on [JDK-8345573](https://bugs.openjdk.org/browse/JDK-8345573) for it to work fully. >> >> Testing: >> - [x] GHA >> - [x] running tests in `test/jdk/tools/jpackage` on a JEP 493 enabled JDK. As far as I could see the failures that I was seeing weren't any more related to JEP 493 (some RPM requirements showing up that it didn't expect to). >> >> Thoughts? Opinions? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Adjust BasicTest for ALL-MODULE-PATH and JDK-8345259 > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Use TKit.trace() > - Refactor BasicTest.java according to review > - Don't resolve service bindings by default > - Revert "Handle ALL-DEFAULT in jpackage tool" > > This reverts commit ca506f85f67f495cd29e8f9ff1a7004c9888aaaf. > - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix > - Adjust JLinkOptionsTest.java after JEP 493 > - Fix tests for JEP 493 enabled JDKs > - ... and 1 more: https://git.openjdk.org/jdk/compare/3f7052ed...478427f5 Looks good ------------- Marked as reviewed by asemenyuk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22644#pullrequestreview-2534884601 From liach at openjdk.org Tue Jan 7 17:38:35 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 7 Jan 2025 17:38:35 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v2] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 04:43:58 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 58: >> >>> 56: * 2: ACC_STRICT modifier >>> 57: * 3: no changes >>> 58: * 4: no changes >> >> The version mapping can be tricky here: is "1" 1.0 plus 1.1? I presume "2" is 1.2, "3" is 1.3.x, "4" is 1.4.x >> >> Might be useful to include the actual JVMS classfile version numbers for ease of reference back to JVMS. > > I assume the wording implicitly is referring to the enum position, which uses a "RELEASE_$N" convention. However, I agree that adding the major version in some form would aid people more familiar with those numbers. One possibility: > > > 3 (47.0) no changes > 4 (48.0) no changes > > > If that is adopted, perhaps the preview features could be listed with the minor version set. How about versions like 1.1, ... 1.8, 9, ... which follows the since versions of libraries and should have no ambiguity? I will commit if everyone agrees. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22934#discussion_r1905830382 From naoto at openjdk.org Tue Jan 7 17:42:41 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Jan 2025 17:42:41 GMT Subject: RFR: 8175709: DateTimeFormatterBuilder.appendZoneId() has misleading JavaDoc [v2] In-Reply-To: <5HcT8q1Ais4MPisgJy8EQLH4ZIGjepWPMm31JU45C4c=.d4cd0e34-711f-4234-b269-888a46fb1eb3@github.com> References: <5HcT8q1Ais4MPisgJy8EQLH4ZIGjepWPMm31JU45C4c=.d4cd0e34-711f-4234-b269-888a46fb1eb3@github.com> Message-ID: <_9_Hqx-3ySeR83A4b8NFNu9t-p_1Xg_I-n1ZhK2J3J0=.7c1b0da8-61cd-4a7e-abca-d3312c2e6cb2@github.com> On Fri, 20 Dec 2024 18:12:17 GMT, Naoto Sato wrote: >> Clarifying the documentation of `DateTimeFormatterBuilder.appendZoneId()` and similar methods to align the description with the behavior, in which `ZoneOffset` is only parsed from the formatter for offset texts without any prefixes. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Reflects review comments Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22837#issuecomment-2575878313 From naoto at openjdk.org Tue Jan 7 17:42:42 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Jan 2025 17:42:42 GMT Subject: Integrated: 8175709: DateTimeFormatterBuilder.appendZoneId() has misleading JavaDoc In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 22:12:52 GMT, Naoto Sato wrote: > Clarifying the documentation of `DateTimeFormatterBuilder.appendZoneId()` and similar methods to align the description with the behavior, in which `ZoneOffset` is only parsed from the formatter for offset texts without any prefixes. Corresponding CSR has also been drafted. This pull request has now been integrated. Changeset: 9702accd Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/9702accdd9a25e05628d470bf248edd5d80c0c4d Stats: 35 lines in 1 file changed: 0 ins; 1 del; 34 mod 8175709: DateTimeFormatterBuilder.appendZoneId() has misleading JavaDoc Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/22837 From mchung at openjdk.org Tue Jan 7 18:01:37 2025 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 7 Jan 2025 18:01:37 GMT Subject: [jdk24] RFR: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 18:18:48 GMT, Mandy Chung wrote: >> Clean backport of [JDK-8345259](https://bugs.openjdk.org/browse/JDK-8345259) to JDK 24 which has JEP 493. > > I created https://bugs.openjdk.org/browse/JDK-8345259. Looks like the tests need update. > I think the bug you mean @mlchung is https://bugs.openjdk.org/browse/JDK-8346739, right? Yes. I put the wrong link. > Would it be OK to get both into the `jdk24` branch? Ok with me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22849#issuecomment-2575913571 From javalists at cbfiddle.com Tue Jan 7 18:08:41 2025 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 7 Jan 2025 10:08:41 -0800 Subject: Objective-C memory management Message-ID: <3D1F758E-1352-464F-8441-E31FBFDC4AC4@cbfiddle.com> I?m a bit confused about how the macOS implementation of JDK uses Objective-C memory management. Does it use ARC? I?m guessing it does, because I see dealloc methods that clear pointer variables without first releasing them. However, if I put an Xcode breakpoint on -[MTLLayer dealloc], the breakpoint is never hit after I close windows or dismiss menus, which suggests the MTLLayer instances are leaked. This matters because MTLLayer instances have associated CVDisplayLinks, which have active threads. I see that Java_sun_lwawt_macosx_CFRetainedResource_nativeCFRelease is called on MTLLayer instances, but the retain count at that time is 6. Three other Objective-C instances are released using this function: AWTView, AWTWindow_Panel, and AWTSurfaceLayers, but that is not enough to do the job. Apple has tools for diagnosing memory leaks, but I don?t know how to run them on a JDK based application. From naoto at openjdk.org Tue Jan 7 18:32:12 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 7 Jan 2025 18:32:12 GMT Subject: RFR: 8166983: Remove old/legacy unused tzdata files Message-ID: Long overdue cleanup, especially the old `javazic` tool, which has been maintenance burden for some time. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/22955/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22955&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8166983 Stats: 8665 lines in 28 files changed: 0 ins; 8663 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22955/head:pull/22955 PR: https://git.openjdk.org/jdk/pull/22955 From iris at openjdk.org Tue Jan 7 18:39:34 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 7 Jan 2025 18:39:34 GMT Subject: RFR: 8166983: Remove old/legacy unused tzdata files In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 18:27:31 GMT, Naoto Sato wrote: > Long overdue cleanup, especially the old `javazic` tool, which has been maintenance burden for some time. Thanks for taking care of this long-overdue removal! ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22955#pullrequestreview-2535116465 From bchristi at openjdk.org Tue Jan 7 19:40:47 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 7 Jan 2025 19:40:47 GMT Subject: RFR: 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 10:44:22 GMT, Per Minborg wrote: > This PR proposes to eliminate the capturing of `this` in the cleanup action of `AbstractMemorySegment::reinterpretInternal`. As a matter of style, I believe there is something to be said for writing out cleaning actions as static nested classes, as one can/must include explicit fields for all object and values that the `Runnable` object must reference. But it's more verbose, of course. Also, some conversions of finalizer to Cleaner have included tests to ensure that objects become unreachable as expected. (A relatively simple technique is to add the objects in question into a WeakHashMap, and ensure they are removed as expected.) [GssContextCleanup.java](https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/jgss/GssContextCleanup.java) and [GssNameCleanup.java](https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/jgss/GssNameCleanup.java) from [JDK-8284490](https://bugs.openjdk.org/browse/JDK-8284490) are examples. I don't know if it's practical to construct such a test in this case. Anyway, just a couple things to think about. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22943#issuecomment-2576085140 From asotona at openjdk.org Tue Jan 7 20:07:34 2025 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Jan 2025 20:07:34 GMT Subject: RFR: 8346986: Remove ASM from java.base Message-ID: There are no more consumers of ASM library except for hotspot tests. This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. Please review. Thanks, Adam ------------- Commit messages: - fixed TestMHUnloaded - patching hotspot tests - removed obsolete export - 8346986: Remove ASM from java.base Changes: https://git.openjdk.org/jdk/pull/22946/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346986 Stats: 308 lines in 265 files changed: 67 ins; 100 del; 141 mod Patch: https://git.openjdk.org/jdk/pull/22946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946 PR: https://git.openjdk.org/jdk/pull/22946 From alanb at openjdk.org Tue Jan 7 20:22:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Jan 2025 20:22:34 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona wrote: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Moving it to test/hotspot/jtreg is initially surprising, I assumed it would move to test/lib. Did you choose the hotspot tree as only tests in hotspot/jtreg use it and you didn't want to add or change the @library tag on these tests? The other thing is the package name, maybe it should move back to org.objectweb.asm as it won't be a JDK internal package. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576150512 From rriggs at openjdk.org Tue Jan 7 20:30:34 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Jan 2025 20:30:34 GMT Subject: RFR: 8166983: Remove old/legacy unused tzdata files In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 18:27:31 GMT, Naoto Sato wrote: > Long overdue cleanup, especially the old `javazic` tool, which has been maintenance burden for some time. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22955#pullrequestreview-2535303759 From duke at openjdk.org Tue Jan 7 20:40:46 2025 From: duke at openjdk.org (duke) Date: Tue, 7 Jan 2025 20:40:46 GMT Subject: Withdrawn: 8343933: Add a MemorySegment::fill benchmark with varying sizes In-Reply-To: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com> References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com> Message-ID: <1CkvPUsBbBqWwACe1riTHA-N19J2qIBk-QbNSttJE3I=.7a4e7115-9245-412b-9af1-b230e6848c70@github.com> On Mon, 11 Nov 2024 11:55:27 GMT, Per Minborg wrote: > This PR proposes to add a new `MemorySegment::fill" benchmark where the byte size of the segments varies. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22010 From rriggs at openjdk.org Tue Jan 7 20:46:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 7 Jan 2025 20:46:39 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v14] In-Reply-To: References: Message-ID: <-rAkx4rny55Ys1lUMWTCv9wcehBYQoZ_16GsB86RnUs=.6003a884-a371-44aa-b9bb-47aba0ae8acc@github.com> On Tue, 7 Jan 2025 10:45:09 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > change "@since" to 25 src/java.base/share/classes/java/util/zip/Deflater.java line 815: > 813: * than {@link Integer#MAX_VALUE}. > 814: * > 815: * @throws IllegalStateException if the Deflater is closed @throws should follow @return; (Style notes in https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html). src/java.base/share/classes/java/util/zip/Deflater.java line 848: > 846: * than {@link Integer#MAX_VALUE}. > 847: * > 848: * @throws IllegalStateException if the Deflater is closed Ditto `@throws` throws should follow `@return` src/java.base/share/classes/java/util/zip/Inflater.java line 663: > 661: * than {@link Integer#MAX_VALUE}. > 662: * > 663: * @throws IllegalStateException if the Inflater is closed Ditto ` @throws` should follow `@return` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1906011672 PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1906012010 PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1906014988 From lancea at openjdk.org Tue Jan 7 21:02:19 2025 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 7 Jan 2025 21:02:19 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v14] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 10:45:09 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > change "@since" to 25 Overall looks good Jai. Roger is right on moving the @throws IAE further down ------------- PR Review: https://git.openjdk.org/jdk/pull/19675#pullrequestreview-2535355914 From duke at openjdk.org Tue Jan 7 21:39:51 2025 From: duke at openjdk.org (duke) Date: Tue, 7 Jan 2025 21:39:51 GMT Subject: Withdrawn: 8162500: Receiver annotations of inner classes of local classes not found at runtime In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 18:02:57 GMT, Chen Liang wrote: > In annotated types, local and inner class types should be annotated as "top-level" types. For example, in the test here > > public static Class getLocalsMember() { > class Local { > class Member { > @Annot(2635) Member(@Annot(2732) Local Local.this) {} > } > } > return Local.Member.class; > } > > > The `Local` occurrences cannot be qualified with the enclosing class type, even if the local class may be compiled to capture the enclosing class. > > However, core reflection had a bug where it looks for an enclosing class instead of a declaring class; this meant that for said `Local`, core reflection was treating the outer class as the top-level in type annotations, while the top level should be the local class instead. This patch fixes this bug. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20200 From duke at openjdk.org Tue Jan 7 22:15:37 2025 From: duke at openjdk.org (Thayne McCombs) Date: Tue, 7 Jan 2025 22:15:37 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v14] In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 10:45:09 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > change "@since" to 25 Please keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/19675#issuecomment-2575735704 From asotona at openjdk.org Tue Jan 7 22:21:35 2025 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 7 Jan 2025 22:21:35 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona wrote: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam I've decided to move it under hotspot/jtreg test root as all other tests have been already converted to Class-File API and there is no other consumer of the library outside of the hotspot/jtreg test root. Despite the 265 modified files is this PR trying to be minimalistic. Repackaging of the library would be far more complex and would affect significantly more files, including the library itself. I would recommend to invest that effort into the tests conversion into Class-File API instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576337657 From bpb at openjdk.org Tue Jan 7 22:52:42 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 7 Jan 2025 22:52:42 GMT Subject: RFR: 8343342: java/io/File/GetXSpace.java fails on Windows with CD-ROM drive [v10] In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 13:18:09 GMT, Taizo Kurashige wrote: >> To resolve java/io/File/GetXSpace.java failure, I fix libGetXSpace.c to use Cygwin?s `df` to get the size for comparison if the test target drive is a CD-ROM drive. >> >> As described in JDK-8343342, GetDiskSpaceInformationW can't get information about the size of the CD-ROM drive. >> GetDiskFreeSpaceExW can also get information about the size of the CD-ROM drive. However, because GetDiskFreeSpaceExW is called by the File.get-X-Space methods, it seems more reasonable to compare the size got by other way than GetDiskFreeSpaceExW as a test. For this reason, I use Cygwin's `df`. >> In JDK-8298619, GetDiskSpaceInformationW was adopted instead of `df` because the size got by File.get-X-Space methods may not match the size got by `df` when per-user quotas are used. I don't think this problem applies to CD-ROM drive, so I think we can use Cygwin's `df` for CD-ROM drive. >> >> After fix, I ran a test on Windows Server 2019 where drive C is a normal local disk, drive D is an unmounted iso CD-ROM drive, and drive F is an iso mounted CD-ROM drive and confirmed that it passes. >> >> I think this fix may also resolves the similar failure reported at https://github.com/openjdk/jdk/pull/12397#issuecomment-1705164515. >> >> Thanks > > Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision: > > java.lang.Runtime.exec() This latest version works with no CD mounted, with an ISO file mounted, and with some physical CDs mounted. Some physical CDs still fail, but I think these are not significant and we can go with the current version. As I have access to a physical drive, I might look into it after the current PR is integrated. Thanks. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21799#pullrequestreview-2535521929 From henryjen at openjdk.org Wed Jan 8 00:40:04 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 8 Jan 2025 00:40:04 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v3] In-Reply-To: References: Message-ID: <-QhN582ZLm6wkdTDRDZBdizuk7WBRtZqGBzHbB1_St8=.ac2047df-0eaf-48b5-b641-a58bb86fdf7e@github.com> > Improving option value handling to support passing argument value starts with "--". > > Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. > --add-options --add-modules=jdk.incubator.concurrent > --add-options=--add-modules=jdk.incubator.concurrent > > will cause JLink to report > Error: no value given for --add-options > as --add-modules is considered another option for JLink. > > After the fix, by using = will ensure the value is properly handled as argument value. Also using "" with multiple values will be recognized properly. So following form should work > --add-options "--add-modules jdk.incubator.concurrent" > --add-options=--add-modules=jdk.incubator.concurrent Henry Jen 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 five additional commits since the last revision: - Merge remote-tracking branch 'openjdk/master' into JDK-8303884 - Use opt=value format when value is starting with -- - Fix style - add test - 8303884: jlink --add-options plugin does not allow GNU style options to be provided ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22526/files - new: https://git.openjdk.org/jdk/pull/22526/files/7dbc99f9..7060e47f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22526&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22526&range=01-02 Stats: 55020 lines in 3799 files changed: 35891 ins; 10199 del; 8930 mod Patch: https://git.openjdk.org/jdk/pull/22526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22526/head:pull/22526 PR: https://git.openjdk.org/jdk/pull/22526 From duke at openjdk.org Wed Jan 8 01:10:50 2025 From: duke at openjdk.org (Taizo Kurashige) Date: Wed, 8 Jan 2025 01:10:50 GMT Subject: RFR: 8343342: java/io/File/GetXSpace.java fails on Windows with CD-ROM drive [v10] In-Reply-To: References: Message-ID: <-IQaIWdaq3Z504W5oV0CdyCjMuYBkRQS-IoHJqkF5kg=.cf47faf0-61a8-42a2-af6a-4c530dc66ec3@github.com> On Mon, 23 Dec 2024 13:18:09 GMT, Taizo Kurashige wrote: >> To resolve java/io/File/GetXSpace.java failure, I fix libGetXSpace.c to use Cygwin?s `df` to get the size for comparison if the test target drive is a CD-ROM drive. >> >> As described in JDK-8343342, GetDiskSpaceInformationW can't get information about the size of the CD-ROM drive. >> GetDiskFreeSpaceExW can also get information about the size of the CD-ROM drive. However, because GetDiskFreeSpaceExW is called by the File.get-X-Space methods, it seems more reasonable to compare the size got by other way than GetDiskFreeSpaceExW as a test. For this reason, I use Cygwin's `df`. >> In JDK-8298619, GetDiskSpaceInformationW was adopted instead of `df` because the size got by File.get-X-Space methods may not match the size got by `df` when per-user quotas are used. I don't think this problem applies to CD-ROM drive, so I think we can use Cygwin's `df` for CD-ROM drive. >> >> After fix, I ran a test on Windows Server 2019 where drive C is a normal local disk, drive D is an unmounted iso CD-ROM drive, and drive F is an iso mounted CD-ROM drive and confirmed that it passes. >> >> I think this fix may also resolves the similar failure reported at https://github.com/openjdk/jdk/pull/12397#issuecomment-1705164515. >> >> Thanks > > Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision: > > java.lang.Runtime.exec() I'm sorry that I cannot handle that some physical CDs still fail. Thank you for testing all the cases and reviewing over the long term. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21799#issuecomment-2576510704 From duke at openjdk.org Wed Jan 8 01:10:50 2025 From: duke at openjdk.org (duke) Date: Wed, 8 Jan 2025 01:10:50 GMT Subject: RFR: 8343342: java/io/File/GetXSpace.java fails on Windows with CD-ROM drive [v10] In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 13:18:09 GMT, Taizo Kurashige wrote: >> To resolve java/io/File/GetXSpace.java failure, I fix libGetXSpace.c to use Cygwin?s `df` to get the size for comparison if the test target drive is a CD-ROM drive. >> >> As described in JDK-8343342, GetDiskSpaceInformationW can't get information about the size of the CD-ROM drive. >> GetDiskFreeSpaceExW can also get information about the size of the CD-ROM drive. However, because GetDiskFreeSpaceExW is called by the File.get-X-Space methods, it seems more reasonable to compare the size got by other way than GetDiskFreeSpaceExW as a test. For this reason, I use Cygwin's `df`. >> In JDK-8298619, GetDiskSpaceInformationW was adopted instead of `df` because the size got by File.get-X-Space methods may not match the size got by `df` when per-user quotas are used. I don't think this problem applies to CD-ROM drive, so I think we can use Cygwin's `df` for CD-ROM drive. >> >> After fix, I ran a test on Windows Server 2019 where drive C is a normal local disk, drive D is an unmounted iso CD-ROM drive, and drive F is an iso mounted CD-ROM drive and confirmed that it passes. >> >> I think this fix may also resolves the similar failure reported at https://github.com/openjdk/jdk/pull/12397#issuecomment-1705164515. >> >> Thanks > > Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision: > > java.lang.Runtime.exec() @kurashige23 Your change (at version 3fb0dc4f9a1400c9b22f9d9d6241d7b51fede9cd) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21799#issuecomment-2576511658 From dholmes at openjdk.org Wed Jan 8 01:12:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Jan 2025 01:12:47 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona wrote: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Test libraries belong in test/lib even if only hotspot is using this one IMO. I'd like to hear @lmesnik 's opinion on this. Also how is this library being built for the tests to use? If relying on jtreg facilities we will likely hit the known problems that jtreg has in this area - and this library would seem a good candidate for the proposal to prebuild some test libraries when the test image is built. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576512536 From dholmes at openjdk.org Wed Jan 8 01:16:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Jan 2025 01:16:33 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: <5IYTUxLAMpubLWi2gSAh6paz3K6XWZSGeQ6Nk3ahEiw=.6a26ad2a-e88e-4430-945f-996d648b1fda@github.com> On Tue, 7 Jan 2025 20:19:53 GMT, Alan Bateman wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Moving it to test/hotspot/jtreg is initially surprising, I assumed it would move to test/lib. Did you choose the hotspot tree as only tests in hotspot/jtreg use it and you didn't want to add or change the @library tag on these tests? > > The other thing is the package name, maybe it should move back to org.objectweb.asm as it won't be a JDK internal package. I also agree with @AlanBateman about the package name. It is not appropriate for anything outside the platform modules to claim to be part of `jdk.internal`. In fact I'm surprised we are even allowed to add to that from outside the module! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576516315 From bpb at openjdk.org Wed Jan 8 01:18:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 8 Jan 2025 01:18:43 GMT Subject: RFR: 8343342: java/io/File/GetXSpace.java fails on Windows with CD-ROM drive [v10] In-Reply-To: References: Message-ID: <7iZ_UtiCSGm29q7BvF9BYliFi929djqZsWQsxTCKRX4=.c44d2d0a-b903-4522-b360-110d67b46a66@github.com> On Mon, 23 Dec 2024 13:18:09 GMT, Taizo Kurashige wrote: >> To resolve java/io/File/GetXSpace.java failure, I fix libGetXSpace.c to use Cygwin?s `df` to get the size for comparison if the test target drive is a CD-ROM drive. >> >> As described in JDK-8343342, GetDiskSpaceInformationW can't get information about the size of the CD-ROM drive. >> GetDiskFreeSpaceExW can also get information about the size of the CD-ROM drive. However, because GetDiskFreeSpaceExW is called by the File.get-X-Space methods, it seems more reasonable to compare the size got by other way than GetDiskFreeSpaceExW as a test. For this reason, I use Cygwin's `df`. >> In JDK-8298619, GetDiskSpaceInformationW was adopted instead of `df` because the size got by File.get-X-Space methods may not match the size got by `df` when per-user quotas are used. I don't think this problem applies to CD-ROM drive, so I think we can use Cygwin's `df` for CD-ROM drive. >> >> After fix, I ran a test on Windows Server 2019 where drive C is a normal local disk, drive D is an unmounted iso CD-ROM drive, and drive F is an iso mounted CD-ROM drive and confirmed that it passes. >> >> I think this fix may also resolves the similar failure reported at https://github.com/openjdk/jdk/pull/12397#issuecomment-1705164515. >> >> Thanks > > Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision: > > java.lang.Runtime.exec() It would be hard for you to work on this further without a physical drive. I'll see what I can do. Thanks for the submission. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21799#issuecomment-2576516922 From duke at openjdk.org Wed Jan 8 01:18:44 2025 From: duke at openjdk.org (Taizo Kurashige) Date: Wed, 8 Jan 2025 01:18:44 GMT Subject: Integrated: 8343342: java/io/File/GetXSpace.java fails on Windows with CD-ROM drive In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 07:15:16 GMT, Taizo Kurashige wrote: > To resolve java/io/File/GetXSpace.java failure, I fix libGetXSpace.c to use Cygwin?s `df` to get the size for comparison if the test target drive is a CD-ROM drive. > > As described in JDK-8343342, GetDiskSpaceInformationW can't get information about the size of the CD-ROM drive. > GetDiskFreeSpaceExW can also get information about the size of the CD-ROM drive. However, because GetDiskFreeSpaceExW is called by the File.get-X-Space methods, it seems more reasonable to compare the size got by other way than GetDiskFreeSpaceExW as a test. For this reason, I use Cygwin's `df`. > In JDK-8298619, GetDiskSpaceInformationW was adopted instead of `df` because the size got by File.get-X-Space methods may not match the size got by `df` when per-user quotas are used. I don't think this problem applies to CD-ROM drive, so I think we can use Cygwin's `df` for CD-ROM drive. > > After fix, I ran a test on Windows Server 2019 where drive C is a normal local disk, drive D is an unmounted iso CD-ROM drive, and drive F is an iso mounted CD-ROM drive and confirmed that it passes. > > I think this fix may also resolves the similar failure reported at https://github.com/openjdk/jdk/pull/12397#issuecomment-1705164515. > > Thanks This pull request has now been integrated. Changeset: 40f0a398 Author: Taizo Kurashige URL: https://git.openjdk.org/jdk/commit/40f0a398fa9b1b39a43640973eaffb041bb7b63d Stats: 80 lines in 2 files changed: 75 ins; 0 del; 5 mod 8343342: java/io/File/GetXSpace.java fails on Windows with CD-ROM drive Reviewed-by: bpb, aturbanov ------------- PR: https://git.openjdk.org/jdk/pull/21799 From lmesnik at openjdk.org Wed Jan 8 01:48:34 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 8 Jan 2025 01:48:34 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona wrote: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam I think it is make sense to put ASM into hotspot testlibrary if there are no any other users. So it is clear that non-hotspot tests don't depend on it. There is a location test/hotspot/jtreg/testlibrary for hotstpot specific libraries. Could you please move it here. Before renaming packages, I would like to understand if we can move to standard ASM? We are no planning to develop new tests and maintain this library for newer releases. Otherwise, keeping jdk.internal simplify backporting changes. It is not possible to implement it as a precompiled library because of jtreg limitations to find jars in test-images. So I'll implement this later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576544218 From liach at openjdk.org Wed Jan 8 03:40:43 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Jan 2025 03:40:43 GMT Subject: RFR: 8342468: Improve API documentation for java.lang.classfile.constantpool [v3] In-Reply-To: References: <3vFQsVbVNWwkMmujMjMqpMA-ZvbxbWqRp5W-4XrycYM=.c60d6f08-74eb-4874-bbee-aa2d0365e8f3@github.com> Message-ID: On Mon, 6 Jan 2025 21:41:17 GMT, Chen Liang wrote: >> Improve documentation for constant pool entries. This include some models for those entries, symbolic descriptors, and some general guidance in package summary. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-consts/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-consts/ >> >> Please review the associated CSR as well. >> >> Companion PRs: #21625 > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - BSMEntry and copyright year > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Minor cleanups > - Stage more doc changes > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - More concise message about exceptions > - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool > - Improve api docs for constantpool Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22217#issuecomment-2576659249 From liach at openjdk.org Wed Jan 8 03:40:44 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Jan 2025 03:40:44 GMT Subject: Integrated: 8342468: Improve API documentation for java.lang.classfile.constantpool In-Reply-To: <3vFQsVbVNWwkMmujMjMqpMA-ZvbxbWqRp5W-4XrycYM=.c60d6f08-74eb-4874-bbee-aa2d0365e8f3@github.com> References: <3vFQsVbVNWwkMmujMjMqpMA-ZvbxbWqRp5W-4XrycYM=.c60d6f08-74eb-4874-bbee-aa2d0365e8f3@github.com> Message-ID: On Mon, 18 Nov 2024 19:59:16 GMT, Chen Liang wrote: > Improve documentation for constant pool entries. This include some models for those entries, symbolic descriptors, and some general guidance in package summary. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-consts/ > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-consts/ > > Please review the associated CSR as well. > > Companion PRs: #21625 This pull request has now been integrated. Changeset: bcefab5e Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/bcefab5e55d4527a38dcab550581a734c1564608 Stats: 1139 lines in 31 files changed: 768 ins; 69 del; 302 mod 8342468: Improve API documentation for java.lang.classfile.constantpool Reviewed-by: asotona ------------- PR: https://git.openjdk.org/jdk/pull/22217 From liach at openjdk.org Wed Jan 8 05:51:12 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Jan 2025 05:51:12 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v3] In-Reply-To: References: Message-ID: > `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Use since-style versions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22934/files - new: https://git.openjdk.org/jdk/pull/22934/files/13396297..f34c91c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22934&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22934&range=01-02 Stats: 37 lines in 1 file changed: 0 ins; 0 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/22934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22934/head:pull/22934 PR: https://git.openjdk.org/jdk/pull/22934 From jpai at openjdk.org Wed Jan 8 06:01:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Jan 2025 06:01:55 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: > Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? > > The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: > > https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html > > To summarize those discussions, we had concluded that: > - `Deflater` and `Inflater` will implement the `AutoCloseable` interface > - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). > - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. > - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. > - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. > > New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. > > I'll file a CSR shortly. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: fix javadoc tag ordering - "@throws" after "@return" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19675/files - new: https://git.openjdk.org/jdk/pull/19675/files/618ccc4c..4fbbc83d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=13-14 Stats: 16 lines in 2 files changed: 6 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675 PR: https://git.openjdk.org/jdk/pull/19675 From jpai at openjdk.org Wed Jan 8 06:01:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Jan 2025 06:01:55 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v14] In-Reply-To: <-rAkx4rny55Ys1lUMWTCv9wcehBYQoZ_16GsB86RnUs=.6003a884-a371-44aa-b9bb-47aba0ae8acc@github.com> References: <-rAkx4rny55Ys1lUMWTCv9wcehBYQoZ_16GsB86RnUs=.6003a884-a371-44aa-b9bb-47aba0ae8acc@github.com> Message-ID: On Tue, 7 Jan 2025 20:37:32 GMT, Roger Riggs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> change "@since" to 25 > > src/java.base/share/classes/java/util/zip/Deflater.java line 815: > >> 813: * than {@link Integer#MAX_VALUE}. >> 814: * >> 815: * @throws IllegalStateException if the Deflater is closed > > @throws should follow @return; (Style notes in https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html). Done - I've updated the PR to fix this and the other places that were introduced in this PR to follow that style guide. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1906521338 From liach at openjdk.org Wed Jan 8 06:06:47 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Jan 2025 06:06:47 GMT Subject: RFR: 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 Message-ID: The anchor is `refkinds` instead of `refKinds`. ------------- Commit messages: - 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 Changes: https://git.openjdk.org/jdk/pull/22961/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22961&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347163 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22961.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22961/head:pull/22961 PR: https://git.openjdk.org/jdk/pull/22961 From asotona at openjdk.org Wed Jan 8 06:54:35 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Jan 2025 06:54:35 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 01:45:48 GMT, Leonid Mesnik wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > I think it is make sense to put ASM into hotspot testlibrary if there are no any other users. So it is clear that non-hotspot tests don't depend on it. > There is a location > test/hotspot/jtreg/testlibrary > for hotstpot specific libraries. > Could you please move it here. > > Before renaming packages, I would like to understand if we can move to standard ASM? We are no planning to develop new tests and maintain this library for newer releases. Otherwise, keeping jdk.internal simplify backporting changes. > > It is not possible to implement it as a precompiled library because of jtreg limitations to find jars in test-images. So I'll implement this later. I agree with @lmesnik that any unnecessary repackaging would affect backporting compatibility (>1200 unnecessary changes across >250 source files causing potential conflicts). My question to test/hotspot/jtreg/testlibrary - is it effective to mix existing testlibrary with ASM. From the hotspot tests I see not all tests requiring testlibrary need ASM and vice versa. And many tests include other test libraries. However maybe it is irrelevant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576876491 From alanb at openjdk.org Wed Jan 8 06:59:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Jan 2025 06:59:44 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 22:19:22 GMT, Adam Sotona wrote: > Despite the 265 modified files is this PR trying to be minimalistic. Repackaging of the library would be far more complex and would affect significantly more files, including the library itself. I would recommend to invest that effort into the tests conversion into Class-File API instead. I'm not suggesting any re-packaging or pre-packaging, just saying that you can revert the changes that we have in the jdk repo so it goes back to .org.objectweb.asm. If we aren't doing that then okay but we still need to change all the tests that use it to remove "@modules java.base/jdk.internal.org.objectweb.asm". ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576882323 From asotona at openjdk.org Wed Jan 8 07:05:45 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Jan 2025 07:05:45 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 06:57:04 GMT, Alan Bateman wrote: > > you can revert the changes that we have in the jdk repo so it goes back to .org.objectweb.asm that represents a refactoring with >1200 changes in >250 files across multiple repositories ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576889598 From alanb at openjdk.org Wed Jan 8 07:08:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Jan 2025 07:08:34 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: <5IYTUxLAMpubLWi2gSAh6paz3K6XWZSGeQ6Nk3ahEiw=.6a26ad2a-e88e-4430-945f-996d648b1fda@github.com> References: <5IYTUxLAMpubLWi2gSAh6paz3K6XWZSGeQ6Nk3ahEiw=.6a26ad2a-e88e-4430-945f-996d648b1fda@github.com> Message-ID: On Wed, 8 Jan 2025 01:14:00 GMT, David Holmes wrote: > It is not appropriate for anything outside the platform modules to claim to be part of `jdk.internal`. In fact I'm surprised we are even allowed to add to that from outside the module! There's nothing to prohibit this, it's just surprising to have classes in jdk.internal.obj.objectweb.asm in an unnamed module, it will work of course. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576894583 From lmesnik at openjdk.org Wed Jan 8 07:12:35 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 8 Jan 2025 07:12:35 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: <4QEGZN9Q1i4qxuYSaP5Hsl4HsVqpiiyIgOnx_yUp61o=.a20ae6e2-85e8-4848-9c4f-dcf720b63fe3@github.com> On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona wrote: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam so you if add asm and use it like `* @library /testlibrary/asm` it should fit. There are tests that use `* @library /testlibrary` but seems it is redundant and leftover after merging hostpot and jdk. I'll file bug to clean up this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2576899567 From jpai at openjdk.org Wed Jan 8 07:21:35 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Jan 2025 07:21:35 GMT Subject: RFR: 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 In-Reply-To: References: Message-ID: <7eGukYad5ihXpdmdiPrzKVDd8yeAtmq59Rbu4qZl-Yw=.71b62b82-9176-4f15-b658-20c29a84d368@github.com> On Wed, 8 Jan 2025 06:02:38 GMT, Chen Liang wrote: > The anchor is `refkinds` instead of `refKinds`. Looks good and trivial to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22961#pullrequestreview-2536185329 From asotona at openjdk.org Wed Jan 8 07:21:36 2025 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 8 Jan 2025 07:21:36 GMT Subject: RFR: 8346986: Remove ASM from java.base [v2] In-Reply-To: References: Message-ID: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: asm move under test/hotspot/jtreg/testlibrary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22946/files - new: https://git.openjdk.org/jdk/pull/22946/files/f94d79e4..56fc9e41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=00-01 Stats: 143 lines in 263 files changed: 0 ins; 0 del; 143 mod Patch: https://git.openjdk.org/jdk/pull/22946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946 PR: https://git.openjdk.org/jdk/pull/22946 From liach at openjdk.org Wed Jan 8 07:45:39 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Jan 2025 07:45:39 GMT Subject: RFR: 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 06:02:38 GMT, Chen Liang wrote: > The anchor is `refkinds` instead of `refKinds`. I only ran the failed test and confirmed it works. It's a bit late for me, so if some other committer is interested and has verified there are no new failures feel free to integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22961#issuecomment-2576950986 From alan.bateman at oracle.com Wed Jan 8 08:03:57 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 8 Jan 2025 08:03:57 +0000 Subject: Does anyone have context on jdk.httpserver? In-Reply-To: <3C2AA0D2-B54A-4AC2-A843-06045BFE2B7F@ix.netcom.com> References: <45a03625-12fb-4c6b-8b67-18c4fffad732@oracle.com> <1CF18B51-7710-4035-965B-73D08C09CEC7@ix.netcom.com> <3C2AA0D2-B54A-4AC2-A843-06045BFE2B7F@ix.netcom.com> Message-ID: On 07/01/2025 15:18, robert engels wrote: > Hi, > > I would like to revisit this. I have signed the OCA for another PR I worked on - I believe it covers all of my contributions. > > The websockets license looks to be very permissive. But it seems like this is something Oracle could reach out to the authors to resolve. The simple HTTP server in the JDK was never meant to be a fully featured and high performance server. Instead it's meant for very simple usages, so think getting started, the rite of passage to serve up a file, and local testing. If someone wants a production ready server then there are dozens to choose from. So I think highly questionable as to whether it's worth putting any time into adding websockets or HTTP/2 support. > I could also simply create a whiteroom ws impl, as I did for the http2 support - it?s a pretty small surface api. > > I am more than willing to work on this, but I need to know what the feasibility is of it actually being included. > > Even if the work was limited to ?better support for vt?, some of the changes are more extensive (like the SSL handling). There may be a few small things that would make sense to bring to net-dev to discuss. I assume "vt" means virtual threads so if there is some issues there then bring them to the mailing list to get some agreement that they are worth doing. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Wed Jan 8 08:46:53 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 08:46:53 GMT Subject: RFR: 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 11:35:54 GMT, Maurizio Cimadamore wrote: > Please test this extensively. There is a non-zero chance that some tests (esp. in later tiers) might be relying on the current (bogus) behavior. So it might be possible for this fix to uncover more use-after-free issues. Passes tiers 1-5 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22943#issuecomment-2577091325 From pminborg at openjdk.org Wed Jan 8 08:46:54 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 08:46:54 GMT Subject: Integrated: 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 10:44:22 GMT, Per Minborg wrote: > This PR proposes to eliminate the capturing of `this` in the cleanup action of `AbstractMemorySegment::reinterpretInternal`. This pull request has now been integrated. Changeset: b0c935c0 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/b0c935c03ebb34f20f15dd8c7616c6c4526073cd Stats: 10 lines in 1 file changed: 7 ins; 2 del; 1 mod 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/22943 From pminborg at openjdk.org Wed Jan 8 08:54:49 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 08:54:49 GMT Subject: RFR: 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: <20jTmhHfPfigoh9aVPYDJCuwjr-11Cj7m0TtAIr1gM0=.6aeed91d-2b43-4520-977f-91182cf3dadb@github.com> On Tue, 7 Jan 2025 19:38:23 GMT, Brent Christian wrote: >> This PR proposes to eliminate the capturing of `this` in the cleanup action of `AbstractMemorySegment::reinterpretInternal`. > > As a matter of style, I believe there is something to be said for writing out cleaning actions as static nested classes, as one can/must include explicit fields for all object and values that the `Runnable` object must reference. But it's more verbose, of course. > > Also, some conversions of finalizer to Cleaner have included tests to ensure that objects become unreachable as expected. (A relatively simple technique is to add the objects in question into a WeakHashMap, and ensure they are removed as expected.) [GssContextCleanup.java](https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/jgss/GssContextCleanup.java) and [GssNameCleanup.java](https://github.com/openjdk/jdk/blob/master/test/jdk/sun/security/jgss/GssNameCleanup.java) from [JDK-8284490](https://bugs.openjdk.org/browse/JDK-8284490) are examples. I don't know if it's practical to construct such a test in this case. > > Anyway, just a couple things to think about. Thanks for the tips @bchristi-git : https://bugs.openjdk.org/browse/JDK-8347249 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22943#issuecomment-2577114779 From pminborg at openjdk.org Wed Jan 8 09:03:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 09:03:15 GMT Subject: [jdk24] RFR: 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive Message-ID: Hi all, This pull request contains a backport of commit [b0c935c0](https://github.com/openjdk/jdk/commit/b0c935c03ebb34f20f15dd8c7616c6c4526073cd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Per Minborg on 8 Jan 2025 and was reviewed by Maurizio Cimadamore. Thanks! ------------- Commit messages: - Backport b0c935c03ebb34f20f15dd8c7616c6c4526073cd Changes: https://git.openjdk.org/jdk/pull/22962/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22962&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347047 Stats: 10 lines in 1 file changed: 7 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22962.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22962/head:pull/22962 PR: https://git.openjdk.org/jdk/pull/22962 From pminborg at openjdk.org Wed Jan 8 09:05:39 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 09:05:39 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 15:37:41 GMT, Maurizio Cimadamore wrote: > copyrights should say 2025 I believe all the changes were made and committed in 2024. So, shouldn't the copyright year be 2024 then? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22827#issuecomment-2577140833 From pminborg at openjdk.org Wed Jan 8 09:12:38 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 09:12:38 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 14:00:53 GMT, Alan Bateman wrote: >> Both alternatives were present and I picked the most prevailing one in the package. Also, this is what you get when you auto format in IntelliJ. But if there is a preference for the other way, we could switch. No problem. > > I don't have any strong opinion on the topic, I was mostly just curious when I saw "conformant" in the title. I've renamed the title: "conformant" -> "consistent" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22827#discussion_r1906849451 From pminborg at openjdk.org Wed Jan 8 09:12:37 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 09:12:37 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 15:38:51 GMT, Maurizio Cimadamore wrote: > Do we have a sense on how easy would it be, moving forward, to preserve the "correct" order of imports? E.g. if I add a new one using IntelliJ autocompletion, where would it end up? Has this patch been generated using the IDE's own import reorganization? Perhaps doing something like that might be preferrable/more maintainable longer term? The updates in this PR were generated automatically by selecting the relevant packages and then using IntelliJ's automatic Code->Optimize Imports. It is possible to tell IntelliJ to make this automatically upon saving a file: https://www.jetbrains.com/help/idea/creating-and-optimizing-imports.html#optimize-on-save ------------- PR Comment: https://git.openjdk.org/jdk/pull/22827#issuecomment-2577151527 From mbaesken at openjdk.org Wed Jan 8 09:18:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 8 Jan 2025 09:18:41 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails [v3] In-Reply-To: References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Fri, 3 Jan 2025 21:33:17 GMT, Alexey Semenyuk wrote: >> Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. > > Alexey Semenyuk 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: > > - Merge branch 'master' into JDK-8346872 > - Add missing `@library /test/lib` and update copyright year > - 8346872: tools/jpackage/windows/WinLongPathTest.java fails Marked as reviewed by mbaesken (Reviewer). Thanks for the fix. Should probably we backported to 24 too, we see the issue there as well. ------------- PR Review: https://git.openjdk.org/jdk/pull/22896#pullrequestreview-2536593442 PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2577170599 From shade at openjdk.org Wed Jan 8 10:00:45 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 8 Jan 2025 10:00:45 GMT Subject: [jdk24] RFR: 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 08:57:33 GMT, Per Minborg wrote: > Hi all, > > This pull request contains a backport of commit [b0c935c0](https://github.com/openjdk/jdk/commit/b0c935c03ebb34f20f15dd8c7616c6c4526073cd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 8 Jan 2025 and was reviewed by Maurizio Cimadamore. > > Thanks! I agree this is worth fixing in JDK 24. Technically P4 bug is not a candidate for a fix in RDP 1 phase, but I would say this is actually a P3 bug. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22962#pullrequestreview-2536698104 From shade at openjdk.org Wed Jan 8 10:01:46 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 8 Jan 2025 10:01:46 GMT Subject: RFR: 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 In-Reply-To: References: Message-ID: <6OxNW_b79ZA5tADyeqHdBGyj-lunowmRtGDVQptYQoU=.3d4cfa4e-4c02-483c-a3ae-d427ff1d0eb8@github.com> On Wed, 8 Jan 2025 06:02:38 GMT, Chen Liang wrote: > The anchor is `refkinds` instead of `refKinds`. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22961#pullrequestreview-2536699804 From pminborg at openjdk.org Wed Jan 8 10:19:41 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 10:19:41 GMT Subject: [jdk24] RFR: 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 08:57:33 GMT, Per Minborg wrote: > Hi all, > > This pull request contains a backport of commit [b0c935c0](https://github.com/openjdk/jdk/commit/b0c935c03ebb34f20f15dd8c7616c6c4526073cd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 8 Jan 2025 and was reviewed by Maurizio Cimadamore. > > Thanks! I've updated the bug to P3. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22962#issuecomment-2577302974 From pminborg at openjdk.org Wed Jan 8 10:19:42 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 8 Jan 2025 10:19:42 GMT Subject: [jdk24] Integrated: 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive In-Reply-To: References: Message-ID: <4wp5gTtPJh2B9k3TpTABqx62ExTqir8OhiG_Prot_k4=.b95db3e3-b0fe-4545-8657-a0b05ade3bc5@github.com> On Wed, 8 Jan 2025 08:57:33 GMT, Per Minborg wrote: > Hi all, > > This pull request contains a backport of commit [b0c935c0](https://github.com/openjdk/jdk/commit/b0c935c03ebb34f20f15dd8c7616c6c4526073cd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Per Minborg on 8 Jan 2025 and was reviewed by Maurizio Cimadamore. > > Thanks! This pull request has now been integrated. Changeset: 860b30dd Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/860b30ddf9459ab1e4ef44cb9f3df2ad24e9652d Stats: 10 lines in 1 file changed: 7 ins; 2 del; 1 mod 8347047: Cleanup action passed to MemorySegment::reinterpret keeps old segment alive Reviewed-by: shade Backport-of: b0c935c03ebb34f20f15dd8c7616c6c4526073cd ------------- PR: https://git.openjdk.org/jdk/pull/22962 From sgehwolf at openjdk.org Wed Jan 8 10:41:42 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 10:41:42 GMT Subject: Integrated: 8346239: Improve memory efficiency of JimageDiffGenerator In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the `JimageDiffGenerator` works. The original implementation is pretty naive and read all bytes into memory and then compared them. This improved version only reads bytes on a bound buffer into memory compares those bytes and if equal continues on to reading the next bytes (`2k` at most) at a time. Previously it was `2*N` (where `N` is the file size of a file in bytes) part of the JDK. Ouch. > > There is still the off-chance of reading a full file into memory when the generator detects a change, but this shouldn't happen for large files since the total diff should be around `600K` as of today. > > This also reverts changes from [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036) other than the `/timeout` change to the test, which is preserved as I think this bump is no longer needed. > > Testing: > - [x] GHA > - [x] jlink tests on a fastdebug build with `--with-native-debug-symbols=internal` (so as to have a large libjvm.so). > - [x] Manual reproducer from the bug which fails with OOM before the patch and passes after > > Thoughts? This pull request has now been integrated. Changeset: f696d9c5 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/f696d9c521fa13969cb81381dc8586bcdccf67d9 Stats: 77 lines in 16 files changed: 57 ins; 3 del; 17 mod 8346239: Improve memory efficiency of JimageDiffGenerator Reviewed-by: mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/22835 From mcimadamore at openjdk.org Wed Jan 8 10:46:38 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 8 Jan 2025 10:46:38 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 09:02:57 GMT, Per Minborg wrote: > > copyrights should say 2025 > > I believe all the changes were made and committed in 2024. So, shouldn't the copyright year be 2024 then? I've typically used the year of when things are integrated. It's a bit of a gray area and I'm not super sure. Note that Skara will take your commits and squash them into a new commit which will feature a 2025 date (I think). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22827#issuecomment-2577357523 From alanb at openjdk.org Wed Jan 8 10:46:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Jan 2025 10:46:50 GMT Subject: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the `JimageDiffGenerator` works. The original implementation is pretty naive and read all bytes into memory and then compared them. This improved version only reads bytes on a bound buffer into memory compares those bytes and if equal continues on to reading the next bytes (`2k` at most) at a time. Previously it was `2*N` (where `N` is the file size of a file in bytes) part of the JDK. Ouch. > > There is still the off-chance of reading a full file into memory when the generator detects a change, but this shouldn't happen for large files since the total diff should be around `600K` as of today. > > This also reverts changes from [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036) other than the `/timeout` change to the test, which is preserved as I think this bump is no longer needed. > > Testing: > - [x] GHA > - [x] jlink tests on a fastdebug build with `--with-native-debug-symbols=internal` (so as to have a large libjvm.so). > - [x] Manual reproducer from the bug which fails with OOM before the patch and passes after > > Thoughts? @slowhog Would it be possible to do a pass over this too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22835#issuecomment-2577358214 From jpai at openjdk.org Wed Jan 8 10:59:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Jan 2025 10:59:59 GMT Subject: RFR: 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 06:02:38 GMT, Chen Liang wrote: > The anchor is `refkinds` instead of `refKinds`. tier testing of this change in the CI completed without any failures. I'll go ahead and integrate this now to reduce additional sighting of this failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22961#issuecomment-2577382732 From liach at openjdk.org Wed Jan 8 11:00:00 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Jan 2025 11:00:00 GMT Subject: Integrated: 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 In-Reply-To: References: Message-ID: <6UZXqG-q3HPqyRKjRhThVWtDHIMn7TUtWi8vsoj6nn4=.e5847e5d-55ed-44ec-bd15-921741244868@github.com> On Wed, 8 Jan 2025 06:02:38 GMT, Chen Liang wrote: > The anchor is `refkinds` instead of `refKinds`. This pull request has now been integrated. Changeset: afe54341 Author: Chen Liang Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/afe543414f58a04832d4f07dea88881d64954a0b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 Reviewed-by: jpai, shade ------------- PR: https://git.openjdk.org/jdk/pull/22961 From jnordstrom at openjdk.org Wed Jan 8 11:03:06 2025 From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=) Date: Wed, 8 Jan 2025 11:03:06 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2] In-Reply-To: References: Message-ID: > Could I get a review of this fix to refine the warnings printed by `libjsig` when using the deprecated `signal()`/`sigset()` functions? > > Currently the libjsig library supports chaining `signal()` and `sigset()`. With these functions being deprecated, `libjsig` warns when a program calls either function when the it's LD_PRELOADed. The warning is supposed to warn that when the support for `signal()` and `sigset()` is removed, the application might stop working as expected. > >> VM warning: the use of signal() and sigset() for signal chaining was deprecated in version 16.0 and will be removed in a future release. Use sigaction() instead. > > The warning is however printed in a few cases when its unnecessary, and also fails to catch some usages where it should be printed. With this fix the warning is printed (in order as they appear in jsig.c): > 1. when `signal()` or `sigset()` is called for a JVM-used signal, after the JVM has installed its signals > 2. when the JVM installs its signals (using `sigaction()`), and libjsig sees that `signal()` or `sigset()` has been used for a JVM-used signal > > ### Changes > * The printing is removed from `call_os_signal()`. This warning was only correct if `signal()` or `sigset()` was called for a JVM-used signal before the JVM was installed. This is now instead covered by step 1 above. > * If the JVM was installed first, the `signal()`/`sigset()` calls were effectively translated to `sigaction()`, and the warning was _not_ printed. When the `signal()`/`sigset()` support is dropped, this behaviour will change and the warning should be printed. This is now covered by step 2. > > ## Testing > - [x] Test `open/test/hotspot/jtreg/runtime/signal` has added checks for the deprecation warning, and passes with the fix > - [x] Tier1-3 in progress Joakim Nordstr?m has updated the pull request incrementally with three additional commits since the last revision: - Merge - Copyright year. Doc updated. Comments revised. - Merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22806/files - new: https://git.openjdk.org/jdk/pull/22806/files/6aa575ef..0fd4e6f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22806&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22806&range=00-01 Stats: 12 lines in 3 files changed: 5 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22806/head:pull/22806 PR: https://git.openjdk.org/jdk/pull/22806 From jnordstrom at openjdk.org Wed Jan 8 11:03:06 2025 From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=) Date: Wed, 8 Jan 2025 11:03:06 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2] In-Reply-To: References: Message-ID: <8XxtXuytxUWy-MAQbt57DYLQd_RmfpYP6dEF65vgj2A=.30a9b436-3a85-45cf-a778-05098d267dd8@github.com> On Tue, 7 Jan 2025 14:26:13 GMT, Joakim Nordstr?m wrote: >> test/hotspot/jtreg/runtime/signal/SigTestDriver.java line 176: >> >>> 174: /** >>> 175: * Return true for all signals used by the JVM. This only covers the >>> 176: * case where the JVM is started normally, and not with -Xrs. >> >> The VM also uses SIGUSR2 (`SR_signum`), SIGINT, and SIGQUIT. Though the latter two only if no `-Xrs` is given. > > The test is skipped for SIGUSR2 on Linux and MacOS, and Windows skips all signal testing. So I guess that leaves aix, which seems to use signals_poxis.cpp... so perhaps the SIGUSR2 test should be skipped for aix too? > But I'll add the signals for clarity. Just to add to this, "aix" is explicitly skipped in the TestSigsur2.java test. So this test is never run for SIGUSR2. I changed the comment for the method to indicate better what it returns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22806#discussion_r1907003799 From lancea at openjdk.org Wed Jan 8 13:24:49 2025 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 8 Jan 2025 13:24:49 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 06:01:55 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fix javadoc tag ordering - "@throws" after "@return" Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19675#pullrequestreview-2537131993 From sgehwolf at openjdk.org Wed Jan 8 13:34:23 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 13:34:23 GMT Subject: RFR: 8345185: Update jpackage to not include service bindings by default [v5] In-Reply-To: References: Message-ID: > Please review these changes to jpackage in light of [JEP 493](https://openjdk.org/jeps/493). When this feature is enabled, then some of the `jpackage` tests fail. The failures fall into the following categories: > > - `ALL-DEFAULT` notion from `jpackage` which includes all modules that export an API, which includes `jdk.jlink`, which is prevented from being included when linking from the run-time image (see the [JEP 493](https://openjdk.org/jeps/493) restrictions). The proposal is to change module resolution from `Configuration.resolveAndBind()` to `Configuration.resolve()`. I.e. don't perform service binding which is in line what [JEP 392](https://openjdk.org/jeps/392) and [JEP 343](https://openjdk.org/jeps/343) claim. That is, this patch brings the implementation aligned to what it says on the JEPs > - `ALL-MODULE-PATH` changes: `BasicTest.java` verifies the `--add-modules` argument to `jpackage`. Using `ALL-MODULE-PATH` for JDK modules won't be supported for JEP 493-enabled builds. So I've changed this test to skip the test using `ALL-MODULE-PATH` when we have such an enabled build. Other tests, such as `RuntimeImageTest.java` and `RuntimeImageSymbolicLinksTest.java` tests verify something else not related to `ALL-MODULE-PATH` or `--add-modules`. It seems more appropriate to use the smaller set of modules to use for the runtime JDK image. > - `JLinkOptionsTest.java`: That test verifies options passed to `jlink` via the `ToolProvider` API. For some reason, it uses `--bind-services` extensively and that - in turn - and, when not limited with the `--limit-modules` option as well, will include `jdk.jlink` in the resulting image, again running afoul the JEP 493 restriction of not allowing `jdk.jlink` for now. I propose to use suitable options including `--limit-modules` which would then no longer include `jdk.jlink` in the runtime image and the link from a run-time image works as well. These changes depend on [JDK-8345573](https://bugs.openjdk.org/browse/JDK-8345573) for it to work fully. > > Testing: > - [x] GHA > - [x] running tests in `test/jdk/tools/jpackage` on a JEP 493 enabled JDK. As far as I could see the failures that I was seeing weren't any more related to JEP 493 (some RPM requirements showing up that it didn't expect to). > > Thoughts? Opinions? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix - Adjust BasicTest for ALL-MODULE-PATH and JDK-8345259 - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix - Use TKit.trace() - Refactor BasicTest.java according to review - Don't resolve service bindings by default - Revert "Handle ALL-DEFAULT in jpackage tool" This reverts commit ca506f85f67f495cd29e8f9ff1a7004c9888aaaf. - Merge branch 'master' into jdk-8345185-jpackage-all-default-fix - Adjust JLinkOptionsTest.java after JEP 493 - ... and 2 more: https://git.openjdk.org/jdk/compare/672c413c...897347ee ------------- Changes: https://git.openjdk.org/jdk/pull/22644/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22644&range=04 Stats: 60 lines in 7 files changed: 36 ins; 11 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/22644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22644/head:pull/22644 PR: https://git.openjdk.org/jdk/pull/22644 From epeter at openjdk.org Wed Jan 8 14:13:40 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 8 Jan 2025 14:13:40 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com> References: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com> Message-ID: On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja wrote: >>> > Can you quickly summarize what tests you have, and what they test? >>> >>> Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps. >> >> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours. > >> > > Can you quickly summarize what tests you have, and what they test? >> > >> > >> > Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps. >> >> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours. > > > Validations details:- > > A) x86 backend changes > - new assembler instruction > - macro assembly routines. > Test point:- test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java > - This test is based on a testng framework and includes new DataProviders to generate test vectors. > - Test vectors cover the entire float16 value range and also special floating point values (NaN, +Int, -Inf, 0.0 and -0.0) > B) GVN transformations:- > - Value Transforms > Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Covers all the constant folding scenarios for add, sub, mul, div, sqrt, fma, min, and max operations addressed by this patch. > - It also tests special case scenarios for each operation as specified by Java language specification. > - identity Transforms > Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Covers identity transformation for ReinterpretS2HFNode, DivHFNode > - idealization Transforms > Test points:- test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java > :- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Contains test point for the following transform > MulHF idealization i.e. MulHF * 2 => AddHF > - Contains test point for the following transform > DivHF SRC , PoT(constant) => MulHF SRC * reciprocal (constant) > - Contains idealization test points for the following transform > ConvF2HF(FP32BinOp(ConvHF2F(x), ConvHF2F(y))) => > ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y))) @jatin-bhateja Is this ready for another review pass? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2577768041 From sgehwolf at openjdk.org Wed Jan 8 14:30:17 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 14:30:17 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime Message-ID: Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. Testing: - [ ] GHA - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. Thoughts? ------------- Commit messages: - 8347124: Clean tests with --enable-linkable-runtime Changes: https://git.openjdk.org/jdk/pull/22969/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347124 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22969/head:pull/22969 PR: https://git.openjdk.org/jdk/pull/22969 From alanb at openjdk.org Wed Jan 8 14:45:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Jan 2025 14:45:38 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime In-Reply-To: References: Message-ID: <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com> On Wed, 8 Jan 2025 14:24:25 GMT, Severin Gehwolf wrote: > Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. > > Testing: > - [ ] GHA > - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. > > Thoughts? test/jdk/tools/launcher/SourceMode.java line 29: > 27: * @summary Test source mode > 28: * @modules jdk.compiler jdk.jlink > 29: * @run main/othervm SourceMode This looks fine, might need to add `@comment` to something brief to say why the test are othervm. Also I assume you'll bump the copyright header on the tests before ingtegrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22969#discussion_r1907293028 From asemenyuk at openjdk.org Wed Jan 8 14:46:42 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 14:46:42 GMT Subject: RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails [v3] In-Reply-To: References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Fri, 3 Jan 2025 21:33:17 GMT, Alexey Semenyuk wrote: >> Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. > > Alexey Semenyuk 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: > > - Merge branch 'master' into JDK-8346872 > - Add missing `@library /test/lib` and update copyright year > - 8346872: tools/jpackage/windows/WinLongPathTest.java fails Thank you for the review, everyone! I agree this needs to be backported to jdk24. I will take care of the backport. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22896#issuecomment-2577843441 From asemenyuk at openjdk.org Wed Jan 8 14:46:43 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 14:46:43 GMT Subject: Integrated: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> References: <25cLDuwZgnb4g-LiwlTsGVl1rF99IicSyZtWTi5PucA=.f7b7043c-648f-4b41-8b01-b8a6d04ab57a@github.com> Message-ID: On Mon, 30 Dec 2024 21:25:20 GMT, Alexey Semenyuk wrote: > Skip the test (throw `jtreg.SkippedException`) if the volume that owns the test's work directory doesn't support DOS file names. This pull request has now been integrated. Changeset: 4d18e5a1 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/4d18e5a1e26e04beb550d01ba5a3dbb8c0c37fa0 Stats: 25 lines in 1 file changed: 24 ins; 0 del; 1 mod 8346872: tools/jpackage/windows/WinLongPathTest.java fails Reviewed-by: almatvee, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/22896 From sgehwolf at openjdk.org Wed Jan 8 14:56:55 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 14:56:55 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: References: Message-ID: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> > Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. > > Testing: > - [ ] GHA > - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Copyright and @comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22969/files - new: https://git.openjdk.org/jdk/pull/22969/files/afc33798..6eceb0de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=00-01 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22969/head:pull/22969 PR: https://git.openjdk.org/jdk/pull/22969 From sgehwolf at openjdk.org Wed Jan 8 14:56:56 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 14:56:56 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com> References: <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com> Message-ID: On Wed, 8 Jan 2025 14:42:45 GMT, Alan Bateman wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright and @comment > > test/jdk/tools/launcher/SourceMode.java line 29: > >> 27: * @summary Test source mode >> 28: * @modules jdk.compiler jdk.jlink >> 29: * @run main/othervm SourceMode > > This looks fine, might need to add `@comment` to something brief to say why the test are othervm. Also I assume you'll bump the copyright header on the tests before ingtegrating. Thanks. `@comment` added and copyright header updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22969#discussion_r1907309808 From sgehwolf at openjdk.org Wed Jan 8 15:12:40 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 15:12:40 GMT Subject: [jdk24] RFR: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path In-Reply-To: References: Message-ID: <6KHJqOSuvrEhYV7pYXL9p4yhzxXYZMbdZbXPx94E7r8=.f01ef38b-d228-44f2-968f-5c88782b9019@github.com> On Fri, 20 Dec 2024 18:04:15 GMT, Alan Bateman wrote: >> Clean backport of [JDK-8345259](https://bugs.openjdk.org/browse/JDK-8345259) to JDK 24 which has JEP 493. > > Hold off on integrating this into jdk24 until some issues with jpackage tests are figured out, I think we have some failures in main line with tests that specify ALL-MODULE-PATH without a module path. @AlanBateman @mlchung RDP2 is on January 16 for JDK 24, so about a week time. AFAIK, both fixes are eligible still. This and https://github.com/openjdk/jdk/pull/22972 together should be safe. OK? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22849#issuecomment-2577910143 From sgehwolf at openjdk.org Wed Jan 8 15:15:13 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 15:15:13 GMT Subject: [jdk24] RFR: 8346739: jpackage tests failed after JDK-8345259 Message-ID: Clean backport of a test follow-up for #22849 targeting JDK 24. Please review! Thanks in advance. ------------- Commit messages: - Backport 7ba969a576eb92446e40587fecf98e1e4aba8883 Changes: https://git.openjdk.org/jdk/pull/22972/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22972&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346739 Stats: 7 lines in 3 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22972/head:pull/22972 PR: https://git.openjdk.org/jdk/pull/22972 From alanb at openjdk.org Wed Jan 8 15:17:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Jan 2025 15:17:47 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [ ] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Copyright and @comment Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2537439865 From alanb at openjdk.org Wed Jan 8 15:17:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Jan 2025 15:17:52 GMT Subject: [jdk24] RFR: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 13:25:43 GMT, Severin Gehwolf wrote: > Clean backport of [JDK-8345259](https://bugs.openjdk.org/browse/JDK-8345259) to JDK 24 which has JEP 493. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22849#pullrequestreview-2537442047 From liach at openjdk.org Wed Jan 8 15:25:38 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Jan 2025 15:25:38 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v3] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 05:51:12 GMT, Chen Liang wrote: >> `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use since-style versions Joe and David, can you look at this updated versioning that uses the core libraries since scheme? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22934#issuecomment-2577945273 From sgehwolf at openjdk.org Wed Jan 8 15:26:36 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 15:26:36 GMT Subject: [jdk24] RFR: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 13:25:43 GMT, Severin Gehwolf wrote: > Clean backport of [JDK-8345259](https://bugs.openjdk.org/browse/JDK-8345259) to JDK 24 which has JEP 493. Thanks for the review. I'll wait until #22972 is reviewed and ready as well so as to make the window with test failures as small as possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22849#issuecomment-2577946561 From sgehwolf at openjdk.org Wed Jan 8 15:29:36 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 15:29:36 GMT Subject: [jdk24] RFR: 8346739: jpackage tests failed after JDK-8345259 In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 15:08:31 GMT, Severin Gehwolf wrote: > Clean backport of a test follow-up for #22849 targeting JDK 24. Please review! Thanks in advance. @alexeysemenyukoracle Could you please help review this for JDK 24? The change needing this is about to go into JDK 24 as well in #22849. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22972#issuecomment-2577954513 From shade at openjdk.org Wed Jan 8 15:43:36 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 8 Jan 2025 15:43:36 GMT Subject: [jdk24] RFR: 8346739: jpackage tests failed after JDK-8345259 In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 15:08:31 GMT, Severin Gehwolf wrote: > Clean backport of a test follow-up for #22849 targeting JDK 24. Please review! Thanks in advance. Backport looks fine. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22972#pullrequestreview-2537507091 From cstein at openjdk.org Wed Jan 8 15:45:47 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 8 Jan 2025 15:45:47 GMT Subject: RFR: 8340380: Improve source launcher's shebang script detection Message-ID: Please review this change that improves the launcher mode detection by reading the initial two characters from the started shebang script. It addresses the reported confusing error messages and also supports more shebang line variations. Including those line variations that omit the `--source` arguments like shown in the underlying issue description of JDK-8340380. ------------- Commit messages: - Add shebang test case without `--source` - 8340380: Improve source launcher's shebang script detection Changes: https://git.openjdk.org/jdk/pull/21910/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21910&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340380 Stats: 31 lines in 2 files changed: 30 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21910.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21910/head:pull/21910 PR: https://git.openjdk.org/jdk/pull/21910 From rriggs at openjdk.org Wed Jan 8 15:47:40 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 8 Jan 2025 15:47:40 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 06:01:55 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fix javadoc tag ordering - "@throws" after "@return" Thanks for the updates. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19675#pullrequestreview-2537518189 From vpaprotski at openjdk.org Wed Jan 8 16:26:46 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Wed, 8 Jan 2025 16:26:46 GMT Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 23:45:37 GMT, Volodymyr Paprotski wrote: > @TobiHartmann There are still some unanswered questions I have, but committing this since we need to work around vacation schedules. > > **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This fix fixes the crash but I don't understand entirely why the crash happens in the first place. > > The issue fixed here are all the CheckJNI warnings: > > OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall > > > Crash has nothing to do with String.indexOf work, but was introduced by my `8319429: Resetting MXCSR flags degrades ecore` change. I was able to get HelloWorld to crash on Windows (`-Xcheck:jni -XX:+EnableX86ECoreOpts`). Same command on linux produces hundreds of CheckJNI warnings. Is it odd that its only being found now, no other CheckJNI tests? > > I would appreciate some help/reviews from somebody more aware of the Java-to-C linkage. I think I got the masks fixed, but there is one specific place (see the 'FIXME' question in the diff) for Windows I am not certain about. (@sviswa7 is on vacation for few more weeks) > > Note: Crash on windows (if I have the Windows debugger actually correct), happens on: > > 0x000001f2525f13c1: fxrstor64 (%rsp) > Stack: > 0x00000088f1bfe060: 00007ff8b4384310 0000025bfaeb2200 > > > `00007ff8` _seems_ like a valid mxcsr value, only way it should crash is if top 2 bytes weren't zeroes, which they are. (back from vacation. After discussing this with Sandhya, will have an update soon) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22673#issuecomment-2578090185 From mbalao at openjdk.org Wed Jan 8 16:40:34 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 8 Jan 2025 16:40:34 GMT Subject: RFR: 8315487: Security Providers Filter [v18] In-Reply-To: References: Message-ID: > In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR. > > ## ProvidersFilter > > ### Filter construction (parser) > > The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized. > > The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor. > > While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future. > > ### Filter (structure and behavior) > > A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser... Martin Balao 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 two additional commits since the last revision: - Add a debug message to inform the Filter property value read. See more in https://mail.openjdk.org/pipermail/security-dev/2024-October/041800.html Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet - 8315487: Security Providers Filter Co-authored-by: Francisco Ferrari Bihurriet Co-authored-by: Martin Balao ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15539/files - new: https://git.openjdk.org/jdk/pull/15539/files/5ab4aa3e..7889bd25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=16-17 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15539.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539 PR: https://git.openjdk.org/jdk/pull/15539 From mbalao at openjdk.org Wed Jan 8 16:50:01 2025 From: mbalao at openjdk.org (Martin Balao) Date: Wed, 8 Jan 2025 16:50:01 GMT Subject: RFR: 8315487: Security Providers Filter [v19] In-Reply-To: References: Message-ID: > In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR. > > ## ProvidersFilter > > ### Filter construction (parser) > > The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized. > > The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor. > > While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future. > > ### Filter (structure and behavior) > > A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser... Martin Balao has updated the pull request incrementally with one additional commit since the last revision: Copyright date update. Co-authored-by: Martin Balao Alonso Co-authored-by: Francisco Ferrari Bihurriet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/15539/files - new: https://git.openjdk.org/jdk/pull/15539/files/7889bd25..23b85913 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=17-18 Stats: 19 lines in 19 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/15539.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539 PR: https://git.openjdk.org/jdk/pull/15539 From naoto at openjdk.org Wed Jan 8 16:51:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 8 Jan 2025 16:51:53 GMT Subject: RFR: 8166983: Remove old/legacy unused tzdata files In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 18:27:31 GMT, Naoto Sato wrote: > Long overdue cleanup, especially the old `javazic` tool, which has been maintenance burden for some time. Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22955#issuecomment-2578145519 From naoto at openjdk.org Wed Jan 8 16:51:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 8 Jan 2025 16:51:54 GMT Subject: Integrated: 8166983: Remove old/legacy unused tzdata files In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 18:27:31 GMT, Naoto Sato wrote: > Long overdue cleanup, especially the old `javazic` tool, which has been maintenance burden for some time. This pull request has now been integrated. Changeset: 49ee4df3 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/49ee4df375f57ef2d06ff7d54aaefed77d60c40b Stats: 8665 lines in 28 files changed: 0 ins; 8663 del; 2 mod 8166983: Remove old/legacy unused tzdata files Reviewed-by: iris, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/22955 From mchung at openjdk.org Wed Jan 8 17:31:19 2025 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 8 Jan 2025 17:31:19 GMT Subject: [jdk24] RFR: 8346739: jpackage tests failed after JDK-8345259 In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 15:08:31 GMT, Severin Gehwolf wrote: > Clean backport of a test follow-up for #22849 targeting JDK 24. Please review! Thanks in advance. Marked as reviewed by mchung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22972#pullrequestreview-2537763599 From mchung at openjdk.org Wed Jan 8 17:31:53 2025 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 8 Jan 2025 17:31:53 GMT Subject: [jdk24] RFR: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 13:25:43 GMT, Severin Gehwolf wrote: > Clean backport of [JDK-8345259](https://bugs.openjdk.org/browse/JDK-8345259) to JDK 24 which has JEP 493. Marked as reviewed by mchung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22849#pullrequestreview-2537765946 From acobbs at openjdk.org Wed Jan 8 17:44:50 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 8 Jan 2025 17:44:50 GMT Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v8] In-Reply-To: <1A--E365t_-y1kXsWKb_wotAzGiVatMGWyqjdaLkTK8=.72f824e4-07ae-4e5f-b8cc-713280df230d@github.com> References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com> <1A--E365t_-y1kXsWKb_wotAzGiVatMGWyqjdaLkTK8=.72f824e4-07ae-4e5f-b8cc-713280df230d@github.com> Message-ID: On Mon, 9 Dec 2024 22:18:30 GMT, Joe Darcy wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Remove more unnecessary suppressions. >> - Merge branch 'master' into SuppressWarningsCleanup-core-libs >> - Remove more unnecessary @SuppressWarnings annotations. >> - Merge branch 'master' into SuppressWarningsCleanup-core-libs >> - Remove more unnecessary warning suppressions. >> - Merge branch 'master' into SuppressWarningsCleanup-core-libs >> - Put back @SuppressWarnings annotations to be fixed by JDK-8343286. >> - Merge branch 'master' into SuppressWarningsCleanup-core-libs >> - Update copyright years. >> - Remove a few more @SuppressWarnings annotations. >> - ... and 5 more: https://git.openjdk.org/jdk/compare/cc628a13...ee2862e5 > > Core reflection changes look fine; thanks for the cleanup @archiecobbs . @jddarcy , thanks for your previous review. A few changes have been added since then so would you mind updating your review? Also, can you confirm all necessary reviews have been made? This covers several areas so want to double-check. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2578254734 From henryjen at openjdk.org Wed Jan 8 18:03:43 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 8 Jan 2025 18:03:43 GMT Subject: RFR: 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image In-Reply-To: References: Message-ID: On Sun, 22 Sep 2024 15:38:19 GMT, Alan Bateman wrote: >> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those. >> >> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created. >> >> Another is for random set, such as packages, thus we put those request into a queue to amend the class later. >> >> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time. >> >> So we make this build in advance, and use a static array for values referred more than once. >> >> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent. > > It would be helpful for potential reviewers if the PR description included a brief summary on the changes to the code generated, otherwise it's a lot to wade through to understand the changes. @AlanBateman Do I need another approval before integrate this? If so, would you have a look? @jerboaa , @liach Thanks for reviewing, is there anything else you would like to add? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21022#issuecomment-2578297968 From iris at openjdk.org Wed Jan 8 18:11:55 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 8 Jan 2025 18:11:55 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v3] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 05:51:12 GMT, Chen Liang wrote: >> `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use since-style versions Versions matching `java.specification.version` look good. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22934#pullrequestreview-2537849309 From henryjen at openjdk.org Wed Jan 8 19:15:05 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 8 Jan 2025 19:15:05 GMT Subject: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the `JimageDiffGenerator` works. The original implementation is pretty naive and read all bytes into memory and then compared them. This improved version only reads bytes on a bound buffer into memory compares those bytes and if equal continues on to reading the next bytes (`2k` at most) at a time. Previously it was `2*N` (where `N` is the file size of a file in bytes) part of the JDK. Ouch. > > There is still the off-chance of reading a full file into memory when the generator detects a change, but this shouldn't happen for large files since the total diff should be around `600K` as of today. > > This also reverts changes from [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036) other than the `/timeout` change to the test, which is preserved as I think this bump is no longer needed. > > Testing: > - [x] GHA > - [x] jlink tests on a fastdebug build with `--with-native-debug-symbols=internal` (so as to have a large libjvm.so). > - [x] Manual reproducer from the bug which fails with OOM before the patch and passes after > > Thoughts? src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 133: > 131: try (is1; is2) { > 132: while ((bytesRead1 = is1.read(buf1)) != -1 && > 133: (bytesRead2 = is2.read(buf2)) != -1) { - what's the point to have second try block? - I think it's easier to read to while loop on is1, then read and check is2 within the loop instead of && on both. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22835#discussion_r1907650243 From asemenyuk at openjdk.org Wed Jan 8 19:26:44 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 19:26:44 GMT Subject: [jdk24] RFR: 8346739: jpackage tests failed after JDK-8345259 In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 15:08:31 GMT, Severin Gehwolf wrote: > Clean backport of a test follow-up for #22849 targeting JDK 24. Please review! Thanks in advance. LGTM ------------- Marked as reviewed by asemenyuk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22972#pullrequestreview-2538018043 From hannesw at openjdk.org Wed Jan 8 19:47:13 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 8 Jan 2025 19:47:13 GMT Subject: RFR: 8347121: Add missing @serial tags to module java.base Message-ID: Please review a doc-only change to add missing `@serial` javadoc tags in module `java.base`. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. (For protected and public serialized fields we would have appended an empty `@serial` block tag instead with the same effect, but there are no protected/public fields in this particular sub-task.) For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. There is one special case in `java/util/UUID.java` where two private fields had plain traditional comments containing `@serial` tags instead of doc comments. Converting these comments to doc-comments is the only change in this PR that causes a change in the generated documentation, adding documentation for these two fields to the `serialized-form.html` page. ------------- Commit messages: - 8347121: Add missing @serial tags to module java.base Changes: https://git.openjdk.org/jdk/pull/22978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347121 Stats: 305 lines in 89 files changed: 83 ins; 4 del; 218 mod Patch: https://git.openjdk.org/jdk/pull/22978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22978/head:pull/22978 PR: https://git.openjdk.org/jdk/pull/22978 From dfuchs at openjdk.org Wed Jan 8 19:57:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Jan 2025 19:57:45 GMT Subject: RFR: 8347121: Add missing @serial tags to module java.base In-Reply-To: References: Message-ID: <4QE9pLQdvn8djpGnGMzgcoI9PSLLsD6RpGQAiVB6D2Q=.477d3db7-3d47-4bbe-8a3b-88f09e73ded6@github.com> On Wed, 8 Jan 2025 19:41:42 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to add missing `@serial` javadoc tags in module `java.base`. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. (For protected and public serialized fields we would have appended an empty `@serial` block tag instead with the same effect, but there are no protected/public fields in this particular sub-task.) For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > There is one special case in `java/util/UUID.java` where two private fields had plain traditional comments containing `@serial` tags instead of doc comments. Converting these comments to doc-comments is the only change in this PR that causes a change in the generated documentation, adding documentation for these two fields to the `serialized-form.html` page. Changes to `java.net` look OK. ------------- PR Review: https://git.openjdk.org/jdk/pull/22978#pullrequestreview-2538086167 From sgehwolf at openjdk.org Wed Jan 8 20:09:36 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 20:09:36 GMT Subject: [jdk24] RFR: 8346739: jpackage tests failed after JDK-8345259 In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 15:08:31 GMT, Severin Gehwolf wrote: > Clean backport of a test follow-up for #22849 targeting JDK 24. Please review! Thanks in advance. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22972#issuecomment-2578544126 From sgehwolf at openjdk.org Wed Jan 8 20:29:33 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 8 Jan 2025 20:29:33 GMT Subject: RFR: 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image [v8] In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 20:23:32 GMT, Severin Gehwolf wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix regression failed to setup helper methods properly > > Typo > @jerboaa , @liach Thanks for reviewing, is there anything else you would like to add? Good from my point of view. The only comment I have is to check the warning in https://github.com/openjdk/jdk/pull/21022#issue-2529094545 and possibly change the fix version to JDK 25 before integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21022#issuecomment-2578555335 From hannesw at openjdk.org Wed Jan 8 20:30:11 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 8 Jan 2025 20:30:11 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules Message-ID: Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. ------------- Commit messages: - 8347123: Add missing @serial tags to other modules Changes: https://git.openjdk.org/jdk/pull/22980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22980&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347123 Stats: 107 lines in 39 files changed: 45 ins; 0 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/22980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22980/head:pull/22980 PR: https://git.openjdk.org/jdk/pull/22980 From acobbs at openjdk.org Wed Jan 8 20:34:27 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 8 Jan 2025 20:34:27 GMT Subject: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the `JimageDiffGenerator` works. The original implementation is pretty naive and read all bytes into memory and then compared them. This improved version only reads bytes on a bound buffer into memory compares those bytes and if equal continues on to reading the next bytes (`2k` at most) at a time. Previously it was `2*N` (where `N` is the file size of a file in bytes) part of the JDK. Ouch. > > There is still the off-chance of reading a full file into memory when the generator detects a change, but this shouldn't happen for large files since the total diff should be around `600K` as of today. > > This also reverts changes from [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036) other than the `/timeout` change to the test, which is preserved as I think this bump is no longer needed. > > Testing: > - [x] GHA > - [x] jlink tests on a fastdebug build with `--with-native-debug-symbols=internal` (so as to have a large libjvm.so). > - [x] Manual reproducer from the bug which fails with OOM before the patch and passes after > > Thoughts? src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 134: > 132: while ((bytesRead1 = is1.read(buf1)) != -1 && > 133: (bytesRead2 = is2.read(buf2)) != -1) { > 134: if (bytesRead1 != bytesRead2) { This test seems to assume there won't be any short reads. That might be true in practice, but for defensive programming reasons it would be safer to use `readNBytes()` instead of `read()`. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 137: > 135: return false; > 136: } > 137: if (bytesRead1 == buf1.length) { This can be simplified by using [`Arrays.equals(byte[],int,int,byte[],int,int)`](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Arrays.html#equals(byte%5B%5D,int,int,byte%5B%5D,int,int)) for both cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22835#discussion_r1907828139 PR Review Comment: https://git.openjdk.org/jdk/pull/22835#discussion_r1907830279 From liach at openjdk.org Wed Jan 8 21:36:27 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 8 Jan 2025 21:36:27 GMT Subject: RFR: 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image [v16] In-Reply-To: References: Message-ID: On Fri, 3 Jan 2025 16:55:24 GMT, Henry Jen wrote: >> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those. >> >> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created. >> >> Another is for random set, such as packages, thus we put those request into a queue to amend the class later. >> >> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time. >> >> So we make this build in advance, and use a static array for values referred more than once. >> >> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Clean up I think the usages of ClassFile API looks good in the last review. And for the skara warning, you can simply clear the fix versions in the JBS issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21022#issuecomment-2578704734 From acobbs at openjdk.org Wed Jan 8 21:36:29 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 8 Jan 2025 21:36:29 GMT Subject: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator In-Reply-To: References: Message-ID: <4kOcByLRHOjjAihMzrwyog5GiAa32V8NVNmw41mkshA=.b50ad3c5-9525-49c2-8f1a-1a6ffd5290fe@github.com> On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the `JimageDiffGenerator` works. The original implementation is pretty naive and read all bytes into memory and then compared them. This improved version only reads bytes on a bound buffer into memory compares those bytes and if equal continues on to reading the next bytes (`2k` at most) at a time. Previously it was `2*N` (where `N` is the file size of a file in bytes) part of the JDK. Ouch. > > There is still the off-chance of reading a full file into memory when the generator detects a change, but this shouldn't happen for large files since the total diff should be around `600K` as of today. > > This also reverts changes from [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036) other than the `/timeout` change to the test, which is preserved as I think this bump is no longer needed. > > Testing: > - [x] GHA > - [x] jlink tests on a fastdebug build with `--with-native-debug-symbols=internal` (so as to have a large libjvm.so). > - [x] Manual reproducer from the bug which fails with OOM before the patch and passes after > > Thoughts? Sorry, I didn't realize this PR was already closed. You can treat my comments as "FYI". ------------- PR Comment: https://git.openjdk.org/jdk/pull/22835#issuecomment-2578704167 From asemenyuk at openjdk.org Wed Jan 8 22:16:11 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 22:16:11 GMT Subject: [jdk24] RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails Message-ID: Clean backport to jdk24 ------------- Commit messages: - Backport 4d18e5a1e26e04beb550d01ba5a3dbb8c0c37fa0 Changes: https://git.openjdk.org/jdk/pull/22982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22982&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346872 Stats: 25 lines in 1 file changed: 24 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22982/head:pull/22982 PR: https://git.openjdk.org/jdk/pull/22982 From asemenyuk at openjdk.org Wed Jan 8 22:16:11 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 22:16:11 GMT Subject: [jdk24] RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: References: Message-ID: <-_dUBw2pKsVVRQDTuY4zIQyKkYDc680-WxLUHFhz-Ao=.43e30a0f-adcc-4c87-b2d0-011c547b4a52@github.com> On Wed, 8 Jan 2025 22:09:29 GMT, Alexey Semenyuk wrote: > Clean backport to jdk24 @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/22982#issuecomment-2578773249 From dholmes at openjdk.org Wed Jan 8 22:16:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Jan 2025 22:16:49 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: <66NC-smYThiCbhz0NF3Q-2MkeyQze5NB0mBqG3_holM=.c1afabd3-ca94-446c-9363-777e5512281f@github.com> On Wed, 8 Jan 2025 06:52:10 GMT, Adam Sotona wrote: > BTW: purpose of this PR is to seamlessly remove ASM from java.base and it is slightly turning into a massive synchronous refactoring of several hundreds of hotspot tests. Moving the ASM library requires modifying every single test that uses it. If you also change the package structure then you also need to modify the import statements in those tests, so that is more work. Personally I think continuing to use `jdk.internal` is just wrong (in principle) and I'm surprised it is being allowed. But I'm prepared to address that change as a follow up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2578774743 From almatvee at openjdk.org Wed Jan 8 22:31:40 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 8 Jan 2025 22:31:40 GMT Subject: [jdk24] RFR: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 22:09:29 GMT, Alexey Semenyuk wrote: > Clean backport to jdk24 Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22982#pullrequestreview-2538406774 From asemenyuk at openjdk.org Wed Jan 8 22:34:47 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 22:34:47 GMT Subject: RFR: 8347300: Don't exclude the "PATH" var from the environment when running app launchers in jpackage tests Message-ID: - Don't remove the `PATH` variable from the environment when running app launchers in jpackage tests; - Replace `Executor.setRemovePathEnvVar()` with `Executor.removeEnvVar()` to support removal of any variable from the environment of a child process executed in jpackage tests; - Add support of a new boolean property `jpackage.test.clear-app-launcher-java-env-vars` in jpackage tests. If it is set to "true", the `JAVA_TOOL_OPTIONS` and `_JAVA_OPTIONS` variables will be removed from the environment of app launchers executed in jpackage tests. It is handy in local testing using jpackage test runner instead of the jtreg. The first change is unrelated to other changes. They are bundled together as they apply to the same source code. ------------- Commit messages: - - Don't exclude the "PATH" var from the environment when running app launchers in jpackage tests. Removal of the "PATH" var was a part of the JDK-8254920 fix. But this removal is redundant as JDK-8254920 was fixed by making jpackage app launcher not to look up for dll-s in the PATH. There are a few jpackage tests running app launchers without removing the PATH var from the environment - WinChildProcessTest, AppLauncherEnvTest. They proves that removal of the "PATH" var from the environment when testing app launchers is redundant. Changes: https://git.openjdk.org/jdk/pull/22983/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22983&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347300 Stats: 34 lines in 4 files changed: 19 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/22983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22983/head:pull/22983 PR: https://git.openjdk.org/jdk/pull/22983 From henryjen at openjdk.org Wed Jan 8 23:23:41 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 8 Jan 2025 23:23:41 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v3] In-Reply-To: References: Message-ID: <7S1U_KWA9SnzGwLbS6U4CLPky_uJ3ZdC2AffhtU_3M0=.9e12daa4-5176-405f-bcab-2db08d29f105@github.com> On Thu, 2 Jan 2025 18:43:35 GMT, Henry Jen wrote: >> I would expect the next token would be parsed as the value. I suggest to explore that and see how complex it would be. >> >> It seems awkward if the following are accepted: >> >> --add-options "--add-modules jdk.incubator.concurrent" >> --add-options=--add-modules=jdk.incubator.concurrent >> >> >> but not this: >> >> --add-options "--add-modules=jdk.incubator.concurrent" > > I agree it's a little bit awkward, unfortunately we cannot look at the quotation as that had been decoded by shell. > > Just take next token as value would be simpler, see the origin PR from @YaSuenag at https://github.com/openjdk/jdk/pull/19987. > > The other alternative would be that, we can check next token against known options of jlink, and treat it as value without match. That would limited the potential ambiguous conflicts but would be even more mysterious to user? After the update, = must be used if value is prefixed with `--`. `--add-options=--add-modules=jdk.incubator.concurrent` will work and `--add-options="--add-modules=jdk.incubator.concurrent --module-path xx"` will work, but not -add-options "--add-modules=jdk.incubator.concurrent --module-path xx"`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22526#discussion_r1907969495 From asemenyuk at openjdk.org Wed Jan 8 23:29:22 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:29:22 GMT Subject: RFR: 8347300: Don't exclude the "PATH" var from the environment when running app launchers in jpackage tests [v2] In-Reply-To: References: Message-ID: > - Don't remove the `PATH` variable from the environment when running app launchers in jpackage tests; > - Fix tests that use `Executor` rather than `HelloApp` class to run app launchers: apply the same changes to the environment as would be applied by `HelloApp` class. > - Replace `Executor.setRemovePathEnvVar()` with `Executor.removeEnvVar()` to support removal of any variable from the environment of a child process executed in jpackage tests; > - Add support of a new boolean property `jpackage.test.clear-app-launcher-java-env-vars` in jpackage tests. If it is set to "true", the `JAVA_TOOL_OPTIONS` and `_JAVA_OPTIONS` variables will be removed from the environment of app launchers executed in jpackage tests. It is handy in local testing using jpackage test runner instead of the jtreg. > > The first and the second changes are unrelated to other changes. They are bundled together as they apply to the same source code. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Fix copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22983/files - new: https://git.openjdk.org/jdk/pull/22983/files/dce50596..a865317a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22983&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22983&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22983/head:pull/22983 PR: https://git.openjdk.org/jdk/pull/22983 From asemenyuk at openjdk.org Wed Jan 8 23:29:22 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:29:22 GMT Subject: RFR: 8347300: Don't exclude the "PATH" var from the environment when running app launchers in jpackage tests In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 22:29:04 GMT, Alexey Semenyuk wrote: > - Don't remove the `PATH` variable from the environment when running app launchers in jpackage tests; > - Fix tests that use `Executor` rather than `HelloApp` class to run app launchers: apply the same changes to the environment as would be applied by `HelloApp` class. > - Replace `Executor.setRemovePathEnvVar()` with `Executor.removeEnvVar()` to support removal of any variable from the environment of a child process executed in jpackage tests; > - Add support of a new boolean property `jpackage.test.clear-app-launcher-java-env-vars` in jpackage tests. If it is set to "true", the `JAVA_TOOL_OPTIONS` and `_JAVA_OPTIONS` variables will be removed from the environment of app launchers executed in jpackage tests. It is handy in local testing using jpackage test runner instead of the jtreg. > > The first and the second changes are unrelated to other changes. They are bundled together as they apply to the same source code. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/22983#issuecomment-2578870413 From asemenyuk at openjdk.org Wed Jan 8 23:35:48 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:35:48 GMT Subject: RFR: 8347298: Bug in JPackageCommand.ignoreFakeRuntime() Message-ID: `JPackageCommand.ignoreFakeRuntime()` method mistakenly tests if Java runtime configured for the current jpackage command is a valid Java runtime. It must test the runtime configured for jpackage tests with `jdk.jpackage.test.runtime-image` system property instead. ------------- Commit messages: - Update copyright year - Fix JPackageCommand.ignoreFakeRuntime() to test externally supplied runtime instead of the runtime configured for the current jpackage command line. Changes: https://git.openjdk.org/jdk/pull/22986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22986&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347298 Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22986.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22986/head:pull/22986 PR: https://git.openjdk.org/jdk/pull/22986 From asemenyuk at openjdk.org Wed Jan 8 23:39:48 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:39:48 GMT Subject: RFR: 8347299: Add annotations to test cases in LicenseTest Message-ID: Add missing `jdk.jpackage.test.Annotations.Test` annotations to test cases in `LicenseTest` test and update jtreg command line accordingly. ------------- Commit messages: - Copyright year updated - Add annotations to test cases in LicenseTest Changes: https://git.openjdk.org/jdk/pull/22987/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22987&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347299 Stats: 19 lines in 1 file changed: 11 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22987.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22987/head:pull/22987 PR: https://git.openjdk.org/jdk/pull/22987 From asemenyuk at openjdk.org Wed Jan 8 23:44:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:44:55 GMT Subject: RFR: 8347297: Skip the RuntimeImageSymbolicLinksTest test on Windows when it is executed outside of the jtreg Message-ID: Minor change affecting jpackage tests execution with jpackage test runner ------------- Commit messages: - Update copyright year - Skip the RuntimeImageSymbolicLinksTest test on Windows when it is executed outside of jtreg. This is shared test and applies to multiple platforms but Windows. Changes: https://git.openjdk.org/jdk/pull/22988/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22988&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347297 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22988.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22988/head:pull/22988 PR: https://git.openjdk.org/jdk/pull/22988 From asemenyuk at openjdk.org Wed Jan 8 23:44:55 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:44:55 GMT Subject: RFR: 8347297: Skip the RuntimeImageSymbolicLinksTest test on Windows when it is executed outside of the jtreg In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:39:14 GMT, Alexey Semenyuk wrote: > Minor change affecting jpackage tests execution with jpackage test runner @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/22988#issuecomment-2578887581 From asemenyuk at openjdk.org Wed Jan 8 23:46:35 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:46:35 GMT Subject: RFR: 8347298: Bug in JPackageCommand.ignoreFakeRuntime() In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:29:49 GMT, Alexey Semenyuk wrote: > `JPackageCommand.ignoreFakeRuntime()` method mistakenly tests if Java runtime configured for the current jpackage command is a valid Java runtime. > > It must test the runtime configured for jpackage tests with `jdk.jpackage.test.runtime-image` system property instead. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/22986#issuecomment-2578888360 From asemenyuk at openjdk.org Wed Jan 8 23:51:16 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:51:16 GMT Subject: RFR: 8347295: Fix WinResourceTest to make it work with WiX v4.0+ Message-ID: Look up different patterns in WiX output based on the version of the WiX. ------------- Commit messages: - Update copyright year - Fix WinResourceTest to make it work with WiX v4.0+ Changes: https://git.openjdk.org/jdk/pull/22989/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22989&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347295 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22989/head:pull/22989 PR: https://git.openjdk.org/jdk/pull/22989 From asemenyuk at openjdk.org Wed Jan 8 23:51:16 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:51:16 GMT Subject: RFR: 8347295: Fix WinResourceTest to make it work with WiX v4.0+ In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:45:53 GMT, Alexey Semenyuk wrote: > Look up different patterns in WiX output based on the version of the WiX. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/22989#issuecomment-2578892515 From asemenyuk at openjdk.org Wed Jan 8 23:57:20 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:57:20 GMT Subject: RFR: 8347296: WinInstallerUiTest fails in local test runs if the path to test work directory is longer that regular Message-ID: <8yMw-20-36KaIIftRg_oAxJxdiGRXzP1h-o0r5H4X6M=.2cae7966-368b-4f44-9f55-f05a3ffdd4cf@github.com> Make names of msi files created in test cases of WinInstallerUiTest test shorter to workaround limitations of msi.exe on file path length. Old msi file names: WinInstallerUiTestWithDirChooserLicense-1.0.msi WinInstallerUiTestWithDirChooserShortcutPrompt-1.0.msi WinInstallerUiTestWithDirChooserShortcutPromptLicense-1.0.msi WinInstallerUiTestWithShortcutPrompt-1.0.msi WinInstallerUiTestWithShortcutPromptLicense-1.0.msi New msi file names: WinInstallerUiTestWithDcL-1.0.msi WinInstallerUiTestWithDcSp-1.0.msi WinInstallerUiTestWithDcSpL-1.0.msi WinInstallerUiTestWithSp-1.0.msi WinInstallerUiTestWithSpL-1.0.msi ------------- Commit messages: - Update copyright year - Shorten names of variants of packages created by the WinInstallerUiTest test to avoid test failures when the test output directory is long enough that some paths exceed 260 characters. Changes: https://git.openjdk.org/jdk/pull/22990/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22990&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347296 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22990.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22990/head:pull/22990 PR: https://git.openjdk.org/jdk/pull/22990 From asemenyuk at openjdk.org Wed Jan 8 23:59:36 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 8 Jan 2025 23:59:36 GMT Subject: RFR: 8347296: WinInstallerUiTest fails in local test runs if the path to test work directory is longer that regular In-Reply-To: <8yMw-20-36KaIIftRg_oAxJxdiGRXzP1h-o0r5H4X6M=.2cae7966-368b-4f44-9f55-f05a3ffdd4cf@github.com> References: <8yMw-20-36KaIIftRg_oAxJxdiGRXzP1h-o0r5H4X6M=.2cae7966-368b-4f44-9f55-f05a3ffdd4cf@github.com> Message-ID: On Wed, 8 Jan 2025 23:51:55 GMT, Alexey Semenyuk wrote: > Make names of msi files created in test cases of WinInstallerUiTest test shorter to workaround limitations of msi.exe on file path length. > > Old msi file names: > WinInstallerUiTestWithDirChooserLicense-1.0.msi > WinInstallerUiTestWithDirChooserShortcutPrompt-1.0.msi > WinInstallerUiTestWithDirChooserShortcutPromptLicense-1.0.msi > WinInstallerUiTestWithShortcutPrompt-1.0.msi > WinInstallerUiTestWithShortcutPromptLicense-1.0.msi > > New msi file names: > WinInstallerUiTestWithDcL-1.0.msi > WinInstallerUiTestWithDcSp-1.0.msi > WinInstallerUiTestWithDcSpL-1.0.msi > WinInstallerUiTestWithSp-1.0.msi > WinInstallerUiTestWithSpL-1.0.msi @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/22990#issuecomment-2578905178 From lmesnik at openjdk.org Thu Jan 9 00:11:44 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 9 Jan 2025 00:11:44 GMT Subject: RFR: 8347302: Mark test tools/jimage/JImageToolTest.java as flagless Message-ID: Test test/jdk/tools/jimage/JImageToolTest.java ignore vm flags and should be marked as flagless. It is needed to don't try to run this test with virtual test thread factory. ------------- Commit messages: - 8347302 Changes: https://git.openjdk.org/jdk/pull/22992/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22992&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347302 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22992/head:pull/22992 PR: https://git.openjdk.org/jdk/pull/22992 From lmesnik at openjdk.org Thu Jan 9 00:16:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 9 Jan 2025 00:16:55 GMT Subject: RFR: 8347302: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a: Message-ID: Test runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java uses -Xbootclasspath/a: classpath (2 arguments) Such usage of options -Xbootclasspath/a: should be correctly processed by virtual thread factory support in ProcessTools. ------------- Commit messages: - 8347304: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a: Changes: https://git.openjdk.org/jdk/pull/22993/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22993&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347302 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22993.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22993/head:pull/22993 PR: https://git.openjdk.org/jdk/pull/22993 From almatvee at openjdk.org Thu Jan 9 00:28:48 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 9 Jan 2025 00:28:48 GMT Subject: RFR: 8347300: Don't exclude the "PATH" var from the environment when running app launchers in jpackage tests [v2] In-Reply-To: References: Message-ID: <03FMR3CbRyLlpPW7zV2L4l_0W7h2ki1A7J0XH7DQam4=.f021a7a9-df71-4139-90d9-32bbe93ccb98@github.com> On Wed, 8 Jan 2025 23:29:22 GMT, Alexey Semenyuk wrote: >> - Don't remove the `PATH` variable from the environment when running app launchers in jpackage tests; >> - Fix tests that use `Executor` rather than `HelloApp` class to run app launchers: apply the same changes to the environment as would be applied by `HelloApp` class. >> - Replace `Executor.setRemovePathEnvVar()` with `Executor.removeEnvVar()` to support removal of any variable from the environment of a child process executed in jpackage tests; >> - Add support of a new boolean property `jpackage.test.clear-app-launcher-java-env-vars` in jpackage tests. If it is set to "true", the `JAVA_TOOL_OPTIONS` and `_JAVA_OPTIONS` variables will be removed from the environment of app launchers executed in jpackage tests. It is handy in local testing using jpackage test runner instead of the jtreg. >> >> The first and the second changes are unrelated to other changes. They are bundled together as they apply to the same source code. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22983#pullrequestreview-2538523767 From bpb at openjdk.org Thu Jan 9 00:32:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 9 Jan 2025 00:32:54 GMT Subject: RFR: 8345368: java/io/File/createTempFile/SpecialTempFile.java fails on Windows Server 2025 Message-ID: Change the test as done in #22957 for [JDK-8346671](https://bugs.openjdk.org/browse/JDK-8346671). ------------- Commit messages: - 8345368: java/io/File/createTempFile/SpecialTempFile.java fails on Windows Server 2025 Changes: https://git.openjdk.org/jdk/pull/22994/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22994&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345368 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22994.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22994/head:pull/22994 PR: https://git.openjdk.org/jdk/pull/22994 From almatvee at openjdk.org Thu Jan 9 00:40:53 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 9 Jan 2025 00:40:53 GMT Subject: RFR: 8347298: Bug in JPackageCommand.ignoreFakeRuntime() In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:29:49 GMT, Alexey Semenyuk wrote: > `JPackageCommand.ignoreFakeRuntime()` method mistakenly tests if Java runtime configured for the current jpackage command is a valid Java runtime. > > It must test the runtime configured for jpackage tests with `jdk.jpackage.test.runtime-image` system property instead. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22986#pullrequestreview-2538552149 From almatvee at openjdk.org Thu Jan 9 00:49:35 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 9 Jan 2025 00:49:35 GMT Subject: RFR: 8347299: Add annotations to test cases in LicenseTest In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:35:10 GMT, Alexey Semenyuk wrote: > Add missing `jdk.jpackage.test.Annotations.Test` annotations to test cases in `LicenseTest` test and update jtreg command line accordingly. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22987#pullrequestreview-2538565977 From almatvee at openjdk.org Thu Jan 9 00:51:40 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 9 Jan 2025 00:51:40 GMT Subject: RFR: 8347297: Skip the RuntimeImageSymbolicLinksTest test on Windows when it is executed outside of the jtreg In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:39:14 GMT, Alexey Semenyuk wrote: > Minor change affecting jpackage tests execution with jpackage test runner Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22988#pullrequestreview-2538567325 From almatvee at openjdk.org Thu Jan 9 00:56:44 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 9 Jan 2025 00:56:44 GMT Subject: RFR: 8347296: WinInstallerUiTest fails in local test runs if the path to test work directory is longer that regular In-Reply-To: <8yMw-20-36KaIIftRg_oAxJxdiGRXzP1h-o0r5H4X6M=.2cae7966-368b-4f44-9f55-f05a3ffdd4cf@github.com> References: <8yMw-20-36KaIIftRg_oAxJxdiGRXzP1h-o0r5H4X6M=.2cae7966-368b-4f44-9f55-f05a3ffdd4cf@github.com> Message-ID: <3jhrutyegJ17bYIGsLq_6PO5-6DlRdTqhfVGuK0n5wg=.f5fa8c7f-7320-4d8b-9a23-ad75988ffe31@github.com> On Wed, 8 Jan 2025 23:51:55 GMT, Alexey Semenyuk wrote: > Make names of msi files created in test cases of WinInstallerUiTest test shorter to workaround limitations of msi.exe on file path length. > > Old msi file names: > WinInstallerUiTestWithDirChooserLicense-1.0.msi > WinInstallerUiTestWithDirChooserShortcutPrompt-1.0.msi > WinInstallerUiTestWithDirChooserShortcutPromptLicense-1.0.msi > WinInstallerUiTestWithShortcutPrompt-1.0.msi > WinInstallerUiTestWithShortcutPromptLicense-1.0.msi > > New msi file names: > WinInstallerUiTestWithDcL-1.0.msi > WinInstallerUiTestWithDcSp-1.0.msi > WinInstallerUiTestWithDcSpL-1.0.msi > WinInstallerUiTestWithSp-1.0.msi > WinInstallerUiTestWithSpL-1.0.msi Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22990#pullrequestreview-2538571115 From dholmes at openjdk.org Thu Jan 9 01:27:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Jan 2025 01:27:41 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2] In-Reply-To: <8XxtXuytxUWy-MAQbt57DYLQd_RmfpYP6dEF65vgj2A=.30a9b436-3a85-45cf-a778-05098d267dd8@github.com> References: <8XxtXuytxUWy-MAQbt57DYLQd_RmfpYP6dEF65vgj2A=.30a9b436-3a85-45cf-a778-05098d267dd8@github.com> Message-ID: On Wed, 8 Jan 2025 11:00:14 GMT, Joakim Nordstr?m wrote: >> The test is skipped for SIGUSR2 on Linux and MacOS, and Windows skips all signal testing. So I guess that leaves aix, which seems to use signals_poxis.cpp... so perhaps the SIGUSR2 test should be skipped for aix too? >> But I'll add the signals for clarity. > > Just to add to this, "aix" is explicitly skipped in the TestSigsur2.java test. So this test is never run for SIGUSR2. > > I changed the comment for the method to indicate better what it returns. Hmmm I had missed the skipping of SIGUSR2 - not sure why that is the case. But okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22806#discussion_r1908064700 From dholmes at openjdk.org Thu Jan 9 01:27:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Jan 2025 01:27:40 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 11:03:06 GMT, Joakim Nordstr?m wrote: >> Could I get a review of this fix to refine the warnings printed by `libjsig` when using the deprecated `signal()`/`sigset()` functions? >> >> Currently the libjsig library supports chaining `signal()` and `sigset()`. With these functions being deprecated, `libjsig` warns when a program calls either function when the it's LD_PRELOADed. The warning is supposed to warn that when the support for `signal()` and `sigset()` is removed, the application might stop working as expected. >> >>> VM warning: the use of signal() and sigset() for signal chaining was deprecated in version 16.0 and will be removed in a future release. Use sigaction() instead. >> >> The warning is however printed in a few cases when its unnecessary, and also fails to catch some usages where it should be printed. With this fix the warning is printed (in order as they appear in jsig.c): >> 1. when `signal()` or `sigset()` is called for a JVM-used signal, after the JVM has installed its signals >> 2. when the JVM installs its signals (using `sigaction()`), and libjsig sees that `signal()` or `sigset()` has been used for a JVM-used signal >> >> ### Changes >> * The printing is removed from `call_os_signal()`. This warning was only correct if `signal()` or `sigset()` was called for a JVM-used signal before the JVM was installed. This is now instead covered by step 1 above. >> * If the JVM was installed first, the `signal()`/`sigset()` calls were effectively translated to `sigaction()`, and the warning was _not_ printed. When the `signal()`/`sigset()` support is dropped, this behaviour will change and the warning should be printed. This is now covered by step 2. >> >> ## Testing >> - [x] Test `open/test/hotspot/jtreg/runtime/signal` has added checks for the deprecation warning, and passes with the fix >> - [x] Tier1-3 in progress > > Joakim Nordstr?m has updated the pull request incrementally with three additional commits since the last revision: > > - Merge > - Copyright year. Doc updated. Comments revised. > - Merge Okay looks good! Thanks I'll drum up a second reviewer. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22806#pullrequestreview-2538595896 From dholmes at openjdk.org Thu Jan 9 03:31:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Jan 2025 03:31:36 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v3] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 15:23:23 GMT, Chen Liang wrote: > Joe and David, can you look at this updated versioning that uses the core libraries since scheme? Yep that looks fine. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22934#issuecomment-2579111421 From asemenyuk at openjdk.org Thu Jan 9 03:35:41 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 9 Jan 2025 03:35:41 GMT Subject: Integrated: 8347296: WinInstallerUiTest fails in local test runs if the path to test work directory is longer that regular In-Reply-To: <8yMw-20-36KaIIftRg_oAxJxdiGRXzP1h-o0r5H4X6M=.2cae7966-368b-4f44-9f55-f05a3ffdd4cf@github.com> References: <8yMw-20-36KaIIftRg_oAxJxdiGRXzP1h-o0r5H4X6M=.2cae7966-368b-4f44-9f55-f05a3ffdd4cf@github.com> Message-ID: On Wed, 8 Jan 2025 23:51:55 GMT, Alexey Semenyuk wrote: > Make names of msi files created in test cases of WinInstallerUiTest test shorter to workaround limitations of msi.exe on file path length. > > Old msi file names: > WinInstallerUiTestWithDirChooserLicense-1.0.msi > WinInstallerUiTestWithDirChooserShortcutPrompt-1.0.msi > WinInstallerUiTestWithDirChooserShortcutPromptLicense-1.0.msi > WinInstallerUiTestWithShortcutPrompt-1.0.msi > WinInstallerUiTestWithShortcutPromptLicense-1.0.msi > > New msi file names: > WinInstallerUiTestWithDcL-1.0.msi > WinInstallerUiTestWithDcSp-1.0.msi > WinInstallerUiTestWithDcSpL-1.0.msi > WinInstallerUiTestWithSp-1.0.msi > WinInstallerUiTestWithSpL-1.0.msi This pull request has now been integrated. Changeset: b3e87360 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/b3e87360917fd56df8aa0a927723a561dcb840a2 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8347296: WinInstallerUiTest fails in local test runs if the path to test work directory is longer that regular Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/22990 From asemenyuk at openjdk.org Thu Jan 9 03:38:38 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 9 Jan 2025 03:38:38 GMT Subject: Integrated: 8347297: Skip the RuntimeImageSymbolicLinksTest test on Windows when it is executed outside of the jtreg In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:39:14 GMT, Alexey Semenyuk wrote: > Minor change affecting jpackage tests execution with jpackage test runner This pull request has now been integrated. Changeset: 0a35ebfd Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/0a35ebfd5709c3069fd64bb736bbbc37d392759c Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8347297: Skip the RuntimeImageSymbolicLinksTest test on Windows when it is executed outside of the jtreg Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/22988 From dholmes at openjdk.org Thu Jan 9 03:41:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Jan 2025 03:41:36 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [ ] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Copyright and @comment Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise? ------------- PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2538683215 From asemenyuk at openjdk.org Thu Jan 9 03:42:35 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 9 Jan 2025 03:42:35 GMT Subject: RFR: 8347299: Add annotations to test cases in LicenseTest In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:35:10 GMT, Alexey Semenyuk wrote: > Add missing `jdk.jpackage.test.Annotations.Test` annotations to test cases in `LicenseTest` test and update jtreg command line accordingly. Test cases executed On Windows & OSX: - Create: LicenseTest.testCommon On Linux: - Create: LicenseTest.testLinuxLicenseInUsrTree - Create: LicenseTest.testCommon - Create: LicenseTest.testLinuxLicenseInUsrTree2 - Create: LicenseTest.testLinuxLicenseInUsrTree3 - Create: LicenseTest.testLinuxLicenseInUsrTree4 - Create: LicenseTest.testCustomDebianCopyright - Create: LicenseTest.testCustomDebianCopyrightSubst All as expected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22987#issuecomment-2579120158 From asemenyuk at openjdk.org Thu Jan 9 03:45:44 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 9 Jan 2025 03:45:44 GMT Subject: Integrated: 8347299: Add annotations to test cases in LicenseTest In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:35:10 GMT, Alexey Semenyuk wrote: > Add missing `jdk.jpackage.test.Annotations.Test` annotations to test cases in `LicenseTest` test and update jtreg command line accordingly. This pull request has now been integrated. Changeset: 97dd06ce Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/97dd06ce0a5a2bbc28c3c97b201eca81196af698 Stats: 19 lines in 1 file changed: 11 ins; 6 del; 2 mod 8347299: Add annotations to test cases in LicenseTest Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/22987 From dholmes at openjdk.org Thu Jan 9 03:47:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Jan 2025 03:47:36 GMT Subject: RFR: 8347302: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a: In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:12:29 GMT, Leonid Mesnik wrote: > Test > runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java > uses > -Xbootclasspath/a: classpath > (2 arguments) > > Such usage of options -Xbootclasspath/a: should be correctly processed by virtual thread factory support in ProcessTools. @lmesnik looks like you used the wrong bugid in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22993#issuecomment-2579123994 From asemenyuk at openjdk.org Thu Jan 9 03:47:37 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 9 Jan 2025 03:47:37 GMT Subject: RFR: 8347295: Fix WinResourceTest to make it work with WiX v4.0+ In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:45:53 GMT, Alexey Semenyuk wrote: > Look up different patterns in WiX output based on the version of the WiX. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/22989#issuecomment-2579124566 From asemenyuk at openjdk.org Thu Jan 9 03:47:42 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 9 Jan 2025 03:47:42 GMT Subject: [jdk24] Integrated: 8346872: tools/jpackage/windows/WinLongPathTest.java fails In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 22:09:29 GMT, Alexey Semenyuk wrote: > Clean backport to jdk24 This pull request has now been integrated. Changeset: bf451280 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/bf45128055f6be8b99e862db54899aaa601ddce3 Stats: 25 lines in 1 file changed: 24 ins; 0 del; 1 mod 8346872: tools/jpackage/windows/WinLongPathTest.java fails Reviewed-by: almatvee Backport-of: 4d18e5a1e26e04beb550d01ba5a3dbb8c0c37fa0 ------------- PR: https://git.openjdk.org/jdk/pull/22982 From dholmes at openjdk.org Thu Jan 9 03:50:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Jan 2025 03:50:39 GMT Subject: RFR: 8347302: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a: In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:12:29 GMT, Leonid Mesnik wrote: > Test > runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java > uses > -Xbootclasspath/a: classpath > (2 arguments) > > Such usage of options -Xbootclasspath/a: should be correctly processed by virtual thread factory support in ProcessTools. `-Xbootclasspath/a:` does not accept a space between the ":" and the path! It should only be a single argument, not a double one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22993#issuecomment-2579126881 From dholmes at openjdk.org Thu Jan 9 03:54:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 9 Jan 2025 03:54:35 GMT Subject: RFR: 8347302: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a: In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:12:29 GMT, Leonid Mesnik wrote: > Test > runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java > uses > -Xbootclasspath/a: classpath > (2 arguments) > > Such usage of options -Xbootclasspath/a: should be correctly processed by virtual thread factory support in ProcessTools. Note that in the test runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java the cases with a space are expected to fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22993#issuecomment-2579129163 From sundar at openjdk.org Thu Jan 9 04:36:36 2025 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Thu, 9 Jan 2025 04:36:36 GMT Subject: RFR: 8340380: Improve source launcher's shebang script detection In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 16:16:13 GMT, Christian Stein wrote: > Please review this change that improves the launcher mode detection by reading the initial two characters from the started file for being a shebang script. It addresses the reported confusing error messages and also supports more shebang line variations. Including those line variations that omit the `--source` arguments like shown in the underlying issue description of JDK-8340380. > > Tests of tier 1..3: _in progress_ LGTM ------------- Marked as reviewed by sundar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21910#pullrequestreview-2538724188 From lmesnik at openjdk.org Thu Jan 9 05:47:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 9 Jan 2025 05:47:39 GMT Subject: Withdrawn: 8347302: Update ProcessTools.java to support virtual test factory for Xbootclasspath/a: In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:12:29 GMT, Leonid Mesnik wrote: > Test > runtime/cds/appcds/jigsaw/modulepath/OptimizeModuleHandlingTest.java > uses > -Xbootclasspath/a: classpath > (2 arguments) > > Such usage of options -Xbootclasspath/a: should be correctly processed by virtual thread factory support in ProcessTools. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22993 From alanb at openjdk.org Thu Jan 9 08:08:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Jan 2025 08:08:46 GMT Subject: RFR: 8346986: Remove ASM from java.base In-Reply-To: <66NC-smYThiCbhz0NF3Q-2MkeyQze5NB0mBqG3_holM=.c1afabd3-ca94-446c-9363-777e5512281f@github.com> References: <66NC-smYThiCbhz0NF3Q-2MkeyQze5NB0mBqG3_holM=.c1afabd3-ca94-446c-9363-777e5512281f@github.com> Message-ID: On Wed, 8 Jan 2025 22:14:21 GMT, David Holmes wrote: > Moving the ASM library requires modifying every single test that uses it. Right, as without it there will be warnings due to jtreg launching tests to export packages that aren't in java.base. There may also be a few tests that use launch child VMs with explicit options to export these packages so they will need to be hunted down. It may be that all the tests are passing, in which case this could be done in a follow-up PR, but I think better to do everything at the same time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2579392677 From asotona at openjdk.org Thu Jan 9 08:20:36 2025 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Jan 2025 08:20:36 GMT Subject: RFR: 8346986: Remove ASM from java.base [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 07:21:36 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > asm move under test/hotspot/jtreg/testlibrary The consensus seems to be more toward the all-in-one solution (move + repackage). I'll update the patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2579412022 From alanb at openjdk.org Thu Jan 9 08:29:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Jan 2025 08:29:36 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Thu, 9 Jan 2025 03:38:48 GMT, David Holmes wrote: > Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise? jtreg patches java.base to add JTRegModuleHelper so not compatible that uses that using jlink "in-process" (with ToolProvider). Maybe the `@comment` could be expanded a bit to say this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2579429178 From cstein at openjdk.org Thu Jan 9 08:38:10 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 9 Jan 2025 08:38:10 GMT Subject: RFR: 8340380: Improve source launcher's shebang script detection [v2] In-Reply-To: References: Message-ID: > Please review this change that improves the launcher mode detection by reading the initial two characters from the started file for being a shebang script. It addresses the reported confusing error messages and also supports more shebang line variations. Including those line variations that omit the `--source` arguments like shown in the underlying issue description of JDK-8340380. > > Tests of tier 1..3: _in progress_ Christian Stein has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year and extend bug id list [skip ci] - Update copyright year [skip ci] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21910/files - new: https://git.openjdk.org/jdk/pull/21910/files/5346fa8f..b4b8a8d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21910&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21910&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21910.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21910/head:pull/21910 PR: https://git.openjdk.org/jdk/pull/21910 From asotona at openjdk.org Thu Jan 9 08:40:37 2025 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 9 Jan 2025 08:40:37 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: References: Message-ID: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: removed jdk.internal package prefix from asm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22946/files - new: https://git.openjdk.org/jdk/pull/22946/files/56fc9e41..13267e26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=01-02 Stats: 3748 lines in 240 files changed: 1342 ins; 1342 del; 1064 mod Patch: https://git.openjdk.org/jdk/pull/22946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946 PR: https://git.openjdk.org/jdk/pull/22946 From alanb at openjdk.org Thu Jan 9 09:06:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Jan 2025 09:06:36 GMT Subject: RFR: 8347302: Mark test tools/jimage/JImageToolTest.java as flagless In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:05:30 GMT, Leonid Mesnik wrote: > Test > test/jdk/tools/jimage/JImageToolTest.java > ignore vm flags and should be marked as flagless. > > It is needed to don't try to run this test with virtual test thread factory. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22992#pullrequestreview-2539161950 From alanb at openjdk.org Thu Jan 9 09:11:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Jan 2025 09:11:36 GMT Subject: RFR: 8347121: Add missing @serial tags to module java.base In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:41:42 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to add missing `@serial` javadoc tags in module `java.base`. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. (For protected and public serialized fields we would have appended an empty `@serial` block tag instead with the same effect, but there are no protected/public fields in this particular sub-task.) For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > There is one special case in `java/util/UUID.java` where two private fields had plain traditional comments containing `@serial` tags instead of doc comments. Converting these comments to doc-comments is the only change in this PR that causes a change in the generated documentation, adding documentation for these two fields to the `serialized-form.html` page. I skimmed through this, including the UUID comments, and looks fine. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22978#pullrequestreview-2539183890 From cstein at openjdk.org Thu Jan 9 09:20:51 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 9 Jan 2025 09:20:51 GMT Subject: RFR: 8340380: Improve source launcher's shebang script detection [v3] In-Reply-To: References: Message-ID: > Please review this change that improves the launcher mode detection by reading the initial two characters from the started file for being a shebang script. It addresses the reported confusing error messages and also supports more shebang line variations. Including those line variations that omit the `--source` arguments like shown in the underlying issue description of JDK-8340380. > > Tests of tier 1..3: _in progress_ Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Flip initial checks to restore original behaviour Avoid regression encoded in `test/jdk/tools/launcher/SourceMode.testClassNamedJava()` assertions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21910/files - new: https://git.openjdk.org/jdk/pull/21910/files/b4b8a8d7..f0bd01d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21910&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21910&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21910.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21910/head:pull/21910 PR: https://git.openjdk.org/jdk/pull/21910 From sgehwolf at openjdk.org Thu Jan 9 09:43:40 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 09:43:40 GMT Subject: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the `JimageDiffGenerator` works. The original implementation is pretty naive and read all bytes into memory and then compared them. This improved version only reads bytes on a bound buffer into memory compares those bytes and if equal continues on to reading the next bytes (`2k` at most) at a time. Previously it was `2*N` (where `N` is the file size of a file in bytes) part of the JDK. Ouch. > > There is still the off-chance of reading a full file into memory when the generator detects a change, but this shouldn't happen for large files since the total diff should be around `600K` as of today. > > This also reverts changes from [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036) other than the `/timeout` change to the test, which is preserved as I think this bump is no longer needed. > > Testing: > - [x] GHA > - [x] jlink tests on a fastdebug build with `--with-native-debug-symbols=internal` (so as to have a large libjvm.so). > - [x] Manual reproducer from the bug which fails with OOM before the patch and passes after > > Thoughts? Thanks for the reviews. I'll follow up with those comments/fixes in a separate PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22835#issuecomment-2579597940 From sgehwolf at openjdk.org Thu Jan 9 10:06:41 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 10:06:41 GMT Subject: [jdk24] Integrated: 8346739: jpackage tests failed after JDK-8345259 In-Reply-To: References: Message-ID: <9zRmjZe0bofC7ThrUl7IwSuvyW5kPdaK_ULFtwMhdrU=.e327d28d-d9aa-4ed4-8a65-034041fc8375@github.com> On Wed, 8 Jan 2025 15:08:31 GMT, Severin Gehwolf wrote: > Clean backport of a test follow-up for #22849 targeting JDK 24. Please review! Thanks in advance. This pull request has now been integrated. Changeset: c033806b Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/c033806b8c285ebeefb62fbeec1c27a1ca60a46c Stats: 7 lines in 3 files changed: 7 ins; 0 del; 0 mod 8346739: jpackage tests failed after JDK-8345259 Reviewed-by: shade, mchung, asemenyuk Backport-of: 7ba969a576eb92446e40587fecf98e1e4aba8883 ------------- PR: https://git.openjdk.org/jdk/pull/22972 From sgehwolf at openjdk.org Thu Jan 9 10:07:57 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 10:07:57 GMT Subject: [jdk24] Integrated: 8345259: Disallow ALL-MODULE-PATH without explicit --module-path In-Reply-To: References: Message-ID: <9V98d1CZ5Cx4GXGs1_SMDkPDFttS1onavcc1f8mRvtg=.b76b824f-dffb-4d4d-8b13-c16f6c10eb41@github.com> On Fri, 20 Dec 2024 13:25:43 GMT, Severin Gehwolf wrote: > Clean backport of [JDK-8345259](https://bugs.openjdk.org/browse/JDK-8345259) to JDK 24 which has JEP 493. This pull request has now been integrated. Changeset: 7d4fa781 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/7d4fa7818b2dde1c1b504af464ced0d5db008844 Stats: 258 lines in 6 files changed: 151 ins; 44 del; 63 mod 8345259: Disallow ALL-MODULE-PATH without explicit --module-path Reviewed-by: alanb, mchung Backport-of: bcb1bdaae772c752d54939dae3a0d95892acc228 ------------- PR: https://git.openjdk.org/jdk/pull/22849 From sgehwolf at openjdk.org Thu Jan 9 10:18:35 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 10:18:35 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3] In-Reply-To: References: Message-ID: > Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. > > Testing: > - [x] GHA > - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Expand comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22969/files - new: https://git.openjdk.org/jdk/pull/22969/files/6eceb0de..77dc9376 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22969&range=01-02 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22969.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22969/head:pull/22969 PR: https://git.openjdk.org/jdk/pull/22969 From sgehwolf at openjdk.org Thu Jan 9 10:18:37 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 10:18:37 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [x] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Copyright and @comment I've updated the `@comment` to explain this better. Is it clearer now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2579692209 From vklang at openjdk.org Thu Jan 9 10:18:50 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Jan 2025 10:18:50 GMT Subject: RFR: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing Message-ID: The following patch updates Gatherers.mapConcurrent to limit work-in-progress (on-going and completed-unpushed) to the `maxConcurrency` so that head-of-line blocking does not cause completed-unpushed work to grow unbounded. This also simplifies interruption handling to ignore-and-restore, which needs to be done on a per-element-basis as the calling thread can change between invocations of the integrator, as well as the finisher, so restoring it on finish is not possible (and won't happen if there's an exception thrown during integration anyway). Furthermore, logic has been added to reduce the risk of any spawned virtual threads surviving the processing of the stream. ------------- Commit messages: - 8347274 - Hardens the implementation of Gatherers.mapConcurrent Changes: https://git.openjdk.org/jdk/pull/22999/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22999&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347274 Stats: 144 lines in 2 files changed: 91 ins; 16 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/22999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22999/head:pull/22999 PR: https://git.openjdk.org/jdk/pull/22999 From shade at openjdk.org Thu Jan 9 10:20:38 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 9 Jan 2025 10:20:38 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [x] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Expand comment Looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2539455608 From shade at openjdk.org Thu Jan 9 10:31:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 9 Jan 2025 10:31:56 GMT Subject: RFR: 8347302: Mark test tools/jimage/JImageToolTest.java as flagless In-Reply-To: References: Message-ID: <9esxUhuIDY5hk5HmeY8OvNrXqDA8QyU56TpAFkOUkLM=.f35f2da0-94f7-4d51-a3c6-21b01c975579@github.com> On Thu, 9 Jan 2025 00:05:30 GMT, Leonid Mesnik wrote: > Test > test/jdk/tools/jimage/JImageToolTest.java > ignore vm flags and should be marked as flagless. > > It is needed to don't try to run this test with virtual test thread factory. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22992#pullrequestreview-2539497530 From kevinw at openjdk.org Thu Jan 9 10:34:43 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 9 Jan 2025 10:34:43 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2] In-Reply-To: References: Message-ID: <6oKWNLOm0TiHm-b2RMzqDW_PPwcaJCMzYgCP3BEgUK8=.aa566f44-4bad-405c-916b-5f4c668de09f@github.com> On Wed, 8 Jan 2025 11:03:06 GMT, Joakim Nordstr?m wrote: >> Could I get a review of this fix to refine the warnings printed by `libjsig` when using the deprecated `signal()`/`sigset()` functions? >> >> Currently the libjsig library supports chaining `signal()` and `sigset()`. With these functions being deprecated, `libjsig` warns when a program calls either function when the it's LD_PRELOADed. The warning is supposed to warn that when the support for `signal()` and `sigset()` is removed, the application might stop working as expected. >> >>> VM warning: the use of signal() and sigset() for signal chaining was deprecated in version 16.0 and will be removed in a future release. Use sigaction() instead. >> >> The warning is however printed in a few cases when its unnecessary, and also fails to catch some usages where it should be printed. With this fix the warning is printed (in order as they appear in jsig.c): >> 1. when `signal()` or `sigset()` is called for a JVM-used signal, after the JVM has installed its signals >> 2. when the JVM installs its signals (using `sigaction()`), and libjsig sees that `signal()` or `sigset()` has been used for a JVM-used signal >> >> ### Changes >> * The printing is removed from `call_os_signal()`. This warning was only correct if `signal()` or `sigset()` was called for a JVM-used signal before the JVM was installed. This is now instead covered by step 1 above. >> * If the JVM was installed first, the `signal()`/`sigset()` calls were effectively translated to `sigaction()`, and the warning was _not_ printed. When the `signal()`/`sigset()` support is dropped, this behaviour will change and the warning should be printed. This is now covered by step 2. >> >> ## Testing >> - [x] Test `open/test/hotspot/jtreg/runtime/signal` has added checks for the deprecation warning, and passes with the fix >> - [x] Tier1-3 in progress > > Joakim Nordstr?m has updated the pull request incrementally with three additional commits since the last revision: > > - Merge > - Copyright year. Doc updated. Comments revised. > - Merge src/java.base/unix/native/libjsig/jsig.c line 265: > 263: if (deprecated_usage[sig] == true) { > 264: print_deprecation_warning(); > 265: } Yes, took me a minute to realise this is needed because back when/if signal was called, we set deprecated_usage[sig] but only called print_deprecation_warning() if jvm_signal_installed && sigused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22806#discussion_r1908516725 From kevinw at openjdk.org Thu Jan 9 10:37:36 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 9 Jan 2025 10:37:36 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 11:03:06 GMT, Joakim Nordstr?m wrote: >> Could I get a review of this fix to refine the warnings printed by `libjsig` when using the deprecated `signal()`/`sigset()` functions? >> >> Currently the libjsig library supports chaining `signal()` and `sigset()`. With these functions being deprecated, `libjsig` warns when a program calls either function when the it's LD_PRELOADed. The warning is supposed to warn that when the support for `signal()` and `sigset()` is removed, the application might stop working as expected. >> >>> VM warning: the use of signal() and sigset() for signal chaining was deprecated in version 16.0 and will be removed in a future release. Use sigaction() instead. >> >> The warning is however printed in a few cases when its unnecessary, and also fails to catch some usages where it should be printed. With this fix the warning is printed (in order as they appear in jsig.c): >> 1. when `signal()` or `sigset()` is called for a JVM-used signal, after the JVM has installed its signals >> 2. when the JVM installs its signals (using `sigaction()`), and libjsig sees that `signal()` or `sigset()` has been used for a JVM-used signal >> >> ### Changes >> * The printing is removed from `call_os_signal()`. This warning was only correct if `signal()` or `sigset()` was called for a JVM-used signal before the JVM was installed. This is now instead covered by step 1 above. >> * If the JVM was installed first, the `signal()`/`sigset()` calls were effectively translated to `sigaction()`, and the warning was _not_ printed. When the `signal()`/`sigset()` support is dropped, this behaviour will change and the warning should be printed. This is now covered by step 2. >> >> ## Testing >> - [x] Test `open/test/hotspot/jtreg/runtime/signal` has added checks for the deprecation warning, and passes with the fix >> - [x] Tier1-3 in progress > > Joakim Nordstr?m has updated the pull request incrementally with three additional commits since the last revision: > > - Merge > - Copyright year. Doc updated. Comments revised. > - Merge Looks good. Memories of libjsig.so saving the day. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22806#pullrequestreview-2539519256 From jkern at openjdk.org Thu Jan 9 10:40:49 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 9 Jan 2025 10:40:49 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" Message-ID: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. We can see an exception like: java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] at org.testng.Assert.fail(Assert.java:99) at InfoTest.test1(InfoTest.java:110) After a discussion with Roger Riggs and the team, we came to the following conclusion. The problem is based on 2 independent causes; one fundamental and one AIX-specific. The fundamental cause is as follows: Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. Therefore, such a test makes little sense in principle. The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long intervals. For example, the cpu time is only updated every 1-2 seconds, which can cause the error. The better solution here would be the getprocs64() API. Here the values ??for the cpu time are updated by the OS kernel every few ms. It may therefore be that the error no longer occurs after adjusting the AIX coding, but in principle the problem is not solved. ------------- Commit messages: - JDK-8346880 Changes: https://git.openjdk.org/jdk/pull/22966/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22966&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346880 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22966.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22966/head:pull/22966 PR: https://git.openjdk.org/jdk/pull/22966 From mbaesken at openjdk.org Thu Jan 9 10:40:49 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 9 Jan 2025 10:40:49 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" In-Reply-To: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Wed, 8 Jan 2025 11:53:43 GMT, Joachim Kern wrote: > The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. > > We can see an exception like: > > java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] > at org.testng.Assert.fail(Assert.java:99) > at InfoTest.test1(InfoTest.java:110) > > After a discussion with Roger Riggs and the team, we came to the following conclusion. > The problem is based on 2 independent causes; one fundamental and one AIX-specific. > > The fundamental cause is as follows: > Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. > The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. > > It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). > > If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. > > However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. > > Therefore, such a test makes little sense in principle. > > The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long intervals. For example, the cpu time is only up... Marked as reviewed by mbaesken (Reviewer). > The /proc//psinfo file is evaluated to obtain the cpu time Do you mean` /proc//psinfo` ? Looks reasonable to me. One question, do we still need unix_getParentPidAndTimings ? Seems we called it only from ProcessHandleImpl_aix.c , see a grep on the old codebase before your change java.base/aix/native/libjava/ProcessHandleImpl_aix.c:165: return unix_getParentPidAndTimings(env, pid, total, start); java.base/unix/native/libjava/ProcessHandleImpl_unix.c:98: * implementations simply call back to unix_getParentPidAndTimings() and java.base/unix/native/libjava/ProcessHandleImpl_unix.c:641:pid_t unix_getParentPidAndTimings(JNIEnv *env, pid_t pid, java.base/unix/native/libjava/ProcessHandleImpl_unix.h:59:extern pid_t unix_getParentPidAndTimings(JNIEnv *env, pid_t pid, I created https://bugs.openjdk.org/browse/JDK-8347270 8347270: Remove unix_getParentPidAndTimings after JDK-8346880 ------------- PR Review: https://git.openjdk.org/jdk/pull/22966#pullrequestreview-2537265677 PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2577541379 PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2577552957 PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2577776743 From mdoerr at openjdk.org Thu Jan 9 10:40:50 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 9 Jan 2025 10:40:50 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" In-Reply-To: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Wed, 8 Jan 2025 11:53:43 GMT, Joachim Kern wrote: > The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. > > We can see an exception like: > > java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] > at org.testng.Assert.fail(Assert.java:99) > at InfoTest.test1(InfoTest.java:110) > > After a discussion with Roger Riggs and the team, we came to the following conclusion. > The problem is based on 2 independent causes; one fundamental and one AIX-specific. > > The fundamental cause is as follows: > Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. > The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. > > It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). > > If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. > > However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. > > Therefore, such a test makes little sense in principle. > > The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long intervals. For example, the cpu time is only up... Looks basically good to me. Thanks for improving it. I have minor questions and remarks. I'd be fine with removing the dead code with this PR, too. Your choice. I think we should use src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 167: > 165: pid_t the_pid = pid; > 166: struct procentry64 ProcessBuffer; > 167: struct fdsinfo64 FileDescBuffer; How is `FileDescBuffer` used? I can only see its size used. Wouldn't using `sizeof(fdsinfo64)` below be better? src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 169: > 167: struct fdsinfo64 FileDescBuffer; > 168: > 169: if (getprocs64(&ProcessBuffer, sizeof(ProcessBuffer), NULL, sizeof(FileDescBuffer), &the_pid, 1 ) <= 0) { Extra whitespace before `)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/22966#pullrequestreview-2539498869 PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2579776128 PR Review Comment: https://git.openjdk.org/jdk/pull/22966#discussion_r1908513238 PR Review Comment: https://git.openjdk.org/jdk/pull/22966#discussion_r1908514055 From jkern at openjdk.org Thu Jan 9 10:40:51 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 9 Jan 2025 10:40:51 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Wed, 8 Jan 2025 12:21:21 GMT, Matthias Baesken wrote: > > The /proc//psinfo file is evaluated to obtain the cpu time > > Do you mean` /proc//psinfo` ? Strange, the < pid > is there, but not displayed, maybe interpreted as special characters. I let the string interpreted as code. This helps. > Looks reasonable to me. One question, do we still need unix_getParentPidAndTimings ? Seems we called it only from ProcessHandleImpl_aix.c , see a grep on the old codebase before your change > > ``` > java.base/aix/native/libjava/ProcessHandleImpl_aix.c:165: return unix_getParentPidAndTimings(env, pid, total, start); > java.base/unix/native/libjava/ProcessHandleImpl_unix.c:98: * implementations simply call back to unix_getParentPidAndTimings() and > java.base/unix/native/libjava/ProcessHandleImpl_unix.c:641:pid_t unix_getParentPidAndTimings(JNIEnv *env, pid_t pid, > java.base/unix/native/libjava/ProcessHandleImpl_unix.h:59:extern pid_t unix_getParentPidAndTimings(JNIEnv *env, pid_t pid, > ``` Seems, that we were the only remainding users of unix_getParentPidAndTimings(). Should I remove the orphant? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2577559292 PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2577593048 From mbaesken at openjdk.org Thu Jan 9 10:40:51 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 9 Jan 2025 10:40:51 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Wed, 8 Jan 2025 12:47:58 GMT, Joachim Kern wrote: > Seems, that we were the only remainding users of unix_getParentPidAndTimings(). Should I remove the orphant? I would be in favor of removing it (in this PR or separate). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2577701627 From jkern at openjdk.org Thu Jan 9 10:40:52 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 9 Jan 2025 10:40:52 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Wed, 8 Jan 2025 13:41:52 GMT, Matthias Baesken wrote: > > Seems, that we were the only remainding users of unix_getParentPidAndTimings(). Should I remove the orphant? > > I would be in favor of removing it (in this PR or separate). OK agree, but in a separate PR. Could you please create a JBS bug? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2577723231 From clanger at openjdk.org Thu Jan 9 10:40:52 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 9 Jan 2025 10:40:52 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Wed, 8 Jan 2025 13:51:53 GMT, Joachim Kern wrote: > > > Seems, that we were the only remainding users of unix_getParentPidAndTimings(). Should I remove the orphant? > > > > > > I would be in favor of removing it (in this PR or separate). > > OK agree, but in a separate PR. Could you please create a JBS bug? There is a comment indicating that both, unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo were use for a common implementation of Solaris and AIX: https://github.com/openjdk/jdk/blob/672c413c61d9b155020a0fd4bd1c2bc0661a60fb/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c#L94 So now, after Solaris was deprecated and removed, I think it's time to clean this up and move to AIX specific os_* implementations. From my POV you could do it in this PR as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2577771469 From clanger at openjdk.org Thu Jan 9 10:40:53 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 9 Jan 2025 10:40:53 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Wed, 8 Jan 2025 14:14:29 GMT, Matthias Baesken wrote: > I created https://bugs.openjdk.org/browse/JDK-8347270 8347270: Remove unix_getParentPidAndTimings after JDK-8346880 I massaged the bug a little bit. But I still think this could all be done in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2578095891 From galder at openjdk.org Thu Jan 9 10:43:15 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Thu, 9 Jan 2025 10:43:15 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v7] In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: <1NAcKoms9A361Do3Vi6f4xT_euhDNTrotPWMskOsi70=.ca927892-1d5b-4a0d-b07a-f4f987f824a7@github.com> > This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. > > Currently vectorization does not kick in for loops containing either of these calls because of the following error: > > > VLoop::check_preconditions: failed: control flow in loop not allowed > > > The control flow is due to the java implementation for these methods, e.g. > > > public static long max(long a, long b) { > return (a >= b) ? a : b; > } > > > This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. > By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. > E.g. > > > SuperWord::transform_loop: > Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined > 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) > > > Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1155 > long max 1173 > > > After the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1042 > long max 1042 > > > This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. > Therefore, it still relies on the macro expansion to transform those into CMoveL. > > I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 2500 2500 0 0 >>> jtreg:test/jdk:tier1 ... Galder Zamarre?o has updated the pull request incrementally with two additional commits since the last revision: - Fix license header - Tests should also run on aarch64 asimd=true envs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20098/files - new: https://git.openjdk.org/jdk/pull/20098/files/130b4755..fb0f731f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=05-06 Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/20098.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098 PR: https://git.openjdk.org/jdk/pull/20098 From rgiulietti at openjdk.org Thu Jan 9 10:55:16 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 9 Jan 2025 10:55:16 GMT Subject: RFR: 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal [v5] In-Reply-To: References: Message-ID: > See the JBS bug for some details. Raffaello Giulietti 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 seven additional commits since the last revision: - Merge branch 'master' into 8343829 - Redacted comments. - Merge branch 'master' into 8343829 - Minors in comments. - Removed repeated comment. - Refactoring some code and comments. - 8343829: Unify decimal and hexadecimal parsing in FloatingDecimal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22737/files - new: https://git.openjdk.org/jdk/pull/22737/files/cb7bb259..092755b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22737&range=03-04 Stats: 33016 lines in 808 files changed: 16959 ins; 12980 del; 3077 mod Patch: https://git.openjdk.org/jdk/pull/22737.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22737/head:pull/22737 PR: https://git.openjdk.org/jdk/pull/22737 From pminborg at openjdk.org Thu Jan 9 11:13:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Jan 2025 11:13:03 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API [v2] In-Reply-To: References: Message-ID: <6G1TPv7xy9-amKd00rQDJhzCBo0gXdZbX4waU0oAAMc=.b715a6ed-d35d-4070-ac2c-4542be59018c@github.com> > This PR proposes to clean up all the imports in the FFM lib (excluding tests). > > Passes tier1-tier3 Per Minborg 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: - Update copyright year and reformat - Merge branch 'master' into fix-imports - Fix imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22827/files - new: https://git.openjdk.org/jdk/pull/22827/files/490701e9..f58f3385 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22827&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22827&range=00-01 Stats: 21305 lines in 430 files changed: 8799 ins; 10905 del; 1601 mod Patch: https://git.openjdk.org/jdk/pull/22827.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22827/head:pull/22827 PR: https://git.openjdk.org/jdk/pull/22827 From galder at openjdk.org Thu Jan 9 11:28:40 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Thu, 9 Jan 2025 11:28:40 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v6] In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> <9uGYNmVdvCXvyYSOAfwmvD70nWkimOFIlQJolQWa_Z4=.c6ffbfa0-5eb1-40a4-83a4-b657f57c9836@github.com> Message-ID: On Fri, 3 Jan 2025 08:48:37 GMT, Emanuel Peter wrote: >> That's right. Neoverse V2 is 4 pipes of 128 bits, V1 is 2 pipes of 256 bits. >> That comment is "interesting". Maybe it should be tunable by the back end. Given that Neoverse V2 can issue 4 SVE operations per clock cycle, it might still be a win. >> >> Galder, how about you disable that line and give it another try? > > FYI: I'm working on removing the line [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566). > > The issue is that on some platforms 2-element vectors are somehow really slower, and we need a cost-model to give us a better heuristic, rather than the hard "no". See my draft https://github.com/openjdk/jdk/pull/20964. > > But yes: why don't you remove the line, and see if that makes it work. If so, then don't worry about this case for now, and maybe leave a comment in the test. We can then fix that later. Yeah, this limit limits reductions like this working on 128 bit registers: // Length 2 reductions of INT/LONG do not offer performance benefits if (((arith_type->basic_type() == T_INT) || (arith_type->basic_type() == T_LONG)) && (size == 2)) { retValue = false; I've tried today to remove that but then the profitable checks fail to pass. So, I'm not going down that route now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1908608309 From jkern at openjdk.org Thu Jan 9 11:37:17 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 9 Jan 2025 11:37:17 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" [v2] In-Reply-To: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: > The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. > > We can see an exception like: > > java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] > at org.testng.Assert.fail(Assert.java:99) > at InfoTest.test1(InfoTest.java:110) > > After a discussion with Roger Riggs and the team, we came to the following conclusion. > The problem is based on 2 independent causes; one fundamental and one AIX-specific. > > The fundamental cause is as follows: > Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. > The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. > > It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). > > If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. > > However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. > > Therefore, such a test makes little sense in principle. > > The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long intervals. For example, the cpu time is only up... Joachim Kern has updated the pull request incrementally with two additional commits since the last revision: - remove extra white space - omit unused variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22966/files - new: https://git.openjdk.org/jdk/pull/22966/files/1a5a1951..29007e66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22966&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22966&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22966.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22966/head:pull/22966 PR: https://git.openjdk.org/jdk/pull/22966 From jkern at openjdk.org Thu Jan 9 11:37:17 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 9 Jan 2025 11:37:17 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" [v2] In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Thu, 9 Jan 2025 10:29:32 GMT, Martin Doerr wrote: >> Joachim Kern has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove extra white space >> - omit unused variable > > src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 167: > >> 165: pid_t the_pid = pid; >> 166: struct procentry64 ProcessBuffer; >> 167: struct fdsinfo64 FileDescBuffer; > > How is `FileDescBuffer` used? I can only see its size used. Wouldn't using `sizeof(fdsinfo64)` below be better? I removed `FileDescBuffer` and replaced `sizeof(FileDescBuffer)` by `sizeof(struct fdsinfo64)`. `sizeof(fdsinfo64)` produces syntax errors > src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c line 169: > >> 167: struct fdsinfo64 FileDescBuffer; >> 168: >> 169: if (getprocs64(&ProcessBuffer, sizeof(ProcessBuffer), NULL, sizeof(FileDescBuffer), &the_pid, 1 ) <= 0) { > > Extra whitespace before `)`. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22966#discussion_r1908617187 PR Review Comment: https://git.openjdk.org/jdk/pull/22966#discussion_r1908620205 From pminborg at openjdk.org Thu Jan 9 11:47:15 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 9 Jan 2025 11:47:15 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API [v3] In-Reply-To: References: Message-ID: > This PR proposes to clean up all the imports in the FFM lib (excluding tests). > > Passes tier1-tier3 Per Minborg 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: - Merge branch 'master' into fix-imports - Update copyright year and reformat - Merge branch 'master' into fix-imports - Fix imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22827/files - new: https://git.openjdk.org/jdk/pull/22827/files/f58f3385..d5e1132a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22827&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22827&range=01-02 Stats: 515 lines in 24 files changed: 98 ins; 18 del; 399 mod Patch: https://git.openjdk.org/jdk/pull/22827.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22827/head:pull/22827 PR: https://git.openjdk.org/jdk/pull/22827 From galder at openjdk.org Thu Jan 9 11:47:58 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Thu, 9 Jan 2025 11:47:58 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v8] In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: > This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. > > Currently vectorization does not kick in for loops containing either of these calls because of the following error: > > > VLoop::check_preconditions: failed: control flow in loop not allowed > > > The control flow is due to the java implementation for these methods, e.g. > > > public static long max(long a, long b) { > return (a >= b) ? a : b; > } > > > This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. > By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. > E.g. > > > SuperWord::transform_loop: > Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined > 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) > > > Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1155 > long max 1173 > > > After the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1042 > long max 1042 > > > This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. > Therefore, it still relies on the macro expansion to transform those into CMoveL. > > I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 2500 2500 0 0 >>> jtreg:test/jdk:tier1 ... Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: Test can only run with 256 bit registers or bigger * Remove platform dependant check and use platform independent configuration instead. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20098/files - new: https://git.openjdk.org/jdk/pull/20098/files/fb0f731f..c0491987 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=06-07 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20098.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098 PR: https://git.openjdk.org/jdk/pull/20098 From hannesw at openjdk.org Thu Jan 9 11:51:40 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 9 Jan 2025 11:51:40 GMT Subject: Integrated: 8347121: Add missing @serial tags to module java.base In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 19:41:42 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to add missing `@serial` javadoc tags in module `java.base`. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. (For protected and public serialized fields we would have appended an empty `@serial` block tag instead with the same effect, but there are no protected/public fields in this particular sub-task.) For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > There is one special case in `java/util/UUID.java` where two private fields had plain traditional comments containing `@serial` tags instead of doc comments. Converting these comments to doc-comments is the only change in this PR that causes a change in the generated documentation, adding documentation for these two fields to the `serialized-form.html` page. This pull request has now been integrated. Changeset: ceae2b97 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/ceae2b977dac58a9b2c09e42cb256c94eff9222b Stats: 305 lines in 89 files changed: 83 ins; 4 del; 218 mod 8347121: Add missing @serial tags to module java.base Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/22978 From galder at openjdk.org Thu Jan 9 12:06:41 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Thu, 9 Jan 2025 12:06:41 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Wed, 18 Dec 2024 06:22:56 GMT, Emanuel Peter wrote: >> @eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further. >> >> @jaskarth FYI I've adjusted the expectations in `TestMinMaxIdentities` after this change (thx for adding the test!). Check if there's any comments/changes you'd like. > > @galderz Nice, thanks for the updates. I gave the patch a quick scan and I think it looks really good. Just ping me again when you are done with your aarch64 investigations, and you think I should review again :) @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2579989885 From mdoerr at openjdk.org Thu Jan 9 12:09:36 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 9 Jan 2025 12:09:36 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" [v2] In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Thu, 9 Jan 2025 11:37:17 GMT, Joachim Kern wrote: >> The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. >> >> We can see an exception like: >> >> java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] >> at org.testng.Assert.fail(Assert.java:99) >> at InfoTest.test1(InfoTest.java:110) >> >> After a discussion with Roger Riggs and the team, we came to the following conclusion. >> The problem is based on 2 independent causes; one fundamental and one AIX-specific. >> >> The fundamental cause is as follows: >> Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. >> The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. >> >> It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). >> >> If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. >> >> However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. >> >> Therefore, such a test makes little sense in principle. >> >> The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long... > > Joachim Kern has updated the pull request incrementally with two additional commits since the last revision: > > - remove extra white space > - omit unused variable LGTM. Thanks! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22966#pullrequestreview-2539749879 From jnordstrom at openjdk.org Thu Jan 9 12:18:37 2025 From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=) Date: Thu, 9 Jan 2025 12:18:37 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 01:25:09 GMT, David Holmes wrote: >> Joakim Nordstr?m has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge >> - Copyright year. Doc updated. Comments revised. >> - Merge > > Okay looks good! Thanks > > I'll drum up a second reviewer. Thanks for review @dholmes-ora and @kevinjwalls ! Could either one of you please also sponsor this? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22806#issuecomment-2580011847 From duke at openjdk.org Thu Jan 9 12:18:38 2025 From: duke at openjdk.org (duke) Date: Thu, 9 Jan 2025 12:18:38 GMT Subject: RFR: 8345782: Refining the cases that libjsig deprecation warning is issued [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 11:03:06 GMT, Joakim Nordstr?m wrote: >> Could I get a review of this fix to refine the warnings printed by `libjsig` when using the deprecated `signal()`/`sigset()` functions? >> >> Currently the libjsig library supports chaining `signal()` and `sigset()`. With these functions being deprecated, `libjsig` warns when a program calls either function when the it's LD_PRELOADed. The warning is supposed to warn that when the support for `signal()` and `sigset()` is removed, the application might stop working as expected. >> >>> VM warning: the use of signal() and sigset() for signal chaining was deprecated in version 16.0 and will be removed in a future release. Use sigaction() instead. >> >> The warning is however printed in a few cases when its unnecessary, and also fails to catch some usages where it should be printed. With this fix the warning is printed (in order as they appear in jsig.c): >> 1. when `signal()` or `sigset()` is called for a JVM-used signal, after the JVM has installed its signals >> 2. when the JVM installs its signals (using `sigaction()`), and libjsig sees that `signal()` or `sigset()` has been used for a JVM-used signal >> >> ### Changes >> * The printing is removed from `call_os_signal()`. This warning was only correct if `signal()` or `sigset()` was called for a JVM-used signal before the JVM was installed. This is now instead covered by step 1 above. >> * If the JVM was installed first, the `signal()`/`sigset()` calls were effectively translated to `sigaction()`, and the warning was _not_ printed. When the `signal()`/`sigset()` support is dropped, this behaviour will change and the warning should be printed. This is now covered by step 2. >> >> ## Testing >> - [x] Test `open/test/hotspot/jtreg/runtime/signal` has added checks for the deprecation warning, and passes with the fix >> - [x] Tier1-3 in progress > > Joakim Nordstr?m has updated the pull request incrementally with three additional commits since the last revision: > > - Merge > - Copyright year. Doc updated. Comments revised. > - Merge @jaokim Your change (at version 0fd4e6f57db77c97643f539c75026ce3884b4fa8) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22806#issuecomment-2580013225 From epeter at openjdk.org Thu Jan 9 12:21:44 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 9 Jan 2025 12:21:44 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Thu, 9 Jan 2025 12:03:55 GMT, Galder Zamarre?o wrote: >> @galderz Nice, thanks for the updates. I gave the patch a quick scan and I think it looks really good. Just ping me again when you are done with your aarch64 investigations, and you think I should review again :) > > @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`) @galderz So you want me to review again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2580018680 From jnordstrom at openjdk.org Thu Jan 9 12:44:46 2025 From: jnordstrom at openjdk.org (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=) Date: Thu, 9 Jan 2025 12:44:46 GMT Subject: Integrated: 8345782: Refining the cases that libjsig deprecation warning is issued In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 09:12:55 GMT, Joakim Nordstr?m wrote: > Could I get a review of this fix to refine the warnings printed by `libjsig` when using the deprecated `signal()`/`sigset()` functions? > > Currently the libjsig library supports chaining `signal()` and `sigset()`. With these functions being deprecated, `libjsig` warns when a program calls either function when the it's LD_PRELOADed. The warning is supposed to warn that when the support for `signal()` and `sigset()` is removed, the application might stop working as expected. > >> VM warning: the use of signal() and sigset() for signal chaining was deprecated in version 16.0 and will be removed in a future release. Use sigaction() instead. > > The warning is however printed in a few cases when its unnecessary, and also fails to catch some usages where it should be printed. With this fix the warning is printed (in order as they appear in jsig.c): > 1. when `signal()` or `sigset()` is called for a JVM-used signal, after the JVM has installed its signals > 2. when the JVM installs its signals (using `sigaction()`), and libjsig sees that `signal()` or `sigset()` has been used for a JVM-used signal > > ### Changes > * The printing is removed from `call_os_signal()`. This warning was only correct if `signal()` or `sigset()` was called for a JVM-used signal before the JVM was installed. This is now instead covered by step 1 above. > * If the JVM was installed first, the `signal()`/`sigset()` calls were effectively translated to `sigaction()`, and the warning was _not_ printed. When the `signal()`/`sigset()` support is dropped, this behaviour will change and the warning should be printed. This is now covered by step 2. > > ## Testing > - [x] Test `open/test/hotspot/jtreg/runtime/signal` has added checks for the deprecation warning, and passes with the fix > - [x] Tier1-3 in progress This pull request has now been integrated. Changeset: 3024a738 Author: Joakim Nordstr?m Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/3024a7384f0a1f5177792fa78e872b3053e19f95 Stats: 88 lines in 3 files changed: 70 ins; 6 del; 12 mod 8345782: Refining the cases that libjsig deprecation warning is issued Reviewed-by: dholmes, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/22806 From clanger at openjdk.org Thu Jan 9 13:13:49 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 9 Jan 2025 13:13:49 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" [v2] In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Thu, 9 Jan 2025 11:37:17 GMT, Joachim Kern wrote: >> The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. >> >> We can see an exception like: >> >> java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] >> at org.testng.Assert.fail(Assert.java:99) >> at InfoTest.test1(InfoTest.java:110) >> >> After a discussion with Roger Riggs and the team, we came to the following conclusion. >> The problem is based on 2 independent causes; one fundamental and one AIX-specific. >> >> The fundamental cause is as follows: >> Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. >> The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. >> >> It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). >> >> If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. >> >> However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. >> >> Therefore, such a test makes little sense in principle. >> >> The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long... > > Joachim Kern has updated the pull request incrementally with two additional commits since the last revision: > > - remove extra white space > - omit unused variable Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22966#pullrequestreview-2539880841 From epeter at openjdk.org Thu Jan 9 13:28:51 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 9 Jan 2025 13:28:51 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> References: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> Message-ID: On Thu, 9 Jan 2025 13:14:13 GMT, Emanuel Peter wrote: >> Jatin Bhateja 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: >> >> Updating copyright year of modified files. > > src/hotspot/share/opto/type.cpp line 460: > >> 458: RETURN_ADDRESS=make(Return_Address); >> 459: FLOAT = make(FloatBot); // All floats >> 460: HALF_FLOAT = make(HalfFloatBot); // All half floats > > Suggestion: > > HALF_FLOAT = make(HalfFloatBot); // All half floats If alignment is already broken, we might as well just use single spaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908778435 From epeter at openjdk.org Thu Jan 9 13:28:52 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 9 Jan 2025 13:28:52 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v3] In-Reply-To: References: Message-ID: On Mon, 16 Dec 2024 18:42:48 GMT, Joe Darcy wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding more test points > > src/java.base/share/classes/jdk/internal/vm/vector/Float16Math.java line 35: > >> 33: * The class {@code Float16Math} constains intrinsic entry points corresponding >> 34: * to scalar numeric operations defined in Float16 class. >> 35: * @author > > Please remove all author tags. We haven't used them in new code in the JDK for some time. @jatin-bhateja did you remove them? I still see an `@author` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908788132 From epeter at openjdk.org Thu Jan 9 13:28:50 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 9 Jan 2025 13:28:50 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: References: Message-ID: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> On Fri, 3 Jan 2025 20:42:15 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja 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: > > Updating copyright year of modified files. We are on the final approach. Just a few small comments / suggestions left. src/hotspot/share/opto/convertnode.cpp line 991: > 989: return Op_MinHF; > 990: default: > 991: return false; Is that a sane return value? Should we not assert here? src/hotspot/share/opto/library_call.cpp line 8665: > 8663: fatal_unexpected_iid(id); > 8664: break; > 8665: } Suggestion: switch (id) { // Unary operations case vmIntrinsics::_sqrt_float16: result = _gvn.transform(new SqrtHFNode(C, control(), fld1)); break; // Ternary operations case vmIntrinsics::_fma_float16: result = _gvn.transform(new FmaHFNode(control(), fld1, fld2, fld3)); break; default: fatal_unexpected_iid(id); break; } Formatting could be improved. In the other switch you indent the cases. The lines are also a little long. src/hotspot/share/opto/mulnode.cpp line 560: > 558: // Compute the product type of two half float ranges into this node. > 559: const Type* MulHFNode::mul_ring(const Type* t0, const Type* t1) const { > 560: if(t0 == Type::HALF_FLOAT || t1 == Type::HALF_FLOAT) return Type::HALF_FLOAT; Suggestion: if(t0 == Type::HALF_FLOAT || t1 == Type::HALF_FLOAT) { return Type::HALF_FLOAT; } src/hotspot/share/opto/superword.cpp line 2567: > 2565: // half float to float, in such a case back propagation of narrow type (SHORT) > 2566: // may not be possible. > 2567: if (n->Opcode() == Op_ConvF2HF || n->Opcode() == Op_ReinterpretHF2S) { Is this relevant, or does that belong to a different (vector) RFE? src/hotspot/share/opto/type.cpp line 460: > 458: RETURN_ADDRESS=make(Return_Address); > 459: FLOAT = make(FloatBot); // All floats > 460: HALF_FLOAT = make(HalfFloatBot); // All half floats Suggestion: HALF_FLOAT = make(HalfFloatBot); // All half floats src/hotspot/share/opto/type.cpp line 1092: > 1090: if (_base == DoubleTop || _base == DoubleBot) return Type::BOTTOM; > 1091: typerr(t); > 1092: return Type::BOTTOM; Please use curly-braces even for single-line ifs src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1434: > 1432: return float16ToRawShortBits(valueOf(product + float16ToFloat(f16c))); > 1433: }); > 1434: return shortBitsToFloat16(res); I don't understand what is happening here. But I leave this to @PaulSandoz to review ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2539863536 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908759602 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908769721 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908771698 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908776380 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908777422 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908779530 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1908792237 From sgehwolf at openjdk.org Thu Jan 9 13:54:40 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 13:54:40 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2] In-Reply-To: References: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com> Message-ID: On Thu, 9 Jan 2025 03:38:48 GMT, David Holmes wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyright and @comment > > Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise? @dholmes-ora Is the latest patch any better? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2580239188 From jkern at openjdk.org Thu Jan 9 14:26:41 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 9 Jan 2025 14:26:41 GMT Subject: Integrated: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" In-Reply-To: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Wed, 8 Jan 2025 11:53:43 GMT, Joachim Kern wrote: > The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. > > We can see an exception like: > > java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] > at org.testng.Assert.fail(Assert.java:99) > at InfoTest.test1(InfoTest.java:110) > > After a discussion with Roger Riggs and the team, we came to the following conclusion. > The problem is based on 2 independent causes; one fundamental and one AIX-specific. > > The fundamental cause is as follows: > Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. > The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. > > It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). > > If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. > > However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. > > Therefore, such a test makes little sense in principle. > > The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long intervals. For example, the cpu time is only up... This pull request has now been integrated. Changeset: f9b11332 Author: Joachim Kern URL: https://git.openjdk.org/jdk/commit/f9b11332eccd8a8ffb4128308f442b209d07a3b1 Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" Reviewed-by: mdoerr, clanger, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/22966 From rriggs at openjdk.org Thu Jan 9 15:26:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Jan 2025 15:26:44 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" [v2] In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Thu, 9 Jan 2025 11:37:17 GMT, Joachim Kern wrote: >> The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. >> >> We can see an exception like: >> >> java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] >> at org.testng.Assert.fail(Assert.java:99) >> at InfoTest.test1(InfoTest.java:110) >> >> After a discussion with Roger Riggs and the team, we came to the following conclusion. >> The problem is based on 2 independent causes; one fundamental and one AIX-specific. >> >> The fundamental cause is as follows: >> Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. >> The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. >> >> It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). >> >> If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. >> >> However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. >> >> Therefore, such a test makes little sense in principle. >> >> The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long... > > Joachim Kern has updated the pull request incrementally with two additional commits since the last revision: > > - remove extra white space > - omit unused variable The usual review period for OpenJDK changes is 24 hours to allow contributors whereever and whenever they are awake a chance to review. Some allowance for shorter reviews is maee for urgent or particularly trivial changes. This PR seems to have been proposed, reviewed, and integrated in less than 4 hours. Keep that in mind for future changes. Thanks, Roger ------------- PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2580556193 From alanb at openjdk.org Thu Jan 9 15:28:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Jan 2025 15:28:42 GMT Subject: RFR: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 10:13:52 GMT, Viktor Klang wrote: > The following patch updates Gatherers.mapConcurrent to limit work-in-progress (on-going and completed-unpushed) to the `maxConcurrency` so that head-of-line blocking does not cause completed-unpushed work to grow unbounded. > > This also simplifies interruption handling to ignore-and-restore, which needs to be done on a per-element-basis as the calling thread can change between invocations of the integrator, as well as the finisher, so restoring it on finish is not possible (and won't happen if there's an exception thrown during integration anyway). > > Furthermore, logic has been added to reduce the risk of any spawned virtual threads surviving the processing of the stream. I looked at a few early iterations of this as the PR was being created so I think in a good place. src/java.base/share/classes/java/util/stream/Gatherers.java line 392: > 390: while (proceed > 391: && (current = wip.peekFirst()) != null > 392: && (current.isDone() || atLeastN > 0)) { It might be better to indent these two lines so that it's clearer what the while expression is vs. the code in the block. src/java.base/share/classes/java/util/stream/Gatherers.java line 421: > 419: if (!success && !wip.isEmpty()) { > 420: // First signal cancellation for all tasks in progress > 421: for(var task : wip) Minor formating nit is that you probably want a space in "for(", there are a few more of these in the patch. test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 322: > 320: @ParameterizedTest > 321: @MethodSource("concurrencyConfigurations") > 322: public void behavesAsExpectedWhenCallerIsInterrupted(ConcurrencyConfig cc) { It might be helpful for future maintainers to put a comment on the behaveAsExpectedXXX tests so that it's easier to figure out what they are testing. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22999#pullrequestreview-2540222162 PR Review Comment: https://git.openjdk.org/jdk/pull/22999#discussion_r1909009172 PR Review Comment: https://git.openjdk.org/jdk/pull/22999#discussion_r1909010667 PR Review Comment: https://git.openjdk.org/jdk/pull/22999#discussion_r1909013865 From vklang at openjdk.org Thu Jan 9 15:46:56 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Jan 2025 15:46:56 GMT Subject: RFR: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing [v2] In-Reply-To: References: Message-ID: > The following patch updates Gatherers.mapConcurrent to limit work-in-progress (on-going and completed-unpushed) to the `maxConcurrency` so that head-of-line blocking does not cause completed-unpushed work to grow unbounded. > > This also simplifies interruption handling to ignore-and-restore, which needs to be done on a per-element-basis as the calling thread can change between invocations of the integrator, as well as the finisher, so restoring it on finish is not possible (and won't happen if there's an exception thrown during integration anyway). > > Furthermore, logic has been added to reduce the risk of any spawned virtual threads surviving the processing of the stream. Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Addresses PR review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22999/files - new: https://git.openjdk.org/jdk/pull/22999/files/80fc614b..887350bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22999&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22999&range=00-01 Stats: 10 lines in 2 files changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/22999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22999/head:pull/22999 PR: https://git.openjdk.org/jdk/pull/22999 From vklang at openjdk.org Thu Jan 9 15:46:57 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 9 Jan 2025 15:46:57 GMT Subject: RFR: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 15:23:18 GMT, Alan Bateman wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Addresses PR review feedback > > src/java.base/share/classes/java/util/stream/Gatherers.java line 392: > >> 390: while (proceed >> 391: && (current = wip.peekFirst()) != null >> 392: && (current.isDone() || atLeastN > 0)) { > > It might be better to indent these two lines so that it's clearer what the while expression is vs. the code in the block. Fair point?I reformatted that while clause to something which is hopefully easier to read. > src/java.base/share/classes/java/util/stream/Gatherers.java line 421: > >> 419: if (!success && !wip.isEmpty()) { >> 420: // First signal cancellation for all tasks in progress >> 421: for(var task : wip) > > Minor formating nit is that you probably want a space in "for(", there are a few more of these in the patch. Fixed! > test/jdk/java/util/stream/GatherersMapConcurrentTest.java line 322: > >> 320: @ParameterizedTest >> 321: @MethodSource("concurrencyConfigurations") >> 322: public void behavesAsExpectedWhenCallerIsInterrupted(ConcurrencyConfig cc) { > > It might be helpful for future maintainers to put a comment on the behaveAsExpectedXXX tests so that it's easier to figure out what they are testing. That's fair, I decided to improve the names of the methods in the follow-on commit I just pushed ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22999#discussion_r1909049038 PR Review Comment: https://git.openjdk.org/jdk/pull/22999#discussion_r1909048037 PR Review Comment: https://git.openjdk.org/jdk/pull/22999#discussion_r1909047753 From mdoerr at openjdk.org Thu Jan 9 16:01:45 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 9 Jan 2025 16:01:45 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" [v2] In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Thu, 9 Jan 2025 11:37:17 GMT, Joachim Kern wrote: >> The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. >> >> We can see an exception like: >> >> java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] >> at org.testng.Assert.fail(Assert.java:99) >> at InfoTest.test1(InfoTest.java:110) >> >> After a discussion with Roger Riggs and the team, we came to the following conclusion. >> The problem is based on 2 independent causes; one fundamental and one AIX-specific. >> >> The fundamental cause is as follows: >> Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. >> The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. >> >> It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). >> >> If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. >> >> However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. >> >> Therefore, such a test makes little sense in principle. >> >> The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long... > > Joachim Kern has updated the pull request incrementally with two additional commits since the last revision: > > - remove extra white space > - omit unused variable I guess the problem was that the core-libs label was missing. The PR was open for more than 24 hours. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2580643211 From rriggs at openjdk.org Thu Jan 9 16:34:48 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Jan 2025 16:34:48 GMT Subject: RFR: 8346880: [aix] java/lang/ProcessHandle/InfoTest.java still fails: "reported cputime less than expected" [v2] In-Reply-To: References: <3b2It3VK0nfIZvcymT92ZmLKEGvJt16BdT2u28psNpE=.a8c0e7a8-ca5e-413f-b9bc-b4f46cdc25d0@github.com> Message-ID: On Thu, 9 Jan 2025 11:37:17 GMT, Joachim Kern wrote: >> The test java/lang/ProcessHandle/InfoTest.java still fails sporadically on AIX. The test exclusion was removed through [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847) under the assumption the problem was gone. But it turned out that it was wrong. >> >> We can see an exception like: >> >> java.lang.AssertionError: reported cputime less than expected: PT0.2S, actual: Optional[PT0.021179882S] >> at org.testng.Assert.fail(Assert.java:99) >> at InfoTest.test1(InfoTest.java:110) >> >> After a discussion with Roger Riggs and the team, we came to the following conclusion. >> The problem is based on 2 independent causes; one fundamental and one AIX-specific. >> >> The fundamental cause is as follows: >> Modern hardware provides many hardware threads (up to several hundred) that enable the worker threads of the processes to be processed in real parallel. To ensure that such a worker thread does not take up a hardware thread resource for itself, it is rolled out by the OS after a few ms at the latest to make room for another worker thread, possibly from another process. >> The OS continuously adds up all the times that each worker thread of a process is active as process cpu time. >> >> It is easy to see that there is no correlation between the CPU time of a process and the real time(wall time). >> >> If you have a system with many hardware threads and few worker threads, these are active almost all the time. If they are rolled out, they are immediately rolled back in due to a lack of competition. If a process has several worker threads, the CPU time will increase faster than the real time. In this case, cpu time > real time is to be expected, which is what the test wants. >> >> However, if the same system is heavily loaded, i.e. there are a lot of worker threads competing on one hardware thread, each individual worker thread can only become active relatively rarely. Even if a process has several worker threads, the total CPU time will be less than the past real time. This is even more pronounced if the individual worker threads have to wait for each other via synchronization objects. Since this is the normal case, cpu time < real time usually applies. >> >> Therefore, such a test makes little sense in principle. >> >> The AIX-specific cause of the problem lies in the API used to get the cpu time. The `/proc//psinfo` file is evaluated to obtain the cpu time. The /proc directory is only present on AIX for portability reasons. The data in it is only updated at long... > > Joachim Kern has updated the pull request incrementally with two additional commits since the last revision: > > - remove extra white space > - omit unused variable Thanks, It was only observable after the core-libs label was added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22966#issuecomment-2580749504 From mbaesken at openjdk.org Thu Jan 9 16:51:46 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 9 Jan 2025 16:51:46 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo Message-ID: The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. ------------- Commit messages: - JDK-8347270 Changes: https://git.openjdk.org/jdk/pull/23013/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23013&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347270 Stats: 167 lines in 3 files changed: 57 ins; 108 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23013/head:pull/23013 PR: https://git.openjdk.org/jdk/pull/23013 From jkern at openjdk.org Thu Jan 9 16:58:43 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 9 Jan 2025 16:58:43 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 16:47:18 GMT, Matthias Baesken wrote: > The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. LGTM ------------- Marked as reviewed by jkern (Committer). PR Review: https://git.openjdk.org/jdk/pull/23013#pullrequestreview-2540461156 From rriggs at openjdk.org Thu Jan 9 17:12:37 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 9 Jan 2025 17:12:37 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 16:47:18 GMT, Matthias Baesken wrote: > The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. Nice cleaup. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23013#pullrequestreview-2540490952 From sgehwolf at openjdk.org Thu Jan 9 17:35:48 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 17:35:48 GMT Subject: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the `JimageDiffGenerator` works. The original implementation is pretty naive and read all bytes into memory and then compared them. This improved version only reads bytes on a bound buffer into memory compares those bytes and if equal continues on to reading the next bytes (`2k` at most) at a time. Previously it was `2*N` (where `N` is the file size of a file in bytes) part of the JDK. Ouch. > > There is still the off-chance of reading a full file into memory when the generator detects a change, but this shouldn't happen for large files since the total diff should be around `600K` as of today. > > This also reverts changes from [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036) other than the `/timeout` change to the test, which is preserved as I think this bump is no longer needed. > > Testing: > - [x] GHA > - [x] jlink tests on a fastdebug build with `--with-native-debug-symbols=internal` (so as to have a large libjvm.so). > - [x] Manual reproducer from the bug which fails with OOM before the patch and passes after > > Thoughts? @slowhog @AlanBateman @archiecobbs Clean ups done in https://github.com/openjdk/jdk/pull/23014 PTAL. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22835#issuecomment-2580889692 From sgehwolf at openjdk.org Thu Jan 9 17:37:50 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 17:37:50 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups Message-ID: During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. Testing: - [ ] GHA - [x] tools/jlink tests (including the new one). Thoughts? ------------- Commit messages: - 8347334: JimageDiffGenerator code clean-ups Changes: https://git.openjdk.org/jdk/pull/23014/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23014&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347334 Stats: 319 lines in 2 files changed: 291 ins; 12 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/23014.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23014/head:pull/23014 PR: https://git.openjdk.org/jdk/pull/23014 From henryjen at openjdk.org Thu Jan 9 17:39:00 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 9 Jan 2025 17:39:00 GMT Subject: Integrated: 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 17:50:52 GMT, Henry Jen wrote: > This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those. > > In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created. > > Another is for random set, such as packages, thus we put those request into a queue to amend the class later. > > To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time. > > So we make this build in advance, and use a static array for values referred more than once. > > All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent. This pull request has now been integrated. Changeset: 22f70a74 Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/22f70a742abbf528340c133c4ed215b97b4a9717 Stats: 2148 lines in 5 files changed: 1380 ins; 673 del; 95 mod 8321413: IllegalArgumentException: Code length outside the allowed range while creating a jlink image Reviewed-by: mchung ------------- PR: https://git.openjdk.org/jdk/pull/21022 From acobbs at openjdk.org Thu Jan 9 17:46:38 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 9 Jan 2025 17:46:38 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 17:32:39 GMT, Severin Gehwolf wrote: > During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. > > Testing: > - [ ] GHA > - [x] tools/jlink tests (including the new one). > > Thoughts? src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 131: > 129: int bytesRead1, bytesRead2; > 130: try (is1; is2) { > 131: while ((bytesRead1 = is1.readNBytes(buf1, 0, buf1.length)) != 0) { If `in1` is exactly 1024 bytes, and `in2` is those same bytes plus one extra byte (1025 bytes), this method will return a false positive. Probably just want `while (true)` here, then read both `in1` and `in2`, then check results. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23014#discussion_r1909219888 From mullan at openjdk.org Thu Jan 9 17:52:02 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 9 Jan 2025 17:52:02 GMT Subject: RFR: 8315487: Security Providers Filter [v17] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 20:48:18 GMT, Martin Balao wrote: >> Martin Balao 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. > > Added a non-goal to the JEP to indicate that security providers must only register algorithms and use algorithm parameters for which they have been certified, without delegating their responsibility to the filter. @martinuy I suggest you remove the core-libs component from this review (using `/label remove core-libs`). It may have been added due to the shared secret changes in `jdk/internal/access`, but this is entirely a seclibs feature. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2580918500 From mchung at openjdk.org Thu Jan 9 18:07:47 2025 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 9 Jan 2025 18:07:47 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v3] In-Reply-To: <-QhN582ZLm6wkdTDRDZBdizuk7WBRtZqGBzHbB1_St8=.ac2047df-0eaf-48b5-b641-a58bb86fdf7e@github.com> References: <-QhN582ZLm6wkdTDRDZBdizuk7WBRtZqGBzHbB1_St8=.ac2047df-0eaf-48b5-b641-a58bb86fdf7e@github.com> Message-ID: On Wed, 8 Jan 2025 00:40:04 GMT, Henry Jen wrote: >> Improving option value handling to support passing argument value starts with "--". >> >> Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. >> --add-options --add-modules=jdk.incubator.concurrent >> --add-options=--add-modules=jdk.incubator.concurrent >> >> will cause JLink to report >> Error: no value given for --add-options >> as --add-modules is considered another option for JLink. >> >> After the fix, by using = will ensure the value is properly handled as argument value >> --add-options=--add-modules=jdk.incubator.concurrent > > Henry Jen 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'openjdk/master' into JDK-8303884 > - Use opt=value format when value is starting with -- > - Fix style > - add test > - 8303884: jlink --add-options plugin does not allow GNU style options to be provided I like this better. If a parameter value starts with `--`, it needs to be disambigated by using the `=` form --add-options=--add-modules=jdk.incubator.concurrent This is like passing VM options to tools like `javac` using a single `-J` option and it needs to use the `=` form as in `-J--=`. It'd be good if this is documented, maybe `jlink --list-plugins` help page? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22526#issuecomment-2580947066 From henryjen at openjdk.org Thu Jan 9 18:08:41 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 9 Jan 2025 18:08:41 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 17:32:39 GMT, Severin Gehwolf wrote: > During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. > > Testing: > - [ ] GHA > - [x] tools/jlink tests (including the new one). > > Thoughts? src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 133: > 131: while ((bytesRead1 = is1.readNBytes(buf1, 0, buf1.length)) != 0) { > 132: bytesRead2 = is2.readNBytes(buf2, 0, buf2.length); > 133: if (bytesRead2 == 0) { This is redundant to next statement. However, we do need to read and test byteRead2 is also 0 after byteRead1 is 0 and exit the loop. test/jdk/tools/jlink/runtimeImage/JimageDiffGeneratorTest.java line 1: > 1: /* Looks good to me. Nitpick: Most test cases use a common base image can be defined once? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23014#discussion_r1909225813 PR Review Comment: https://git.openjdk.org/jdk/pull/23014#discussion_r1909242794 From sgehwolf at openjdk.org Thu Jan 9 18:25:16 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 18:25:16 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: > During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. > > Testing: > - [ ] GHA > - [x] tools/jlink tests (including the new one). > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23014/files - new: https://git.openjdk.org/jdk/pull/23014/files/5b98866d..42baf977 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23014&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23014&range=00-01 Stats: 48 lines in 2 files changed: 42 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23014.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23014/head:pull/23014 PR: https://git.openjdk.org/jdk/pull/23014 From sgehwolf at openjdk.org Thu Jan 9 18:25:16 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 18:25:16 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 17:44:05 GMT, Archie Cobbs wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 131: > >> 129: int bytesRead1, bytesRead2; >> 130: try (is1; is2) { >> 131: while ((bytesRead1 = is1.readNBytes(buf1, 0, buf1.length)) != 0) { > > If `in1` is exactly 1024 bytes, and `in2` is those same bytes plus one extra byte (1025 bytes), this method will return a false positive. > > Probably just want `while (true)` here, then read both `in1` and `in2`, then check results. Good catch! Added a test for this case and fixed the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23014#discussion_r1909262927 From sgehwolf at openjdk.org Thu Jan 9 18:25:16 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 9 Jan 2025 18:25:16 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 17:49:23 GMT, Henry Jen wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 133: > >> 131: while ((bytesRead1 = is1.readNBytes(buf1, 0, buf1.length)) != 0) { >> 132: bytesRead2 = is2.readNBytes(buf2, 0, buf2.length); >> 133: if (bytesRead2 == 0) { > > This is redundant to next statement. However, we do need to read and test byteRead2 is also 0 after byteRead1 is 0 and exit the loop. OK. > test/jdk/tools/jlink/runtimeImage/JimageDiffGeneratorTest.java line 1: > >> 1: /* > > Looks good to me. Nitpick: Most test cases use a common base image can be defined once? They are slightly different each. I don't think this will make the code a lot shorter/easier to read. As it is it keeps the test cases independent as much as possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23014#discussion_r1909262375 PR Review Comment: https://git.openjdk.org/jdk/pull/23014#discussion_r1909262161 From naoto at openjdk.org Thu Jan 9 18:33:49 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Jan 2025 18:33:49 GMT Subject: RFR: 8347146: Convert IncludeLocalesPluginTest to use JUnit Message-ID: A simple refinement to the test makes diagnosing failures easier. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/23016/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23016&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347146 Stats: 423 lines in 1 file changed: 22 ins; 40 del; 361 mod Patch: https://git.openjdk.org/jdk/pull/23016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23016/head:pull/23016 PR: https://git.openjdk.org/jdk/pull/23016 From henryjen at openjdk.org Thu Jan 9 18:54:38 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 9 Jan 2025 18:54:38 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 18:25:16 GMT, Severin Gehwolf wrote: >> During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. >> >> Testing: >> - [ ] GHA >> - [x] tools/jlink tests (including the new one). >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback Marked as reviewed by henryjen (Committer). src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 135: > 133: bytesRead2 = is2.readNBytes(buf2, 0, buf2.length); > 134: if (bytesRead1 == 0 || bytesRead2 == 0) { > 135: break; // no more bytes for a stream break after test same amount of bytes can remove the test exit the while loop. ------------- PR Review: https://git.openjdk.org/jdk/pull/23014#pullrequestreview-2540700499 PR Review Comment: https://git.openjdk.org/jdk/pull/23014#discussion_r1909295648 From psandoz at openjdk.org Thu Jan 9 19:25:53 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 9 Jan 2025 19:25:53 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> References: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> Message-ID: On Thu, 9 Jan 2025 13:23:19 GMT, Emanuel Peter wrote: >> Jatin Bhateja 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: >> >> Updating copyright year of modified files. > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1434: > >> 1432: return float16ToRawShortBits(valueOf(product + float16ToFloat(f16c))); >> 1433: }); >> 1434: return shortBitsToFloat16(res); > > I don't understand what is happening here. But I leave this to @PaulSandoz to review Uncertain on what bits, but i am guessing it's mostly related to the fallback code in the lambda. To avoid the intrinsics operating on Float16 instances we instead "unpack" the carrier (16bits) values and pass those as arguments to the intrinsic. The fallback (when intrinsification is not supported) also accepts those carrier values as arguments and we convert the carriers to floats, operate on then, convert to the carrier, and then back to float16 on the result. The code in the lambda could potentially be simplified if `Float16Math.fma` accepted six arguments the first three being the carrier values used by the intrinsic, and the subsequent three being the float16 values used by the fallback. Then we could express the code in the original source in the lambda. I believe when intrinsified there would be no penalty for those extra arguments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1909327094 From acobbs at openjdk.org Thu Jan 9 19:42:37 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 9 Jan 2025 19:42:37 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 18:25:16 GMT, Severin Gehwolf wrote: >> During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. >> >> Testing: >> - [ ] GHA >> - [x] tools/jlink tests (including the new one). >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback (Getting into marginal returns on comments here, so my apologies for nitpicking) The loop could be simplified even further... while (true) { int bytesRead1 = is1.readNBytes(buf1, 0, buf1.length); int bytesRead2 = is2.readNBytes(buf2, 0, buf2.length); if (!Arrays.equals(buf1, 0, bytesRead1, buf2, 0, bytesRead2)) return false; if (bytesRead1 == 0) return true; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/23014#issuecomment-2581110477 From lancea at openjdk.org Thu Jan 9 19:43:37 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 9 Jan 2025 19:43:37 GMT Subject: RFR: 8345368: java/io/File/createTempFile/SpecialTempFile.java fails on Windows Server 2025 In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:27:15 GMT, Brian Burkhalter wrote: > Change the test as done in #22957 for [JDK-8346671](https://bugs.openjdk.org/browse/JDK-8346671). Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22994#pullrequestreview-2540788054 From cstein at openjdk.org Thu Jan 9 20:18:45 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 9 Jan 2025 20:18:45 GMT Subject: RFR: 8346778: Enable native access should work with the source launcher [v2] In-Reply-To: <9sLyfxjDPJJ9Uml93j13lDSYveieHktAba2Fm8Y5CgY=.0a9cd126-c335-4a6f-bedf-c831c41b4bf1@github.com> References: <9sLyfxjDPJJ9Uml93j13lDSYveieHktAba2Fm8Y5CgY=.0a9cd126-c335-4a6f-bedf-c831c41b4bf1@github.com> Message-ID: On Thu, 9 Jan 2025 20:06:49 GMT, Alan Bateman wrote: > Do you expect any other options that the source launcher might need to handle? Right now, there are warnings when the module or package name is not in modules in the boot layer. There other CLI options would be very advanced so assume not. I cannot think of any other useful options in addition to the ones handled in [RelevantJavacOptions.java](https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/RelevantJavacOptions.java) for the time being that should also be forwarded to source launcher module layer setup for compilation or run time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2581170181 From aturbanov at openjdk.org Thu Jan 9 20:23:37 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 9 Jan 2025 20:23:37 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> References: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> Message-ID: On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed jdk.internal package prefix from asm test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/Util.java line 135: > 133: */ > 134: public static void printClassFile(byte[] classFile) { > 135: int flags = org.objectweb.asm.ClassReader.SKIP_DEBUG; Nit. Pre-existing, buy may be worth to fix Suggestion: int flags = org.objectweb.asm.ClassReader.SKIP_DEBUG; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22946#discussion_r1909386706 From alanb at openjdk.org Thu Jan 9 20:32:37 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Jan 2025 20:32:37 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> References: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> Message-ID: <4GtzkRBR_ZsI88__nvWdUvW4GXBJKt7bmyNb0gmCOkA=.4eb2a08f-f9da-4c69-a860-64da90d80fce@github.com> On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed jdk.internal package prefix from asm Thanks for doing the right thing and reverting the package name and removing the `@modules` from the tests. I sample as many as I could and they look fine. I assume you'll bump the copyright headers of the modified tests before integrating. Can you say which tiers have been run? I'm sure David can advise but I suspect you'll need to run most of the tiers to ensure that all the modified tests are run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2581190049 From alanb at openjdk.org Thu Jan 9 20:36:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 9 Jan 2025 20:36:45 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> References: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> Message-ID: On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed jdk.internal package prefix from asm Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2540875300 From lmesnik at openjdk.org Thu Jan 9 20:53:42 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 9 Jan 2025 20:53:42 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> References: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> Message-ID: On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed jdk.internal package prefix from asm Changes looks good. The only concern is that jtreg might be fail to correctly compile so huge source set as testlibrary, but it should be addressed by jtreg. Thank you for moving ASM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2581222597 From jlu at openjdk.org Thu Jan 9 21:47:41 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 9 Jan 2025 21:47:41 GMT Subject: RFR: 8347146: Convert IncludeLocalesPluginTest to use JUnit In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 18:28:19 GMT, Naoto Sato wrote: > A simple refinement to the test makes diagnosing failures easier. Looked through the changes and the swap to a JUnit ParameterizedTest looks good to me. test/jdk/tools/jlink/plugins/IncludeLocalesPluginTest.java line 417: > 415: helper = Helper.newHelper(isLinkableRuntime); > 416: if (helper == null) { > 417: fail("Helper could not be initialized"); Could be `assertNotNull`, but probably best to not use an assertion in the setup method. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/23016#pullrequestreview-2540984215 PR Review Comment: https://git.openjdk.org/jdk/pull/23016#discussion_r1909466470 From almatvee at openjdk.org Thu Jan 9 22:36:46 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 9 Jan 2025 22:36:46 GMT Subject: RFR: 8347295: Fix WinResourceTest to make it work with WiX v4.0+ In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:45:53 GMT, Alexey Semenyuk wrote: > Look up different patterns in WiX output based on the version of the WiX. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22989#pullrequestreview-2541076743 From naoto at openjdk.org Thu Jan 9 22:44:15 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Jan 2025 22:44:15 GMT Subject: RFR: 8347146: Convert IncludeLocalesPluginTest to use JUnit [v2] In-Reply-To: References: Message-ID: > A simple refinement to the test makes diagnosing failures easier. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addresses review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23016/files - new: https://git.openjdk.org/jdk/pull/23016/files/ac7f72f5..47289b51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23016&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23016&range=00-01 Stats: 10 lines in 1 file changed: 2 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23016/head:pull/23016 PR: https://git.openjdk.org/jdk/pull/23016 From naoto at openjdk.org Thu Jan 9 22:46:40 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 9 Jan 2025 22:46:40 GMT Subject: RFR: 8347146: Convert IncludeLocalesPluginTest to use JUnit [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 21:43:57 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addresses review comments > > test/jdk/tools/jlink/plugins/IncludeLocalesPluginTest.java line 417: > >> 415: helper = Helper.newHelper(isLinkableRuntime); >> 416: if (helper == null) { >> 417: fail("Helper could not be initialized"); > > Could be `assertNotNull`, but probably best to not use an assertion in the setup method. Replaced with assertion here, and one other location. I think it is fine ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23016#discussion_r1909551683 From jlu at openjdk.org Thu Jan 9 22:53:42 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 9 Jan 2025 22:53:42 GMT Subject: RFR: 8347146: Convert IncludeLocalesPluginTest to use JUnit [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 22:44:15 GMT, Naoto Sato wrote: >> A simple refinement to the test makes diagnosing failures easier. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addresses review comments Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23016#pullrequestreview-2541098891 From clanger at openjdk.org Fri Jan 10 05:42:43 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 10 Jan 2025 05:42:43 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 16:47:18 GMT, Matthias Baesken wrote: > The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. Looks good, but I have a few requests/suggestions: 1. Please update the copyright years 2. In ProcessHandleImpl_aix.c you could add an SAP copyright line 3. In line 57 of src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c there is another mentioning of Solaris which could be removed 4. On the same lines you could get rid of unix_getChildren in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c and move the implementation to os_getChildren in src/java.base/linux/native/libjava/ProcessHandleImpl_linux.c ------------- Changes requested by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23013#pullrequestreview-2541585572 From plevart at openjdk.org Fri Jan 10 07:34:53 2025 From: plevart at openjdk.org (Peter Levart) Date: Fri, 10 Jan 2025 07:34:53 GMT Subject: RFR: 8347397: Cleanup of JDK-8169880 Message-ID: [JDK-8169880](https://bugs.openjdk.org/browse/JDK-8169880) removed a debugging option to disable caching of reflective data in java.lang.Class, which had a consequence that now Class#reflectiveData method guarantees to return a non-null result. Existing callers of that method were left intact and still contain null checks and branches that are never taken after this change. Some new callers were added later and they don't have null checks. I propose a patch to remove these unneeded null checks and never taken branches. ------------- Commit messages: - 8347397: Cleanup of JDK-8169880 Changes: https://git.openjdk.org/jdk/pull/23025/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347397 Stats: 57 lines in 1 file changed: 2 ins; 27 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/23025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23025/head:pull/23025 PR: https://git.openjdk.org/jdk/pull/23025 From liach at openjdk.org Fri Jan 10 07:38:19 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 07:38:19 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute Message-ID: Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. APIDiff, Javadoc, and CSR incoming. ------------- Commit messages: - 8342466: Improve API documentation for java.lang.classfile.attribute Changes: https://git.openjdk.org/jdk/pull/23026/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23026&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342466 Stats: 2571 lines in 68 files changed: 1608 ins; 125 del; 838 mod Patch: https://git.openjdk.org/jdk/pull/23026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23026/head:pull/23026 PR: https://git.openjdk.org/jdk/pull/23026 From liach at openjdk.org Fri Jan 10 08:07:46 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 08:07:46 GMT Subject: RFR: 8347397: Cleanup of JDK-8169880 In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 07:30:04 GMT, Peter Levart wrote: > [JDK-8169880](https://bugs.openjdk.org/browse/JDK-8169880) removed a debugging option to disable caching of reflective data in java.lang.Class, which had a consequence that now Class#reflectiveData method guarantees to return a non-null result. Existing callers of that method were left intact and still contain null checks and branches that are never taken after this change. Some new callers were added later and they don't have null checks. I propose a patch to remove these unneeded null checks and never taken branches. Good; now no usage of `reflectionData()` involves redundant null checks. Also it's 2025 so you get the privilege to bump copyright year on `Class.java`. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23025#pullrequestreview-2541769274 From liach at openjdk.org Fri Jan 10 08:25:36 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 08:25:36 GMT Subject: RFR: 8316882: Add NOT_INTERRUPTIBLE OpenOption and use it in ZipFS In-Reply-To: References: Message-ID: <16OW58lt-tWhc8B1G-yLedW2jG6XJwUCQumjKrwD7nU=.5daa8ce2-c4fa-4869-b302-bfa1008a6461@github.com> On Wed, 25 Dec 2024 23:55:18 GMT, Bruno Ploumhans wrote: > Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882. > > Following discussion in nio-dev a while ago, I have opted to add a new `NOT_INTERRUPTIBLE` open option, superseding `FileChannelImpl#setUninterruptible`. src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 112: > 110: opts.add(StandardOpenOption.READ); > 111: // No lambdas during bootstrap > 112: AccessController.doPrivileged(new PrivilegedAction() { Can probably remove this AccessController wrapping on JDK 25+, and just additionally catch SecurityException in case this fails in older releases where security manager exists. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22882#discussion_r1909985130 From plevart at openjdk.org Fri Jan 10 08:28:58 2025 From: plevart at openjdk.org (Peter Levart) Date: Fri, 10 Jan 2025 08:28:58 GMT Subject: RFR: 8347397: Cleanup of JDK-8169880 [v2] In-Reply-To: References: Message-ID: > [JDK-8169880](https://bugs.openjdk.org/browse/JDK-8169880) removed a debugging option to disable caching of reflective data in java.lang.Class, which had a consequence that now Class#reflectiveData method guarantees to return a non-null result. Existing callers of that method were left intact and still contain null checks and branches that are never taken after this change. Some new callers were added later and they don't have null checks. I propose a patch to remove these unneeded null checks and never taken branches. Peter Levart has updated the pull request incrementally with one additional commit since the last revision: 8347397: Happy New Year 2025 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23025/files - new: https://git.openjdk.org/jdk/pull/23025/files/d1a9464e..51dfa22e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23025&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23025&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23025/head:pull/23025 PR: https://git.openjdk.org/jdk/pull/23025 From sundar at openjdk.org Fri Jan 10 08:40:35 2025 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Fri, 10 Jan 2025 08:40:35 GMT Subject: RFR: 8340380: Improve source launcher's shebang script detection [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 09:20:51 GMT, Christian Stein wrote: >> Please review this change that improves the launcher mode detection by reading the initial two characters from the started file for being a shebang script. It addresses the reported confusing error messages and also supports more shebang line variations. Including those line variations that omit the `--source` arguments like shown in the underlying issue description of JDK-8340380. >> >> Tests of tier 1..3: _in progress_ > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Flip initial checks to restore original behaviour > > Avoid regression encoded in `test/jdk/tools/launcher/SourceMode.testClassNamedJava()` assertions incremental changes look good to me ------------- Marked as reviewed by sundar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21910#pullrequestreview-2541824395 From aturbanov at openjdk.org Fri Jan 10 09:17:47 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 10 Jan 2025 09:17:47 GMT Subject: RFR: 8346468: SM cleanup of common test library [v3] In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 21:07:14 GMT, Roger Riggs wrote: >> SM Cleanup of common test library test/lib/...: >> >> Remove unnecessary catches of SecurityException >> Remove AccessController and doPrivileged from SimpleSSLContext and ProcessTools. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed more references to WhiteBox$Permission test/lib/jdk/test/lib/helpers/ClassFileInstaller.java line 96: > 94: System.out.println("ClassFileInstaller: Writing to " + System.getProperty("user.dir")); > 95: } > 96: String[] classes = Arrays.copyOfRange(args,0, args.length); Suggestion: String[] classes = Arrays.copyOfRange(args, 0, args.length); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22814#discussion_r1910050712 From liach at openjdk.org Fri Jan 10 09:33:40 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 09:33:40 GMT Subject: RFR: 8347397: Cleanup of JDK-8169880 [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 08:28:58 GMT, Peter Levart wrote: >> [JDK-8169880](https://bugs.openjdk.org/browse/JDK-8169880) removed a debugging option to disable caching of reflective data in java.lang.Class, which had a consequence that now Class#reflectiveData method guarantees to return a non-null result. Existing callers of that method were left intact and still contain null checks and branches that are never taken after this change. Some new callers were added later and they don't have null checks. I propose a patch to remove these unneeded null checks and never taken branches. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > 8347397: Happy New Year 2025 Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23025#pullrequestreview-2541943657 From duke at openjdk.org Fri Jan 10 09:34:57 2025 From: duke at openjdk.org (ExE Boss) Date: Fri, 10 Jan 2025 09:34:57 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno In-Reply-To: References: Message-ID: <58rTK7u0IZy4n3asMgWysIxwAIqoXfdMooP2quE4vbg=.eecaa175-22db-4d4e-b14d-4f3c7e7f5654@github.com> On Tue, 26 Nov 2024 15:04:51 GMT, Per Minborg wrote: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Tested and passed tiers 1-3. Since the?`returnFilter(?)`?methods are?only?ever invoked?reflectively by?method?handle combinators, they?can?use `throws?Throwable`, which?avoids possible double?wrapping of?`Error`s (`StackOverflowError` or?`OutOfMemoryError`) and?`RuntimeException`s: src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 171: > 169: throw new InternalError(t); > 170: } > 171: } Suggestion: private static int returnFilter(MethodHandle errorHandle, int result) throws Throwable { if (result >= 0) { return result; } return -(int) errorHandle.invoke(); } src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 183: > 181: throw new InternalError(t); > 182: } > 183: } Suggestion: private static long returnFilter(MethodHandle errorHandle, long result) throws Throwable { if (result >= 0) { return result; } return -(int) errorHandle.invoke(); } src/java.base/share/classes/jdk/internal/foreign/ErrnoUtil.java line 122: > 120: } > 121: > 122: // Used reflectively via RETURN_FILTER_MH Suggestion: // Used reflectively via INT_RETURN_FILTER_MH src/java.base/share/classes/jdk/internal/foreign/ErrnoUtil.java line 127: > 125: } > 126: > 127: // Used reflectively via RETURN_FILTER_MH Suggestion: // Used reflectively via LONG_RETURN_FILTER_MH src/java.base/share/classes/jdk/internal/foreign/ResultErrno.java line 30: > 28: * > 29: * @param result the result returned from the native call > 30: * @param errno the errno (if result <= 0) or 0 Suggestion: * @param errno the errno (if result < 0) or 0 ------------- PR Review: https://git.openjdk.org/jdk/pull/22391#pullrequestreview-2465893687 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1861206877 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1861207179 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1860280069 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1860280510 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1859646876 From pminborg at openjdk.org Fri Jan 10 09:34:56 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 10 Jan 2025 09:34:56 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno Message-ID: Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. Tested and passed tiers 1-3. ------------- Commit messages: - Simplify and optimize return filters - Select the appropriate layout - Merge branch 'master' into errno-util - Bump copyright years and rename method - Merge branch 'master' into errno-util - Merge branch 'master' into errno-util - Add tests and improve docs - Clean up - Rename test - Reuse MHs - ... and 8 more: https://git.openjdk.org/jdk/compare/8c87ea2b...878a4096 Changes: https://git.openjdk.org/jdk/pull/22391/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347408 Stats: 368 lines in 3 files changed: 367 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From alanb at openjdk.org Fri Jan 10 09:38:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Jan 2025 09:38:45 GMT Subject: RFR: 8347397: Cleanup of JDK-8169880 [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 08:28:58 GMT, Peter Levart wrote: >> [JDK-8169880](https://bugs.openjdk.org/browse/JDK-8169880) removed a debugging option to disable caching of reflective data in java.lang.Class, which had a consequence that now Class#reflectiveData method guarantees to return a non-null result. Existing callers of that method were left intact and still contain null checks and branches that are never taken after this change. Some new callers were added later and they don't have null checks. I propose a patch to remove these unneeded null checks and never taken branches. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > 8347397: Happy New Year 2025 Marked as reviewed by alanb (Reviewer). Welcome back, this looks fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/23025#pullrequestreview-2541958602 PR Comment: https://git.openjdk.org/jdk/pull/23025#issuecomment-2582189843 From alanb at openjdk.org Fri Jan 10 09:44:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Jan 2025 09:44:41 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:04:51 GMT, Per Minborg wrote: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Tested and passed tiers 1-3. src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 50: > 48: private static final long SIZE = Linker.Option.captureStateLayout().byteSize(); > 49: > 50: private static final TerminatingThreadLocal TL = new TerminatingThreadLocal<>() { TerminatingThreadLocal is carrier-local so the usage here will require a detailed walk through to make sure that a virtual thread cannot be preempted when it has access to this memory segment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1910094423 From sgehwolf at openjdk.org Fri Jan 10 10:09:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 10:09:51 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [x] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Expand comment This is a test-only fix and fairly trivial. I'll integrate now. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2582265348 From sgehwolf at openjdk.org Fri Jan 10 10:09:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 10:09:51 GMT Subject: Integrated: 8347124: Clean tests with --enable-linkable-runtime In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 14:24:25 GMT, Severin Gehwolf wrote: > Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. > > Testing: > - [x] GHA > - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. > > Thoughts? This pull request has now been integrated. Changeset: 1f457977 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/1f457977f062e4ed219c6fa0fe26cb42acaf4bf2 Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod 8347124: Clean tests with --enable-linkable-runtime Reviewed-by: shade, alanb ------------- PR: https://git.openjdk.org/jdk/pull/22969 From sgehwolf at openjdk.org Fri Jan 10 10:14:08 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 10:14:08 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 19:39:34 GMT, Archie Cobbs wrote: > The loop could be simplified even further... Done it the latest update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23014#issuecomment-2582276780 From sgehwolf at openjdk.org Fri Jan 10 10:14:08 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 10:14:08 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v3] In-Reply-To: References: Message-ID: <3HQNuQ6DgW4MORKxwLJ4_oGOVyFqdGr9M494QFGFEXs=.3ae60648-1c8d-48b8-a129-574971c8649f@github.com> > During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. > > Testing: > - [x] GHA > - [x] tools/jlink tests (including the new one). > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Further simplification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23014/files - new: https://git.openjdk.org/jdk/pull/23014/files/42baf977..c9cbb9a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23014&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23014&range=01-02 Stats: 13 lines in 1 file changed: 1 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23014.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23014/head:pull/23014 PR: https://git.openjdk.org/jdk/pull/23014 From sgehwolf at openjdk.org Fri Jan 10 10:14:08 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 10:14:08 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 18:51:09 GMT, Henry Jen wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java line 135: > >> 133: bytesRead2 = is2.readNBytes(buf2, 0, buf2.length); >> 134: if (bytesRead1 == 0 || bytesRead2 == 0) { >> 135: break; // no more bytes for a stream > > break after test same amount of bytes can remove the test exit the while loop. I went with @archiecobbs suggestion which simplifies this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23014#discussion_r1910142221 From alanb at openjdk.org Fri Jan 10 10:38:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Jan 2025 10:38:44 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v3] In-Reply-To: <-QhN582ZLm6wkdTDRDZBdizuk7WBRtZqGBzHbB1_St8=.ac2047df-0eaf-48b5-b641-a58bb86fdf7e@github.com> References: <-QhN582ZLm6wkdTDRDZBdizuk7WBRtZqGBzHbB1_St8=.ac2047df-0eaf-48b5-b641-a58bb86fdf7e@github.com> Message-ID: On Wed, 8 Jan 2025 00:40:04 GMT, Henry Jen wrote: >> Improving option value handling to support passing argument value starts with "--". >> >> Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. >> --add-options --add-modules=jdk.incubator.concurrent >> --add-options=--add-modules=jdk.incubator.concurrent >> >> will cause JLink to report >> Error: no value given for --add-options >> as --add-modules is considered another option for JLink. >> >> After the fix, by using = will ensure the value is properly handled as argument value >> --add-options=--add-modules=jdk.incubator.concurrent > > Henry Jen 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'openjdk/master' into JDK-8303884 > - Use opt=value format when value is starting with -- > - Fix style > - add test > - 8303884: jlink --add-options plugin does not allow GNU style options to be provided Good, I like this too. I agree with Mandy on documenting this. Also to avoid developer flapping around trying to figure this out then maybe we need a better err.missing.arg resource when potentiallyGnuOption and the param starts with "--". In otherwise, could be just given a better error message? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22526#issuecomment-2582331118 From alanb at openjdk.org Fri Jan 10 10:39:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Jan 2025 10:39:38 GMT Subject: RFR: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 15:46:56 GMT, Viktor Klang wrote: >> The following patch updates Gatherers.mapConcurrent to limit work-in-progress (on-going and completed-unpushed) to the `maxConcurrency` so that head-of-line blocking does not cause completed-unpushed work to grow unbounded. >> >> This also simplifies interruption handling to ignore-and-restore, which needs to be done on a per-element-basis as the calling thread can change between invocations of the integrator, as well as the finisher, so restoring it on finish is not possible (and won't happen if there's an exception thrown during integration anyway). >> >> Furthermore, logic has been added to reduce the risk of any spawned virtual threads surviving the processing of the stream. > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Addresses PR review feedback Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22999#pullrequestreview-2542102640 From alanb at openjdk.org Fri Jan 10 10:39:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Jan 2025 10:39:39 GMT Subject: RFR: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 15:43:59 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/stream/Gatherers.java line 392: >> >>> 390: while (proceed >>> 391: && (current = wip.peekFirst()) != null >>> 392: && (current.isDone() || atLeastN > 0)) { >> >> It might be better to indent these two lines so that it's clearer what the while expression is vs. the code in the block. > > Fair point?I reformatted that while clause to something which is hopefully easier to read. I'd probably formatting it differently but what you have it readable so okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22999#discussion_r1910176615 From mbaesken at openjdk.org Fri Jan 10 10:43:35 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 10 Jan 2025 10:43:35 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo [v2] In-Reply-To: References: Message-ID: > The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: remove unix_getChildren, adjust COPYRIGHT info ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23013/files - new: https://git.openjdk.org/jdk/pull/23013/files/d49d3d36..d4b539e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23013&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23013&range=00-01 Stats: 267 lines in 4 files changed: 123 ins; 137 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23013/head:pull/23013 PR: https://git.openjdk.org/jdk/pull/23013 From mbaesken at openjdk.org Fri Jan 10 10:45:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 10 Jan 2025 10:45:41 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 16:47:18 GMT, Matthias Baesken wrote: > The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. Hi Christoph, I adjusted the COPYRIGHT info and removed unix_getChildren . Regarding 'Solaris' mentioning in this file , I removed that one too but a grep shows there are plenty of Solaris comments etc. in the codebase. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23013#issuecomment-2582394133 From pminborg at openjdk.org Fri Jan 10 10:47:34 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 10 Jan 2025 10:47:34 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v2] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add thread stress test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/878a4096..124567cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=00-01 Stats: 45 lines in 1 file changed: 35 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From clanger at openjdk.org Fri Jan 10 11:04:42 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 10 Jan 2025 11:04:42 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo [v2] In-Reply-To: References: Message-ID: <6aERx7amXsMBVBIkDYrsQEfxu9UHwpGsVdPxbN0reZ0=.526d17f1-9413-4276-984a-3367275d3771@github.com> On Fri, 10 Jan 2025 10:43:35 GMT, Matthias Baesken wrote: >> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove unix_getChildren, adjust COPYRIGHT info Marked as reviewed by clanger (Reviewer). src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c line 81: > 79: * ProcessHandleImpl_.c file. > 80: * > 81: * Example : Suggestion: * Example: ------------- PR Review: https://git.openjdk.org/jdk/pull/23013#pullrequestreview-2542158411 PR Review Comment: https://git.openjdk.org/jdk/pull/23013#discussion_r1910213004 From clanger at openjdk.org Fri Jan 10 11:04:43 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 10 Jan 2025 11:04:43 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 10:43:24 GMT, Matthias Baesken wrote: > Hi Christoph, I adjusted the COPYRIGHT info and removed unix_getChildren . Regarding 'Solaris' mentioning in this file , I removed that one too but a grep shows there are plenty of Solaris comments etc. in the codebase. Looks good, thanks for incorporating the suggestion. Found one other minor nit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23013#issuecomment-2582436570 From alanb at openjdk.org Fri Jan 10 11:13:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Jan 2025 11:13:48 GMT Subject: RFR: 8346778: Enable native access should work with the source launcher [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 20:29:03 GMT, Christian Stein wrote: >> Please review this change request enabling native access in source launch mode when using a modular setup. >> >> The change comes in two parts: >> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java` >> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java` >> >> _Testing of tier1..3 is in progress..._ > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Ignore already handled `ALL-UNNAMED` name src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 838: > 836: * command line option, and also to JDK modules that need the access. > 837: *

> 838: * In case of being in "source" launchmode, warnings about unknown modules are Typo, this should say "launcher mode" or "launch mode". src/java.base/share/native/libjli/java.c line 1376: > 1374: if (mode == LM_SOURCE) { > 1375: // signal module bootstrap to defer warnings about unknown modules > 1376: AddOption("-Djdk.internal.java.launchmode=source", NULL); This is the launcher code so better if the comment said could say that it communicates the launcher mode to runtime (confusing to say "signal module bootstrap" or anything about warnings here). I note that the existing property is "sun.java.launcher". If you want then you could continue this contention and use "sun.java.launcher.mode". It'a all JDK-internal and the system property is removed during startup so the naming doesn't really matter of course, I'd like prefer it end in ".mode" rather than "launchmode". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1910223717 PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1910214018 From alanb at openjdk.org Fri Jan 10 11:13:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Jan 2025 11:13:46 GMT Subject: RFR: 8346778: Enable native access should work with the source launcher [v2] In-Reply-To: References: <9sLyfxjDPJJ9Uml93j13lDSYveieHktAba2Fm8Y5CgY=.0a9cd126-c335-4a6f-bedf-c831c41b4bf1@github.com> Message-ID: On Thu, 9 Jan 2025 20:16:16 GMT, Christian Stein wrote: > I cannot think of any other useful options in addition to the ones handled in [RelevantJavacOptions.java](https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/RelevantJavacOptions.java) for the time being that should also be forwarded to source launcher module layer setup for compilation or run time. Okay, main reason for asking is whether we need infrastructure rather than a point solution but I think you are right that the others aren't too interesting at this point. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2582456903 From mbaesken at openjdk.org Fri Jan 10 11:22:31 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 10 Jan 2025 11:22:31 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo [v3] In-Reply-To: References: Message-ID: > The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: remove blank ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23013/files - new: https://git.openjdk.org/jdk/pull/23013/files/d4b539e6..4676494c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23013&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23013&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23013/head:pull/23013 PR: https://git.openjdk.org/jdk/pull/23013 From ihse at openjdk.org Fri Jan 10 12:54:43 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Jan 2025 12:54:43 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> References: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> Message-ID: On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed jdk.internal package prefix from asm I'm wondering about the build implications of this. This will move ASM from pre-compiled java classes in the JDK, into on-the-fly compiled classes in JTreg. I'm just back from vacation, so I have not had much time to look at this, but it does not seem as simple as "just move the files", and I'd like to get some more consideration about this change before it is pushed. For instance, maybe we could rely on upstream ASM for the tests? I assume it gets distributed as a jar, that we could add as a dependency. (I guess that removing the `jdk.internal` prefix from the package name would be a pre-requisite for such a change, so that might also give the suggestion to this some more weight.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2582643101 From mullan at openjdk.org Fri Jan 10 13:17:36 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 10 Jan 2025 13:17:36 GMT Subject: RFR: 8316882: Add NOT_INTERRUPTIBLE OpenOption and use it in ZipFS In-Reply-To: <16OW58lt-tWhc8B1G-yLedW2jG6XJwUCQumjKrwD7nU=.5daa8ce2-c4fa-4869-b302-bfa1008a6461@github.com> References: <16OW58lt-tWhc8B1G-yLedW2jG6XJwUCQumjKrwD7nU=.5daa8ce2-c4fa-4869-b302-bfa1008a6461@github.com> Message-ID: On Fri, 10 Jan 2025 08:22:37 GMT, Chen Liang wrote: >> Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882. >> >> Following discussion in nio-dev a while ago, I have opted to add a new `NOT_INTERRUPTIBLE` open option, superseding `FileChannelImpl#setUninterruptible`. > > src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 112: > >> 110: opts.add(StandardOpenOption.READ); >> 111: // No lambdas during bootstrap >> 112: AccessController.doPrivileged(new PrivilegedAction() { > > Can probably remove this AccessController wrapping on JDK 25+, and just additionally catch SecurityException in case this fails in older releases where security manager exists. Why catch the `SecurityException` - why do we need to make JDK 25+ code work on older releases? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22882#discussion_r1910363981 From alanb at openjdk.org Fri Jan 10 13:28:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 10 Jan 2025 13:28:40 GMT Subject: RFR: 8316882: Add NOT_INTERRUPTIBLE OpenOption and use it in ZipFS In-Reply-To: References: <16OW58lt-tWhc8B1G-yLedW2jG6XJwUCQumjKrwD7nU=.5daa8ce2-c4fa-4869-b302-bfa1008a6461@github.com> Message-ID: On Fri, 10 Jan 2025 13:14:36 GMT, Sean Mullan wrote: >> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 112: >> >>> 110: opts.add(StandardOpenOption.READ); >>> 111: // No lambdas during bootstrap >>> 112: AccessController.doPrivileged(new PrivilegedAction() { >> >> Can probably remove this AccessController wrapping on JDK 25+, and just additionally catch SecurityException in case this fails in older releases where security manager exists. > > Why catch the `SecurityException` - why do we need to make JDK 25+ code work on older releases? The jrtfs provider is compiled --release 8 and packaging into jrt-fs.jar to allow tools on JDK 8+ to access the classes/resources in the run-time image. In any case, it's nothing to do with the topic that this PR is about, see discussion on nio-dev instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22882#discussion_r1910376495 From plevart at openjdk.org Fri Jan 10 14:49:47 2025 From: plevart at openjdk.org (Peter Levart) Date: Fri, 10 Jan 2025 14:49:47 GMT Subject: Integrated: 8347397: Cleanup of JDK-8169880 In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 07:30:04 GMT, Peter Levart wrote: > [JDK-8169880](https://bugs.openjdk.org/browse/JDK-8169880) removed a debugging option to disable caching of reflective data in java.lang.Class, which had a consequence that now Class#reflectiveData method guarantees to return a non-null result. Existing callers of that method were left intact and still contain null checks and branches that are never taken after this change. Some new callers were added later and they don't have null checks. I propose a patch to remove these unneeded null checks and never taken branches. This pull request has now been integrated. Changeset: beb0e607 Author: Peter Levart URL: https://git.openjdk.org/jdk/commit/beb0e607d3b66b9e97c263cd8f2e23f447ebfc50 Stats: 58 lines in 1 file changed: 2 ins; 27 del; 29 mod 8347397: Cleanup of JDK-8169880 Reviewed-by: liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/23025 From sgehwolf at openjdk.org Fri Jan 10 14:57:09 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 14:57:09 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v15] In-Reply-To: References: Message-ID: > Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). > > This patch addresses this issue by: > > 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. > 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). > > As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. > > This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. > > Thoughts? > > Testing: > > - [x] GHA > - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems > - [x] Some manual testing using systemd slices Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Fix missing imports - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Add exclusive access dirs directive for systemd tests - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - ... and 31 more: https://git.openjdk.org/jdk/compare/1f457977...c83c22eb ------------- Changes: https://git.openjdk.org/jdk/pull/20280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=14 Stats: 1621 lines in 27 files changed: 1373 ins; 152 del; 96 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280 From sgehwolf at openjdk.org Fri Jan 10 14:58:36 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 10 Jan 2025 14:58:36 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v4] In-Reply-To: References: Message-ID: > During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. > > Testing: > - [x] GHA > - [x] tools/jlink tests (including the new one). > > Thoughts? Severin Gehwolf 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: - Merge branch 'master' into jdk-8347334-jimage-diff-gen-cleanup - Further simplification - Review feedback - 8347334: JimageDiffGenerator code clean-ups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23014/files - new: https://git.openjdk.org/jdk/pull/23014/files/c9cbb9a0..8b602b42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23014&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23014&range=02-03 Stats: 13212 lines in 322 files changed: 2494 ins; 9484 del; 1234 mod Patch: https://git.openjdk.org/jdk/pull/23014.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23014/head:pull/23014 PR: https://git.openjdk.org/jdk/pull/23014 From pminborg at openjdk.org Fri Jan 10 15:01:38 2025 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 10 Jan 2025 15:01:38 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v3] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Clean up - Add VT pinning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/124567cf..67a1deae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=01-02 Stats: 109 lines in 2 files changed: 92 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From asotona at openjdk.org Fri Jan 10 15:48:19 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Jan 2025 15:48:19 GMT Subject: RFR: 8346986: Remove ASM from java.base [v4] In-Reply-To: References: Message-ID: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/vmTestbase/vm/runtime/defmeth/shared/Util.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22946/files - new: https://git.openjdk.org/jdk/pull/22946/files/13267e26..ac5063c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946 PR: https://git.openjdk.org/jdk/pull/22946 From asotona at openjdk.org Fri Jan 10 15:48:19 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Jan 2025 15:48:19 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> References: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> Message-ID: On Thu, 9 Jan 2025 08:40:37 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed jdk.internal package prefix from asm Thanks for the reviews. I'll update the copyright years and run again tier1 - 4 tests (just to be sure). Jtreg seems to have no problems to use ASM as a declared library. This PR primary purpose is to remove the ASM from java.base. Further improvements of hotspot tests using ASM can follow. However I would prefer to see further conversions of the hotspot tests to use Class-File API instead. Long-term goal is to remove ASM from JDK completely. FYI: Regarding the merge of this PR I've been asked to wait until some downstream projects dependent on jdk.internal.objectweb.asm are fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2582985694 From jpai at openjdk.org Fri Jan 10 15:49:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 10 Jan 2025 15:49:41 GMT Subject: RFR: 8346468: SM cleanup of common test library [v3] In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 21:07:14 GMT, Roger Riggs wrote: >> SM Cleanup of common test library test/lib/...: >> >> Remove unnecessary catches of SecurityException >> Remove AccessController and doPrivileged from SimpleSSLContext and ProcessTools. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed more references to WhiteBox$Permission test/lib/jdk/test/lib/SA/SATestUtils.java line 208: > 206: var deny_ptrace = Paths.get("/sys/fs/selinux/booleans/deny_ptrace"); > 207: if (Files.exists(deny_ptrace)) { > 208: var bb = Files.readAllBytes(deny_ptrace); Hello Roger, I'm guessing the `@SuppressWarnings("removal")` on this method will no longer be needed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22814#discussion_r1910559552 From jpai at openjdk.org Fri Jan 10 15:58:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 10 Jan 2025 15:58:41 GMT Subject: RFR: 8346468: SM cleanup of common test library [v3] In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 21:07:14 GMT, Roger Riggs wrote: >> SM Cleanup of common test library test/lib/...: >> >> Remove unnecessary catches of SecurityException >> Remove AccessController and doPrivileged from SimpleSSLContext and ProcessTools. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removed more references to WhiteBox$Permission Overall this looks good to me. I am not familiar with the purpose of `WhiteBoxPermission`, but with the SecurityManager gone, I think removing it and its usage from the tests is the right thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22814#issuecomment-2583042687 From asotona at openjdk.org Fri Jan 10 16:04:41 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Jan 2025 16:04:41 GMT Subject: RFR: 8346986: Remove ASM from java.base [v5] In-Reply-To: References: Message-ID: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: updated copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22946/files - new: https://git.openjdk.org/jdk/pull/22946/files/ac5063c9..98f90462 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=03-04 Stats: 105 lines in 105 files changed: 0 ins; 0 del; 105 mod Patch: https://git.openjdk.org/jdk/pull/22946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946 PR: https://git.openjdk.org/jdk/pull/22946 From jpai at openjdk.org Fri Jan 10 16:09:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 10 Jan 2025 16:09:42 GMT Subject: RFR: 8340380: Improve source launcher's shebang script detection [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 09:20:51 GMT, Christian Stein wrote: >> Please review this change that improves the launcher mode detection by reading the initial two characters from the started file for being a shebang script. It addresses the reported confusing error messages and also supports more shebang line variations. Including those line variations that omit the `--source` arguments like shown in the underlying issue description of JDK-8340380. >> >> Tests of tier 1..3: _in progress_ > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Flip initial checks to restore original behaviour > > Avoid regression encoded in `test/jdk/tools/launcher/SourceMode.testClassNamedJava()` assertions src/java.base/share/native/libjli/java.c line 763: > 761: if (stat(arg, &st) != 0) > 762: return JNI_FALSE; > 763: if (JLI_HasSuffix(arg, ".java") == JNI_TRUE) Hello Christian, I think it might be better to retain the previous order and first check for the suffix and if it's not `.java`, only then do a `stat` system call. Also a nit - the `== JNI_TRUE` isn't needed, just `if (JLI_HasSuffix(arg, ".java"))` would be enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21910#discussion_r1910589659 From asotona at openjdk.org Fri Jan 10 16:12:54 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Jan 2025 16:12:54 GMT Subject: RFR: 8346986: Remove ASM from java.base [v6] In-Reply-To: References: Message-ID: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: updated copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22946/files - new: https://git.openjdk.org/jdk/pull/22946/files/98f90462..d3559630 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=04-05 Stats: 79 lines in 79 files changed: 0 ins; 0 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/22946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946 PR: https://git.openjdk.org/jdk/pull/22946 From cstein at openjdk.org Fri Jan 10 16:17:40 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 10 Jan 2025 16:17:40 GMT Subject: RFR: 8340380: Improve source launcher's shebang script detection [v3] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 16:06:32 GMT, Jaikiran Pai wrote: > [...] retain the previous order and first check for the suffix and if it's not .java, only then do a stat system call. I started with that oder (before https://github.com/openjdk/jdk/pull/21910/commits/f0bd01d393a5d88e8b33723b7b4ca16379b97636) and it led to a regression when there's package `HelloWorld` and class named `java`, like in `HelloWorld/java.class`. See test/jdk/tools/launcher/SourceMode.testClassNamedJava() for details: https://github.com/openjdk/jdk/blob/1bf2f5c8a92b30eabb530737158f57c63a81fef6/test/jdk/tools/launcher/SourceMode.java#L265-L289 > Also a nit - the == JNI_TRUE isn't needed, just if (JLI_HasSuffix(arg, ".java")) would be enough. True. Will remove the extra characters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21910#discussion_r1910601718 From danielaveryj at gmail.com Fri Jan 10 16:17:47 2025 From: danielaveryj at gmail.com (Daniel Avery) Date: Fri, 10 Jan 2025 09:17:47 -0700 Subject: Minor optimizations / questions about stream implementation Message-ID: Hi, I recently finished a deep-dive through the code in java.util.stream, and came across a few corners that stuck out to me as being odd, in a "small missed opportunity" kind of way. I figured I'd raise them here just in case any are legitimate, or I could get some better insight. I am looking at JDK 24 [build 30] ( https://github.com/openjdk/jdk/tree/jdk-24%2B30/src/java.base/share/classes/java ). 1. AbstractPipeline.wrap() is passed isParallel(), which ultimately (only) plays into determining if StreamSpliterators.AbstractWrappingSpliterator is allowed to split. It looks like the code could be more lenient, and instead pass (isParallel() || !hasAnyStateful()), i.e. allow splitting the spliterator() from sequential streams that do not have stateful ops. 2. It looks like StreamSpliterators.UnorderedSliceSpliterator.trySplit() should disable splitting if (permitStatus() == NO_MORE), instead of (permits.get() == 0). As is, it would appear to unnecessarily disable splitting after skipping, in the skip-only case. 3. It looks like SortedOps could override opEvaluateParallelLazy to no-op in the already-sorted case, similar to DistinctOps in the already-distinct case. 4. It looks like SliceOps.makeRef() could fuse adjacent skip()/limit() ops (though I could see that being an overly niche optimization, especially if it makes linked/consumed handling painful). 5. It looks like there is some dead code in StreamOpFlag? I don't see a path where isPreserved() would return true in practice (it appears to only be called in exactly 2 'minor optimization' places: SliceTask.doLeaf() and DropWhileTask.doLeaf()). With the way StreamOpFlag.combineOpFlags() works, it looks like in practice 0b00 is used to preserve, rather than 0b11. I also don't see Type.OP, Type.TERMINAL_OP, or Type.UPSTREAM_TERMINAL_OP being used anywhere. I assume some of the methods here are intended for tests only (isStreamFlag(), canSet())... But given how much of this class I'm not seeing being used, I'm wondering if I'm just missing something. Thank you, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihse at openjdk.org Fri Jan 10 16:47:48 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Jan 2025 16:47:48 GMT Subject: RFR: 8342807: Update links in java.base to use https:// In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 19:29:43 GMT, Eirik Bj?rsn?s wrote: >> FWIW: I don't believe a change to a link in a comment in an internal class requires a CSR. >> For PortConfig.java - it would be good to have someone involved in the AIX port comment on the proposed changes. >> Removing the obsolete link altogether is also a possibility. > >> For PortConfig.java - it would be good to have someone involved in the AIX port comment on the proposed changes. Removing the obsolete link altogether is also a possibility. > > The context for the link in PortConfig.java is: > > > // The ephemeral port is OS version dependent on AIX: > // http://publib.boulder.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.rsct315.admin/bl503_ephport.htm > // However, on AIX 5.3 / 6.1 / 7.1 we always see the > // settings below by using: > // /usr/sbin/no -a | fgrep ephemeral > defaultLower = 32768; > defaultUpper = 65535; > > > So while the FAQ link I changed this to confirms the port numbers here, it probably makes the comment "The ephemeral port is OS version dependent on AIX" somewhat stale. Seems the original linked document somehow contradicted the observed settings? So if we use my suggested FAQ link, perhaps it is better to remove the surrounding comment altogether, as it seems stale. > > For `ProcessImpl_md.c`, the obsolete link was to a request for clarification to what I think may be an early version of some POSIX standard. If I'm right, the current version is https://www.iso.org/standard/50516.html, which is not publicly available (requires paid access). > > But yes, would be nice if some AIX people could have a look at this. @eirbjo This seemed like a valuable and worthwhile contribution, and I think it is a bit sad to see it closed due to inactivity. Was it the lack of volunteering reviewers that made you let it go? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2583231907 From asotona at openjdk.org Fri Jan 10 16:49:46 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 10 Jan 2025 16:49:46 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 07:32:24 GMT, Chen Liang wrote: > Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html Great documentation improvement, thank you. Only minor nits are in the comments. src/java.base/share/classes/java/lang/classfile/attribute/ModuleExportInfo.java line 71: > 69: * flag enums} > 70: * > 71: * @throws IllegalArgumentException if the flags mask has any unused bit set I'm not sure "if the flags mask has any unused bit set" is clear to understand src/java.base/share/classes/java/lang/classfile/attribute/ModuleOpenInfo.java line 77: > 75: * flag enums} > 76: * > 77: * @throws IllegalArgumentException if the flags mask has any unused bit set dtto src/java.base/share/classes/java/lang/classfile/attribute/ModuleRequireInfo.java line 68: > 66: * flag enums} > 67: * > 68: * @throws IllegalArgumentException if the flags mask has any unused bit set dtto src/java.base/share/classes/java/lang/classfile/attribute/package-info.java line 30: > 28: * > 29: * The {@code java.lang.classfile.attribute} package contains interfaces describing specific {@code class} file attributes. > 30: * General and user-defined attributes reside in {@link java.lang.classfile}, including {@link Attributes}, {@link "General and user-defined attributes reside in java.lang.classfile" is a bit confusing to me. ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23026#pullrequestreview-2542303434 PR Review Comment: https://git.openjdk.org/jdk/pull/23026#discussion_r1910299892 PR Review Comment: https://git.openjdk.org/jdk/pull/23026#discussion_r1910305291 PR Review Comment: https://git.openjdk.org/jdk/pull/23026#discussion_r1910307335 PR Review Comment: https://git.openjdk.org/jdk/pull/23026#discussion_r1910327178 From lmesnik at openjdk.org Fri Jan 10 16:53:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 10 Jan 2025 16:53:41 GMT Subject: Integrated: 8347302: Mark test tools/jimage/JImageToolTest.java as flagless In-Reply-To: References: Message-ID: <9-YZJHaP0WY4Tvpiwpu1XHOc4xGRZGwVEf8A3sXbxzQ=.6b9bf3be-7ae1-4cf4-94a4-f0c76758acc4@github.com> On Thu, 9 Jan 2025 00:05:30 GMT, Leonid Mesnik wrote: > Test > test/jdk/tools/jimage/JImageToolTest.java > ignore vm flags and should be marked as flagless. > > It is needed to don't try to run this test with virtual test thread factory. This pull request has now been integrated. Changeset: e7e8f60c Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/e7e8f60c9bedd5622525cc4339300b438eedc9fd Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8347302: Mark test tools/jimage/JImageToolTest.java as flagless Reviewed-by: alanb, shade ------------- PR: https://git.openjdk.org/jdk/pull/22992 From ihse at openjdk.org Fri Jan 10 17:07:48 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Jan 2025 17:07:48 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: References: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> Message-ID: On Fri, 10 Jan 2025 15:39:20 GMT, Adam Sotona wrote: > Jtreg seems to have no problems to use ASM as a declared library. Whan you say "no problems", I guess you are referring to the pass rate of the tests. But how does it affect the runtime spent doing testing? I must insist that "just moving" code from `src` to `test` is not at all like moving code internally inside `src` or inside `test`, and that it is not at all an obviously trivial operation. I understand that you want to remove ASM from the source base, and I do not object to that goal. I'm just saying that having tests that rely on code being present is basically just the same as having code in `src` relying on it, and that moving the entire source base to ASM is perhaps not the right way to deal with this remaining dependency. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2583277826 From rriggs at openjdk.org Fri Jan 10 17:10:03 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Jan 2025 17:10:03 GMT Subject: RFR: 8346468: SM cleanup of common test library [v4] In-Reply-To: References: Message-ID: > SM Cleanup of common test library test/lib/...: > > Remove unnecessary catches of SecurityException > Remove AccessController and doPrivileged from SimpleSSLContext and ProcessTools. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Removal of SuppressWarning("removal") ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22814/files - new: https://git.openjdk.org/jdk/pull/22814/files/ee8aefc3..11803568 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22814&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22814&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22814/head:pull/22814 PR: https://git.openjdk.org/jdk/pull/22814 From rriggs at openjdk.org Fri Jan 10 17:11:50 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 10 Jan 2025 17:11:50 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo [v3] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 11:22:31 GMT, Matthias Baesken wrote: >> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove blank Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23013#pullrequestreview-2542997227 From bpb at openjdk.org Fri Jan 10 17:11:48 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 10 Jan 2025 17:11:48 GMT Subject: RFR: 8345368: java/io/File/createTempFile/SpecialTempFile.java fails on Windows Server 2025 In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:27:15 GMT, Brian Burkhalter wrote: > Change the test as done in #22957 for [JDK-8346671](https://bugs.openjdk.org/browse/JDK-8346671). Withholding integration until this change is verified on Windows Server 2025. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22994#issuecomment-2583285608 From clanger at openjdk.org Fri Jan 10 18:02:42 2025 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 10 Jan 2025 18:02:42 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo [v3] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 11:22:31 GMT, Matthias Baesken wrote: >> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove blank Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23013#pullrequestreview-2543108697 From ihse at openjdk.org Fri Jan 10 18:02:50 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 10 Jan 2025 18:02:50 GMT Subject: Integrated: 8346669: Increase abstraction in SetupBuildLauncher and remove extra args In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 16:27:30 GMT, Magnus Ihse Bursie wrote: > We need to raise the abstraction of the SetupBuildLauncher API, to prepare for static launchers. We should specify the desired outcome, not what flags we should add. This can be seen as the last part of [JDK-8141444](https://bugs.openjdk.org/browse/JDK-8141444) (9 years later). > > In the process, I am removing EXTRA_JAVA_ARGS which has not been used for a long time. I also removed this part from the launcher itself. This pull request has now been integrated. Changeset: 46ba515c Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/46ba515c4989de7545d409570315274e0ea1c5ac Stats: 105 lines in 12 files changed: 14 ins; 57 del; 34 mod 8346669: Increase abstraction in SetupBuildLauncher and remove extra args Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/22832 From asemenyuk at openjdk.org Fri Jan 10 19:33:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 10 Jan 2025 19:33:50 GMT Subject: Integrated: 8347300: Don't exclude the "PATH" var from the environment when running app launchers in jpackage tests In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 22:29:04 GMT, Alexey Semenyuk wrote: > - Don't remove the `PATH` variable from the environment when running app launchers in jpackage tests; > - Fix tests that use `Executor` rather than `HelloApp` class to run app launchers: apply the same changes to the environment as would be applied by `HelloApp` class. > - Replace `Executor.setRemovePathEnvVar()` with `Executor.removeEnvVar()` to support removal of any variable from the environment of a child process executed in jpackage tests; > - Add support of a new boolean property `jpackage.test.clear-app-launcher-java-env-vars` in jpackage tests. If it is set to "true", the `JAVA_TOOL_OPTIONS` and `_JAVA_OPTIONS` variables will be removed from the environment of app launchers executed in jpackage tests. It is handy in local testing using jpackage test runner instead of the jtreg. > > The first and the second changes are unrelated to other changes. They are bundled together as they apply to the same source code. This pull request has now been integrated. Changeset: d69463e4 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/d69463e4bcbddd346b9486059c5ad3a1cb555632 Stats: 38 lines in 4 files changed: 19 ins; 3 del; 16 mod 8347300: Don't exclude the "PATH" var from the environment when running app launchers in jpackage tests Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/22983 From asemenyuk at openjdk.org Fri Jan 10 19:34:42 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 10 Jan 2025 19:34:42 GMT Subject: Integrated: 8347295: Fix WinResourceTest to make it work with WiX v4.0+ In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:45:53 GMT, Alexey Semenyuk wrote: > Look up different patterns in WiX output based on the version of the WiX. This pull request has now been integrated. Changeset: 10f7142d Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/10f7142dce296fedbb4d945378473d44ecde34b7 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod 8347295: Fix WinResourceTest to make it work with WiX v4.0+ Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/22989 From asemenyuk at openjdk.org Fri Jan 10 19:34:46 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 10 Jan 2025 19:34:46 GMT Subject: Integrated: 8347298: Bug in JPackageCommand.ignoreFakeRuntime() In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 23:29:49 GMT, Alexey Semenyuk wrote: > `JPackageCommand.ignoreFakeRuntime()` method mistakenly tests if Java runtime configured for the current jpackage command is a valid Java runtime. > > It must test the runtime configured for jpackage tests with `jdk.jpackage.test.runtime-image` system property instead. This pull request has now been integrated. Changeset: 01c8ba2c Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/01c8ba2cde881c3d483cb776ca17a5aa13123b23 Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod 8347298: Bug in JPackageCommand.ignoreFakeRuntime() Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/22986 From liach at openjdk.org Fri Jan 10 19:37:40 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 19:37:40 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 12:15:33 GMT, Adam Sotona wrote: >> Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html > > src/java.base/share/classes/java/lang/classfile/attribute/ModuleExportInfo.java line 71: > >> 69: * flag enums} >> 70: * >> 71: * @throws IllegalArgumentException if the flags mask has any unused bit set > > I'm not sure "if the flags mask has any unused bit set" is clear to understand I think I will call it "undefined bit set". Is that more clear? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23026#discussion_r1911103619 From liach at openjdk.org Fri Jan 10 20:25:06 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 20:25:06 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute [v2] In-Reply-To: References: Message-ID: > Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Review comments, also simplify Attribute ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23026/files - new: https://git.openjdk.org/jdk/pull/23026/files/575712c8..c08f76c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23026&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23026&range=00-01 Stats: 37 lines in 8 files changed: 5 ins; 12 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/23026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23026/head:pull/23026 PR: https://git.openjdk.org/jdk/pull/23026 From liach at openjdk.org Fri Jan 10 20:39:43 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 20:39:43 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 20:25:06 GMT, Chen Liang wrote: >> Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review comments, also simplify Attribute I have pushed an update for the review comments and slightly simplified `Attribute`, and updated code review site and the CSR. Please review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23026#issuecomment-2584066907 From liach at openjdk.org Fri Jan 10 20:57:17 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 20:57:17 GMT Subject: [jdk24] RFR: 8342468: Improve API documentation for java.lang.classfile.constantpool Message-ID: This is a non-clean backport of bcefab5e55d4527a38dcab550581a734c1564608, because afe543414f58a04832d4f07dea88881d64954a0b which fixes a Javadoc link error was also included in this backport. This backports Javadoc improvements to the ClassFile API committed to mainline back to 24, the finalization release of the ClassFile API. Running tier 1-3 tests right now. ------------- Commit messages: - 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 - 8342468: Improve API documentation for java.lang.classfile.constantpool Changes: https://git.openjdk.org/jdk/pull/23046/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23046&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342468 Stats: 1139 lines in 31 files changed: 768 ins; 69 del; 302 mod Patch: https://git.openjdk.org/jdk/pull/23046.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23046/head:pull/23046 PR: https://git.openjdk.org/jdk/pull/23046 From darcy at openjdk.org Fri Jan 10 21:05:47 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 10 Jan 2025 21:05:47 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v3] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 05:51:12 GMT, Chen Liang wrote: >> `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use since-style versions Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22934#pullrequestreview-2543853880 From darcy at openjdk.org Fri Jan 10 21:05:47 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 10 Jan 2025 21:05:47 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 03:29:21 GMT, David Holmes wrote: > > Joe and David, can you look at this updated versioning that uses the core libraries since scheme? > > Yep that looks fine. Thanks. I think it is fine it its current form, but would be better also listing the class file format version: 1.1/45.3 1.2/46.0 etc. However, I'll approve the PR in it current state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22934#issuecomment-2584173589 From liach at openjdk.org Fri Jan 10 21:26:46 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 21:26:46 GMT Subject: RFR: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history [v3] In-Reply-To: References: Message-ID: <3MEd3w6OdcfMcNKMQazExjOyF81A4sdTUh_LrObr1JI=.26e42b52-6eac-4b22-a75d-d584a814d240@github.com> On Wed, 8 Jan 2025 05:51:12 GMT, Chen Liang wrote: >> `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Use since-style versions Technically this 45.0 vs 45.3 only matters for 1.0 vs 1.1; those are intricate details like "Oak classes" with u1 max stacks and locals which was removed from hotspot around JDK 14 or so and never part of the JVMS. Now we really only care about majors, and we have the majors in the enums themselves, so I wasn't too eager to jam up the list of versions with the major versions. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22934#issuecomment-2584263459 From liach at openjdk.org Fri Jan 10 21:26:47 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 21:26:47 GMT Subject: Integrated: 8347063: Add comments in ClassFileFormatVersion for class file format evolution history In-Reply-To: References: Message-ID: <4SkP4eV4HLDy-fxgXTDAJbHd4v6gcRPq9B5Xx_m1h3Q=.5c0e3520-a30f-43bb-bebb-dffa2aa252ab@github.com> On Mon, 6 Jan 2025 18:26:54 GMT, Chen Liang wrote: > `javax.lang.model.SourceVersion` has a series of comments describing the new language features present in each source version. Similar comments for the `ClassFileFormatVersion` would be helpful, so readers no longer need to search through the JVMS to find changes in new versions. This pull request has now been integrated. Changeset: 6f1f2f25 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/6f1f2f2537cd921e2c13c333c78c2ad8c599dcc3 Stats: 42 lines in 1 file changed: 41 ins; 0 del; 1 mod 8347063: Add comments in ClassFileFormatVersion for class file format evolution history Reviewed-by: darcy, iris ------------- PR: https://git.openjdk.org/jdk/pull/22934 From liach at openjdk.org Fri Jan 10 21:49:40 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 21:49:40 GMT Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications [v7] In-Reply-To: References: Message-ID: On Sun, 29 Dec 2024 01:06:36 GMT, Chen Liang wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Problems with owner type, kevin suggestions > > src/java.base/share/classes/java/lang/reflect/ParameterizedType.java line 124: > >> 122: * class or interface declaration} and have equal {@linkplain >> 123: * #getActualTypeArguments() type parameters}, including those from the >> 124: * {@linkplain #getOwnerType() enclosing classes}. > > ... if they are non-static nested types. (etc.) Not necessary on second thought. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19977#discussion_r1911476971 From liach at openjdk.org Fri Jan 10 21:53:20 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 10 Jan 2025 21:53:20 GMT Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications [v8] In-Reply-To: References: Message-ID: > The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts. > > A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`. > > To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate. > > Here are some actions: > 1. Add section for hierarchy overview for both Type and AnnotatedType > 2. Specify the underlying type for different AnnotatedType subinterfaces > 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`. > 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version > 5. Minor improvements to `ParameterizedType::getRawType` > 6. Move the equals specification for `ParameterizedType` to the actual `equals` method. > > ApiDiff: https://cr.openjdk.org/~liach/apidiff/types-facelift/java.base/java/lang/reflect/package-summary.html > Javadoc: https://cr.openjdk.org/~liach/javadoc/types-facelift/java.base/java/lang/reflect/package-summary.html > > Please review the associated CSR as well. Chen Liang 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 17 additional commits since the last revision: - Year and typos - Merge branch 'm5' into doc/owner-type - Problems with owner type, kevin suggestions - Slightly improve snippet - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type - Improve getRawType - Intro and other various improvements - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type - Cleanup - ... and 7 more: https://git.openjdk.org/jdk/compare/6e722b7a...4f4d9b91 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19977/files - new: https://git.openjdk.org/jdk/pull/19977/files/1306153e..4f4d9b91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=06-07 Stats: 64042 lines in 3874 files changed: 36532 ins; 17864 del; 9646 mod Patch: https://git.openjdk.org/jdk/pull/19977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977 PR: https://git.openjdk.org/jdk/pull/19977 From jpai at openjdk.org Sat Jan 11 01:56:36 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 11 Jan 2025 01:56:36 GMT Subject: RFR: 8346468: SM cleanup of common test library [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 17:10:03 GMT, Roger Riggs wrote: >> SM Cleanup of common test library test/lib/...: >> >> Remove unnecessary catches of SecurityException >> Remove AccessController and doPrivileged from SimpleSSLContext and ProcessTools. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Removal of SuppressWarning("removal") This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22814#pullrequestreview-2544396787 From headius at headius.com Sat Jan 11 02:31:41 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 10 Jan 2025 20:31:41 -0600 Subject: High cost of failed Math.*Exact calls In-Reply-To: References: Message-ID: On Fri, Dec 13, 2024 at 7:22?AM Raffaello Giulietti < raffaello.giulietti at oracle.com> wrote: > long high = Math.multiplyHigh(a, b); > long low = a * b; > if (high == 0) return low; > return "the big integer consisting of high and low"; > There's a flaw in this logic: the overflowed multiplication may result in a value greater than MAX_VALUE but less than 2^64-1 (unsigned int64 max) and those values need to be rejected. I believe checking for a sign change as follows covers that situation but please give me something better! long high = Math.multiplyHigh(value, other); long low = value * other; if (high == 0 && low >= 0 || value < 0 || high == 0 && other < 0) { return asFixnum(context, low); } Regarding an API change in JDK, what's the best process to make that happen? I've created one JEP before but this seems too small for that. We have had several proposals and I add one more here: * multiplyExact(long a, long b, long fail) returning fail to indicate overflow * multiplyExact(long a, long b, LongBinaryOperator o) calls o on overflow * multiplyExact(long a, long b, T exception) to allow pre-allocating an exception and avoiding the stack trace And we would add equivalent methods for the other *Exact operations. All of these forms would meet my needs (my LongBinaryOperator would also just throw a pre-allocated exception). -------------- next part -------------- An HTML attachment was scrubbed... URL: From headius at headius.com Sat Jan 11 02:48:22 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 10 Jan 2025 20:48:22 -0600 Subject: High cost of failed Math.*Exact calls In-Reply-To: References: Message-ID: On Fri, Jan 10, 2025 at 8:31?PM Charles Oliver Nutter wrote: > long high = Math.multiplyHigh(value, other); > long low = value * other; > if (high == 0 && low >= 0 || value < 0 || high == 0 && other < 0) { > return asFixnum(context, low); > } > This pasted weirdly... but it doesn't matter because there's an additional flaw: it will reject *all* negative results because the high 64 bits will be non-zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henryjen at openjdk.org Sat Jan 11 02:49:45 2025 From: henryjen at openjdk.org (Henry Jen) Date: Sat, 11 Jan 2025 02:49:45 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v3] In-Reply-To: <-QhN582ZLm6wkdTDRDZBdizuk7WBRtZqGBzHbB1_St8=.ac2047df-0eaf-48b5-b641-a58bb86fdf7e@github.com> References: <-QhN582ZLm6wkdTDRDZBdizuk7WBRtZqGBzHbB1_St8=.ac2047df-0eaf-48b5-b641-a58bb86fdf7e@github.com> Message-ID: On Wed, 8 Jan 2025 00:40:04 GMT, Henry Jen wrote: >> Improving option value handling to support passing argument value starts with "--". >> >> Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. >> --add-options --add-modules=jdk.incubator.concurrent >> --add-options=--add-modules=jdk.incubator.concurrent >> >> will cause JLink to report >> Error: no value given for --add-options >> as --add-modules is considered another option for JLink. >> >> After the fix, by using = will ensure the value is properly handled as argument value >> --add-options=--add-modules=jdk.incubator.concurrent > > Henry Jen 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'openjdk/master' into JDK-8303884 > - Use opt=value format when value is starting with -- > - Fix style > - add test > - 8303884: jlink --add-options plugin does not allow GNU style options to be provided I prefer to have a better error message which tell users what to do. Would something like following work? $ jlink --add-modules java.base --add-options --help Error: value for option --add-options starts with "--" should use --add-options= format $ jlink --add-modules --help --add-options --help Error: value for option --add-modules starts with "--" should use --add-modules= format ------------- PR Comment: https://git.openjdk.org/jdk/pull/22526#issuecomment-2585031849 From headius at headius.com Sat Jan 11 02:59:15 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 10 Jan 2025 20:59:15 -0600 Subject: High cost of failed Math.*Exact calls In-Reply-To: References: Message-ID: On Fri, Jan 10, 2025 at 8:48?PM Charles Oliver Nutter wrote: > This pasted weirdly... but it doesn't matter because there's an additional > flaw: it will reject *all* negative results because the high 64 bits will > be non-zero. > This version passes all my tests: if ((high == 0 && low >= 0) // result is within [0, MAX] || (high == -1 && low < 0)) { // result is within [MIN, 0) return low; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Sat Jan 11 06:09:10 2025 From: john.r.rose at oracle.com (John Rose) Date: Fri, 10 Jan 2025 22:09:10 -0800 Subject: High cost of failed Math.*Exact calls In-Reply-To: References: Message-ID: <6DF3BFA1-686C-48BD-91CC-7D11F42FE66D@oracle.com> On 13 Dec 2024, at 5:22, Raffaello Giulietti wrote: > For your specific multiplication use case you might try with > > long high = Math.multiplyHigh(a, b); > long low = a * b; > if (high == 0) return low; > return "the big integer consisting of high and low"; > > It might be possible that the multiplyHigh() and * on the same operands, when appearing adjacent to each other, get optimized to just one instruction. > And if not, they might be executed "in parallel" inside the CPU. Here?s a relevant RFE, not yet implemented: https://bugs.openjdk.org/browse/JDK-8285871 Math.multiplyHigh and multiply on same inputs can be computed faster if their computation is shared And FWIW, a lambda-based API could be made generic in the lambda result, so that the full BigInteger (or whatever) could be returned immediately: public static R multiplyExact(long x, long y, BiFunction recompute) { if () return x * y; return recompute(x, y); } That lambda can also cover use cases with throwing and sigils and nulls. To work efficiently it also needs some sort of box suppression, either by reliable inlining and EA, or by handling Long as a value class. For completeness, if we get primitives over generics, then we could also spell it with lower-case ?L?s: public static R multiplyExact(long x, long y, BiFunction recompute) { if () return x * y; return recompute(x, y); } From duke at openjdk.org Sat Jan 11 14:10:44 2025 From: duke at openjdk.org (fabioromano1) Date: Sat, 11 Jan 2025 14:10:44 GMT Subject: RFR: 8341402: BigDecimal's square root optimization [v31] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 14:56:02 GMT, fabioromano1 wrote: >> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it. >> >> The main steps of the algorithm are as follows: >> first argument reduce the value to an integer using the following relations: >> >> x = y * 10 ^ exp >> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even >> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd >> >> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result. >> >> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation. > > fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: > > An optimization This comment is to avoid closing this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2585280639 From jwaters at openjdk.org Sun Jan 12 09:31:48 2025 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 12 Jan 2025 09:31:48 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v7] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters 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 eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into unused > - Neater warning silencer in proc_md.h > - Revert _WIN32 workaround in log_messages.c > - Copyright in VersionInfo.cpp > - Remove neutralLangId in VersionInfo.cpp > - Remove global memHandle, would've liked to keep it as a comment :( > - Merge branch 'master' into unused > - 8342682 Keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2585658045 From syan at openjdk.org Mon Jan 13 03:06:09 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 13 Jan 2025 03:06:09 GMT Subject: [jdk24] RFR: 8347302: Mark test tools/jimage/JImageToolTest.java as flagless Message-ID: <7dooar8_-8E_DBbaSltN1pexdsG3IeltgxU6wS0Q9P0=.c376b363-9d5d-4d87-969e-3999b02fc0c8@github.com> Hi all, This pull request contains a backport of commit [e7e8f60c](https://github.com/openjdk/jdk/commit/e7e8f60c9bedd5622525cc4339300b438eedc9fd) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. Test test/jdk/tools/jimage/JImageToolTest.java ignore vm flags and should be marked as flagless. The commit being backported was authored by Leonid Mesnik on 10 Jan 2025 and was reviewed by Alan Bateman and Aleksey Shipilev. Thanks! ------------- Commit messages: - Backport e7e8f60c9bedd5622525cc4339300b438eedc9fd Changes: https://git.openjdk.org/jdk/pull/23058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347302 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23058/head:pull/23058 PR: https://git.openjdk.org/jdk/pull/23058 From dholmes at openjdk.org Mon Jan 13 04:55:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Jan 2025 04:55:37 GMT Subject: RFR: 8346986: Remove ASM from java.base [v6] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 16:12:54 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright years Like @magicus I am also having some doubts about the ability of jtreg to manage this. In particular the test/hotspot/jtreg/runtime/SelectionResolution/ tests. The testcases in these tests do not use ASM themselves, ASM is used by the selectionresolution/classes library that is also used by the tests. I'm not even clear how the library directives are making this work. There is also the overhead as Magnus raised as we know jtreg does not handle compilation dependencies the way we would expect. That said I'm okay with looking at using an ASM binary jar as a follow-up to this, provided we do not get a lot of failures triggered by this change. To that end I would want to see full tiers 1-8 testing carried out before this gets integrated. Using an ASM jar could either be a downstream dependency as Magnus suggested, or we could pre-build into the test-image as part of Leonid's work in that area. ------------- PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2545705480 From dholmes at openjdk.org Mon Jan 13 06:04:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Jan 2025 06:04:42 GMT Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3] In-Reply-To: References: Message-ID: <90L-N_yB8R9WfOVhMC7FM0StbeiRMz9DMa93apWR7R0=.33263ced-4a96-42a7-a89f-0a4ecdd7daa9@github.com> On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf wrote: >> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK. >> >> Testing: >> - [x] GHA >> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder. >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Expand comment Sorry for the tardy response - the updated comment looks good. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2586229113 From alanb at openjdk.org Mon Jan 13 06:54:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Jan 2025 06:54:50 GMT Subject: RFR: 8346986: Remove ASM from java.base [v3] In-Reply-To: References: <2cF92ctzWrGfVABtPmlxEhTZolbXtjksk3Lub7aICOw=.1698fd6b-d0e3-4a27-ada7-86a5942c3d25@github.com> Message-ID: On Fri, 10 Jan 2025 15:39:20 GMT, Adam Sotona wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> removed jdk.internal package prefix from asm > > Thanks for the reviews. I'll update the copyright years and run again tier1 - 4 tests (just to be sure). > > Jtreg seems to have no problems to use ASM as a declared library. This PR primary purpose is to remove the ASM from java.base. Further improvements of hotspot tests using ASM can follow. However I would prefer to see further conversions of the hotspot tests to use Class-File API instead. Long-term goal is to remove ASM from JDK completely. > > FYI: Regarding the merge of this PR I've been asked to wait until some downstream projects dependent on jdk.internal.objectweb.asm are fixed. @asotona Can you add to your list to move src/java.base/share/legal/asm.md so that it's not included in the JDK build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586328809 From asotona at openjdk.org Mon Jan 13 07:06:46 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Jan 2025 07:06:46 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 20:25:06 GMT, Chen Liang wrote: >> Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review comments, also simplify Attribute Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23026#pullrequestreview-2545855283 From asotona at openjdk.org Mon Jan 13 07:40:06 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Jan 2025 07:40:06 GMT Subject: RFR: 8346986: Remove ASM from java.base [v7] In-Reply-To: References: Message-ID: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: removed asm.md ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22946/files - new: https://git.openjdk.org/jdk/pull/22946/files/d3559630..72ed71d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=05-06 Stats: 36 lines in 1 file changed: 0 ins; 36 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946 PR: https://git.openjdk.org/jdk/pull/22946 From mbaesken at openjdk.org Mon Jan 13 07:50:46 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Jan 2025 07:50:46 GMT Subject: RFR: 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo [v3] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 11:22:31 GMT, Matthias Baesken wrote: >> The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove blank Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23013#issuecomment-2586411570 From mbaesken at openjdk.org Mon Jan 13 07:50:46 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Jan 2025 07:50:46 GMT Subject: Integrated: 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 16:47:18 GMT, Matthias Baesken wrote: > The functions unix_getParentPidAndTimings and unix_getCmdlineAndUserInfo in src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c used to hold an implementation that was shared between Solaris and AIX. Linux and MacOS already had specific implementations. After the removal of the Solaris port, these two functions can be removed in favor of inline implementations of os_getParentPidAndTimings and os_getCmdlineAndUserInfo in src/java.base/aix/native/libjava/ProcessHandleImpl_aix.c. This pull request has now been integrated. Changeset: 1f7925ce Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/1f7925ceb4460b1052c93969749a52487bf133fc Stats: 434 lines in 4 files changed: 180 ins; 245 del; 9 mod 8347270: Remove unix_getParentPidAndTimings, unix_getChildren and unix_getCmdlineAndUserInfo Reviewed-by: rriggs, clanger, jkern ------------- PR: https://git.openjdk.org/jdk/pull/23013 From asotona at openjdk.org Mon Jan 13 07:54:41 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Jan 2025 07:54:41 GMT Subject: RFR: 8346986: Remove ASM from java.base [v7] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 07:40:06 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed asm.md Across JDK tests I see two tests use @library pointing to compiled jars, however in both cases the jars are a part of the tests source tree. Is there a way to pre-compile a test library and point related tests (or maybe all hotspot tests) to the library jar? FYI: I've triggered full tiers 1 - 8 testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586419903 From alanb at openjdk.org Mon Jan 13 08:01:43 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Jan 2025 08:01:43 GMT Subject: RFR: 8346986: Remove ASM from java.base [v7] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 07:40:06 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed asm.md I see you've removed asm.md in 72ed71d but I assume it should move to the test tree. skynet.md and acvp.md are two examples to look at. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586429925 From asotona at openjdk.org Mon Jan 13 08:14:08 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Jan 2025 08:14:08 GMT Subject: RFR: 8346986: Remove ASM from java.base [v8] In-Reply-To: References: Message-ID: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: moved asm.md to the testlibrary/asm ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22946/files - new: https://git.openjdk.org/jdk/pull/22946/files/72ed71d6..92b93fc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22946&range=06-07 Stats: 36 lines in 1 file changed: 36 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22946.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22946/head:pull/22946 PR: https://git.openjdk.org/jdk/pull/22946 From asotona at openjdk.org Mon Jan 13 08:14:08 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Jan 2025 08:14:08 GMT Subject: RFR: 8346986: Remove ASM from java.base [v7] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 07:40:06 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > removed asm.md > I see you've removed asm.md in [72ed71d](https://github.com/openjdk/jdk/commit/72ed71d6bcc570b600ac7c591e7b6d69a3bf2559) but I assume it should move to the test tree. skynet.md and acvp.md are two examples to look at. Oh, right, thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586440763 From asotona at openjdk.org Mon Jan 13 08:44:49 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Jan 2025 08:44:49 GMT Subject: [jdk24] RFR: 8342468: Improve API documentation for java.lang.classfile.constantpool In-Reply-To: References: Message-ID: <11XyLxvFMRoQCepI9-oPF-OX14Njkck-g_--uE779YI=.f6d4857d-a6d1-4599-909b-db4a4dcc7802@github.com> On Fri, 10 Jan 2025 20:50:20 GMT, Chen Liang wrote: > This is a non-clean backport of bcefab5e55d4527a38dcab550581a734c1564608, because afe543414f58a04832d4f07dea88881d64954a0b which fixes a Javadoc link error was also included in this backport. This backports Javadoc improvements to the ClassFile API committed to mainline back to 24, the finalization release of the ClassFile API. > > Running tier 1-3 tests right now. Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23046#pullrequestreview-2546008163 From pminborg at openjdk.org Mon Jan 13 09:04:25 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Jan 2025 09:04:25 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v4] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove thread test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/67a1deae..a1f3c723 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=02-03 Stats: 105 lines in 1 file changed: 0 ins; 105 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From jbhateja at openjdk.org Mon Jan 13 09:06:12 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 13 Jan 2025 09:06:12 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v10] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22754/files - new: https://git.openjdk.org/jdk/pull/22754/files/175f4ed2..43aa3eb7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=08-09 Stats: 22 lines in 5 files changed: 5 ins; 2 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From jbhateja at openjdk.org Mon Jan 13 09:06:13 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 13 Jan 2025 09:06:13 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> References: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> Message-ID: <88_pE_E7P1iOkpSUuLuou6wH9UxWvPx83MFo033dY2Y=.d942086a-e87f-45dd-8c1d-72b8fd9c85d6@github.com> On Thu, 9 Jan 2025 13:13:30 GMT, Emanuel Peter wrote: >> Jatin Bhateja 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: >> >> Updating copyright year of modified files. > > src/hotspot/share/opto/superword.cpp line 2567: > >> 2565: // half float to float, in such a case back propagation of narrow type (SHORT) >> 2566: // may not be possible. >> 2567: if (n->Opcode() == Op_ConvF2HF || n->Opcode() == Op_ReinterpretHF2S) { > > Is this relevant, or does that belong to a different (vector) RFE? It makes sure to assign a SHORT container type to the ReinterpretHF2S node which could be succeeded by a ConvHF2F IR which expects its inputs to be of SHORT type. During early phase of SLP extraction we get into a control flow querying the implemented vector IR opcode through split_packs_only_implemented_with_smaller_size https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vectornode.cpp#L1446 This scenario is tested by following JTREG [test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java](https://github.com/openjdk/jdk/pull/22754/files#diff-7e7404a977d8ca567f8005b80bd840ea2e722c022e7187fa2dd21df4a5837faaR49) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1912858395 From jbhateja at openjdk.org Mon Jan 13 09:06:14 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 13 Jan 2025 09:06:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: References: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> Message-ID: On Thu, 9 Jan 2025 19:22:35 GMT, Paul Sandoz wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1434: >> >>> 1432: return float16ToRawShortBits(valueOf(product + float16ToFloat(f16c))); >>> 1433: }); >>> 1434: return shortBitsToFloat16(res); >> >> I don't understand what is happening here. But I leave this to @PaulSandoz to review > > Uncertain on what bits, but i am guessing it's mostly related to the fallback code in the lambda. To avoid the intrinsics operating on Float16 instances we instead "unpack" the carrier (16bits) values and pass those as arguments to the intrinsic. The fallback (when intrinsification is not supported) also accepts those carrier values as arguments and we convert the carriers to floats, operate on then, convert to the carrier, and then back to float16 on the result. > > The code in the lambda could potentially be simplified if `Float16Math.fma` accepted six arguments the first three being the carrier values used by the intrinsic, and the subsequent three being the float16 values used by the fallback. Then we could express the code in the original source in the lambda. I believe when intrinsified there would be no penalty for those extra arguments. Hi @PaulSandoz , In the current scheme we are passing unboxed carriers to intrinsic entry point, in the fallback implementation carrier type is first converted to floating point value using Float.float16ToFloat API which expects to receive a short type argument, after the operation we again convert float value to carrier type (short) using Float.floatToFloat16 API which expects a float argument, thus our intent here is to perform unboxing and boxing outside the intrinsic thereby avoiding all complexities around boxing by compiler. Even if we pass 3 additional parameters we still need to use Float16.floatValue which invokes Float.float16ToFloat underneath, thus this minor modification on Java side is on account of optimizing the intrinsic interface. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1912858286 From sgehwolf at openjdk.org Mon Jan 13 09:29:53 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 13 Jan 2025 09:29:53 GMT Subject: Integrated: 8345185: Update jpackage to not include service bindings by default In-Reply-To: References: Message-ID: On Mon, 9 Dec 2024 12:57:22 GMT, Severin Gehwolf wrote: > Please review these changes to jpackage in light of [JEP 493](https://openjdk.org/jeps/493). When this feature is enabled, then some of the `jpackage` tests fail. The failures fall into the following categories: > > - `ALL-DEFAULT` notion from `jpackage` which includes all modules that export an API, which includes `jdk.jlink`, which is prevented from being included when linking from the run-time image (see the [JEP 493](https://openjdk.org/jeps/493) restrictions). The proposal is to change module resolution from `Configuration.resolveAndBind()` to `Configuration.resolve()`. I.e. don't perform service binding which is in line what [JEP 392](https://openjdk.org/jeps/392) and [JEP 343](https://openjdk.org/jeps/343) claim. That is, this patch brings the implementation aligned to what it says on the JEPs > - `ALL-MODULE-PATH` changes: `BasicTest.java` verifies the `--add-modules` argument to `jpackage`. Using `ALL-MODULE-PATH` for JDK modules won't be supported for JEP 493-enabled builds. So I've changed this test to skip the test using `ALL-MODULE-PATH` when we have such an enabled build. Other tests, such as `RuntimeImageTest.java` and `RuntimeImageSymbolicLinksTest.java` tests verify something else not related to `ALL-MODULE-PATH` or `--add-modules`. It seems more appropriate to use the smaller set of modules to use for the runtime JDK image. > - `JLinkOptionsTest.java`: That test verifies options passed to `jlink` via the `ToolProvider` API. For some reason, it uses `--bind-services` extensively and that - in turn - and, when not limited with the `--limit-modules` option as well, will include `jdk.jlink` in the resulting image, again running afoul the JEP 493 restriction of not allowing `jdk.jlink` for now. I propose to use suitable options including `--limit-modules` which would then no longer include `jdk.jlink` in the runtime image and the link from a run-time image works as well. These changes depend on [JDK-8345573](https://bugs.openjdk.org/browse/JDK-8345573) for it to work fully. > > Testing: > - [x] GHA > - [x] running tests in `test/jdk/tools/jpackage` on a JEP 493 enabled JDK. As far as I could see the failures that I was seeing weren't any more related to JEP 493 (some RPM requirements showing up that it didn't expect to). > > Thoughts? Opinions? This pull request has now been integrated. Changeset: 85ed78c0 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/85ed78c063493259247d88f5ca51b47b7a45fcb0 Stats: 60 lines in 7 files changed: 36 ins; 11 del; 13 mod 8345185: Update jpackage to not include service bindings by default Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/22644 From pminborg at openjdk.org Mon Jan 13 10:05:23 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Jan 2025 10:05:23 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v5] In-Reply-To: References: Message-ID: <5dcgcA6buldQvbVHAZ5WyH8uhZo24oElgCQBgR2Cms8=.a2c97f2b-cfcb-40d6-9723-88c2d1f868a6@github.com> > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/a1f3c723..4821c2f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=03-04 Stats: 116 lines in 1 file changed: 116 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From pminborg at openjdk.org Mon Jan 13 10:11:27 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Jan 2025 10:11:27 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitFail avgt 30 42.184 ? 0.998 ns/op > CaptureStateUtilBench.explicitSuccess avgt 30 42.278 ? 1.490 ns/op > CaptureStateUtilBench.tlFail avgt 30 23.594 ? 0.774 ns/op > CaptureStateUtilBench.tlSuccess avgt 30 12.135 ? 0.107 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Clean up benchmark - Fix allocation problem in benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/4821c2f2..f128c912 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=04-05 Stats: 11 lines in 1 file changed: 2 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From pminborg at openjdk.org Mon Jan 13 10:17:47 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Jan 2025 10:17:47 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 09:41:34 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Clean up benchmark >> - Fix allocation problem in benchmark > > src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 50: > >> 48: private static final long SIZE = Linker.Option.captureStateLayout().byteSize(); >> 49: >> 50: private static final TerminatingThreadLocal TL = new TerminatingThreadLocal<>() { > > TerminatingThreadLocal is carrier-local so the usage here will require a detailed walk through to make sure that a virtual thread cannot be preempted when it has access to this memory segment. Identifying preemption is hard and will often during startup/first-use. So while tempting to use TerminatingThreadLocal here, I think we will have to do more work on it before it can more widely used in java.base. Right. So, I have added this issue: https://bugs.openjdk.org/browse/JDK-8347537 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1912954825 From vklang at openjdk.org Mon Jan 13 10:40:45 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 13 Jan 2025 10:40:45 GMT Subject: Integrated: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: References: Message-ID: <0fmXkPb3ajcPokNiMZ1cDhAJov6Q8SWUd95WeqmA-QA=.60ee6884-a16b-4b64-97ad-7948aa1f0772@github.com> On Thu, 9 Jan 2025 10:13:52 GMT, Viktor Klang wrote: > The following patch updates Gatherers.mapConcurrent to limit work-in-progress (on-going and completed-unpushed) to the `maxConcurrency` so that head-of-line blocking does not cause completed-unpushed work to grow unbounded. > > This also simplifies interruption handling to ignore-and-restore, which needs to be done on a per-element-basis as the calling thread can change between invocations of the integrator, as well as the finisher, so restoring it on finish is not possible (and won't happen if there's an exception thrown during integration anyway). > > Furthermore, logic has been added to reduce the risk of any spawned virtual threads surviving the processing of the stream. This pull request has now been integrated. Changeset: 450636ae Author: Viktor Klang URL: https://git.openjdk.org/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e Stats: 148 lines in 2 files changed: 93 ins; 16 del; 39 mod 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/22999 From sgehwolf at openjdk.org Mon Jan 13 10:50:43 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 13 Jan 2025 10:50:43 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 19:39:34 GMT, Archie Cobbs wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback > > (Getting into marginal returns on comments here, so my apologies for nitpicking) > > The loop could be simplified even further... > > while (true) { > int bytesRead1 = is1.readNBytes(buf1, 0, buf1.length); > int bytesRead2 = is2.readNBytes(buf2, 0, buf2.length); > if (!Arrays.equals(buf1, 0, bytesRead1, buf2, 0, bytesRead2)) > return false; > if (bytesRead1 == 0) > return true; > } @archiecobbs @AlanBateman Any thoughts? Is this good to go? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23014#issuecomment-2586767737 From pminborg at openjdk.org Mon Jan 13 11:07:11 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 13 Jan 2025 11:07:11 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitFail avgt 30 42.061 ? 1.261 ns/op > CaptureStateUtilBench.explicitSuccess avgt 30 23.142 ? 0.739 ns/op > CaptureStateUtilBench.tlFail avgt 30 23.580 ? 0.267 ns/op > CaptureStateUtilBench.tlSuccess avgt 30 1.753 ? 0.016 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/3cf122bb-0ed6-4dd6-ab6d-dcada0147efb) > > This is a >10x improvement on the happy path. > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Update benchmark and micro optimize ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/f128c912..fe12661a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=05-06 Stats: 6 lines in 2 files changed: 3 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From mcimadamore at openjdk.org Mon Jan 13 11:09:37 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Jan 2025 11:09:37 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 10:11:27 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitFail avgt 30 42.061 ? 1.261 ns/op >> CaptureStateUtilBench.explicitSuccess avgt 30 23.142 ? 0.739 ns/op >> CaptureStateUtilBench.tlFail avgt 30 23.580 ? 0.267 ns/op >> CaptureStateUtilBench.tlSuccess avgt 30 1.753 ? 0.016 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/3cf122bb-0ed6-4dd6-ab6d-dcada0147efb) >> >> This is a >10x improvement on the happy path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Clean up benchmark > - Fix allocation problem in benchmark src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 214: > 212: // Used reflectively by `getAsIntHandle(MemoryLayout layout)` > 213: private static int getStateAsInt(VarHandle handle) { > 214: if (Thread.currentThread().isVirtual() && ContinuationSupport.isSupported()) { Shouldn't we pin for the entire duration of the native call + errno retrieval? Otherwise, can't we end up in a situation where we have a back to back native call where the second native call overwrites the errno state of the first? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1913019319 From mcimadamore at openjdk.org Mon Jan 13 11:16:43 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 Jan 2025 11:16:43 GMT Subject: RFR: 8346778: Enable native access should work with the source launcher [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 20:29:03 GMT, Christian Stein wrote: >> Please review this change request enabling native access in source launch mode when using a modular setup. >> >> The change comes in two parts: >> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java` >> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java` >> >> _Testing of tier1..3 is in progress..._ > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Ignore already handled `ALL-UNNAMED` name The handling of the new option seems correct: * `ALL-UNNAMED` is already handled by module bootstrap, so left alone * source modules are correctly handled * `illegal-native-access` is a runtime option, so again, not handled (which is ok) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2586824078 From cstein at openjdk.org Mon Jan 13 11:29:06 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 13 Jan 2025 11:29:06 GMT Subject: RFR: 8346778: Enable native access should work with the source launcher [v3] In-Reply-To: References: Message-ID: <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com> > Please review this change request enabling native access in source launch mode when using a modular setup. > > The change comes in two parts: > 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java` > 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java` > > _Testing of tier1..3 is in progress..._ Christian Stein has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java - Update src/java.base/share/native/libjli/java.c [skip ci] - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java [skip ci] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22930/files - new: https://git.openjdk.org/jdk/pull/22930/files/7c615966..6ff0cd30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22930&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22930&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22930.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22930/head:pull/22930 PR: https://git.openjdk.org/jdk/pull/22930 From cstein at openjdk.org Mon Jan 13 11:29:07 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 13 Jan 2025 11:29:07 GMT Subject: RFR: 8346778: Enable native access should work with the source launcher [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 20:29:03 GMT, Christian Stein wrote: >> Please review this change request enabling native access in source launch mode when using a modular setup. >> >> The change comes in two parts: >> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java` >> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java` >> >> _Testing of tier1..3 is in progress..._ > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Ignore already handled `ALL-UNNAMED` name Submit improvements as suggested. src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 838: > 836: * command line option, and also to JDK modules that need the access. > 837: *

> 838: * In case of being in "source" launchmode, warnings about unknown modules are Suggestion: * In case of being in "source" launcher mode, warnings about unknown modules are src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 844: > 842: private static void addEnableNativeAccess(ModuleLayer layer) { > 843: String launchMode = getAndRemoveProperty("jdk.internal.java.launchmode"); > 844: boolean shouldWarn = !"source".equals(launchMode); Suggestion: String launcherMode = getAndRemoveProperty("sun.java.launcher.mode"); boolean shouldWarn = !"source".equals(launcherMode); src/java.base/share/native/libjli/java.c line 1376: > 1374: if (mode == LM_SOURCE) { > 1375: // signal module bootstrap to defer warnings about unknown modules > 1376: AddOption("-Djdk.internal.java.launchmode=source", NULL); Suggestion: // communicate the launcher mode to runtime AddOption("-Dsun.java.launcher.mode=source", NULL); ------------- PR Review: https://git.openjdk.org/jdk/pull/22930#pullrequestreview-2546345699 PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1913035292 PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1913038153 PR Review Comment: https://git.openjdk.org/jdk/pull/22930#discussion_r1913037463 From ihse at openjdk.org Mon Jan 13 12:20:44 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 13 Jan 2025 12:20:44 GMT Subject: RFR: 8346986: Remove ASM from java.base [v7] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 07:52:08 GMT, Adam Sotona wrote: > Is there a way to pre-compile a test library and point related tests (or maybe all hotspot tests) to the library jar? My initial thought was just to add the jar to the classpath, but maybe it is better to use an explicit `@library` tag. I guess we need to check how jtreg works, if it is possible to have it look for libraries outside the test root. Maybe we can send in an additional path in which to look for libraries as an argument. (Or maybe jtreg can be fixed to accept such a path.) If that works, then the build system can provide the "glue" to accept in an argument to configure pointing out the ASM jar, and then pass it on to jtreg. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2586954447 From ihse at openjdk.org Mon Jan 13 12:22:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 13 Jan 2025 12:22:53 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman wrote: >>> Thanks for making the changes. LGTM, assuming that tests still pass. >> >> The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating. > >> The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating. > > Can you hold off integrating, I plan to go over the changes soon. @AlanBateman I think what is holding this PR back is that you said you wanted to review it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2586958882 From ihse at openjdk.org Mon Jan 13 12:27:44 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 13 Jan 2025 12:27:44 GMT Subject: Integrated: 8346377: Properly support static builds for Windows In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 15:41:51 GMT, Magnus Ihse Bursie wrote: > When the static launcher was introduced in [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and resource constraints, it was only working properly on Linux and macOS, while the Windows port compiled but did not work. Now the time has come to fix that. > > Most of the changes mirrors the kind of changes that were made for Linux and macOS in JDK-8339480. There are still limitations to static builds on Windows (e.g. starting with a splashscreen), but these kind of limitations also exists on the other platforms. > > Note that this PR is blocked by [JDK-8346433](https://bugs.openjdk.org/browse/JDK-8346433), [JDK-8346195](https://bugs.openjdk.org/browse/JDK-8346195), [JDK-8346378](https://bugs.openjdk.org/browse/JDK-8346378), [JDK-8346383](https://bugs.openjdk.org/browse/JDK-8346383), [JDK-8346388](https://bugs.openjdk.org/browse/JDK-8346388) and [JDK-8346394](https://bugs.openjdk.org/browse/JDK-8346394), which must be integrated before this one. This pull request has now been integrated. Changeset: c885e59c Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/c885e59cfaeaab98bd05ec1ea54441d8e7c8268a Stats: 59 lines in 5 files changed: 38 ins; 4 del; 17 mod 8346377: Properly support static builds for Windows Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/22795 From alanb at openjdk.org Mon Jan 13 12:37:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Jan 2025 12:37:38 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v7] In-Reply-To: References: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com> Message-ID: On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman wrote: >>> Thanks for making the changes. LGTM, assuming that tests still pass. >> >> The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating. > >> The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating. > > Can you hold off integrating, I plan to go over the changes soon. > @AlanBateman I think what is holding this PR back is that you said you wanted to review it. I asked Brian to hold off integrating this as I need time to work through several issues. Note that this is just one part of overall solution, we don't know yet if this changes in this PR will help the startup issue that motivated it (in isolation, the changes in this PR don't make sense of course). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2586989708 From vklang at openjdk.org Mon Jan 13 13:04:21 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 13 Jan 2025 13:04:21 GMT Subject: [jdk24] RFR: 8347542: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing Message-ID: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> Backport to jdk24 of https://bugs.openjdk.org/browse/JDK-8347274 ------------- Commit messages: - 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing Changes: https://git.openjdk.org/jdk/pull/23068/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23068&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347542 Stats: 148 lines in 2 files changed: 93 ins; 16 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/23068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23068/head:pull/23068 PR: https://git.openjdk.org/jdk/pull/23068 From ihse at openjdk.org Mon Jan 13 13:25:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 13 Jan 2025 13:25:51 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v11] In-Reply-To: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com> References: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@github.com> Message-ID: <3a81ilsvQuU-PhG4LjAyj2mri7Yn2XikJgpmk3nwAro=.27e1ca09-4d2d-45e5-bbaa-3024450d6d39@github.com> On Thu, 5 Dec 2024 18:44:06 GMT, Brian Burkhalter wrote: >> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge > - Merge > - Merge > - 8337143: Minor makefile tweak > - 8337143: Clean up to address reviewer comments > - Merge > - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c > - Merge > - 8337143: Removed dependency of libjava on headers in libnio/ch > - 8337143: Move natives to /native/libjava/nio/{ch,fs} as a function of their original location in libnio > - ... and 1 more: https://git.openjdk.org/jdk/compare/bedb68ab...2cb82267 I see. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2587094183 From asotona at openjdk.org Mon Jan 13 13:26:45 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 13 Jan 2025 13:26:45 GMT Subject: RFR: 8346986: Remove ASM from java.base [v8] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > moved asm.md to the testlibrary/asm I did some manual benchmarking and created two sets of 100 no-op Jtreg tests. The first set references compiled j.l.classfile.ClassModel and the second set references org.objectweb.asm.ClassWriter declared as a @library. The difference in execution of the tests is ~3 seconds on my computer (~30ms per test). Given the limited number of tests affected, I would estimate that the overall performance regression will be in the single digit seconds range. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2587096026 From alanb at openjdk.org Mon Jan 13 13:26:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Jan 2025 13:26:45 GMT Subject: [jdk24] RFR: 8347542: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> References: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> Message-ID: On Mon, 13 Jan 2025 12:59:06 GMT, Viktor Klang wrote: > Backport to jdk24 of https://bugs.openjdk.org/browse/JDK-8347274 Did you use "/backport" or is this a manual back port? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23068#issuecomment-2587096942 From mbaesken at openjdk.org Mon Jan 13 14:01:49 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 13 Jan 2025 14:01:49 GMT Subject: RFR: 8346869: [AIX] Add regression test for handling 4 Byte aligned doubles in structures In-Reply-To: References: Message-ID: On Sat, 28 Dec 2024 18:43:30 GMT, Martin Doerr wrote: > [JDK-8317545](https://bugs.openjdk.org/browse/JDK-8317545) introduced code for supporting 4 Byte aligned doubles: https://github.com/openjdk/jdk/blob/60e0730a3ba26180d0eb2cd278e389c3e70fec5f/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java#L59 > We should test this case. The new test can serve as an example implementation for handling such structures in Java code such that it works on all platforms including AIX. looks okay, guess you have to adjust the COPYRIGHT year now to 2025 . ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22889#pullrequestreview-2546691078 From mdoerr at openjdk.org Mon Jan 13 14:05:46 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 13 Jan 2025 14:05:46 GMT Subject: RFR: 8346869: [AIX] Add regression test for handling 4 Byte aligned doubles in structures In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 13:58:43 GMT, Matthias Baesken wrote: > looks okay, guess you have to adjust the COPYRIGHT year now to 2025 . Only if I make more modifications. No files were changed in 2025. The update script says "No files were changed". But, thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22889#issuecomment-2587190425 From jkern at openjdk.org Mon Jan 13 14:16:40 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 13 Jan 2025 14:16:40 GMT Subject: RFR: 8346869: [AIX] Add regression test for handling 4 Byte aligned doubles in structures In-Reply-To: References: Message-ID: On Sat, 28 Dec 2024 18:43:30 GMT, Martin Doerr wrote: > [JDK-8317545](https://bugs.openjdk.org/browse/JDK-8317545) introduced code for supporting 4 Byte aligned doubles: https://github.com/openjdk/jdk/blob/60e0730a3ba26180d0eb2cd278e389c3e70fec5f/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java#L59 > We should test this case. The new test can serve as an example implementation for handling such structures in Java code such that it works on all platforms including AIX. C Code LGTM ------------- Marked as reviewed by jkern (Committer). PR Review: https://git.openjdk.org/jdk/pull/22889#pullrequestreview-2546739414 From mdoerr at openjdk.org Mon Jan 13 14:20:46 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 13 Jan 2025 14:20:46 GMT Subject: RFR: 8346869: [AIX] Add regression test for handling 4 Byte aligned doubles in structures In-Reply-To: References: Message-ID: On Sat, 28 Dec 2024 18:43:30 GMT, Martin Doerr wrote: > [JDK-8317545](https://bugs.openjdk.org/browse/JDK-8317545) introduced code for supporting 4 Byte aligned doubles: https://github.com/openjdk/jdk/blob/60e0730a3ba26180d0eb2cd278e389c3e70fec5f/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java#L59 > We should test this case. The new test can serve as an example implementation for handling such structures in Java code such that it works on all platforms including AIX. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22889#issuecomment-2587227005 From acobbs at openjdk.org Mon Jan 13 14:25:53 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 13 Jan 2025 14:25:53 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v2] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 10:47:41 GMT, Severin Gehwolf wrote: >> (Getting into marginal returns on comments here, so my apologies for nitpicking) >> >> The loop could be simplified even further... >> >> while (true) { >> int bytesRead1 = is1.readNBytes(buf1, 0, buf1.length); >> int bytesRead2 = is2.readNBytes(buf2, 0, buf2.length); >> if (!Arrays.equals(buf1, 0, bytesRead1, buf2, 0, bytesRead2)) >> return false; >> if (bytesRead1 == 0) >> return true; >> } > > @archiecobbs @AlanBateman Any thoughts? Is this good to go? Thanks! Hi @jerboaa, LGMT - my comments are addressed (thanks :) I'm not an official reviewer though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23014#issuecomment-2587238153 From vklang at openjdk.org Mon Jan 13 14:27:42 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 13 Jan 2025 14:27:42 GMT Subject: [jdk24] RFR: 8347542: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: References: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> Message-ID: On Mon, 13 Jan 2025 13:24:10 GMT, Alan Bateman wrote: >> Backport to jdk24 of https://bugs.openjdk.org/browse/JDK-8347274 > > Did you use "/backport" or is this a manual back port? @AlanBateman I did a manual backport since there was a merge conflict (on the copyright notice change). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23068#issuecomment-2587244966 From alanb at openjdk.org Mon Jan 13 14:38:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Jan 2025 14:38:41 GMT Subject: [jdk24] RFR: 8347542: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> References: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> Message-ID: <9O9Jzkc3YKZlFvBJPzTYO9fHr6ErI2S8UM94ycfcRUs=.ca37022e-a9be-4030-ba4c-d9312fca1779@github.com> On Mon, 13 Jan 2025 12:59:06 GMT, Viktor Klang wrote: > Backport to jdk24 of https://bugs.openjdk.org/browse/JDK-8347274 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23068#pullrequestreview-2546813506 From galder at openjdk.org Mon Jan 13 15:37:44 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 13 Jan 2025 15:37:44 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Thu, 9 Jan 2025 12:18:48 GMT, Emanuel Peter wrote: >> @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`) > > @galderz So you want me to review again? @eme64 Yes please ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2587450313 From syan at openjdk.org Mon Jan 13 15:40:46 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 13 Jan 2025 15:40:46 GMT Subject: RFR: 8345016: [ASAN] java.c reported =?UTF-8?B?4oCYJXPigJk=?= directive argument is null [-Werror=format-truncation=] [v3] In-Reply-To: References: Message-ID: On Mon, 16 Dec 2024 12:47:13 GMT, SendaoYan wrote: >> Hi all, >> The file src/java.base/share/native/libjli/java.c generate compile warning by gcc14 with gcc options `-fsanitize=undefined -O2`, and make jdk build error when configure with option `--enable-ubsan`. So I think it's necessory to make gcc quiet and make jdk build normally with configure option `--enable-ubsan`. >> >> This PR add `NULL` check for `s` after call `s = JLI_WildcardExpandClasspath(s);` to make gcc quiet. There is another solution to disable the compile warning seen as below, but it will disable the compile warning of java.c. So I use the first solution. >> >> >> >> diff --git a/make/modules/java.base/lib/CoreLibraries.gmk b/make/modules/java.base/lib/CoreLibraries.gmk >> index 61ac495968a..5bc83cf0978 100644 >> --- a/make/modules/java.base/lib/CoreLibraries.gmk >> +++ b/make/modules/java.base/lib/CoreLibraries.gmk >> @@ -178,6 +178,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJLI, \ >> OPTIMIZATION := HIGH, \ >> CFLAGS := $(LIBJLI_CFLAGS) $(LIBZ_CFLAGS), \ >> DISABLED_WARNINGS_gcc := unused-function unused-variable, \ >> + DISABLED_WARNINGS_gcc_java.c := format-truncation, \ >> DISABLED_WARNINGS_clang := deprecated-non-prototype format-nonliteral \ >> unused-function, \ >> DISABLED_WARNINGS_clang_java_md_macosx.m := unused-variable, \ > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add NULL check after call "s = JLI_WildcardExpandClasspath(s);" Hi all, This PR add an extra `NULL` check after call `s = JLI_WildcardExpandClasspath(s);` to make gcc sanitizer slient. I think it's no risk. Can anyone take look this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22546#issuecomment-2587457516 From galder at openjdk.org Mon Jan 13 15:45:46 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 13 Jan 2025 15:45:46 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Thu, 9 Jan 2025 12:18:48 GMT, Emanuel Peter wrote: >> @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`) > > @galderz So you want me to review again? @eme64 I've noticed some failures in CI, I'll check those and ping you when it's ready for a review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2587472207 From ihse at openjdk.org Mon Jan 13 16:04:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 13 Jan 2025 16:04:51 GMT Subject: RFR: 8346986: Remove ASM from java.base [v8] In-Reply-To: References: Message-ID: <929j76hroJpqOdYZuJWij42cPeWBNXfYTOdQLqhCSqY=.4ab4ada8-b556-42f7-9f93-742b9cd68bbd@github.com> On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > moved asm.md to the testlibrary/asm In that case I have no more objections for the build part of this PR. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2547103022 From rriggs at openjdk.org Mon Jan 13 16:31:43 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Jan 2025 16:31:43 GMT Subject: RFR: 8345016: [ASAN] java.c reported =?UTF-8?B?4oCYJXPigJk=?= directive argument is null [-Werror=format-truncation=] [v3] In-Reply-To: References: Message-ID: On Mon, 16 Dec 2024 12:47:13 GMT, SendaoYan wrote: >> Hi all, >> The file src/java.base/share/native/libjli/java.c generate compile warning by gcc14 with gcc options `-fsanitize=undefined -O2`, and make jdk build error when configure with option `--enable-ubsan`. So I think it's necessory to make gcc quiet and make jdk build normally with configure option `--enable-ubsan`. >> >> This PR add `NULL` check for `s` after call `s = JLI_WildcardExpandClasspath(s);` to make gcc quiet. There is another solution to disable the compile warning seen as below, but it will disable the compile warning of java.c. So I use the first solution. >> >> >> >> diff --git a/make/modules/java.base/lib/CoreLibraries.gmk b/make/modules/java.base/lib/CoreLibraries.gmk >> index 61ac495968a..5bc83cf0978 100644 >> --- a/make/modules/java.base/lib/CoreLibraries.gmk >> +++ b/make/modules/java.base/lib/CoreLibraries.gmk >> @@ -178,6 +178,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJLI, \ >> OPTIMIZATION := HIGH, \ >> CFLAGS := $(LIBJLI_CFLAGS) $(LIBZ_CFLAGS), \ >> DISABLED_WARNINGS_gcc := unused-function unused-variable, \ >> + DISABLED_WARNINGS_gcc_java.c := format-truncation, \ >> DISABLED_WARNINGS_clang := deprecated-non-prototype format-nonliteral \ >> unused-function, \ >> DISABLED_WARNINGS_clang_java_md_macosx.m := unused-variable, \ > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add NULL check after call "s = JLI_WildcardExpandClasspath(s);" Looks fine. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22546#pullrequestreview-2547173548 From vklang at openjdk.org Mon Jan 13 16:35:19 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 13 Jan 2025 16:35:19 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message Message-ID: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. ------------- Commit messages: - Addresses IAE and NPE messages for ThreadPoolExecutor Changes: https://git.openjdk.org/jdk/pull/23081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347491 Stats: 25 lines in 1 file changed: 6 ins; 5 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/23081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23081/head:pull/23081 PR: https://git.openjdk.org/jdk/pull/23081 From vklang at openjdk.org Mon Jan 13 16:35:19 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 13 Jan 2025 16:35:19 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: On Mon, 13 Jan 2025 16:28:52 GMT, Viktor Klang wrote: > Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. @DougLea This is the PR I was talking about earlier today. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23081#issuecomment-2587597495 From rriggs at openjdk.org Mon Jan 13 16:46:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 13 Jan 2025 16:46:46 GMT Subject: Integrated: 8346468: SM cleanup of common test library In-Reply-To: References: Message-ID: <7YawxMCUbGSzTEJPOG-9SjoHuEyfufDL7i5N5Qgitog=.7ceaefdd-664e-4c33-8068-f6caa67e0a44@github.com> On Wed, 18 Dec 2024 15:00:13 GMT, Roger Riggs wrote: > SM Cleanup of common test library test/lib/...: > > Remove unnecessary catches of SecurityException > Remove AccessController and doPrivileged from SimpleSSLContext and ProcessTools. This pull request has now been integrated. Changeset: a7915bb2 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/a7915bb2e1b822b6d9cbeb220765e8c821c71d0b Stats: 224 lines in 11 files changed: 1 ins; 167 del; 56 mod 8346468: SM cleanup of common test library Reviewed-by: jpai, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/22814 From dl at openjdk.org Mon Jan 13 16:48:35 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 13 Jan 2025 16:48:35 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: On Mon, 13 Jan 2025 16:28:52 GMT, Viktor Klang wrote: > Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. Thanks for doing this. Looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23081#issuecomment-2587638498 From psandoz at openjdk.org Mon Jan 13 16:53:45 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 13 Jan 2025 16:53:45 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: References: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> Message-ID: On Mon, 13 Jan 2025 09:02:24 GMT, Jatin Bhateja wrote: >> Uncertain on what bits, but i am guessing it's mostly related to the fallback code in the lambda. To avoid the intrinsics operating on Float16 instances we instead "unpack" the carrier (16bits) values and pass those as arguments to the intrinsic. The fallback (when intrinsification is not supported) also accepts those carrier values as arguments and we convert the carriers to floats, operate on then, convert to the carrier, and then back to float16 on the result. >> >> The code in the lambda could potentially be simplified if `Float16Math.fma` accepted six arguments the first three being the carrier values used by the intrinsic, and the subsequent three being the float16 values used by the fallback. Then we could express the code in the original source in the lambda. I believe when intrinsified there would be no penalty for those extra arguments. > > Hi @PaulSandoz , In the current scheme we are passing unboxed carriers to intrinsic entry point, in the fallback implementation carrier type is first converted to floating point value using Float.float16ToFloat API which expects to receive a short type argument, after the operation we again convert float value to carrier type (short) using Float.floatToFloat16 API which expects a float argument, thus our intent here is to perform unboxing and boxing outside the intrinsic thereby avoiding all complexities around boxing by compiler. Even if we pass 3 additional parameters we still need to use Float16.floatValue which invokes Float.float16ToFloat underneath, thus this minor modification on Java side is on account of optimizing the intrinsic interface. Yes, i understand the approach. It's about clarity of the fallback implementation retaining what was expressed in the original code: short res = Float16Math.fma(fa, fb, fc, a, b, c, (a_, b_, c_) -> { double product = (double)(a_.floatValue() * b._floatValue()); return valueOf(product + c_.doubleValue()); }); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1913502565 From lmesnik at openjdk.org Mon Jan 13 16:57:48 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 13 Jan 2025 16:57:48 GMT Subject: RFR: 8346986: Remove ASM from java.base [v8] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > moved asm.md to the testlibrary/asm Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2547237930 From liach at openjdk.org Mon Jan 13 17:02:47 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 13 Jan 2025 17:02:47 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute [v2] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 20:25:06 GMT, Chen Liang wrote: >> Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review comments, also simplify Attribute Thanks for the reviews. There was just one unrelated test failure; integrating. Wait a second, I thought this was the backport patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23026#issuecomment-2587673247 PR Comment: https://git.openjdk.org/jdk/pull/23026#issuecomment-2587675113 From liach at openjdk.org Mon Jan 13 17:03:51 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 13 Jan 2025 17:03:51 GMT Subject: [jdk24] Integrated: 8342468: Improve API documentation for java.lang.classfile.constantpool In-Reply-To: References: Message-ID: <21zVoXDjRkKdEGD9Fw95IF9c2xtv_GPMqKvVFe2wdy8=.2d6643df-21c6-46c8-ba94-f3223204fd2c@github.com> On Fri, 10 Jan 2025 20:50:20 GMT, Chen Liang wrote: > This is a non-clean backport of bcefab5e55d4527a38dcab550581a734c1564608, because afe543414f58a04832d4f07dea88881d64954a0b which fixes a Javadoc link error was also included in this backport. This backports Javadoc improvements to the ClassFile API committed to mainline back to 24, the finalization release of the ClassFile API. > > Running tier 1-3 tests right now. This pull request has now been integrated. Changeset: 4a623a2b Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/4a623a2b6dee69be53361d88c88da7a4d787fd08 Stats: 1139 lines in 31 files changed: 768 ins; 69 del; 302 mod 8342468: Improve API documentation for java.lang.classfile.constantpool 8347163: Javadoc error in ConstantPoolBuilder after JDK-8342468 Reviewed-by: asotona Backport-of: bcefab5e55d4527a38dcab550581a734c1564608 ------------- PR: https://git.openjdk.org/jdk/pull/23046 From liach at openjdk.org Mon Jan 13 17:03:49 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 13 Jan 2025 17:03:49 GMT Subject: [jdk24] RFR: 8342468: Improve API documentation for java.lang.classfile.constantpool In-Reply-To: References: Message-ID: <5V9Zpi99e4zEGlXpB4bVsr9NxsA_C8FujJuaa3rr1Bc=.30193fe4-c606-4e5b-a42d-21158c1894e9@github.com> On Fri, 10 Jan 2025 20:50:20 GMT, Chen Liang wrote: > This is a non-clean backport of bcefab5e55d4527a38dcab550581a734c1564608, because afe543414f58a04832d4f07dea88881d64954a0b which fixes a Javadoc link error was also included in this backport. This backports Javadoc improvements to the ClassFile API committed to mainline back to 24, the finalization release of the ClassFile API. > > Running tier 1-3 tests right now. Thanks for the reviews. There was just one unrelated test failure; integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23046#issuecomment-2587675371 From galder at openjdk.org Mon Jan 13 17:12:31 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 13 Jan 2025 17:12:31 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v9] In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com> > This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. > > Currently vectorization does not kick in for loops containing either of these calls because of the following error: > > > VLoop::check_preconditions: failed: control flow in loop not allowed > > > The control flow is due to the java implementation for these methods, e.g. > > > public static long max(long a, long b) { > return (a >= b) ? a : b; > } > > > This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. > By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. > E.g. > > > SuperWord::transform_loop: > Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined > 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) > > > Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1155 > long max 1173 > > > After the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1042 > long max 1042 > > > This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. > Therefore, it still relies on the macro expansion to transform those into CMoveL. > > I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 2500 2500 0 0 >>> jtreg:test/jdk:tier1 ... Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: Make sure it runs with cpus with either avx512 or asimd ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20098/files - new: https://git.openjdk.org/jdk/pull/20098/files/c0491987..abbaf875 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=07-08 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20098.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098 PR: https://git.openjdk.org/jdk/pull/20098 From darcy at openjdk.org Mon Jan 13 17:34:23 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 13 Jan 2025 17:34:23 GMT Subject: RFR: 8347605: Use spec tag to refer to IEEE 754 standard Message-ID: Redo the work done in JDK-8285977 to use the `@spec` tag so that the IEEE floating-point standard gets listed as one of the external specifications. ------------- Commit messages: - JDK-8347605: Use spec tag to refer to IEEE 754 standard Changes: https://git.openjdk.org/jdk/pull/23082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347605 Stats: 30 lines in 7 files changed: 0 ins; 0 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/23082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23082/head:pull/23082 PR: https://git.openjdk.org/jdk/pull/23082 From bpb at openjdk.org Mon Jan 13 17:48:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Jan 2025 17:48:38 GMT Subject: RFR: 8347605: Use spec tag to refer to IEEE 754 standard In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 17:28:33 GMT, Joe Darcy wrote: > Redo the work done in JDK-8285977 to use the `@spec` tag so that the IEEE floating-point standard gets listed as one of the external specifications. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23082#pullrequestreview-2547352186 From iris at openjdk.org Mon Jan 13 17:59:45 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 13 Jan 2025 17:59:45 GMT Subject: RFR: 8347605: Use spec tag to refer to IEEE 754 standard In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 17:28:33 GMT, Joe Darcy wrote: > Redo the work done in JDK-8285977 to use the `@spec` tag so that the IEEE floating-point standard gets listed as one of the external specifications. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23082#pullrequestreview-2547378753 From alanb at openjdk.org Mon Jan 13 18:06:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Jan 2025 18:06:44 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: On Mon, 13 Jan 2025 16:28:52 GMT, Viktor Klang wrote: > Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. Looks fine, just wondering if the tests for IAE should check there is a message. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23081#pullrequestreview-2547400057 From bpb at openjdk.org Mon Jan 13 18:12:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Jan 2025 18:12:54 GMT Subject: RFR: 8345368: java/io/File/createTempFile/SpecialTempFile.java fails on Windows Server 2025 In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:27:15 GMT, Brian Burkhalter wrote: > Change the test as done in #22957 for [JDK-8346671](https://bugs.openjdk.org/browse/JDK-8346671). Change verified by "faking" OS name in the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22994#issuecomment-2587845005 From bpb at openjdk.org Mon Jan 13 18:12:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 13 Jan 2025 18:12:54 GMT Subject: Integrated: 8345368: java/io/File/createTempFile/SpecialTempFile.java fails on Windows Server 2025 In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 00:27:15 GMT, Brian Burkhalter wrote: > Change the test as done in #22957 for [JDK-8346671](https://bugs.openjdk.org/browse/JDK-8346671). This pull request has now been integrated. Changeset: b0c131e8 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/b0c131e872f997cb7deadc9b0a87bd76e3a2a83c Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8345368: java/io/File/createTempFile/SpecialTempFile.java fails on Windows Server 2025 Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/22994 From henryjen at openjdk.org Mon Jan 13 18:19:59 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 13 Jan 2025 18:19:59 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v4] In-Reply-To: References: Message-ID: > Improving option value handling to support passing argument value starts with "--". > > Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. > --add-options --add-modules=jdk.incubator.concurrent > --add-options=--add-modules=jdk.incubator.concurrent > > will cause JLink to report > Error: no value given for --add-options > as --add-modules is considered another option for JLink. > > After the fix, by using = will ensure the value is properly handled as argument value > --add-options=--add-modules=jdk.incubator.concurrent Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Use different error message for ambiguous gnu-style options as value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22526/files - new: https://git.openjdk.org/jdk/pull/22526/files/7060e47f..76ce4472 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22526&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22526&range=02-03 Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22526/head:pull/22526 PR: https://git.openjdk.org/jdk/pull/22526 From liach at openjdk.org Mon Jan 13 18:20:36 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 13 Jan 2025 18:20:36 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: On Mon, 13 Jan 2025 16:28:52 GMT, Viktor Klang wrote: > Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. There's a contributor PR from the java bugs submitter at https://github.com/openjdk/jdk/pull/23050, I wonder what we should do in this case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23081#issuecomment-2587874800 From alanb at openjdk.org Mon Jan 13 18:26:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Jan 2025 18:26:38 GMT Subject: RFR: 8346778: Enable native access should work with the source launcher [v3] In-Reply-To: <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com> References: <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com> Message-ID: <09_Yl-pKAww_X3X4nf_pBjI4wK-PMomd54MfmmBwSXo=.41407acd-47b9-4ef7-9a21-8f4da8c26a56@github.com> On Mon, 13 Jan 2025 11:29:06 GMT, Christian Stein wrote: >> Please review this change request enabling native access in source launch mode when using a modular setup. >> >> The change comes in two parts: >> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java` >> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java` >> >> _Testing of tier1..3 is in progress..._ > > Christian Stein has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > - Update src/java.base/share/native/libjli/java.c > > [skip ci] > - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > > [skip ci] Good, I don't have any other comments on this. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22930#pullrequestreview-2547469239 From alanb at openjdk.org Mon Jan 13 18:36:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Jan 2025 18:36:42 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v4] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 18:19:59 GMT, Henry Jen wrote: >> Improving option value handling to support passing argument value starts with "--". >> >> Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. >> --add-options --add-modules=jdk.incubator.concurrent >> --add-options=--add-modules=jdk.incubator.concurrent >> >> will cause JLink to report >> Error: no value given for --add-options >> as --add-modules is considered another option for JLink. >> >> After the fix, by using = will ensure the value is properly handled as argument value >> --add-options=--add-modules=jdk.incubator.concurrent > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Use different error message for ambiguous gnu-style options as value The update looks good, I assume you'll bump the copyright date of the files before integrating. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22526#pullrequestreview-2547498940 From duke at openjdk.org Mon Jan 13 18:54:35 2025 From: duke at openjdk.org (He-Pin (kerr)) Date: Mon, 13 Jan 2025 18:54:35 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: On Mon, 13 Jan 2025 16:28:52 GMT, Viktor Klang wrote: > Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. https://github.com/openjdk/jdk/pull/23050 There is already a pr for this:) As I encountered this in production ------------- PR Comment: https://git.openjdk.org/jdk/pull/23081#issuecomment-2587942547 From naoto at openjdk.org Mon Jan 13 19:04:24 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Jan 2025 19:04:24 GMT Subject: RFR: 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal Message-ID: The use of [three-letter time zone IDs](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/util/TimeZone.html#three-letter-time-zone-ids-heading) has long been deprecated. For their actual removal in the future, making the runtime emit warnings for using those IDs would be desirable. --------- ### Progress - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) - [x] Change must not contain extraneous whitespace - [x] Commit message must refer to an issue ### Reviewers without OpenJDK IDs * @abdelhak-zaaim (no known openjdk.org user name / role) ### Reviewing

Using git Checkout this PR locally: \ `$ git fetch https://git.openjdk.org/jdk.git pull/23049/head:pull/23049` \ `$ git checkout pull/23049` Update a local copy of the PR: \ `$ git checkout pull/23049` \ `$ git pull https://git.openjdk.org/jdk.git pull/23049/head`
Using Skara CLI tools Checkout this PR locally: \ `$ git pr checkout 23049` View PR using the GUI difftool: \ `$ git pr show -t 23049`
Using diff file Download this PR as a diff file: \ https://git.openjdk.org/jdk/pull/23049.diff
------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/23049/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23049&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342550 Stats: 61 lines in 3 files changed: 56 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23049/head:pull/23049 PR: https://git.openjdk.org/jdk/pull/23049 From duke at openjdk.org Mon Jan 13 19:04:24 2025 From: duke at openjdk.org (Abdelhak Zaaim) Date: Mon, 13 Jan 2025 19:04:24 GMT Subject: RFR: 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 23:05:13 GMT, Naoto Sato wrote: > The use of [three-letter time zone IDs](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/util/TimeZone.html#three-letter-time-zone-ids-heading) has long been deprecated. For their actual removal in the future, making the runtime emit warnings for using those IDs would be desirable. > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewers without OpenJDK IDs > * @abdelhak-zaaim (no known openjdk.org user name / role) > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/23049/head:pull/23049` \ > `$ git checkout pull/23049` > > Update a local copy of the PR: \ > `$ git checkout pull/23049` \ > `$ git pull https://git.openjdk.org/jdk.git pull/23049/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 23049` > > View PR using the GUI difftool: \ > `$ git pr show -t 23049` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/23049.diff > >
Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/23049#pullrequestreview-2544634590 From duke at openjdk.org Mon Jan 13 19:23:39 2025 From: duke at openjdk.org (He-Pin (kerr)) Date: Mon, 13 Jan 2025 19:23:39 GMT Subject: [jdk24] RFR: 8347542: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> References: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> Message-ID: On Mon, 13 Jan 2025 12:59:06 GMT, Viktor Klang wrote: > Backport to jdk24 of https://bugs.openjdk.org/browse/JDK-8347274 Does this fix the OOM problem? import java.util.stream.Gatherers; import java.util.stream.IntStream; /** * TODO: description of this file * * @author ?? */ public class Main { public static void main(String[] args) { final var stream = IntStream.range(0, Integer.MAX_VALUE); stream.boxed() .gather(Gatherers.mapConcurrent( 2, i -> { if (i == 0) { try { Thread.sleep(Integer.MAX_VALUE); } catch (InterruptedException e) { throw new RuntimeException(e); } } return i; })) .forEach(System.out::println); try { Thread.sleep(Integer.MAX_VALUE); } catch (InterruptedException e) { throw new RuntimeException(e); } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/23068#issuecomment-2587998277 From zjx001202 at gmail.com Mon Jan 13 19:36:40 2025 From: zjx001202 at gmail.com (Glavo) Date: Tue, 14 Jan 2025 03:36:40 +0800 Subject: Request for Enhancement: Objects.checkPositionIndex(int, int) Message-ID: Currently the java.util.Objects provide the method `checkIndex(int, int)` for checking indexes. It is convenient, but cannot be used to implement methods such as List::add(int, E) because these methods accept an index pointing to the end of the collection. So is it possible to add a new method to Objects to check this kind of index? This is useful for implementing collections. (The checkPositionIndex in the title is its name in guava. I don't like the name, but I don't have a better idea.) Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlu at openjdk.org Mon Jan 13 19:59:35 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 13 Jan 2025 19:59:35 GMT Subject: RFR: 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 23:05:13 GMT, Naoto Sato wrote: > The use of [three-letter time zone IDs](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/util/TimeZone.html#three-letter-time-zone-ids-heading) has long been deprecated. For their actual removal in the future, making the runtime emit warnings for using those IDs would be desirable. > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewers without OpenJDK IDs > * @abdelhak-zaaim (no known openjdk.org user name / role) > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/23049/head:pull/23049` \ > `$ git checkout pull/23049` > > Update a local copy of the PR: \ > `$ git checkout pull/23049` \ > `$ git pull https://git.openjdk.org/jdk.git pull/23049/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 23049` > > View PR using the GUI difftool: \ > `$ git pr show -t 23049` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/23049.diff > >
Fix and associated test both look good to me. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/23049#pullrequestreview-2547726687 From darcy at openjdk.org Mon Jan 13 20:02:53 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 13 Jan 2025 20:02:53 GMT Subject: Integrated: 8347605: Use spec tag to refer to IEEE 754 standard In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 17:28:33 GMT, Joe Darcy wrote: > Redo the work done in JDK-8285977 to use the `@spec` tag so that the IEEE floating-point standard gets listed as one of the external specifications. This pull request has now been integrated. Changeset: 7c883c28 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/7c883c284de4fa1cb55f4fd4cf4dc9115bee5e65 Stats: 30 lines in 7 files changed: 0 ins; 0 del; 30 mod 8347605: Use spec tag to refer to IEEE 754 standard Reviewed-by: bpb, iris ------------- PR: https://git.openjdk.org/jdk/pull/23082 From ihse at openjdk.org Mon Jan 13 20:09:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 13 Jan 2025 20:09:54 GMT Subject: RFR: 8346669: Increase abstraction in SetupBuildLauncher and remove extra args In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 13:11:15 GMT, Magnus Ihse Bursie wrote: >> make/common/modules/LauncherCommon.gmk line 162: >> >>> 160: -framework ApplicationServices \ >>> 161: -framework Cocoa \ >>> 162: -framework Security, \ >> >> What happened to all of these? Were they never needed? > > I don't know. If so, it was a long time ago. > > Hm, maybe it was from when JLI was statically linked. It could actually be that we still need something like: > > LIB_aix := $(LIBZ_LIBS), \ > > > Perhaps someone from the AIX team can check this? It seems they were required for the static launcher, which I obviously did not test with this change. :-( I should add `static-launcher` to the `launchers` target, so I don't forget about it again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22832#discussion_r1913747211 From mdoerr at openjdk.org Mon Jan 13 20:10:54 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 13 Jan 2025 20:10:54 GMT Subject: Integrated: 8346869: [AIX] Add regression test for handling 4 Byte aligned doubles in structures In-Reply-To: References: Message-ID: <_D1pWc1Xl81skdQvUqJjQwX8s6WRa1OzHxib7tcmRbk=.2780e4d9-275c-461e-99ad-6c9ed44bc659@github.com> On Sat, 28 Dec 2024 18:43:30 GMT, Martin Doerr wrote: > [JDK-8317545](https://bugs.openjdk.org/browse/JDK-8317545) introduced code for supporting 4 Byte aligned doubles: https://github.com/openjdk/jdk/blob/60e0730a3ba26180d0eb2cd278e389c3e70fec5f/src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/aix/AixPPC64Linker.java#L59 > We should test this case. The new test can serve as an example implementation for handling such structures in Java code such that it works on all platforms including AIX. This pull request has now been integrated. Changeset: 61dc07c1 Author: Martin Doerr URL: https://git.openjdk.org/jdk/commit/61dc07c118ee9d2d7e1747b6e49508cae7c19dc4 Stats: 178 lines in 2 files changed: 178 ins; 0 del; 0 mod 8346869: [AIX] Add regression test for handling 4 Byte aligned doubles in structures Reviewed-by: mbaesken, jkern ------------- PR: https://git.openjdk.org/jdk/pull/22889 From kevin.bourrillion at oracle.com Mon Jan 13 20:19:18 2025 From: kevin.bourrillion at oracle.com (Kevin Bourrillion) Date: Mon, 13 Jan 2025 20:19:18 +0000 Subject: Request for Enhancement: Objects.checkPositionIndex(int, int) In-Reply-To: References: Message-ID: <8CB00D1C-46C5-41DE-A090-6319A9E40E22@oracle.com> Oh hey, I named those Guava methods. :-) This was my attempt to promote the terms ?position indexes vs. element indexes? and hope that the idea caught on... which I?d say it still never has. I?m surprised you even noticed the methods. The notion is that ?element indexes? are the buckets and ?position indexes? are the possible insertion points between buckets. I personally find it simpler to think of a method like `subList` as simply accepting two position indexes, rather than thinking about half-open ranges. To me this was clarifying, but for people who never have this explained to them it?s probably not that clear. And basically, the adoption counts for those methods always remained very low. And I remember seeing a number of misuses, too. Not sure what to make of all this; just adding some context. On Jan 13, 2025, at 11:36?AM, Glavo wrote: Currently the java.util.Objects provide the method `checkIndex(int, int)` for checking indexes. It is convenient, but cannot be used to implement methods such as List::add(int, E) because these methods accept an index pointing to the end of the collection. So is it possible to add a new method to Objects to check this kind of index? This is useful for implementing collections. (The checkPositionIndex in the title is its name in guava. I don't like the name, but I don't have a better idea.) Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Mon Jan 13 21:10:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 13 Jan 2025 21:10:42 GMT Subject: RFR: 8346986: Remove ASM from java.base [v8] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > moved asm.md to the testlibrary/asm Okay lets give this a whirl and see how it goes. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22946#pullrequestreview-2547901035 From jlu at openjdk.org Mon Jan 13 21:44:15 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 13 Jan 2025 21:44:15 GMT Subject: RFR: 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java Message-ID: Please review this PR which removes a leftover `doPrivileged` call in the Currency test, _CheckDataVersion.java_. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/23087/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23087&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347613 Stats: 42 lines in 1 file changed: 14 ins; 26 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23087.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23087/head:pull/23087 PR: https://git.openjdk.org/jdk/pull/23087 From henryjen at openjdk.org Mon Jan 13 22:04:04 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 13 Jan 2025 22:04:04 GMT Subject: RFR: 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413 Message-ID: Sort services provided by a module to ensure reproduce same result. ------------- Commit messages: - 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413 Changes: https://git.openjdk.org/jdk/pull/23088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347376 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23088/head:pull/23088 PR: https://git.openjdk.org/jdk/pull/23088 From darcy at openjdk.org Mon Jan 13 22:46:22 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 13 Jan 2025 22:46:22 GMT Subject: [jdk24] RFR: 8347605: Use spec tag to refer to IEEE 754 standard Message-ID: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> Get IEEE 754 added as an external standard in JDK 24's docs too. ------------- Commit messages: - Backport 7c883c284de4fa1cb55f4fd4cf4dc9115bee5e65 Changes: https://git.openjdk.org/jdk/pull/23091/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23091&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347605 Stats: 30 lines in 7 files changed: 0 ins; 0 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/23091.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23091/head:pull/23091 PR: https://git.openjdk.org/jdk/pull/23091 From naoto at openjdk.org Mon Jan 13 22:48:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 13 Jan 2025 22:48:46 GMT Subject: RFR: 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java In-Reply-To: References: Message-ID: <5aeM5FU84iMw3Z4G3BlqXcFRp2RH5amobrIkbTLi2FU=.7ae01a18-3078-44f5-954d-9a2793042e91@github.com> On Mon, 13 Jan 2025 21:38:04 GMT, Justin Lu wrote: > Please review this PR which removes a leftover `doPrivileged` call in the Currency test, _CheckDataVersion.java_. test/jdk/java/util/Currency/CheckDataVersion.java line 79: > 77: } catch (IOException ioe) { > 78: throw new RuntimeException( > 79: "CheckDataVersion was not set up properly: " + ioe); IOException could happen not by the test setup failure, but for the case the `currency.data` file in the JDK is missing or corrupt, so if you want to give extra message to the exception, needs some rewording. Also, I prefer `ioe` should be the `cause` and not to be consumed in the message. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23087#discussion_r1913898713 From jlu at openjdk.org Mon Jan 13 23:12:18 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 13 Jan 2025 23:12:18 GMT Subject: RFR: 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java [v2] In-Reply-To: References: Message-ID: <8AwEb33QMIxBTEkFR_m3fJSkuch08NfUUzVCUJmtMa4=.51edea1f-71b5-43ee-96f0-62a4ddedd27e@github.com> > Please review this PR which removes a leftover `doPrivileged` call in the Currency test, _CheckDataVersion.java_. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23087/files - new: https://git.openjdk.org/jdk/pull/23087/files/b2d0edfd..aafade3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23087&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23087&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23087.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23087/head:pull/23087 PR: https://git.openjdk.org/jdk/pull/23087 From jlu at openjdk.org Mon Jan 13 23:12:19 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 13 Jan 2025 23:12:19 GMT Subject: RFR: 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java [v2] In-Reply-To: <5aeM5FU84iMw3Z4G3BlqXcFRp2RH5amobrIkbTLi2FU=.7ae01a18-3078-44f5-954d-9a2793042e91@github.com> References: <5aeM5FU84iMw3Z4G3BlqXcFRp2RH5amobrIkbTLi2FU=.7ae01a18-3078-44f5-954d-9a2793042e91@github.com> Message-ID: On Mon, 13 Jan 2025 22:44:39 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect review > > test/jdk/java/util/Currency/CheckDataVersion.java line 79: > >> 77: } catch (IOException ioe) { >> 78: throw new RuntimeException( >> 79: "CheckDataVersion was not set up properly: " + ioe); > > IOException could happen not by the test setup failure, but for the case the `currency.data` file in the JDK is missing or corrupt, so if you want to give extra message to the exception, needs some rewording. Also, I prefer `ioe` should be the `cause` and not to be consumed in the message. Ah, I meant that if _currency.data_ was missing/corrupted, it was a set up failure because we can not test the contents properly. Although, I suppose that just means the test fails, not fails to setup properly. Updated the message to be more clear, and also used the 2 arg ctor to retain the IOE as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23087#discussion_r1913917220 From chen.l.liang at oracle.com Tue Jan 14 00:02:47 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Tue, 14 Jan 2025 00:02:47 +0000 Subject: Request for Enhancement: Objects.checkPositionIndex(int, int) In-Reply-To: <8CB00D1C-46C5-41DE-A090-6319A9E40E22@oracle.com> References: <8CB00D1C-46C5-41DE-A090-6319A9E40E22@oracle.com> Message-ID: I tend to name such an item a "cursor position" as termed in ListIterator; I used the same term for Label in the ClassFile API. I indeed think this API would be useful: List.add, List.listIterator, TypeDescriptor.OfMethod.insertParameterTypes, getting labels in a code array for class files... ________________________________ From: core-libs-dev on behalf of Kevin Bourrillion Sent: Monday, January 13, 2025 2:19 PM To: Glavo Cc: core-libs-dev Subject: Re: Request for Enhancement: Objects.checkPositionIndex(int, int) Oh hey, I named those Guava methods. :-) This was my attempt to promote the terms ?position indexes vs. element indexes? and hope that the idea caught on... which I?d say it still never has. I?m surprised you even noticed the methods. The notion is that ?element indexes? are the buckets and ?position indexes? are the possible insertion points between buckets. I personally find it simpler to think of a method like `subList` as simply accepting two position indexes, rather than thinking about half-open ranges. To me this was clarifying, but for people who never have this explained to them it?s probably not that clear. And basically, the adoption counts for those methods always remained very low. And I remember seeing a number of misuses, too. Not sure what to make of all this; just adding some context. On Jan 13, 2025, at 11:36?AM, Glavo wrote: Currently the java.util.Objects provide the method `checkIndex(int, int)` for checking indexes. It is convenient, but cannot be used to implement methods such as List::add(int, E) because these methods accept an index pointing to the end of the collection. So is it possible to add a new method to Objects to check this kind of index? This is useful for implementing collections. (The checkPositionIndex in the title is its name in guava. I don't like the name, but I don't have a better idea.) Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Tue Jan 14 00:21:04 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 14 Jan 2025 00:21:04 GMT Subject: RFR: 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java [v2] In-Reply-To: <8AwEb33QMIxBTEkFR_m3fJSkuch08NfUUzVCUJmtMa4=.51edea1f-71b5-43ee-96f0-62a4ddedd27e@github.com> References: <8AwEb33QMIxBTEkFR_m3fJSkuch08NfUUzVCUJmtMa4=.51edea1f-71b5-43ee-96f0-62a4ddedd27e@github.com> Message-ID: On Mon, 13 Jan 2025 23:12:18 GMT, Justin Lu wrote: >> Please review this PR which removes a leftover `doPrivileged` call in the Currency test, _CheckDataVersion.java_. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23087#pullrequestreview-2548247930 From liach at openjdk.org Tue Jan 14 00:21:42 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 14 Jan 2025 00:21:42 GMT Subject: [jdk24] RFR: 8347605: Use spec tag to refer to IEEE 754 standard In-Reply-To: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> References: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> Message-ID: On Mon, 13 Jan 2025 22:40:27 GMT, Joe Darcy wrote: > Get IEEE 754 added as an external standard in JDK 24's docs too. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23091#pullrequestreview-2548223777 From bpb at openjdk.org Tue Jan 14 00:21:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 14 Jan 2025 00:21:43 GMT Subject: [jdk24] RFR: 8347605: Use spec tag to refer to IEEE 754 standard In-Reply-To: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> References: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> Message-ID: On Mon, 13 Jan 2025 22:40:27 GMT, Joe Darcy wrote: > Get IEEE 754 added as an external standard in JDK 24's docs too. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23091#pullrequestreview-2548245622 From joehw at openjdk.org Tue Jan 14 00:21:45 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 14 Jan 2025 00:21:45 GMT Subject: RFR: 8347146: Convert IncludeLocalesPluginTest to use JUnit [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 22:44:15 GMT, Naoto Sato wrote: >> A simple refinement to the test makes diagnosing failures easier. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addresses review comments Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23016#pullrequestreview-2548219090 From joehw at openjdk.org Tue Jan 14 00:22:48 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 14 Jan 2025 00:22:48 GMT Subject: RFR: 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 23:05:13 GMT, Naoto Sato wrote: > The use of [three-letter time zone IDs](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/util/TimeZone.html#three-letter-time-zone-ids-heading) has long been deprecated. For their actual removal in the future, making the runtime emit warnings for using those IDs would be desirable. > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewers without OpenJDK IDs > * @abdelhak-zaaim (no known openjdk.org user name / role) > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/23049/head:pull/23049` \ > `$ git checkout pull/23049` > > Update a local copy of the PR: \ > `$ git checkout pull/23049` \ > `$ git pull https://git.openjdk.org/jdk.git pull/23049/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 23049` > > View PR using the GUI difftool: \ > `$ git pr show -t 23049` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/23049.diff > >
Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23049#pullrequestreview-2548242414 From syan at openjdk.org Tue Jan 14 01:15:52 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 14 Jan 2025 01:15:52 GMT Subject: RFR: 8345016: [ASAN] java.c reported =?UTF-8?B?4oCYJXPigJk=?= directive argument is null [-Werror=format-truncation=] [v3] In-Reply-To: References: Message-ID: On Mon, 16 Dec 2024 12:47:13 GMT, SendaoYan wrote: >> Hi all, >> The file src/java.base/share/native/libjli/java.c generate compile warning by gcc14 with gcc options `-fsanitize=undefined -O2`, and make jdk build error when configure with option `--enable-ubsan`. So I think it's necessory to make gcc quiet and make jdk build normally with configure option `--enable-ubsan`. >> >> This PR add `NULL` check for `s` after call `s = JLI_WildcardExpandClasspath(s);` to make gcc quiet. There is another solution to disable the compile warning seen as below, but it will disable the compile warning of java.c. So I use the first solution. >> >> >> >> diff --git a/make/modules/java.base/lib/CoreLibraries.gmk b/make/modules/java.base/lib/CoreLibraries.gmk >> index 61ac495968a..5bc83cf0978 100644 >> --- a/make/modules/java.base/lib/CoreLibraries.gmk >> +++ b/make/modules/java.base/lib/CoreLibraries.gmk >> @@ -178,6 +178,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJLI, \ >> OPTIMIZATION := HIGH, \ >> CFLAGS := $(LIBJLI_CFLAGS) $(LIBZ_CFLAGS), \ >> DISABLED_WARNINGS_gcc := unused-function unused-variable, \ >> + DISABLED_WARNINGS_gcc_java.c := format-truncation, \ >> DISABLED_WARNINGS_clang := deprecated-non-prototype format-nonliteral \ >> unused-function, \ >> DISABLED_WARNINGS_clang_java_md_macosx.m := unused-variable, \ > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add NULL check after call "s = JLI_WildcardExpandClasspath(s);" Thanks all for the suggests and reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22546#issuecomment-2588547301 From syan at openjdk.org Tue Jan 14 01:15:52 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 14 Jan 2025 01:15:52 GMT Subject: Integrated: 8345016: [ASAN] java.c reported =?UTF-8?B?4oCYJXPigJk=?= directive argument is null [-Werror=format-truncation=] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 14:57:22 GMT, SendaoYan wrote: > Hi all, > The file src/java.base/share/native/libjli/java.c generate compile warning by gcc14 with gcc options `-fsanitize=undefined -O2`, and make jdk build error when configure with option `--enable-ubsan`. So I think it's necessory to make gcc quiet and make jdk build normally with configure option `--enable-ubsan`. > > This PR add `NULL` check for `s` after call `s = JLI_WildcardExpandClasspath(s);` to make gcc quiet. There is another solution to disable the compile warning seen as below, but it will disable the compile warning of java.c. So I use the first solution. > > > > diff --git a/make/modules/java.base/lib/CoreLibraries.gmk b/make/modules/java.base/lib/CoreLibraries.gmk > index 61ac495968a..5bc83cf0978 100644 > --- a/make/modules/java.base/lib/CoreLibraries.gmk > +++ b/make/modules/java.base/lib/CoreLibraries.gmk > @@ -178,6 +178,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJLI, \ > OPTIMIZATION := HIGH, \ > CFLAGS := $(LIBJLI_CFLAGS) $(LIBZ_CFLAGS), \ > DISABLED_WARNINGS_gcc := unused-function unused-variable, \ > + DISABLED_WARNINGS_gcc_java.c := format-truncation, \ > DISABLED_WARNINGS_clang := deprecated-non-prototype format-nonliteral \ > unused-function, \ > DISABLED_WARNINGS_clang_java_md_macosx.m := unused-variable, \ This pull request has now been integrated. Changeset: 91b63ca7 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/91b63ca748650b5e127b235efb2f327a8ff39f70 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8345016: [ASAN] java.c reported ?%s? directive argument is null [-Werror=format-truncation=] Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/22546 From zjx001202 at gmail.com Tue Jan 14 02:37:48 2025 From: zjx001202 at gmail.com (Glavo) Date: Tue, 14 Jan 2025 10:37:48 +0800 Subject: Request for Enhancement: Objects.checkPositionIndex(int, int) In-Reply-To: <8CB00D1C-46C5-41DE-A090-6319A9E40E22@oracle.com> References: <8CB00D1C-46C5-41DE-A090-6319A9E40E22@oracle.com> Message-ID: Hi Kevin, I?m surprised you even noticed the methods. I develop and maintain a collection library, in which I copied checkPositionIndex because it is really commonly used by me. I searched my library and found that checkPositionIndex has more than a hundred use cases in my library. And basically, the adoption counts for those methods always remained very > low. And I remember seeing a number of misuses, too. I was surprised by this information, I thought there should be many places using it. Perhaps because it is often needed by other libraries that do not want to add dependencies on Guava. This method should be very useful at least for implementing core libraries. There are many copies of it in the Java standard library, and I found these just by searching casually: - java.lang.String::checkOffset(int, int) - java.util.AbstractList.SubList::rangeCheckForAdd(int) - java.util.ArrayList::rangeCheckForAdd(int) - java.util.ArrayList.SubList::rangeCheckForAdd(int) - java.util.LinkedList::checkPositionIndex(int) - java.util.ImmutableCollections.SubList::rangeCheck(int) - java.util.ReverseOrderListView::checkClosedRange(int, int) - java.util.concurrent.CopyOnWriteArrayList.COWSubList::rangeCheckForAdd(int) There are also some methods that use if...throw directly to check these indexes: - java.lang.AbstractStringBuilder::offsetByCodePoints(int, int) - java.lang.Character::offsetByCodePoints(CharSequence, int, int) - java.lang.invoke.MethodType::insertParameterTypes(int, Class...) - java.util.ImmutableCollections.AbstractImmutableList::listIterator(int) - java.util.concurrent.CopyOnWriteArrayList::add(int, E) - java.util.regex.Matcher::find(int) Glavo On Tue, Jan 14, 2025 at 4:19?AM Kevin Bourrillion < kevin.bourrillion at oracle.com> wrote: > Oh hey, I named those Guava methods. :-) This was my attempt to promote > the terms ?position indexes vs. element indexes? and hope that the idea > caught on... which I?d say it still never has. I?m surprised you even > noticed the methods. > > The notion is that ?element indexes? are the buckets and ?position > indexes? are the possible insertion points *between* buckets. I > personally find it simpler to think of a method like `subList` as simply > accepting two position indexes, rather than thinking about half-open ranges. > > To me this was clarifying, but for people who never have this explained to > them it?s probably not that clear. > > And basically, the adoption counts for those methods always remained very > low. And I remember seeing a number of misuses, too. > > Not sure what to make of all this; just adding some context. > > > > On Jan 13, 2025, at 11:36?AM, Glavo wrote: > > Currently the java.util.Objects provide the method `checkIndex(int, int)` > for checking indexes. > It is convenient, but cannot be used to implement methods such as > List::add(int, E) because these methods accept an index pointing to the end > of the collection. > So is it possible to add a new method to Objects to check this kind of > index? > This is useful for implementing collections. > (The checkPositionIndex in the title is its name in guava. I don't like > the name, but I don't have a better idea.) > > Glavo > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iris at openjdk.org Tue Jan 14 03:20:40 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 14 Jan 2025 03:20:40 GMT Subject: RFR: 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 23:05:13 GMT, Naoto Sato wrote: > The use of [three-letter time zone IDs](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/util/TimeZone.html#three-letter-time-zone-ids-heading) has long been deprecated. For their actual removal in the future, making the runtime emit warnings for using those IDs would be desirable. > > --------- > ### Progress > - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > > > > ### Reviewers without OpenJDK IDs > * @abdelhak-zaaim (no known openjdk.org user name / role) > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.org/jdk.git pull/23049/head:pull/23049` \ > `$ git checkout pull/23049` > > Update a local copy of the PR: \ > `$ git checkout pull/23049` \ > `$ git pull https://git.openjdk.org/jdk.git pull/23049/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 23049` > > View PR using the GUI difftool: \ > `$ git pr show -t 23049` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.org/jdk/pull/23049.diff > >
Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23049#pullrequestreview-2548684638 From duke at openjdk.org Tue Jan 14 03:50:40 2025 From: duke at openjdk.org (duke) Date: Tue, 14 Jan 2025 03:50:40 GMT Subject: Withdrawn: 8342566: Improve javadoc of java.lang.annotation.ElementType In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 20:31:51 GMT, Kevin Bourrillion wrote: > 8342566: Improve javadoc of java.lang.annotation.ElementType This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21506 From redestad at openjdk.org Tue Jan 14 04:10:59 2025 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 14 Jan 2025 04:10:59 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v6] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 22:30:32 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen 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 19 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - form @cl4es > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - fix unsafe address overflow > - add benchmark > - remove comments, from @liach > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202410 > - fix Helper > - ... and 9 more: https://git.openjdk.org/jdk/compare/32ef3930...8122c1bf Always good to see some methods removed from `JavaLangAccess` - but it appears these are already unused? I think the performance gain from this is somewhat underwhelming. `Unsafe` is a big hammer to eek out ~10% performance in an isolated code path. And perhaps it would be better to just push the microbenchmark, any code cleanups (like the removal of unused methods from JavaLangAccess) and leave code unchanged and leave it as a challenge for JIT engineers to get the pre-existing code to parity with this `Unsafe` routine. That said I'm ok with this as is but will request a second opinion. Maybe @rgiulietti can weigh in? ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22023#pullrequestreview-2548739634 From dholmes at openjdk.org Tue Jan 14 04:53:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Jan 2025 04:53:36 GMT Subject: RFR: 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413 In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 21:58:43 GMT, Henry Jen wrote: > Sort services provided by a module to ensure reproduce same result. Seems reasonable. Thanks for fixing. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23088#pullrequestreview-2548790485 From galder at openjdk.org Tue Jan 14 05:10:41 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Tue, 14 Jan 2025 05:10:41 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Thu, 9 Jan 2025 12:18:48 GMT, Emanuel Peter wrote: >> @eme64 aarch64 work for this is now complete. I tweaked the `applyIf` condition `MinMaxRed_Long` to make sure `MaxVectorSize` is 32 or higher. I verified this on both Graviton 3 (256 bit register, `MaxVectorSize=32`) and an AVX-512 intel (512 bit register, `MaxVectorSize=64`) > > @galderz So you want me to review again? @eme64 I've fixed the test issue, it's ready to be reviewed ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2589014197 From iris at openjdk.org Tue Jan 14 05:22:36 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 14 Jan 2025 05:22:36 GMT Subject: [jdk24] RFR: 8347605: Use spec tag to refer to IEEE 754 standard In-Reply-To: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> References: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> Message-ID: On Mon, 13 Jan 2025 22:40:27 GMT, Joe Darcy wrote: > Get IEEE 754 added as an external standard in JDK 24's docs too. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23091#pullrequestreview-2548836665 From joehw at openjdk.org Tue Jan 14 05:22:37 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 14 Jan 2025 05:22:37 GMT Subject: RFR: 8323740: java.lang.ExceptionInInitializerError when trying to load XML classes in wrong order [v2] In-Reply-To: <7g-2K84LP3JyU_1lScCzI-g55KuLiENaR2j43cxhPGE=.3849e408-43d1-41c9-98c1-50139d4fe7b9@github.com> References: <7g-2K84LP3JyU_1lScCzI-g55KuLiENaR2j43cxhPGE=.3849e408-43d1-41c9-98c1-50139d4fe7b9@github.com> Message-ID: On Fri, 20 Dec 2024 19:27:00 GMT, Liam Miller-Cushon wrote: >> Please consider this fix for [JDK-8323740](https://bugs.openjdk.org/browse/JDK-8323740), which avoids an `ExceptionInInitializerError` in the class initializer of `XMLDocumentFragmentScannerImpl` and other classes that have a circular dependency on `jdk.xml.internal.JdkXmlUtils`. The change breaks the cycle by moving some initialization out of the class initializer of `JdkXmlUtils`. > > Liam Miller-Cushon 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 two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8323740 > - 8323740: java.lang.ExceptionInInitializerError when trying to load XML classes in wrong order Looks good. To answer Alan's question, it's unlikely to arise when using just the exported/supported API since the util class will generally be loaded early during the initialization process. ------------- Marked as reviewed by joehw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22803#pullrequestreview-2548837020 From joehw at openjdk.org Tue Jan 14 05:33:41 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 14 Jan 2025 05:33:41 GMT Subject: RFR: 8346142: [perf] scalability issue for the specjvm2008::xml.validation workload [v2] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 02:18:35 GMT, Vladimir Ivanov wrote: >> The double check needs less time vs enter to 'synchronize' block when it not needed. This patch for the xml.validation workload for runs with 112 threads reports ~2.5% improvement on the server with Xeon 8480: >> orig: 1T - 433.64 ops/m, 112T - 17344.25 ops/m >> patched: 1T - 437.01 ops/m, 112T - 17771.94 ops/m >> >> The tier1 and jaxp tests are OK with this patch. > > Vladimir Ivanov 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8346142 > - 8346142 [perf] scalability issue for the specjvm2008::xml.validation workload Nice improvement! ------------- Marked as reviewed by joehw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22723#pullrequestreview-2548846217 From iklam at openjdk.org Tue Jan 14 05:54:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 14 Jan 2025 05:54:39 GMT Subject: RFR: 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413 In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 21:58:43 GMT, Henry Jen wrote: > Sort services provided by a module to ensure reproduce same result. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23088#pullrequestreview-2548864954 From jpai at openjdk.org Tue Jan 14 06:22:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Jan 2025 06:22:39 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 06:01:55 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fix javadoc tag ordering - "@throws" after "@return" Thank you all for the reviews and the inputs. The CSR has been approved. I'll go ahead and integrate this shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19675#issuecomment-2589123865 From dholmes at openjdk.org Tue Jan 14 06:32:46 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Jan 2025 06:32:46 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 11:07:11 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitFail avgt 30 42.061 ? 1.261 ns/op >> CaptureStateUtilBench.explicitSuccess avgt 30 23.142 ? 0.739 ns/op >> CaptureStateUtilBench.tlFail avgt 30 23.580 ? 0.267 ns/op >> CaptureStateUtilBench.tlSuccess avgt 30 1.753 ? 0.016 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/3cf122bb-0ed6-4dd6-ab6d-dcada0147efb) >> >> This is a >10x improvement on the happy path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update benchmark and micro optimize Where do you actually make the native call and grab the errno/last-error value? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22391#issuecomment-2589134251 From alanb at openjdk.org Tue Jan 14 06:41:43 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 06:41:43 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: On Mon, 13 Jan 2025 16:28:52 GMT, Viktor Klang wrote: > Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. > There's a contributor PR from the java bugs submitter at #23050, I wonder what we should do in this case. The PR has the "oca" label so we can't look or comment on it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23081#issuecomment-2589146489 From alanb at openjdk.org Tue Jan 14 06:43:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 06:43:45 GMT Subject: RFR: 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413 In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 21:58:43 GMT, Henry Jen wrote: > Sort services provided by a module to ensure reproduce same result. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23088#pullrequestreview-2548918741 From alanb at openjdk.org Tue Jan 14 06:55:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 06:55:50 GMT Subject: RFR: 8347039: ThreadPerTaskExecutor terminates if cancelled tasks still running Message-ID: The thread-per-task-executor returned by Executors.newVirtualThreadPerTaskExecutor will terminate without waiting for threads that are still executing cancelled tasks. This is different to ThreadPoolExecutor and ForkJoinPool that wait for the threads to finish executing the cancelled tasks. Note that issue with TPTE is specific to Callable tasks, Runnable tasks are not impacted. The change is to override FutureTask.run instead of FutureTask.done. Test coverage is expanded to cover this case. ------------- Commit messages: - Merge branch 'master' into JDK-8347039 - Add asserts to check Future state - Fix typo in comment - Merge branch 'master' into JDK-8347039 - Initial commit Changes: https://git.openjdk.org/jdk/pull/23036/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23036&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347039 Stats: 66 lines in 2 files changed: 54 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/23036.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23036/head:pull/23036 PR: https://git.openjdk.org/jdk/pull/23036 From vklang at openjdk.org Tue Jan 14 06:55:51 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 06:55:51 GMT Subject: RFR: 8347039: ThreadPerTaskExecutor terminates if cancelled tasks still running In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 13:32:39 GMT, Alan Bateman wrote: > The thread-per-task-executor returned by Executors.newVirtualThreadPerTaskExecutor will terminate without waiting for threads that are still executing cancelled tasks. This is different to ThreadPoolExecutor and ForkJoinPool that wait for the threads to finish executing the cancelled tasks. Note that issue with TPTE is specific to Callable tasks, Runnable tasks are not impacted. The change is to override FutureTask.run instead of FutureTask.done. Test coverage is expanded to cover this case. test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 306: > 304: stop.await(); > 305: return null; > 306: }); One (additional?) option would be to obtain a reference to the returned Future from submit and assert that the Future isn't done after shutdown() returns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23036#discussion_r1910436867 From vklang at openjdk.org Tue Jan 14 06:55:51 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 06:55:51 GMT Subject: RFR: 8347039: ThreadPerTaskExecutor terminates if cancelled tasks still running In-Reply-To: <01gZ1yJjhgZi1qG1BTMCHxDi3wxFywWCWqVBHJm566A=.30ba01c4-7aae-4577-be00-4a5f7f8388eb@github.com> References: <01gZ1yJjhgZi1qG1BTMCHxDi3wxFywWCWqVBHJm566A=.30ba01c4-7aae-4577-be00-4a5f7f8388eb@github.com> Message-ID: On Sat, 11 Jan 2025 07:29:32 GMT, Alan Bateman wrote: >> test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 306: >> >>> 304: stop.await(); >>> 305: return null; >>> 306: }); >> >> One (additional?) option would be to obtain a reference to the returned Future from submit and assert that the Future isn't done after shutdown() returns. > > Done but I don't want to too far with adding tests for Future methods in these test methods, only because the testAwaitTerminationXXX methods are for awaitTermination. @AlanBateman That's fair, my suggestion was based on the notion that the task/future itself was changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23036#discussion_r1911985040 From alanb at openjdk.org Tue Jan 14 06:55:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 06:55:51 GMT Subject: RFR: 8347039: ThreadPerTaskExecutor terminates if cancelled tasks still running In-Reply-To: References: Message-ID: <01gZ1yJjhgZi1qG1BTMCHxDi3wxFywWCWqVBHJm566A=.30ba01c4-7aae-4577-be00-4a5f7f8388eb@github.com> On Fri, 10 Jan 2025 14:16:44 GMT, Viktor Klang wrote: >> The thread-per-task-executor returned by Executors.newVirtualThreadPerTaskExecutor will terminate without waiting for threads that are still executing cancelled tasks. This is different to ThreadPoolExecutor and ForkJoinPool that wait for the threads to finish executing the cancelled tasks. Note that issue with TPTE is specific to Callable tasks, Runnable tasks are not impacted. The change is to override FutureTask.run instead of FutureTask.done. Test coverage is expanded to cover this case. > > test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 306: > >> 304: stop.await(); >> 305: return null; >> 306: }); > > One (additional?) option would be to obtain a reference to the returned Future from submit and assert that the Future isn't done after shutdown() returns. Done but I don't want to too far with adding tests for Future methods in these test methods, only because the testAwaitTerminationXXX methods are for awaitTermination. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23036#discussion_r1911923157 From pminborg at openjdk.org Tue Jan 14 07:37:39 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 14 Jan 2025 07:37:39 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 06:29:36 GMT, David Holmes wrote: > Where do you actually make the native call and grab the errno/last-error value? So, as we foresee the adoption of the FFM API in the JDK internals, we will use such a mechanism for system calls like `fopen`, `socket`, and the like. See https://github.com/openjdk/jdk/pull/22307 for example. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22391#issuecomment-2589211900 From pminborg at openjdk.org Tue Jan 14 07:37:42 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 14 Jan 2025 07:37:42 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 11:06:36 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Clean up benchmark >> - Fix allocation problem in benchmark > > src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 214: > >> 212: // Used reflectively by `getAsIntHandle(MemoryLayout layout)` >> 213: private static int getStateAsInt(VarHandle handle) { >> 214: if (Thread.currentThread().isVirtual() && ContinuationSupport.isSupported()) { > > Shouldn't we pin for the entire duration of the native call + errno retrieval? Otherwise, can't we end up in a situation where we have a back to back native call where the second native call overwrites the errno state of the first? True. We need to rework the solution a bit as we do not want to pin virtual threads during system calls. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1914364338 From liach at openjdk.org Tue Jan 14 07:43:05 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 14 Jan 2025 07:43:05 GMT Subject: RFR: 8347471: Provide valid flags and mask in AccessFlag.Location Message-ID: Some AccessFlag parsing methods throw IAE because a flag mask is not valid in a location. However, there is no easy way to check what flag mask bits or what flags are valid for a location. We need such APIs to check, specific to each class file format version. Also in the investigation, it's noted that `ACC_SYNTHETIC` is incorrectly represented - it is available since release 5.0 instead of release 7. This bug is fixed together for implementation simplicity. The new methods are all in `AccessFlag.Location`: - `Set flags()` - `int flagsMask()` - `Set flags(ClassFileFormatVersion)` - `int flagsMask(ClassFileFormatVersion)` Also there is some simplification to `AccessFlag` itself to remove the anonymous classes, which should be more startup-friendly. Testing: Tier 1-3 ------------- Commit messages: - ClassLoading order, Typos in NPE test - 8347471: Provide valid flags and mask in AccessFlag.Location Changes: https://git.openjdk.org/jdk/pull/23095/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23095&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347471 Stats: 548 lines in 7 files changed: 282 ins; 137 del; 129 mod Patch: https://git.openjdk.org/jdk/pull/23095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23095/head:pull/23095 PR: https://git.openjdk.org/jdk/pull/23095 From alanb at openjdk.org Tue Jan 14 08:21:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 08:21:44 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 06:01:55 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fix javadoc tag ordering - "@throws" after "@return" src/java.base/share/classes/java/util/zip/Deflater.java line 52: > 50: *

> 51: * This class deflates sequences of bytes into ZLIB compressed data format. > 52: * The input byte sequence is provided in either byte array or {@link ByteBuffer}, We should probably fix this sentence to say "in either a byte array or ...". src/java.base/share/classes/java/util/zip/Deflater.java line 60: > 58: * {@code Deflater} by calling either the {@link #end()} or the {@link #close()} method. > 59: * After the {@code Deflater} has been closed, subsequent calls to several methods > 60: * of the {@code Deflater} will throw an {@link IllegalStateException}. This paragraph uses the definite article but there isn't a specific Deflater to speak of, and it's not a singleton. The first sentence of this paragraph might be better if re-worded "To release the resources used a Deflater, an application must close it by invoking its end() or close() method". src/java.base/share/classes/java/util/zip/Deflater.java line 66: > 64: * {@code try}-with-resources statement. The {@linkplain Deflater#close() close() method} simply > 65: * calls {@code end()}. Subclasses should override {@linkplain #end()} to clean up the > 66: * resources acquired by the subclass. I wonder if the note for subclasses should move to the end method as implSpec, it looks out of place in the class API note. src/java.base/share/classes/java/util/zip/Deflater.java line 892: > 890: * and discards any unprocessed input. > 891: *

> 892: * If this method is invoked multiple times, the second and subsequent calls do nothing. I think this could be clearer if you replace this sentence with "If the Deflater is already closed then invoking this method has no effect." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914314823 PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914408496 PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914413749 PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914410532 From epeter at openjdk.org Tue Jan 14 08:23:40 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 14 Jan 2025 08:23:40 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v9] In-Reply-To: <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com> References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com> Message-ID: On Mon, 13 Jan 2025 17:12:31 GMT, Galder Zamarre?o wrote: >> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. >> >> Currently vectorization does not kick in for loops containing either of these calls because of the following error: >> >> >> VLoop::check_preconditions: failed: control flow in loop not allowed >> >> >> The control flow is due to the java implementation for these methods, e.g. >> >> >> public static long max(long a, long b) { >> return (a >= b) ? a : b; >> } >> >> >> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. >> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. >> E.g. >> >> >> SuperWord::transform_loop: >> Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined >> 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) >> >> >> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> long min 1155 >> long max 1173 >> >> >> After the patch, on darwin/aarch64 (M1): >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> long min 1042 >> long max 1042 >> >> >> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. >> Therefore, it still relies on the macro expansion to transform those into CMoveL. >> >> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PA... > > Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: > > Make sure it runs with cpus with either avx512 or asimd test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 2: > 1: /* > 2: * Copyright (c) 2024, Red Hat, Inc. All rights reserved. Should probably be 2025 by now, right? At least that is our policy for Oracle, not sure what you want to do at Red Hat ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914414960 From liach at openjdk.org Tue Jan 14 08:31:39 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 14 Jan 2025 08:31:39 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 08:18:57 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> fix javadoc tag ordering - "@throws" after "@return" > > src/java.base/share/classes/java/util/zip/Deflater.java line 66: > >> 64: * {@code try}-with-resources statement. The {@linkplain Deflater#close() close() method} simply >> 65: * calls {@code end()}. Subclasses should override {@linkplain #end()} to clean up the >> 66: * resources acquired by the subclass. > > I wonder if the note for subclasses should move to the end method as implSpec, it looks out of place in the class API note. I believe an `@implSpec` only restricts the implementation of this immediate method, such as those seen on default methods, and has no impact on the overrides. If we need to specify something for overrides to abide to, I believe they usually stay in the API specification itself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914425192 From epeter at openjdk.org Tue Jan 14 08:41:46 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 14 Jan 2025 08:41:46 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v9] In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com> Message-ID: On Tue, 14 Jan 2025 08:29:25 GMT, Emanuel Peter wrote: >> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: >> >> Make sure it runs with cpus with either avx512 or asimd > > test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 104: > >> 102: } >> 103: >> 104: public static void ReductionInit(long[] longs, int probability) { > > Suggestion: > > public static void reductionInit(long[] longs, int probability) { > > This is a method name, not a class - so I think it should start lower-case, right? And the method might as well allocate the array too. But up to you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914427359 From epeter at openjdk.org Tue Jan 14 08:41:45 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 14 Jan 2025 08:41:45 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v9] In-Reply-To: <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com> References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com> Message-ID: On Mon, 13 Jan 2025 17:12:31 GMT, Galder Zamarre?o wrote: >> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. >> >> Currently vectorization does not kick in for loops containing either of these calls because of the following error: >> >> >> VLoop::check_preconditions: failed: control flow in loop not allowed >> >> >> The control flow is due to the java implementation for these methods, e.g. >> >> >> public static long max(long a, long b) { >> return (a >= b) ? a : b; >> } >> >> >> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. >> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. >> E.g. >> >> >> SuperWord::transform_loop: >> Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined >> 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) >> >> >> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> long min 1155 >> long max 1173 >> >> >> After the patch, on darwin/aarch64 (M1): >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> long min 1042 >> long max 1042 >> >> >> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. >> Therefore, it still relies on the macro expansion to transform those into CMoveL. >> >> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PA... > > Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: > > Make sure it runs with cpus with either avx512 or asimd Changes requested by epeter (Reviewer). test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxInlining.java line 2: > 1: /* > 2: * Copyright (c) 2024, Red Hat, Inc. All rights reserved. Year 2025? No idea what the Red Hat policy is though. test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 104: > 102: } > 103: > 104: public static void ReductionInit(long[] longs, int probability) { Suggestion: public static void reductionInit(long[] longs, int probability) { This is a method name, not a class - so I think it should start lower-case, right? test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 107: > 105: int aboveCount, abovePercent; > 106: > 107: // Iterate until you find a set that matches the requirement probability Can you give a high-level definition / explanation what this does? Also: what is the expected number of rounds you iterate here? I'm asking because I would like to be sure that a timeout is basically impossible because the probability is too low. test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 121: > 119: } else { > 120: // Decrement by at least 1 > 121: long decrement = random.nextLong(10) + 1; Nit: I would call it `diffToMax`, because you are really just going to get a value below the `max`, and you are not decrementing the `max`. But up to you if you want to change it. ------------- PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2549073452 PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914424784 PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914426190 PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914431043 PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1914434395 From epeter at openjdk.org Tue Jan 14 08:46:38 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 14 Jan 2025 08:46:38 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Tue, 14 Jan 2025 05:07:55 GMT, Galder Zamarre?o wrote: >> @galderz So you want me to review again? > > @eme64 I've fixed the test issue, it's ready to be reviewed @galderz I don't remember from above, but did you ever run the Long Min/Max benchmarks from this? https://github.com/openjdk/jdk/pull/21032 Would just be nice to see that they have an improvement after this change :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2589327111 From alanb at openjdk.org Tue Jan 14 08:52:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 08:52:40 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 07:31:08 GMT, Per Minborg wrote: >> src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 214: >> >>> 212: // Used reflectively by `getAsIntHandle(MemoryLayout layout)` >>> 213: private static int getStateAsInt(VarHandle handle) { >>> 214: if (Thread.currentThread().isVirtual() && ContinuationSupport.isSupported()) { >> >> Shouldn't we pin for the entire duration of the native call + errno retrieval? Otherwise, can't we end up in a situation where we have a back to back native call where the second native call overwrites the errno state of the first? > > True. We need to rework the solution a bit as we do not want to pin virtual threads during system calls. A virtual thread can't unmount when there is a native frame on the continuation stack so it's pinned when in the syscall. For the errno capture then I think it will need to explicitly pin before the syscall, then unpin after the capture. The only access to the carrier local will be while pinned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1914451688 From epeter at openjdk.org Tue Jan 14 08:57:45 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 14 Jan 2025 08:57:45 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Tue, 14 Jan 2025 05:07:55 GMT, Galder Zamarre?o wrote: >> @galderz So you want me to review again? > > @eme64 I've fixed the test issue, it's ready to be reviewed @galderz I ran some testing on our side, feel free to ping me in 1-2 days for the results. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2589351747 From jpai at openjdk.org Tue Jan 14 08:58:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Jan 2025 08:58:46 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 06:35:04 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> fix javadoc tag ordering - "@throws" after "@return" > > src/java.base/share/classes/java/util/zip/Deflater.java line 52: > >> 50: *

>> 51: * This class deflates sequences of bytes into ZLIB compressed data format. >> 52: * The input byte sequence is provided in either byte array or {@link ByteBuffer}, > > We should probably fix this sentence to say "in either a byte array or ...". Fixed. > src/java.base/share/classes/java/util/zip/Deflater.java line 60: > >> 58: * {@code Deflater} by calling either the {@link #end()} or the {@link #close()} method. >> 59: * After the {@code Deflater} has been closed, subsequent calls to several methods >> 60: * of the {@code Deflater} will throw an {@link IllegalStateException}. > > This paragraph uses the definite article but there isn't a specific Deflater to speak of, and it's not a singleton. The first sentence of this paragraph might be better if re-worded "To release the resources used a Deflater, an application must close it by invoking its end() or close() method". I have reworded the sentence to follow your input. Addtionally, I've removed the second sentence, since as you note, relevant methods on the Inflater/Deflater (as part of this PR) already have been updated to state that they throw an `IllegalStateException` if the Inflater/Deflater is already closed. > src/java.base/share/classes/java/util/zip/Deflater.java line 892: > >> 890: * and discards any unprocessed input. >> 891: *

>> 892: * If this method is invoked multiple times, the second and subsequent calls do nothing. > > I think this could be clearer if you replace this sentence with "If the Deflater is already closed then invoking this method has no effect." Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914455153 PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914457795 PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914458103 From jpai at openjdk.org Tue Jan 14 08:58:42 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Jan 2025 08:58:42 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v16] In-Reply-To: References: Message-ID: > Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? > > The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: > > https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html > > To summarize those discussions, we had concluded that: > - `Deflater` and `Inflater` will implement the `AutoCloseable` interface > - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). > - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. > - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. > - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. > > New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. > > I'll file a CSR shortly. Jaikiran Pai 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 33 additional commits since the last revision: - Improve the javadoc on #end() methods - Alan's input - simplify the class level javadoc - add missing "a" in the javadoc - merge latest from master branch - merge latest from master branch - fix javadoc tag ordering - "@throws" after "@return" - change "@since" to 25 - test code comment improvement - Roger's review - improve class level javadoc text of Inflater/Deflater - merge latest from master branch - ... and 23 more: https://git.openjdk.org/jdk/compare/2fc8af51...1cd16c41 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19675/files - new: https://git.openjdk.org/jdk/pull/19675/files/4fbbc83d..1cd16c41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=14-15 Stats: 24578 lines in 762 files changed: 7233 ins; 13850 del; 3495 mod Patch: https://git.openjdk.org/jdk/pull/19675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675 PR: https://git.openjdk.org/jdk/pull/19675 From ysuenaga at openjdk.org Tue Jan 14 09:08:37 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 14 Jan 2025 09:08:37 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v4] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 18:19:59 GMT, Henry Jen wrote: >> Improving option value handling to support passing argument value starts with "--". >> >> Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. >> --add-options --add-modules=jdk.incubator.concurrent >> --add-options=--add-modules=jdk.incubator.concurrent >> >> will cause JLink to report >> Error: no value given for --add-options >> as --add-modules is considered another option for JLink. >> >> After the fix, by using = will ensure the value is properly handled as argument value >> --add-options=--add-modules=jdk.incubator.concurrent > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Use different error message for ambiguous gnu-style options as value It's better, thanks! ------------- Marked as reviewed by ysuenaga (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22526#pullrequestreview-2549151453 From jpai at openjdk.org Tue Jan 14 09:23:35 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Jan 2025 09:23:35 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v17] In-Reply-To: References: Message-ID: > Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? > > The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: > > https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html > > To summarize those discussions, we had concluded that: > - `Deflater` and `Inflater` will implement the `AutoCloseable` interface > - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). > - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. > - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. > - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. > > New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. > > I'll file a CSR shortly. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Move the guidance to subclasses to the end() method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19675/files - new: https://git.openjdk.org/jdk/pull/19675/files/1cd16c41..45bad0e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=15-16 Stats: 10 lines in 2 files changed: 6 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675 PR: https://git.openjdk.org/jdk/pull/19675 From jpai at openjdk.org Tue Jan 14 09:23:37 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Jan 2025 09:23:37 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 08:28:38 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/util/zip/Deflater.java line 66: >> >>> 64: * {@code try}-with-resources statement. The {@linkplain Deflater#close() close() method} simply >>> 65: * calls {@code end()}. Subclasses should override {@linkplain #end()} to clean up the >>> 66: * resources acquired by the subclass. >> >> I wonder if the note for subclasses should move to the end method as implSpec, it looks out of place in the class API note. > > I believe an `@implSpec` only restricts the implementation of this immediate method, such as those seen on default methods, and has no impact on the overrides. If we need to specify something for overrides to abide to, I believe they usually stay in the API specification itself. > I wonder if the note for subclasses should move to the end method as implSpec, it looks out of place in the class API note. Stuart, in his inputs here https://github.com/openjdk/jdk/pull/19675#issuecomment-2172433871 and here https://github.com/openjdk/jdk/pull/19675#discussion_r1848945718 had noted that it would be useful to add this guidance to subclasses. But I see that he wasn't fully convinced whether it must be a apiNote or something else. Given what you note about moving this detail for subclasses to a `@implSpec` on the end() method, I have now updated the PR accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914488626 From jpai at openjdk.org Tue Jan 14 09:23:37 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Jan 2025 09:23:37 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v15] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 09:17:59 GMT, Jaikiran Pai wrote: >> I believe an `@implSpec` only restricts the implementation of this immediate method, such as those seen on default methods, and has no impact on the overrides. If we need to specify something for overrides to abide to, I believe they usually stay in the API specification itself. > >> I wonder if the note for subclasses should move to the end method as implSpec, it looks out of place in the class API note. > > Stuart, in his inputs here https://github.com/openjdk/jdk/pull/19675#issuecomment-2172433871 and here https://github.com/openjdk/jdk/pull/19675#discussion_r1848945718 had noted that it would be useful to add this guidance to subclasses. But I see that he wasn't fully convinced whether it must be a apiNote or something else. Given what you note about moving this detail for subclasses to a `@implSpec` on the end() method, I have now updated the PR accordingly. Hello Chen, > I believe an @implSpec only restricts the implementation of this immediate method, such as those seen on default methods, and has no impact on the overrides. Based on the details about these tags here https://openjdk.org/jeps/8068562, I think the `@implSpec` is the most relevant one for this text: > Interface implementors or class subclassers use the information here in order to decide whether it is sensible or necessary to override a particular method ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1914491835 From asotona at openjdk.org Tue Jan 14 09:31:43 2025 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Jan 2025 09:31:43 GMT Subject: Integrated: 8346986: Remove ASM from java.base In-Reply-To: References: Message-ID: On Tue, 7 Jan 2025 12:49:40 GMT, Adam Sotona wrote: > There are no more consumers of ASM library except for hotspot tests. > This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 3e989fd0 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/3e989fd0f7796a2352ffb1bbeee2dcd89a4416ca Stats: 4233 lines in 322 files changed: 1409 ins; 1442 del; 1382 mod 8346986: Remove ASM from java.base Reviewed-by: dholmes, ihse, lmesnik, alanb ------------- PR: https://git.openjdk.org/jdk/pull/22946 From asotona at openjdk.org Tue Jan 14 09:31:42 2025 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 14 Jan 2025 09:31:42 GMT Subject: RFR: 8346986: Remove ASM from java.base [v8] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 08:14:08 GMT, Adam Sotona wrote: >> There are no more consumers of ASM library except for hotspot tests. >> This patch moves ASM library from java.base module to the hotspot test libraries location and fixes the tests. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > moved asm.md to the testlibrary/asm Tier 1 - 8 tests passed (except for 2 unrelated Swing tests). Thank you for all the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22946#issuecomment-2589418041 From sgehwolf at openjdk.org Tue Jan 14 09:42:50 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 14 Jan 2025 09:42:50 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 14:58:36 GMT, Severin Gehwolf wrote: >> During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. >> >> Testing: >> - [x] GHA >> - [x] tools/jlink tests (including the new one). >> >> Thoughts? > > Severin Gehwolf 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: > > - Merge branch 'master' into jdk-8347334-jimage-diff-gen-cleanup > - Further simplification > - Review feedback > - 8347334: JimageDiffGenerator code clean-ups Still looking for a Reviewer to ack this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23014#issuecomment-2589444573 From vklang at openjdk.org Tue Jan 14 10:08:36 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 10:08:36 GMT Subject: RFR: 8347039: ThreadPerTaskExecutor terminates if cancelled tasks still running In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 13:32:39 GMT, Alan Bateman wrote: > The thread-per-task-executor returned by Executors.newVirtualThreadPerTaskExecutor will terminate without waiting for threads that are still executing cancelled tasks. This is different to ThreadPoolExecutor and ForkJoinPool that wait for the threads to finish executing the cancelled tasks. Note that issue with TPTE is specific to Callable tasks, Runnable tasks are not impacted. The change is to override FutureTask.run instead of FutureTask.done. Test coverage is expanded to cover this case. LGTM ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23036#pullrequestreview-2549285706 From cstein at openjdk.org Tue Jan 14 10:38:46 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 14 Jan 2025 10:38:46 GMT Subject: Integrated: 8346778: Enable native access should work with the source launcher In-Reply-To: References: Message-ID: <8bKSKb4mCjctEm--PsP81y4ZOXycyQgp3Yw7MFUQNIs=.fa345365-bd19-4289-818a-7a1b3f167e49@github.com> On Mon, 6 Jan 2025 16:35:59 GMT, Christian Stein wrote: > Please review this change request enabling native access in source launch mode when using a modular setup. > > The change comes in two parts: > 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java` > 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java` > > Tested tier1..3. This pull request has now been integrated. Changeset: fec769b0 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/fec769b0a840ca4351e2458c24184ec69c112c09 Stats: 82 lines in 6 files changed: 67 ins; 0 del; 15 mod 8346778: Enable native access should work with the source launcher Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/22930 From cstein at openjdk.org Tue Jan 14 10:38:45 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 14 Jan 2025 10:38:45 GMT Subject: RFR: 8346778: Enable native access should work with the source launcher [v3] In-Reply-To: <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com> References: <8_eMCvAuwc2DKbDZnmgJXjs6L2MgkgxRxnF7H5wn0OY=.a53e3440-109c-4e76-ba49-bea945c7ff7e@github.com> Message-ID: <9nkZ1eJrUbtkSnoTuRIuWPwLoigWn1Oxe7Seu3TEXDg=.b6f54c6f-3061-4bac-806a-73d08b2c7531@github.com> On Mon, 13 Jan 2025 11:29:06 GMT, Christian Stein wrote: >> Please review this change request enabling native access in source launch mode when using a modular setup. >> >> The change comes in two parts: >> 1. Prevent warnings of unknown modules being emitted from module bootstrap for user module not being present in the boot layer: `java.c` and `ModuleBootstrap.java` >> 2. Enable native access in source module(s) and also user modules on the module path as requested by `--enable-native-access` via the `ModuleLayer.Controller` API - and emit warning for unknown modules: `MemoryContext.java` >> >> Tested tier1..3. > > Christian Stein has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > - Update src/java.base/share/native/libjli/java.c > > [skip ci] > - Update src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java > > [skip ci] Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22930#issuecomment-2589560502 From vklang at openjdk.org Tue Jan 14 10:55:54 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 10:55:54 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v2] In-Reply-To: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: > Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Updates the ThreadPoolExecutorTest.java to assert the exception messages added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23081/files - new: https://git.openjdk.org/jdk/pull/23081/files/10f59695..7cf05b5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23081&range=00-01 Stats: 151 lines in 2 files changed: 116 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/23081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23081/head:pull/23081 PR: https://git.openjdk.org/jdk/pull/23081 From vklang at openjdk.org Tue Jan 14 11:02:45 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 11:02:45 GMT Subject: [jdk24] RFR: 8347542: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> References: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> Message-ID: On Mon, 13 Jan 2025 12:59:06 GMT, Viktor Klang wrote: > Backport to jdk24 of https://bugs.openjdk.org/browse/JDK-8347274 Opening a new PR as something didn't go right with this manual backport. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23068#issuecomment-2589611975 From vklang at openjdk.org Tue Jan 14 11:02:46 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 11:02:46 GMT Subject: [jdk24] RFR: 8347542: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: References: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> Message-ID: On Mon, 13 Jan 2025 19:20:41 GMT, He-Pin(kerr) wrote: >> Backport to jdk24 of https://bugs.openjdk.org/browse/JDK-8347274 > > Does this fix the OOM problem? > > > import java.util.stream.Gatherers; > import java.util.stream.IntStream; > > /** > * TODO: description of this file > * > * @author ?? > */ > public class Main { > public static void main(String[] args) { > final var stream = IntStream.range(0, Integer.MAX_VALUE); > stream.boxed() > .gather(Gatherers.mapConcurrent( > 2, > i -> { > if (i == 0) { > try { > Thread.sleep(Integer.MAX_VALUE); > } catch (InterruptedException e) { > throw new RuntimeException(e); > } > } > return i; > })) > .forEach(System.out::println); > try { > Thread.sleep(Integer.MAX_VALUE); > } catch (InterruptedException e) { > throw new RuntimeException(e); > } > } > } @He-Pin I believe it will, yes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23068#issuecomment-2589614630 From vklang at openjdk.org Tue Jan 14 11:02:46 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 11:02:46 GMT Subject: [jdk24] Withdrawn: 8347542: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> References: <7xlJesBPN1D9CC-GnkJgvZMos3STwtUUloLOo08aTBA=.44e14adc-867a-4547-b573-2ade17525520@github.com> Message-ID: On Mon, 13 Jan 2025 12:59:06 GMT, Viktor Klang wrote: > Backport to jdk24 of https://bugs.openjdk.org/browse/JDK-8347274 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/23068 From vklang at openjdk.org Tue Jan 14 11:09:10 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 11:09:10 GMT Subject: [jdk24] RFR: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing Message-ID: Hi all, This pull request contains a backport of commit [450636ae](https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Viktor Klang on 13 Jan 2025 and was reviewed by Alan Bateman. Thanks! ------------- Commit messages: - Backport 450636ae28b84ded083b6861c6cba85fbf87e16e Changes: https://git.openjdk.org/jdk/pull/23100/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23100&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347274 Stats: 148 lines in 2 files changed: 93 ins; 16 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/23100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23100/head:pull/23100 PR: https://git.openjdk.org/jdk/pull/23100 From alanb at openjdk.org Tue Jan 14 11:32:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 11:32:41 GMT Subject: [jdk24] RFR: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 11:03:38 GMT, Viktor Klang wrote: > Hi all, > > This pull request contains a backport of commit [450636ae](https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Viktor Klang on 13 Jan 2025 and was reviewed by Alan Bateman. > > Thanks! Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23100#pullrequestreview-2549462926 From alanb at openjdk.org Tue Jan 14 11:48:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 11:48:44 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v17] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 09:23:35 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Move the guidance to subclasses to the end() method Thanks for the updates, looks good now. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19675#pullrequestreview-2549495358 From dholmes at openjdk.org Tue Jan 14 12:31:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 14 Jan 2025 12:31:39 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7] In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 11:07:11 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitFail avgt 30 42.061 ? 1.261 ns/op >> CaptureStateUtilBench.explicitSuccess avgt 30 23.142 ? 0.739 ns/op >> CaptureStateUtilBench.tlFail avgt 30 23.580 ? 0.267 ns/op >> CaptureStateUtilBench.tlSuccess avgt 30 1.753 ? 0.016 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/3cf122bb-0ed6-4dd6-ab6d-dcada0147efb) >> >> This is a >10x improvement on the happy path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Update benchmark and micro optimize > So, as we foresee the adoption of the FFM API in the JDK internals, we will use such a mechanism for system calls like `fopen`, `socket`, and the like. > > See #22307 for example. Sorry I still don't see where you do the actual native call and read errno. Just to be clear you have to read errno/last-error immediately after the native call. You can't for example, return to Java see the call failed and then make a second native call to retrieve errno. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22391#issuecomment-2589788261 From jbhateja at openjdk.org Tue Jan 14 13:09:45 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 14 Jan 2025 13:09:45 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: References: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> Message-ID: On Mon, 13 Jan 2025 16:51:02 GMT, Paul Sandoz wrote: >> Hi @PaulSandoz , In the current scheme we are passing unboxed carriers to intrinsic entry point, in the fallback implementation carrier type is first converted to floating point value using Float.float16ToFloat API which expects to receive a short type argument, after the operation we again convert float value to carrier type (short) using Float.floatToFloat16 API which expects a float argument, thus our intent here is to perform unboxing and boxing outside the intrinsic thereby avoiding all complexities around boxing by compiler. Even if we pass 3 additional parameters we still need to use Float16.floatValue which invokes Float.float16ToFloat underneath, thus this minor modification on Java side is on account of optimizing the intrinsic interface. > > Yes, i understand the approach. It's about clarity of the fallback implementation retaining what was expressed in the original code: > > short res = Float16Math.fma(fa, fb, fc, a, b, c, > (a_, b_, c_) -> { > double product = (double)(a_.floatValue() * b._floatValue()); > return valueOf(product + c_.doubleValue()); > }); Hi @PaulSandoz , In above code snippet the return type 'short' of intrinsic call does not comply with the value being returned which is of box type, thereby mandating addition glue code. Regular primitive type boxing APIs are lazily intrinsified, thereby generating an intrinsifiable Call IR during parsing. LoadNode?s idealization can fetch a boxed value from the input of boxing call IR and directly forward it to users. Q1. What is the problem in directly passing Float16 boxes to FMA and SQRT intrinsic entry points? A. The compiler will have to unbox them before the actual operation. There are multiple schemes to perform unboxing, such as name-based, offset-based, and index-based field lookup. Vector API unbox expansion uses an offset-based payload field lookup, for this it bookkeeps the payload?s offset over runtime representation of VectorPayload class created as part of VM initialization. However, VM can only bookkeep this information for classes that are part of java.base module, Float16 being part of incubation module cannot use offset-based field lookup. Thus only viable alternative is to unbox using field name/index based lookup. For this compiler will first verify that the incoming oop is of Float16 type and then use a hardcoded name-based lookup to Load the field value. This looks fragile as it establishes an unwanted dependency b/w Float16 field names and compiler implementation, same applies to index-based lookup as index values are dependent onthe combined field count of class and instance-specific fields, thus any addition or deletion of a class-level static helper field before the field of interest can invalidate any hardcoded index value used by the compiler. All in all, for safe and reliable unboxing by compiler, it's necessary to create an upfront VM representation like vector_VectorPayload. Q2. What are the pros and cons of passing both the unboxed value and boxed values to the intrinsic entry point? A. Pros: - This will save unsafe unboxing implementation if the holder class is not part of java.base module. - We can leverage existing box intrinsification infrastructure which directly forwards the embedded values to its users. - Also, it will minimize the changes in the Java side implementation. Cons: - It's suboptimal in case the call is neither intrinsified or inlined, as it will add additional spills before the call. Q3. Primitive box class boxing API ?valueOf? accepts an argument of the corresponding primitive type. How different are Float16 boxing APIs. A. Unlike primitive box classes, Float16 has multiple boxing APIs and none of them accept a short type argument. public static Float16 valueOf(int value) public static Float16 valueOf(long value) public static Float16 valueOf(float f) public static Float16 valueOf(double d) public static Float16 valueOf(String s) throws NumberFormatException public static Float16 valueOf(BigDecimal v) public static Float16 valueOf(BigInteger bi) Thus, we need to add special handling to first downcast the parameter value to short type carrier otherwise it will pose problems in forwarding the boxed values. Existing LoadNode idealization directly forwards the input of unboxed Call IR to its users. To use existing idealization, we need to massage the input of unboxed Call IR to the exact carrier size, so it?s not a meager one-line change in the following methods to enable seamless intrinsification of Float16 boxing APIs. bool ciMethod::is_boxing_method() const bool ciMethod::is_unboxing_method() const Given the above observations passing 3 additional box arguments to intrinsic and returning a box value needs additional changes in the compiler while minor re-structuring in Java implementation packed with in the glue logic looks like a reasonable approach. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1914782512 From vklang at openjdk.org Tue Jan 14 13:34:56 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 14 Jan 2025 13:34:56 GMT Subject: [jdk24] Integrated: 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 11:03:38 GMT, Viktor Klang wrote: > Hi all, > > This pull request contains a backport of commit [450636ae](https://github.com/openjdk/jdk/commit/450636ae28b84ded083b6861c6cba85fbf87e16e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Viktor Klang on 13 Jan 2025 and was reviewed by Alan Bateman. > > Thanks! This pull request has now been integrated. Changeset: 24053d9b Author: Viktor Klang URL: https://git.openjdk.org/jdk/commit/24053d9b6a10f51101aaa1f9e12fb2664d74e3f3 Stats: 148 lines in 2 files changed: 93 ins; 16 del; 39 mod 8347274: Gatherers.mapConcurrent exhibits undesired behavior under variable delays, interruption, and finishing Reviewed-by: alanb Backport-of: 450636ae28b84ded083b6861c6cba85fbf87e16e ------------- PR: https://git.openjdk.org/jdk/pull/23100 From alanb at openjdk.org Tue Jan 14 14:56:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 14:56:46 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message [v2] In-Reply-To: References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: On Tue, 14 Jan 2025 10:55:54 GMT, Viktor Klang wrote: >> Seems sensible to improve this given that it can be tricky to figure out which parameter caused the exception to be thrown. > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Updates the ThreadPoolExecutorTest.java to assert the exception messages added Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23081#pullrequestreview-2549965930 From cushon at openjdk.org Tue Jan 14 15:07:32 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 14 Jan 2025 15:07:32 GMT Subject: RFR: 8323740: java.lang.ExceptionInInitializerError when trying to load XML classes in wrong order [v3] In-Reply-To: References: Message-ID: > Please consider this fix for [JDK-8323740](https://bugs.openjdk.org/browse/JDK-8323740), which avoids an `ExceptionInInitializerError` in the class initializer of `XMLDocumentFragmentScannerImpl` and other classes that have a circular dependency on `jdk.xml.internal.JdkXmlUtils`. The change breaks the cycle by moving some initialization out of the class initializer of `JdkXmlUtils`. Liam Miller-Cushon 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: - Merge branch 'master' into JDK-8323740 - Merge remote-tracking branch 'origin/master' into JDK-8323740 - 8323740: java.lang.ExceptionInInitializerError when trying to load XML classes in wrong order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22803/files - new: https://git.openjdk.org/jdk/pull/22803/files/278d7017..a9bacdfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22803&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22803&range=01-02 Stats: 34821 lines in 1225 files changed: 12654 ins; 16781 del; 5386 mod Patch: https://git.openjdk.org/jdk/pull/22803.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22803/head:pull/22803 PR: https://git.openjdk.org/jdk/pull/22803 From henryjen at openjdk.org Tue Jan 14 15:29:53 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 14 Jan 2025 15:29:53 GMT Subject: Integrated: 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413 In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 21:58:43 GMT, Henry Jen wrote: > Sort services provided by a module to ensure reproduce same result. This pull request has now been integrated. Changeset: dfd215b7 Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/dfd215b7e9e40526006448369c8847aadfe0926b Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod 8347376: tools/jlink/runtimeImage/JavaSEReproducibleTest.java and PackagedModulesVsRuntimeImageLinkTest.java failed after JDK-8321413 Reviewed-by: dholmes, iklam, alanb ------------- PR: https://git.openjdk.org/jdk/pull/23088 From liach at openjdk.org Tue Jan 14 15:42:54 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 14 Jan 2025 15:42:54 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v5] In-Reply-To: References: Message-ID: On Sun, 5 Jan 2025 11:01:18 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > vector digit2 src/java.base/share/classes/java/lang/Integer.java line 581: > 579: } > 580: > 581: static boolean isDigitLatin2(int ch) { Unused, should be removed src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 154: > 152: Here we are doing a 2-Byte Vector operation on the short type. > 153: > 154: x & 0xF0 != 0xC0 Suggestion: x & 0xF0 != 0x30 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1915043154 PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1915038981 From swen at openjdk.org Tue Jan 14 15:53:36 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 14 Jan 2025 15:53:36 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v6] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - remove unused - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/f97093d3..eb867978 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=04-05 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From pminborg at openjdk.org Tue Jan 14 15:59:42 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 14 Jan 2025 15:59:42 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v8] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitFail avgt 30 42.061 ? 1.261 ns/op > CaptureStateUtilBench.explicitSuccess avgt 30 23.142 ? 0.739 ns/op > CaptureStateUtilBench.tlFail avgt 30 23.580 ? 0.267 ns/op > CaptureStateUtilBench.tlSuccess avgt 30 1.753 ? 0.016 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/3cf122bb-0ed6-4dd6-ab6d-dcada0147efb) > > This is a >10x improvement on the happy path. > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Wip ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/fe12661a..2ad696aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=06-07 Stats: 846 lines in 6 files changed: 843 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From darcy at openjdk.org Tue Jan 14 16:42:46 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 14 Jan 2025 16:42:46 GMT Subject: [jdk24] Integrated: 8347605: Use spec tag to refer to IEEE 754 standard In-Reply-To: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> References: <9d1msRCJAGSwT5fIUL7cFI1n9RlgIE_j6r60U0ImeEQ=.7821ced4-a9bc-42ba-a8b2-7b52d811395c@github.com> Message-ID: On Mon, 13 Jan 2025 22:40:27 GMT, Joe Darcy wrote: > Get IEEE 754 added as an external standard in JDK 24's docs too. This pull request has now been integrated. Changeset: f45a23ca Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/f45a23cabdcf43e1ae82e34a64f04df87a40d415 Stats: 30 lines in 7 files changed: 0 ins; 0 del; 30 mod 8347605: Use spec tag to refer to IEEE 754 standard Reviewed-by: liach, bpb, iris Backport-of: 7c883c284de4fa1cb55f4fd4cf4dc9115bee5e65 ------------- PR: https://git.openjdk.org/jdk/pull/23091 From sgehwolf at openjdk.org Tue Jan 14 16:44:41 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 14 Jan 2025 16:44:41 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v15] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 14:57:09 GMT, Severin Gehwolf wrote: >> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. >> >> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). >> >> This patch addresses this issue by: >> >> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. >> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). >> >> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. >> >> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. >> >> Thoughts? >> >> Testing: >> >> - [x] GHA >> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems >> - [x] Some manual testing using systemd slices > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: > > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Fix missing imports > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Add exclusive access dirs directive for systemd tests > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - ... and 31 more: https://git.openjdk.org/jdk/compare/1f457977...c83c22eb Keep open, bot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2590507466 From henryjen at openjdk.org Tue Jan 14 16:57:13 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 14 Jan 2025 16:57:13 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v5] In-Reply-To: References: Message-ID: > Improving option value handling to support passing argument value starts with "--". > > Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. > --add-options --add-modules=jdk.incubator.concurrent > --add-options=--add-modules=jdk.incubator.concurrent > > will cause JLink to report > Error: no value given for --add-options > as --add-modules is considered another option for JLink. > > After the fix, by using = will ensure the value is properly handled as argument value > --add-options=--add-modules=jdk.incubator.concurrent Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22526/files - new: https://git.openjdk.org/jdk/pull/22526/files/76ce4472..50a8c5ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22526&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22526&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22526/head:pull/22526 PR: https://git.openjdk.org/jdk/pull/22526 From alanb at openjdk.org Tue Jan 14 17:12:38 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 14 Jan 2025 17:12:38 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v5] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 16:57:13 GMT, Henry Jen wrote: >> Improving option value handling to support passing argument value starts with "--". >> >> Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. >> --add-options --add-modules=jdk.incubator.concurrent >> --add-options=--add-modules=jdk.incubator.concurrent >> >> will cause JLink to report >> Error: no value given for --add-options >> as --add-modules is considered another option for JLink. >> >> After the fix, by using = will ensure the value is properly handled as argument value >> --add-options=--add-modules=jdk.incubator.concurrent > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22526#pullrequestreview-2550473108 From cushon at openjdk.org Tue Jan 14 17:30:53 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 14 Jan 2025 17:30:53 GMT Subject: Integrated: 8323740: java.lang.ExceptionInInitializerError when trying to load XML classes in wrong order In-Reply-To: References: Message-ID: <85ewMxIuP2w5EKKGsq3CfxGPTbJR6eEqXYlfq8L9Xuw=.46a9dc18-ed6b-4e8a-a7f4-ab7cdb3e0e69@github.com> On Wed, 18 Dec 2024 02:38:28 GMT, Liam Miller-Cushon wrote: > Please consider this fix for [JDK-8323740](https://bugs.openjdk.org/browse/JDK-8323740), which avoids an `ExceptionInInitializerError` in the class initializer of `XMLDocumentFragmentScannerImpl` and other classes that have a circular dependency on `jdk.xml.internal.JdkXmlUtils`. The change breaks the cycle by moving some initialization out of the class initializer of `JdkXmlUtils`. This pull request has now been integrated. Changeset: e6902cfc Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/e6902cfca43c7434be9aa4a0dde4e44eae7ebf29 Stats: 46 lines in 2 files changed: 44 ins; 0 del; 2 mod 8323740: java.lang.ExceptionInInitializerError when trying to load XML classes in wrong order Reviewed-by: joehw ------------- PR: https://git.openjdk.org/jdk/pull/22803 From henryjen at openjdk.org Tue Jan 14 17:42:46 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 14 Jan 2025 17:42:46 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 14:58:36 GMT, Severin Gehwolf wrote: >> During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. >> >> Testing: >> - [x] GHA >> - [x] tools/jlink tests (including the new one). >> >> Thoughts? > > Severin Gehwolf 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: > > - Merge branch 'master' into jdk-8347334-jimage-diff-gen-cleanup > - Further simplification > - Review feedback > - 8347334: JimageDiffGenerator code clean-ups Marked as reviewed by henryjen (Committer). I am not a JDK reviewer, so you will need someone else. ------------- PR Review: https://git.openjdk.org/jdk/pull/23014#pullrequestreview-2550554318 PR Comment: https://git.openjdk.org/jdk/pull/23014#issuecomment-2590681168 From lancea at openjdk.org Tue Jan 14 17:45:00 2025 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 14 Jan 2025 17:45:00 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v17] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 09:23:35 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Move the guidance to subclasses to the end() method Latest Updates look good Jai ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19675#pullrequestreview-2550565134 From naoto at openjdk.org Tue Jan 14 17:50:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 14 Jan 2025 17:50:55 GMT Subject: Integrated: 8347146: Convert IncludeLocalesPluginTest to use JUnit In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 18:28:19 GMT, Naoto Sato wrote: > A simple refinement to the test makes diagnosing failures easier. This pull request has now been integrated. Changeset: 06ff4c17 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/06ff4c17bdfab9e7aa323425cb18dfdc963aa972 Stats: 430 lines in 1 file changed: 23 ins; 44 del; 363 mod 8347146: Convert IncludeLocalesPluginTest to use JUnit Reviewed-by: jlu, joehw ------------- PR: https://git.openjdk.org/jdk/pull/23016 From naoto at openjdk.org Tue Jan 14 17:50:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 14 Jan 2025 17:50:55 GMT Subject: RFR: 8347146: Convert IncludeLocalesPluginTest to use JUnit [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 22:44:15 GMT, Naoto Sato wrote: >> A simple refinement to the test makes diagnosing failures easier. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addresses review comments Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23016#issuecomment-2590702505 From rriggs at openjdk.org Tue Jan 14 18:46:39 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 14 Jan 2025 18:46:39 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v17] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 09:23:35 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Move the guidance to subclasses to the end() method Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19675#pullrequestreview-2550740352 From headius at headius.com Tue Jan 14 19:40:13 2025 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 14 Jan 2025 13:40:13 -0600 Subject: High cost of failed Math.*Exact calls In-Reply-To: <6DF3BFA1-686C-48BD-91CC-7D11F42FE66D@oracle.com> References: <6DF3BFA1-686C-48BD-91CC-7D11F42FE66D@oracle.com> Message-ID: On Sat, Jan 11, 2025 at 12:09?AM John Rose wrote: > https://bugs.openjdk.org/browse/JDK-8285871 > Math.multiplyHigh and multiply on same inputs can be computed faster if > their computation is shared > I must admit it seemed odd to me that there was a `multiplyHigh` without a corresponding `multiplyLow` but it makes sense there'd be a single CPU instruction to do both. > > And FWIW, a lambda-based API could be made generic in the lambda result, > so that the full BigInteger (or whatever) could be returned immediately: > ... > To work efficiently it also needs some sort of box suppression, either by > reliable inlining and EA, or by handling Long as a value class. > At the very least the Long box needs to be supressed so that the 64-bit safe path can be cheap. In the past, having a branch along the way defeated HotSpot's EA. Are we likely to see the Long eliminated on today's JDKs? Of course if we were able to get the lambda to inline as well, that would be ideal, but I have no idea if any work is being done to profile methods receiving lambdas (perhaps with a hidden marker interface or simply by virtue of being single-method interfaces?) to split and inline multiple paths. Perhaps you know of something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at openjdk.org Tue Jan 14 19:43:43 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 14 Jan 2025 19:43:43 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 14:58:36 GMT, Severin Gehwolf wrote: >> During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. >> >> Testing: >> - [x] GHA >> - [x] tools/jlink tests (including the new one). >> >> Thoughts? > > Severin Gehwolf 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: > > - Merge branch 'master' into jdk-8347334-jimage-diff-gen-cleanup > - Further simplification > - Review feedback > - 8347334: JimageDiffGenerator code clean-ups @MBaesken Would you be OK to ack this as well, since you looked at https://bugs.openjdk.org/browse/JDK-8346239? Thanks in advance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23014#issuecomment-2590960653 From vaivanov at openjdk.org Tue Jan 14 20:53:49 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 14 Jan 2025 20:53:49 GMT Subject: RFR: 8346142: [perf] scalability issue for the specjvm2008::xml.validation workload [v2] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 02:18:35 GMT, Vladimir Ivanov wrote: >> The double check needs less time vs enter to 'synchronize' block when it not needed. This patch for the xml.validation workload for runs with 112 threads reports ~2.5% improvement on the server with Xeon 8480: >> orig: 1T - 433.64 ops/m, 112T - 17344.25 ops/m >> patched: 1T - 437.01 ops/m, 112T - 17771.94 ops/m >> >> The tier1 and jaxp tests are OK with this patch. > > Vladimir Ivanov 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8346142 > - 8346142 [perf] scalability issue for the specjvm2008::xml.validation workload Thanks for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22723#issuecomment-2591077230 From duke at openjdk.org Tue Jan 14 20:53:49 2025 From: duke at openjdk.org (duke) Date: Tue, 14 Jan 2025 20:53:49 GMT Subject: RFR: 8346142: [perf] scalability issue for the specjvm2008::xml.validation workload [v2] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 02:18:35 GMT, Vladimir Ivanov wrote: >> The double check needs less time vs enter to 'synchronize' block when it not needed. This patch for the xml.validation workload for runs with 112 threads reports ~2.5% improvement on the server with Xeon 8480: >> orig: 1T - 433.64 ops/m, 112T - 17344.25 ops/m >> patched: 1T - 437.01 ops/m, 112T - 17771.94 ops/m >> >> The tier1 and jaxp tests are OK with this patch. > > Vladimir Ivanov 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 two additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8346142 > - 8346142 [perf] scalability issue for the specjvm2008::xml.validation workload @IvaVladimir Your change (at version 2055429382d6da8fb13414fb9bee1ef116a0362c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22723#issuecomment-2591078762 From vaivanov at openjdk.org Tue Jan 14 21:32:48 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 14 Jan 2025 21:32:48 GMT Subject: Integrated: 8346142: [perf] scalability issue for the specjvm2008::xml.validation workload In-Reply-To: References: Message-ID: <7dgR9upPZmPA5XkIDXobC6hjGFgQotsQFnwQdaB1ImY=.42966b19-7294-488c-b9de-87558d079399@github.com> On Fri, 13 Dec 2024 00:00:26 GMT, Vladimir Ivanov wrote: > The double check needs less time vs enter to 'synchronize' block when it not needed. This patch for the xml.validation workload for runs with 112 threads reports ~2.5% improvement on the server with Xeon 8480: > orig: 1T - 433.64 ops/m, 112T - 17344.25 ops/m > patched: 1T - 437.01 ops/m, 112T - 17771.94 ops/m > > The tier1 and jaxp tests are OK with this patch. This pull request has now been integrated. Changeset: 10d08dbc Author: Vladimir Ivanov Committer: Derek White URL: https://git.openjdk.org/jdk/commit/10d08dbc81aa14499410f0a7a64d0b3243b660f1 Stats: 23 lines in 1 file changed: 6 ins; 0 del; 17 mod 8346142: [perf] scalability issue for the specjvm2008::xml.validation workload Reviewed-by: joehw ------------- PR: https://git.openjdk.org/jdk/pull/22723 From duke at openjdk.org Tue Jan 14 21:38:47 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 14 Jan 2025 21:38:47 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v8] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 15:59:42 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitFail avgt 30 42.061 ? 1.261 ns/op >> CaptureStateUtilBench.explicitSuccess avgt 30 23.142 ? 0.739 ns/op >> CaptureStateUtilBench.tlFail avgt 30 23.580 ? 0.267 ns/op >> CaptureStateUtilBench.tlSuccess avgt 30 1.753 ? 0.016 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/3cf122bb-0ed6-4dd6-ab6d-dcada0147efb) >> >> This is a >10x improvement on the happy path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Wip src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4617: > 4615: * {@code newType.parameterCount()}, and call {@code #O} the number > 4616: * of outgoing parameters (the value {@code target.type().parameterCount()}). > 4617: * Then the length of the reordering array must be {@code #O }, Suggestion: * Then the length of the reordering array must be {@code #O}, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1915629373 From jlu at openjdk.org Tue Jan 14 21:48:44 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 14 Jan 2025 21:48:44 GMT Subject: Integrated: 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java In-Reply-To: References: Message-ID: <4gE_jlpKE-0FDFGTyJnI5N3o10NojUIMHUlZ_Bof8TU=.35bb6b61-83e0-4306-9957-84f92802aa2a@github.com> On Mon, 13 Jan 2025 21:38:04 GMT, Justin Lu wrote: > Please review this PR which removes a leftover `doPrivileged` call in the Currency test, _CheckDataVersion.java_. This pull request has now been integrated. Changeset: 02d24934 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/02d24934ff8ca8142160392da8101b66e0feab35 Stats: 42 lines in 1 file changed: 14 ins; 26 del; 2 mod 8347613: Remove leftover doPrivileged call in Currency test: CheckDataVersion.java Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/23087 From bpb at openjdk.org Tue Jan 14 21:52:21 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 14 Jan 2025 21:52:21 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing Message-ID: Fix the means of determining whether an exception is to be expected in the Windows test. ------------- Commit messages: - 8347740: java/io/File/createTempFile/SpecialTempFile.java failing Changes: https://git.openjdk.org/jdk/pull/23117/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347740 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23117/head:pull/23117 PR: https://git.openjdk.org/jdk/pull/23117 From bpb at openjdk.org Tue Jan 14 21:52:21 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 14 Jan 2025 21:52:21 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing In-Reply-To: References: Message-ID: <6csydwLxa3h2ihCN4uMqNT4HlTWTSuCdKI277KrTiN0=.0e99c18f-598d-45f7-a68e-eba794668651@github.com> On Tue, 14 Jan 2025 21:47:06 GMT, Brian Burkhalter wrote: > Fix the means of determining whether an exception is to be expected in the Windows test. The test has been verified to pass on Windows 10 and 11 and on Windows Server 2016, 2019, and 2022. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23117#issuecomment-2591173229 From bpb at openjdk.org Tue Jan 14 22:15:07 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 14 Jan 2025 22:15:07 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v2] In-Reply-To: References: Message-ID: > Fix the means of determining whether an exception is to be expected in the Windows test. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8347740: Minor clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23117/files - new: https://git.openjdk.org/jdk/pull/23117/files/42ce22e2..e40d0ce1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23117/head:pull/23117 PR: https://git.openjdk.org/jdk/pull/23117 From henryjen at openjdk.org Tue Jan 14 23:12:37 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 14 Jan 2025 23:12:37 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v4] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 09:06:21 GMT, Yasumasa Suenaga wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Use different error message for ambiguous gnu-style options as value > > It's better, thanks! @YaSuenag Will need you to re-approve the change, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22526#issuecomment-2591290904 From ysuenaga at openjdk.org Tue Jan 14 23:28:41 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 14 Jan 2025 23:28:41 GMT Subject: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided [v5] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 16:57:13 GMT, Henry Jen wrote: >> Improving option value handling to support passing argument value starts with "--". >> >> Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. >> --add-options --add-modules=jdk.incubator.concurrent >> --add-options=--add-modules=jdk.incubator.concurrent >> >> will cause JLink to report >> Error: no value given for --add-options >> as --add-modules is considered another option for JLink. >> >> After the fix, by using = will ensure the value is properly handled as argument value >> --add-options=--add-modules=jdk.incubator.concurrent > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by ysuenaga (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22526#pullrequestreview-2551241848 From liach at openjdk.org Tue Jan 14 23:58:23 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 14 Jan 2025 23:58:23 GMT Subject: RFR: 8345614: Improve AnnotationFormatError message for duplicate annotation interfaces In-Reply-To: <5tYCez7qIf-sEaKIBxvjzTIVmu0P-0tFtmaFxVAo1DQ=.26bf3543-0666-4f5b-bb70-ccfd954712cd@github.com> References: <5tYCez7qIf-sEaKIBxvjzTIVmu0P-0tFtmaFxVAo1DQ=.26bf3543-0666-4f5b-bb70-ccfd954712cd@github.com> Message-ID: On Thu, 5 Dec 2024 16:24:29 GMT, Scott Marlow wrote: > I am getting the `Duplication annotation for class` error as mentioned in https://hibernate.atlassian.net/browse/HHH-18901. The current error message does not include the application class name (e.g. container) that the specified annotation is unexpectedly duplicated. This pull request is for including the class name that has the (duplicate) annotation. I think you might have to cherry-pick the commit (or just prepare an identical patch), and name your PR `Backport 7aa0cbc91d90493a3dae973cb8077cfa283c32b4` for jdk21u-dev. I think I can spawn a backport branch for you; you can create a PR out of that skara bot branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22581#issuecomment-2591326099 PR Comment: https://git.openjdk.org/jdk/pull/22581#issuecomment-2591331766 From henryjen at openjdk.org Tue Jan 14 23:58:24 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 14 Jan 2025 23:58:24 GMT Subject: Integrated: 8303884: jlink --add-options plugin does not allow GNU style options to be provided In-Reply-To: References: Message-ID: <5wC5faRUN-_r_0leROsZEcTlFua10c2zN9ot11YIYao=.2a6d577a-d791-4586-b9e6-c546d19b6b4a@github.com> On Tue, 3 Dec 2024 19:59:56 GMT, Henry Jen wrote: > Improving option value handling to support passing argument value starts with "--". > > Before the fix, in following example, --add-modules will be considered as another option for JLink instead of argument value for --add-options. > --add-options --add-modules=jdk.incubator.concurrent > --add-options=--add-modules=jdk.incubator.concurrent > > will cause JLink to report > Error: no value given for --add-options > as --add-modules is considered another option for JLink. > > After the fix, by using = will ensure the value is properly handled as argument value > --add-options=--add-modules=jdk.incubator.concurrent This pull request has now been integrated. Changeset: d6d45c6e Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/d6d45c6eae2304adb57a49a61861456c3e429e73 Stats: 231 lines in 3 files changed: 224 ins; 0 del; 7 mod 8303884: jlink --add-options plugin does not allow GNU style options to be provided Reviewed-by: ysuenaga, alanb ------------- PR: https://git.openjdk.org/jdk/pull/22526 From liach at openjdk.org Wed Jan 15 00:20:02 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 00:20:02 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute [v3] In-Reply-To: References: Message-ID: > Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html Chen Liang has updated the pull request incrementally with one additional commit since the last revision: CSR review remarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23026/files - new: https://git.openjdk.org/jdk/pull/23026/files/c08f76c0..bb6e26bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23026&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23026&range=01-02 Stats: 20 lines in 10 files changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/23026.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23026/head:pull/23026 PR: https://git.openjdk.org/jdk/pull/23026 From psandoz at openjdk.org Wed Jan 15 00:31:40 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 15 Jan 2025 00:31:40 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: References: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> Message-ID: On Tue, 14 Jan 2025 13:07:27 GMT, Jatin Bhateja wrote: > Given the above observations passing 3 additional box arguments to intrinsic and returning a box value needs additional changes in the compiler while minor re-structuring in Java implementation packed with in the glue logic looks like a reasonable approach. Did you mean to say *no* additional changes in the compiler? Otherwise, if not what would those changes be? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1915791046 From darcy at openjdk.org Wed Jan 15 00:33:35 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 15 Jan 2025 00:33:35 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 00:20:02 GMT, Chen Liang wrote: >> Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > CSR review remarks Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23026#pullrequestreview-2551323280 From jpai at openjdk.org Wed Jan 15 01:06:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 15 Jan 2025 01:06:53 GMT Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v17] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 09:23:35 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html >> >> To summarize those discussions, we had concluded that: >> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface >> - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). >> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. >> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. >> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. >> >> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. >> >> I'll file a CSR shortly. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Move the guidance to subclasses to the end() method Thank you all for the reviews. tier1, tier2 and tier3 tests pass with this change. I'll now go ahead and integrate this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19675#issuecomment-2591418293 From jpai at openjdk.org Wed Jan 15 01:06:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 15 Jan 2025 01:06:55 GMT Subject: Integrated: 8225763: Inflater and Deflater should implement AutoCloseable In-Reply-To: References: Message-ID: On Wed, 12 Jun 2024 10:45:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? > > The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews: > > https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html > https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html > > To summarize those discussions, we had concluded that: > - `Deflater` and `Inflater` will implement the `AutoCloseable` interface > - In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses). > - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op. > - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op. > - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception. > > New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable. > > I'll file a CSR shortly. This pull request has now been integrated. Changeset: 36b7abd6 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/36b7abd617addcf6c7af37788abed7a714b175a5 Stats: 663 lines in 7 files changed: 577 ins; 17 del; 69 mod 8225763: Inflater and Deflater should implement AutoCloseable Reviewed-by: lancea, rriggs, alanb, smarks ------------- PR: https://git.openjdk.org/jdk/pull/19675 From liach at openjdk.org Wed Jan 15 02:07:42 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 02:07:42 GMT Subject: RFR: 8342466: Improve API documentation for java.lang.classfile.attribute [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 00:20:02 GMT, Chen Liang wrote: >> Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > CSR review remarks Reran tier 1-3, no related failures. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23026#issuecomment-2591479679 From liach at openjdk.org Wed Jan 15 02:07:44 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 02:07:44 GMT Subject: Integrated: 8342466: Improve API documentation for java.lang.classfile.attribute In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 07:32:24 GMT, Chen Liang wrote: > Improve documentation for `class` file attributes. This include better specification for user attributes, some more general information about attributes, such as the usage of non-JVMS attributes, and updated some attribute information in the base package too, such as Annotation and Signature. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-attribute/ > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-attribute/java.base/java/lang/classfile/Attribute.html This pull request has now been integrated. Changeset: 973c6307 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/973c630777d4075bc85c7ddc1eb02cc65904344d Stats: 2568 lines in 70 files changed: 1601 ins; 125 del; 842 mod 8342466: Improve API documentation for java.lang.classfile.attribute Reviewed-by: darcy, asotona ------------- PR: https://git.openjdk.org/jdk/pull/23026 From henryjen at openjdk.org Wed Jan 15 02:23:42 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 15 Jan 2025 02:23:42 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 09:08:11 GMT, Per Minborg wrote: > > Do we have a sense on how easy would it be, moving forward, to preserve the "correct" order of imports? E.g. if I add a new one using IntelliJ autocompletion, where would it end up? Has this patch been generated using the IDE's own import reorganization? Perhaps doing something like that might be preferrable/more maintainable longer term? > > The updates in this PR were generated automatically by selecting the relevant packages and then using IntelliJ's automatic Code->Optimize Imports. It is possible to tell IntelliJ to make this automatically upon saving a file: https://www.jetbrains.com/help/idea/creating-and-optimizing-imports.html#optimize-on-save I like auto import, it's great feature to ensure consistency. But the prerequisite is to have consistent settings in coding style(, and different IDEs would be different as well. https://www.jetbrains.com/help/idea/code-style-java.html#imports_table Just curious, do we have a standard IntelliJ setting for OpenJDK coding style, perhaps it's prepared by `bash bin/idea.sh` mentioned in https://github.com/openjdk/jdk/blob/master/doc/ide.md? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22827#issuecomment-2591497703 From liach at openjdk.org Wed Jan 15 04:32:04 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 04:32:04 GMT Subject: RFR: 8347762: ClassFile attribute specification refers to non-SE modules Message-ID: The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. ------------- Commit messages: - 8347762: ClassFile attribute specification refers to non-SE modules Changes: https://git.openjdk.org/jdk/pull/23122/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23122&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347762 Stats: 22 lines in 7 files changed: 0 ins; 7 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23122.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23122/head:pull/23122 PR: https://git.openjdk.org/jdk/pull/23122 From darcy at openjdk.org Wed Jan 15 04:38:43 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 15 Jan 2025 04:38:43 GMT Subject: RFR: 8347762: ClassFile attribute specification refers to non-SE modules In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 04:27:14 GMT, Chen Liang wrote: > The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23122#pullrequestreview-2551535440 From dholmes at openjdk.org Wed Jan 15 04:38:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Jan 2025 04:38:44 GMT Subject: RFR: 8347762: ClassFile attribute specification refers to non-SE modules In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 04:27:14 GMT, Chen Liang wrote: > The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. Changes seem fine to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23122#pullrequestreview-2551537050 From liach at openjdk.org Wed Jan 15 04:57:03 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 04:57:03 GMT Subject: RFR: 8347762: ClassFile attribute specification refers to non-SE modules [v2] In-Reply-To: References: Message-ID: > The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/classfile/attribute/SourceIDAttribute.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23122/files - new: https://git.openjdk.org/jdk/pull/23122/files/aa5fec05..6693a1da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23122&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23122&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23122.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23122/head:pull/23122 PR: https://git.openjdk.org/jdk/pull/23122 From darcy at openjdk.org Wed Jan 15 04:57:03 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 15 Jan 2025 04:57:03 GMT Subject: RFR: 8347762: ClassFile attribute specification refers to non-SE modules [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 04:53:46 GMT, Chen Liang wrote: >> The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/classfile/attribute/SourceIDAttribute.java Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23122#pullrequestreview-2551551187 From liach at openjdk.org Wed Jan 15 04:57:03 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 04:57:03 GMT Subject: RFR: 8347762: ClassFile attribute specification refers to non-SE modules [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 04:53:46 GMT, Chen Liang wrote: >> The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/classfile/attribute/SourceIDAttribute.java src/java.base/share/classes/java/lang/classfile/attribute/SourceIDAttribute.java line 49: > 47: *

> 48: * This attribute is not predefined in the Java SE Platform. This is a > 49: * JDK-specific nonstandard attribute produced bythe reference implementation Suggestion: * JDK-specific nonstandard attribute produced by the reference implementation Typo, doing a quick commit while waiting for CI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23122#discussion_r1915937752 From henryjen at openjdk.org Wed Jan 15 05:19:11 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 15 Jan 2025 05:19:11 GMT Subject: RFR: 8347761: Test tools/jimage/JImageExtractTest.java fails after JDK-8303884 Message-ID: jimage use the same code to parse command line options, the resource bundle for jimage also need update. ------------- Commit messages: - 8347761: Test tools/jimage/JImageExtractTest.java fails after JDK-8303884 Changes: https://git.openjdk.org/jdk/pull/23123/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23123&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347761 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23123.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23123/head:pull/23123 PR: https://git.openjdk.org/jdk/pull/23123 From dholmes at openjdk.org Wed Jan 15 05:21:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Jan 2025 05:21:35 GMT Subject: RFR: 8347762: ClassFile attribute specification refers to non-SE modules [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 04:57:03 GMT, Chen Liang wrote: >> The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/classfile/attribute/SourceIDAttribute.java Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23122#pullrequestreview-2551575741 From liach at openjdk.org Wed Jan 15 05:27:41 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 05:27:41 GMT Subject: RFR: 8347762: ClassFile attribute specification refers to non-SE modules [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 04:57:03 GMT, Chen Liang wrote: >> The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/classfile/attribute/SourceIDAttribute.java Doc build passes. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23122#issuecomment-2591678415 From liach at openjdk.org Wed Jan 15 05:27:42 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 05:27:42 GMT Subject: Integrated: 8347762: ClassFile attribute specification refers to non-SE modules In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 04:27:14 GMT, Chen Liang wrote: > The new API specification for class file attributes link to non-SE modules of jdk.compiler and jdk.jlink, which caused docs build failure for SE docs. This patch removes those links and replace them with plain module name references. This pull request has now been integrated. Changeset: 28e01e65 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/28e01e6559a79720d03355444a4e1c1fbf0b0373 Stats: 22 lines in 7 files changed: 0 ins; 7 del; 15 mod 8347762: ClassFile attribute specification refers to non-SE modules Reviewed-by: darcy, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23122 From dholmes at openjdk.org Wed Jan 15 05:33:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Jan 2025 05:33:35 GMT Subject: RFR: 8347761: Test tools/jimage/JImageExtractTest.java fails after JDK-8303884 In-Reply-To: References: Message-ID: <5ZD-dorgji7iaX8KepuBmy5UQ2AZDqBCcQz0kTSF298=.fc96ce5d-83d1-4cf8-a0f2-afa765b23f2c@github.com> On Wed, 15 Jan 2025 05:14:51 GMT, Henry Jen wrote: > jimage use the same code to parse command line options, the resource bundle for jimage also need update. LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23123#pullrequestreview-2551587048 From henryjen at openjdk.org Wed Jan 15 05:42:53 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 15 Jan 2025 05:42:53 GMT Subject: Integrated: 8347761: Test tools/jimage/JImageExtractTest.java fails after JDK-8303884 In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 05:14:51 GMT, Henry Jen wrote: > jimage use the same code to parse command line options, the resource bundle for jimage also need update. This pull request has now been integrated. Changeset: a3be97e2 Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/a3be97e2d61c10f4bf64e9bdb05f562036589765 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8347761: Test tools/jimage/JImageExtractTest.java fails after JDK-8303884 Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23123 From dholmes at openjdk.org Wed Jan 15 07:21:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 15 Jan 2025 07:21:44 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 22:15:07 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the Windows test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8347740: Minor clean up test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 117: > 115: > 116: String[] nameElements = osName.split(" "); > 117: int nameVers = Integer.valueOf(nameElements[nameElements.length - 1]); That may work with current versions but be aware we sometimes have things like "Server 2012 R2" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1916048007 From mcimadamore at openjdk.org Wed Jan 15 08:57:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 15 Jan 2025 08:57:39 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API [v3] In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 11:47:15 GMT, Per Minborg wrote: >> This PR proposes to clean up all the imports in the FFM lib (excluding tests). >> >> Passes tier1-tier3 > > Per Minborg 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: > > - Merge branch 'master' into fix-imports > - Update copyright year and reformat > - Merge branch 'master' into fix-imports > - Fix imports Looks good. Did you also do a pass on microbenchmarks and tests? Or will that be a separate effort (probably better) ? ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22827#pullrequestreview-2551919980 From alanb at openjdk.org Wed Jan 15 10:56:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 15 Jan 2025 10:56:49 GMT Subject: Integrated: 8347039: ThreadPerTaskExecutor terminates if cancelled tasks still running In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 13:32:39 GMT, Alan Bateman wrote: > The thread-per-task-executor returned by Executors.newVirtualThreadPerTaskExecutor will terminate without waiting for threads that are still executing cancelled tasks. This is different to ThreadPoolExecutor and ForkJoinPool that wait for the threads to finish executing the cancelled tasks. Note that issue with TPTE is specific to Callable tasks, Runnable tasks are not impacted. The change is to override FutureTask.run instead of FutureTask.done. Test coverage is expanded to cover this case. This pull request has now been integrated. Changeset: af3f5d85 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/af3f5d852e5dd0191548bdc477546b5b343d1276 Stats: 66 lines in 2 files changed: 54 ins; 2 del; 10 mod 8347039: ThreadPerTaskExecutor terminates if cancelled tasks still running Reviewed-by: vklang ------------- PR: https://git.openjdk.org/jdk/pull/23036 From pminborg at openjdk.org Wed Jan 15 11:53:10 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 11:53:10 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v9] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 43.942 ? 2.425 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.606 ? 0.837 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 15.660 ? 0.073 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 12.712 ? 0.407 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/fb0051b7-a16c-4636-bf5c-27c01a45c8fe) > > This is a ~2x improvement on the happy path. > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Refactor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/2ad696aa..57b322a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=07-08 Stats: 730 lines in 4 files changed: 163 ins; 504 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From pminborg at openjdk.org Wed Jan 15 12:01:34 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 12:01:34 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v10] In-Reply-To: References: Message-ID: <8FipLrV2qHwwo_o5hh8v3z-MdludfmjMErgozrOKpH8=.8eb3d5d0-9436-4255-879c-a16f1f382359@github.com> > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 43.942 ? 2.425 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.606 ? 0.837 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 15.660 ? 0.073 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 12.712 ? 0.407 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/fb0051b7-a16c-4636-bf5c-27c01a45c8fe) > > This is a ~2x improvement on the happy path. > > > Tested and passed tiers 1-3. Per Minborg 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 29 additional commits since the last revision: - Merge branch 'master' into errno-util - Refactor - Wip - Update benchmark and micro optimize - Clean up benchmark - Fix allocation problem in benchmark - Add benchmark - Remove thread test - Clean up - Add VT pinning - ... and 19 more: https://git.openjdk.org/jdk/compare/19ec23ad...3b8723f3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/57b322a1..3b8723f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=08-09 Stats: 21152 lines in 1016 files changed: 8980 ins; 7017 del; 5155 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From pminborg at openjdk.org Wed Jan 15 12:06:50 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 12:06:50 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v11] In-Reply-To: References: Message-ID: <4ws7rpoA5w2dUa6LOypUxN2oZxiuy2Iw300OfEqofC8=.e4b4edd0-886a-40b9-b57a-3b07a5ebccd3@github.com> > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 43.942 ? 2.425 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.606 ? 0.837 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 15.660 ? 0.073 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 12.712 ? 0.407 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/fb0051b7-a16c-4636-bf5c-27c01a45c8fe) > > This is a ~2x improvement on the happy path. > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Remove unused classes - Remove blanks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/3b8723f3..090ffb6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=09-10 Stats: 361 lines in 3 files changed: 0 ins; 360 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From pminborg at openjdk.org Wed Jan 15 12:21:41 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 12:21:41 GMT Subject: RFR: 8346610: Make all imports consistent in the FFM API [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 08:55:04 GMT, Maurizio Cimadamore wrote: > Did you also do a pass on microbenchmarks and tests? Or will that be a separate effort (probably better) ? https://bugs.openjdk.org/browse/JDK-8347814 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22827#issuecomment-2592648452 From pminborg at openjdk.org Wed Jan 15 12:21:42 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 12:21:42 GMT Subject: Integrated: 8346610: Make all imports consistent in the FFM API In-Reply-To: References: Message-ID: <0ywm3FZpWMx329Wz7mNMPwBovWEoxb76wyluIYUWZO4=.2a4ccc85-2141-4111-8d37-9e7660415b54@github.com> On Thu, 19 Dec 2024 10:46:03 GMT, Per Minborg wrote: > This PR proposes to clean up all the imports in the FFM lib (excluding tests). > > Passes tier1-tier3 This pull request has now been integrated. Changeset: d4e5ec27 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/d4e5ec274673c1ee883e8d5c3785f0b03e39445c Stats: 390 lines in 52 files changed: 165 ins; 155 del; 70 mod 8346610: Make all imports consistent in the FFM API Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/22827 From pminborg at openjdk.org Wed Jan 15 12:39:58 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 12:39:58 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v12] In-Reply-To: References: Message-ID: <3ts9U80YPc2uTLMj0YqVjIDkR4PJFGUOvHWuC9vA1cQ=.05ec5274-0a79-47dc-9f00-0ee52e5bb8fa@github.com> > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 43.942 ? 2.425 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.606 ? 0.837 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 15.660 ? 0.073 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 12.712 ? 0.407 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/fb0051b7-a16c-4636-bf5c-27c01a45c8fe) > > This is a ~2x improvement on the happy path. > > > Tested and passed tiers 1-3. Per Minborg 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 32 additional commits since the last revision: - Merge branch 'master' into errno-util - Remove unused classes - Remove blanks - Merge branch 'master' into errno-util - Refactor - Wip - Update benchmark and micro optimize - Clean up benchmark - Fix allocation problem in benchmark - Add benchmark - ... and 22 more: https://git.openjdk.org/jdk/compare/dace5ed1...6e10dbb8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/090ffb6d..6e10dbb8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=10-11 Stats: 542 lines in 74 files changed: 165 ins; 156 del; 221 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From mbaesken at openjdk.org Wed Jan 15 13:39:42 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 15 Jan 2025 13:39:42 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 14:58:36 GMT, Severin Gehwolf wrote: >> During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. >> >> Testing: >> - [x] GHA >> - [x] tools/jlink tests (including the new one). >> >> Thoughts? > > Severin Gehwolf 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: > > - Merge branch 'master' into jdk-8347334-jimage-diff-gen-cleanup > - Further simplification > - Review feedback > - 8347334: JimageDiffGenerator code clean-ups Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23014#pullrequestreview-2552774188 From rrich at openjdk.org Wed Jan 15 13:46:48 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 15 Jan 2025 13:46:48 GMT Subject: RFR: 8339166: java/lang/String/concat/HiddenClassUnloading.java fails on AIX and Linux ppc64le after JDK-8336856 In-Reply-To: References: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com> Message-ID: On Thu, 29 Aug 2024 15:52:41 GMT, Claes Redestad wrote: > LGTM. On my M1 MacBook this increase total runtime of `make test TEST=.../HiddenClassUnloading.java` by 8-9s, which seems acceptable to ensure it's stable and fit for purpose on all platforms. @cl4es in my tests with a fastdebug build the runtime increased 2x to 5x. On slower ppc64 machines we get also timeouts. I created https://bugs.openjdk.org/browse/JDK-8347817 for tracking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20771#issuecomment-2592895657 From jwaters at openjdk.org Wed Jan 15 14:15:42 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 15 Jan 2025 14:15:42 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: References: <0e9LDE2EBLlaLnG1yS73mRdN29kXRceXEqk-CuUdITg=.2ba14a99-9caa-4087-a034-2bf589b8fbb5@github.com> Message-ID: On Tue, 14 Jan 2025 06:39:22 GMT, Alan Bateman wrote: > > There's a contributor PR from the java bugs submitter at #23050, I wonder what we should do in this case. > > The PR has the "oca" label so we can't look or comment on it. :O People from Oracle aren't allowed to look at work from unverified contributors? I learnt something new today ------------- PR Comment: https://git.openjdk.org/jdk/pull/23081#issuecomment-2592962349 From rrich at openjdk.org Wed Jan 15 14:19:48 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 15 Jan 2025 14:19:48 GMT Subject: RFR: 8347817: timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds Message-ID: This PR reverts the fix from [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it increases the runtime of the test a lot. Instead a full gc is requested via the whitebox api. This solves the issues (see bug description) and it is also clearer and more reliable that allocating objects and classes expecting a gc because of the small heap. The heap setting is also removed since it is not needed anymore. #### Testing: Duration Running HiddenClassUnloading with fastdebug Builds I'm giving the minimum of a few runs because durations vary by +/- 10s. Linux / x86_64: After JDK-8339166: 3m15s JDK-8339166 reverted: 50s PR: 50s macOS / M1: After JDK-8339166: 2m30s JDK-8339166 reverted: 30s PR: 30s Linux / ppc64le After JDK-8339166: 12m30s JDK-8339166 reverted: 2m30s (failure: no classes unloaded) PR: 2m30s (success) ------------- Commit messages: - Call WhiteBox::fullGC() for class unloading - Revert "8339166: java/lang/String/concat/HiddenClassUnloading.java fails on AIX and Linux ppc64le after JDK-8336856" Changes: https://git.openjdk.org/jdk/pull/23137/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23137&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347817 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23137/head:pull/23137 PR: https://git.openjdk.org/jdk/pull/23137 From duke at openjdk.org Wed Jan 15 14:24:45 2025 From: duke at openjdk.org (Scott Marlow) Date: Wed, 15 Jan 2025 14:24:45 GMT Subject: RFR: 8345614: Improve AnnotationFormatError message for duplicate annotation interfaces In-Reply-To: <5tYCez7qIf-sEaKIBxvjzTIVmu0P-0tFtmaFxVAo1DQ=.26bf3543-0666-4f5b-bb70-ccfd954712cd@github.com> References: <5tYCez7qIf-sEaKIBxvjzTIVmu0P-0tFtmaFxVAo1DQ=.26bf3543-0666-4f5b-bb70-ccfd954712cd@github.com> Message-ID: <2R8Hc7UUgIFZgIwZgMhUBdJK0HwizJMh9Bxg5p53NQE=.61a7efc6-3d76-4a4d-baa6-99f1017e683e@github.com> On Thu, 5 Dec 2024 16:24:29 GMT, Scott Marlow wrote: > I am getting the `Duplication annotation for class` error as mentioned in https://hibernate.atlassian.net/browse/HHH-18901. The current error message does not include the application class name (e.g. container) that the specified annotation is unexpectedly duplicated. This pull request is for including the class name that has the (duplicate) annotation. > /backport jdk21u-dev > > I think I can spawn a backport branch for you; you can create a PR out of that skara bot branch. I opened https://github.com/openjdk/jdk21u-dev/compare/openjdk:master...openjdk-bots:backport-liach-7aa0cbc9-master?expand=1 but see message `Pull request creation failed. Validation failed: must be a collaborator` ------------- PR Comment: https://git.openjdk.org/jdk/pull/22581#issuecomment-2592991005 From sgehwolf at openjdk.org Wed Jan 15 14:47:45 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 15 Jan 2025 14:47:45 GMT Subject: RFR: 8347334: JimageDiffGenerator code clean-ups [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 14:58:36 GMT, Severin Gehwolf wrote: >> During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. >> >> Testing: >> - [x] GHA >> - [x] tools/jlink tests (including the new one). >> >> Thoughts? > > Severin Gehwolf 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: > > - Merge branch 'master' into jdk-8347334-jimage-diff-gen-cleanup > - Further simplification > - Review feedback > - 8347334: JimageDiffGenerator code clean-ups Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23014#issuecomment-2593048872 From sgehwolf at openjdk.org Wed Jan 15 14:47:46 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 15 Jan 2025 14:47:46 GMT Subject: Integrated: 8347334: JimageDiffGenerator code clean-ups In-Reply-To: References: Message-ID: <74CY30wPJgelFdJPDR17NFE-WqDin3FIeU424Yjx1c8=.4e9384c6-a5b5-4212-9bbc-f3fffb591ae8@github.com> On Thu, 9 Jan 2025 17:32:39 GMT, Severin Gehwolf wrote: > During code review of [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments were made after the PR integrated. This follow-up patch cleans this up and adds a unit test for the `JimageDiffGenerator` class. > > Testing: > - [x] GHA > - [x] tools/jlink tests (including the new one). > > Thoughts? This pull request has now been integrated. Changeset: 63cedaf4 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/63cedaf40e179267d75445a4c71ec15f29979cd3 Stats: 354 lines in 2 files changed: 327 ins; 14 del; 13 mod 8347334: JimageDiffGenerator code clean-ups Reviewed-by: henryjen, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/23014 From pminborg at openjdk.org Wed Jan 15 15:31:52 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 15:31:52 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v13] In-Reply-To: References: Message-ID: <7E4VKfGe278lAGAcZFl9F4QohgnYHZMMWhhKPCUx78U=.efba2d14-1a8a-4cdc-880a-9ed198270461@github.com> > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) > > This is a ~3x improvement for both the happy and the error path. > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Improve performance using an int lock - Reuse more of the intermediate MHs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/6e10dbb8..69fff386 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=11-12 Stats: 55 lines in 2 files changed: 21 ins; 11 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From ihse at openjdk.org Wed Jan 15 15:39:13 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 15:39:13 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 15:33:14 GMT, Magnus Ihse Bursie wrote: > The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. > > I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. @mcimadamore Can you please verify that the IDEA generation still works properly? I've tried it locally and it seems fine to me, but I'd like you to verify it as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2593235404 From ihse at openjdk.org Wed Jan 15 15:39:13 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 15:39:13 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms Message-ID: The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. ------------- Commit messages: - 8347825: Make IDEA ide support use proper build system mechanisms Changes: https://git.openjdk.org/jdk/pull/23140/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23140&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347825 Stats: 126 lines in 4 files changed: 65 ins; 58 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23140.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23140/head:pull/23140 PR: https://git.openjdk.org/jdk/pull/23140 From liach at openjdk.org Wed Jan 15 15:43:47 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 15:43:47 GMT Subject: RFR: 8345614: Improve AnnotationFormatError message for duplicate annotation interfaces In-Reply-To: <5tYCez7qIf-sEaKIBxvjzTIVmu0P-0tFtmaFxVAo1DQ=.26bf3543-0666-4f5b-bb70-ccfd954712cd@github.com> References: <5tYCez7qIf-sEaKIBxvjzTIVmu0P-0tFtmaFxVAo1DQ=.26bf3543-0666-4f5b-bb70-ccfd954712cd@github.com> Message-ID: On Thu, 5 Dec 2024 16:24:29 GMT, Scott Marlow wrote: > I am getting the `Duplication annotation for class` error as mentioned in https://hibernate.atlassian.net/browse/HHH-18901. The current error message does not include the application class name (e.g. container) that the specified annotation is unexpectedly duplicated. This pull request is for including the class name that has the (duplicate) annotation. Unfortunate! I have created openjdk/jdk21u-dev#1329 for backport. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22581#issuecomment-2593261199 From pminborg at openjdk.org Wed Jan 15 15:55:36 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 15:55:36 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 12:29:11 GMT, David Holmes wrote: > > So, as we foresee the adoption of the FFM API in the JDK internals, we will use such a mechanism for system calls like `fopen`, `socket`, and the like. > > See #22307 for example. > > Sorry I still don't see where you do the actual native call and read errno. Just to be clear you have to read errno/last-error immediately after the native call. You can't for example, return to Java see the call failed and then make a second native call to retrieve errno. I believe the segment handling works as it should now. The segment is now allocated from a platform-thread-local cache. This means we do not have to pin. On the other hand, we will not reuse segments in the unlikely event of a virtual thread unmount during the call. Here is an example of such a system method handle: https://github.com/openjdk/jdk/pull/22307/files#diff-e5ba9b4d94ed42c635e449212e33bc65dc4a823e4187e197f7d39be516eee430R117 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22391#issuecomment-2593297984 From pminborg at openjdk.org Wed Jan 15 16:09:36 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 15 Jan 2025 16:09:36 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v14] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) > > This is a ~3x improvement for both the happy and the error path. > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Use invokeExact semantics in the tests - Clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/69fff386..410508ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=12-13 Stats: 21 lines in 2 files changed: 4 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From ihse at openjdk.org Wed Jan 15 16:13:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 16:13:04 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: References: Message-ID: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> > The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. > > I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix broken make:idea test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23140/files - new: https://git.openjdk.org/jdk/pull/23140/files/2fddb64f..8bf76289 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23140&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23140&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23140.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23140/head:pull/23140 PR: https://git.openjdk.org/jdk/pull/23140 From ihse at openjdk.org Wed Jan 15 16:13:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 16:13:04 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 15:33:14 GMT, Magnus Ihse Bursie wrote: > The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. > > I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. Turns out we actually did have a `make:idea` test, and running it showed a mistake in my code! Who would have thought..? ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2593343512 From mcimadamore at openjdk.org Wed Jan 15 16:16:37 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 15 Jan 2025 16:16:37 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v14] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 16:09:36 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op >> CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op >> CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op >> CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) >> >> This is a ~3x improvement for both the happy and the error path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use invokeExact semantics in the tests > - Clean up src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 288: > 286: > 287: // Using an int lock is faster than CASing a reference field > 288: private int lock; can this be a `boolean`? Or, maybe keep the int, but declare useful static constants, like "READY", "IN_USE" etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1916952265 From mcimadamore at openjdk.org Wed Jan 15 16:19:42 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 15 Jan 2025 16:19:42 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v14] In-Reply-To: References: Message-ID: <8A6NwX273qW9qKLSWaf3YDIIOg6yrNml-vPB3UrQmKM=.1a6d74f7-c865-47bc-9792-9c8d479f0d96@github.com> On Wed, 15 Jan 2025 16:09:36 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op >> CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op >> CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op >> CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) >> >> This is a ~3x improvement for both the happy and the error path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use invokeExact semantics in the tests > - Clean up src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 282: > 280: * use in the boostrap sequence. > 281: */ > 282: private static final class SegmentCache { This abstraction seems very useful, and... it also strikes me as generalizable? It's effectively a one-element cache, where there's some logic to initialize the cached element (which could be provided by a lambda). Then it's using a platform local under the hood and only using the cached element when it makes sense to do so (e.g. when there has not been a virtual thread switcharoo :-) ). In "unsafe" cases, we just compute the element using the user-provided lambda instead of using the cache. Am I dreaming? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1916963768 From mcimadamore at openjdk.org Wed Jan 15 16:28:35 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 15 Jan 2025 16:28:35 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 15:34:30 GMT, Magnus Ihse Bursie wrote: > @mcimadamore Can you please verify that the IDEA generation still works properly? I've tried it locally and it seems fine to me, but I'd like you to verify it as well. I will take a look. Thanks for the headsup. We should probably also ask somebody with Windows (@JornVernee ?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2593382719 From jwaters at openjdk.org Wed Jan 15 16:42:36 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 15 Jan 2025 16:42:36 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 16:26:26 GMT, Maurizio Cimadamore wrote: > We should probably also ask somebody with Windows Hey, don't forget about me! How do I test this, just set up an IDEA Workspace as instructed in the docs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2593414445 From mcimadamore at openjdk.org Wed Jan 15 16:50:35 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 15 Jan 2025 16:50:35 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 16:40:10 GMT, Julian Waters wrote: > > We should probably also ask somebody with Windows > > Hey, don't forget about me! How do I test this, just set up an IDEA Workspace as instructed in the docs? Yes, that would be the case. E.g. run `sh bin/idea.sh java.base` or something like that (then try to open with IJ and see if that works :-) ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2593431954 From bpb at openjdk.org Wed Jan 15 17:01:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 15 Jan 2025 17:01:43 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 07:19:12 GMT, David Holmes wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8347740: Minor clean up > > test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 117: > >> 115: >> 116: String[] nameElements = osName.split(" "); >> 117: int nameVers = Integer.valueOf(nameElements[nameElements.length - 1]); > > That may work with current versions but be aware we sometimes have things like "Server 2012 R2" Thanks. Yes, I looked at various references including [Wikipedia](https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions). It could use some refinement, probably, or perhaps the Windows-specific of the test could simply be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1917025355 From bpb at openjdk.org Wed Jan 15 17:01:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 15 Jan 2025 17:01:43 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 16:56:57 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 117: >> >>> 115: >>> 116: String[] nameElements = osName.split(" "); >>> 117: int nameVers = Integer.valueOf(nameElements[nameElements.length - 1]); >> >> That may work with current versions but be aware we sometimes have things like "Server 2012 R2" > > Thanks. Yes, I looked at various references including [Wikipedia](https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions). It could use some refinement, probably, or perhaps the Windows-specific of the test could simply be removed. Also that for the moment is the entire list of [Windows configurations](https://www.oracle.com/java/technologies/javase/products-doc-jdk23certconfig.html) certified for JDK 23. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1917028546 From naoto at openjdk.org Wed Jan 15 17:17:56 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Jan 2025 17:17:56 GMT Subject: RFR: 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal In-Reply-To: References: Message-ID: <3dy1bI76uXxmIOrKFiLUxD4lHXBqOXnzHuiUmTRTidg=.8933d86b-0768-46da-a9c2-d29540cf473e@github.com> On Fri, 10 Jan 2025 23:05:13 GMT, Naoto Sato wrote: > The use of [three-letter time zone IDs](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/util/TimeZone.html#three-letter-time-zone-ids-heading) has long been deprecated. For their actual removal in the future, making the runtime emit warnings for using those IDs would be desirable. Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23049#issuecomment-2593500862 From naoto at openjdk.org Wed Jan 15 17:17:57 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 15 Jan 2025 17:17:57 GMT Subject: Integrated: 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal In-Reply-To: References: Message-ID: On Fri, 10 Jan 2025 23:05:13 GMT, Naoto Sato wrote: > The use of [three-letter time zone IDs](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/util/TimeZone.html#three-letter-time-zone-ids-heading) has long been deprecated. For their actual removal in the future, making the runtime emit warnings for using those IDs would be desirable. This pull request has now been integrated. Changeset: cfe70ebc Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/cfe70ebcb3a9fadceac5eccdc1f3353d0d74c235 Stats: 61 lines in 3 files changed: 56 ins; 0 del; 5 mod 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal Reviewed-by: jlu, joehw, iris ------------- PR: https://git.openjdk.org/jdk/pull/23049 From mcimadamore at openjdk.org Wed Jan 15 17:33:38 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 15 Jan 2025 17:33:38 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v14] In-Reply-To: References: Message-ID: <3fb-RwkrqzGIMWw1ZCPuSWcyNruFZ_HTH7682T-xEuE=.e6e467b4-ae25-4be0-8b56-d5eda9b3208c@github.com> On Wed, 15 Jan 2025 16:09:36 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op >> CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op >> CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op >> CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) >> >> This is a ~3x improvement for both the happy and the error path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use invokeExact semantics in the tests > - Clean up src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 51: > 49: private static final long SIZE = Linker.Option.captureStateLayout().byteSize(); > 50: > 51: private static final TerminatingThreadLocal TL_CACHE = new TerminatingThreadLocal<>() { I wonder if this should be encapsulated inside the SegmentCache class. In principle the client should only do `acquire` which will get the thread-local cache, and try to get a segment from there, if possible (but the entire operation should be transparent from the client perspective). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1917077192 From jvernee at openjdk.org Wed Jan 15 17:49:37 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Jan 2025 17:49:37 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v7] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 15:51:49 GMT, Per Minborg wrote: > > So, as we foresee the adoption of the FFM API in the JDK internals, we will use such a mechanism for system calls like `fopen`, `socket`, and the like. > > See #22307 for example. > > Sorry I still don't see where you do the actual native call and read errno. Just to be clear you have to read errno/last-error immediately after the native call. You can't for example, return to Java see the call failed and then make a second native call to retrieve errno. There is no separate native call to read errno. The read happens as part of the native call to a function that sets errno, before transitioning back to the java thread state. See: [`DowncallLinker::capture_state`](https://github.com/openjdk/jdk/blob/cfe70ebcb3a9fadceac5eccdc1f3353d0d74c235/src/hotspot/share/prims/downcallLinker.cpp#L36) and its uses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22391#issuecomment-2593577526 From liach at openjdk.org Wed Jan 15 18:32:42 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 15 Jan 2025 18:32:42 GMT Subject: RFR: 8345614: Improve AnnotationFormatError message for duplicate annotation interfaces In-Reply-To: <5tYCez7qIf-sEaKIBxvjzTIVmu0P-0tFtmaFxVAo1DQ=.26bf3543-0666-4f5b-bb70-ccfd954712cd@github.com> References: <5tYCez7qIf-sEaKIBxvjzTIVmu0P-0tFtmaFxVAo1DQ=.26bf3543-0666-4f5b-bb70-ccfd954712cd@github.com> Message-ID: On Thu, 5 Dec 2024 16:24:29 GMT, Scott Marlow wrote: > I am getting the `Duplication annotation for class` error as mentioned in https://hibernate.atlassian.net/browse/HHH-18901. The current error message does not include the application class name (e.g. container) that the specified annotation is unexpectedly duplicated. This pull request is for including the class name that has the (duplicate) annotation. This enhancement is too late for 24. Backporting to 24.0.1; this is a prerequisite for backporting to 21. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22581#issuecomment-2593665890 From jvernee at openjdk.org Wed Jan 15 19:57:39 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Jan 2025 19:57:39 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test I do see a couple of warnings being printed when I run the script: $ bash bin/idea.sh Note: Command line contains non-control variables: * MODULES= * IDEA_OUTPUT=/mnt/h/openjdk/git-jdk2/.idea Make sure it is not mistyped, and that you intend to override this variable. 'make help' will list known control variables. Note: Command line contains non-control variables: * MODULES= * IDEA_OUTPUT=/mnt/h/openjdk/git-jdk2/.idea Make sure it is not mistyped, and that you intend to override this variable. 'make help' will list known control variables. Building target 'idea-gen-config' in configuration 'windows-release' Finished building target 'idea-gen-config' in configuration 'windows-release' Other than that, the generated project files seem to work fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2593812470 From ihse at openjdk.org Wed Jan 15 20:50:35 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 15 Jan 2025 20:50:35 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: <0aEKMHT_3DRW-81-3cbCV7ic8Qtgqc3XYxXxmwX-tQo=.feeffd79-fb88-47f0-80a3-68f9427f2ee8@github.com> On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test Yeah.. technically it is more of a "note" than a "warning". "Make sure that you intend to override this variable" it says, and that is what I intend. If this is very annoying I figure out another way to pass this information without triggering this, but this was the simple way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2593903985 From bpb at openjdk.org Wed Jan 15 21:26:49 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 15 Jan 2025 21:26:49 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: Message-ID: > Fix the means of determining whether an exception is to be expected in the Windows test. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8347740: Change Windows exceptionExpected to be based on build number ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23117/files - new: https://git.openjdk.org/jdk/pull/23117/files/e40d0ce1..f6e7cfa8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=01-02 Stats: 39 lines in 1 file changed: 27 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23117/head:pull/23117 PR: https://git.openjdk.org/jdk/pull/23117 From bpb at openjdk.org Wed Jan 15 21:26:50 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 15 Jan 2025 21:26:50 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 22:15:07 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the Windows test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8347740: Minor clean up Version f6e7cfa was verified on: Windows 10, version 10.0, build 19045 Windows 11, version 10.0, build 22621 Windows Server 2016, version 10.0, build 14393 Windows Server 2019, version 10.0, build 17763 Windows Server 2022, version 10.0, build 20348 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23117#issuecomment-2593965814 From bpb at openjdk.org Wed Jan 15 21:52:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 15 Jan 2025 21:52:38 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 21:26:49 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the Windows test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8347740: Change Windows exceptionExpected to be based on build number The build numbers for the verified Windows releases may be cross-checked at: - [Windows 10](https://learn.microsoft.com/en-us/windows/release-health/release-information) - [Windows 11](https://learn.microsoft.com/en-us/windows/release-health/windows11-release-information) - [Windows Servers](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info#windows-server-release-history) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23117#issuecomment-2594010777 From duke at openjdk.org Wed Jan 15 22:30:45 2025 From: duke at openjdk.org (duke) Date: Wed, 15 Jan 2025 22:30:45 GMT Subject: Withdrawn: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie wrote: > In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. > > I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. > > The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. > > This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22104 From acobbs at openjdk.org Wed Jan 15 22:49:53 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 15 Jan 2025 22:49:53 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 15:16:01 GMT, Lance Andersen wrote: >>> I understand the request here, but is there a current use case for needing a custom Deflater? >> >> I think the primary use case is when you want to set a non-default compression level, e.g., "best" or "fast". This is a pretty normal thing to do and matches what people expect from the `gzip(1)` command line flags. Allowing a custom `Deflater` is the simplest way to accomplish this; it also solves some other less common use cases, e.g., you want to set "no compression" for an already compressed file, or you want to keep the `Deflater` open so you can gather stats or whatever. >> >>> Before adding additional features, I think GZIP could benefit with more test coverage. >> >> Agreed. `GZIPOutputStream` does get some coverage in some of the `GZIPInputStream` tests, and this PR adds more testing, but certainly more is better. > >> > I understand the request here, but is there a current use case for needing a custom Deflater? >> >> I think the primary use case is when you want to set a non-default compression level, e.g., "best" or "fast". This is a pretty normal thing to do and matches what people expect from the `gzip(1)` command line flags. Allowing a custom `Deflater` is the simplest way to accomplish this; it also solves some other less common use cases, e.g., you want to set "no compression" for an already compressed file, or you want to keep the `Deflater` open so you can gather stats or whatever. > > thank you Archie. I don't have an issue with the feature request, but given this API has been around for since JDK 1.1 and there has not been a must have push for this enhancement, I would prefer to focus on JDK-8322256 closed out and adding more overall test coverage before tackling this. >> >> > Before adding additional features, I think GZIP could benefit with more test coverage. >> >> Agreed. `GZIPOutputStream` does get some coverage in some of the `GZIPInputStream` tests, and this PR adds more testing, but certainly more is better. > > Yes which why we should look to add additional tests, including more coverage from gzip files created via the gzip command line tool. @LanceAndersen, if you have time now I'd like to pick this one back up. A review for the CSR is also needed. Thanks for any comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2594091292 From jvernee at openjdk.org Wed Jan 15 22:53:43 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 15 Jan 2025 22:53:43 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: <3LZeFHzpnbMmil7GtpEOxeDT48bQvGq_rHDnaonsBmI=.cf1caa3e-f782-488e-ac33-53a912a3bc81@github.com> On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test I personally rarely need to run the idea.sh script. Mostly just the first time after cloning a repo. So, I don't think it matters. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2594098013 From lmesnik at openjdk.org Wed Jan 15 23:53:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 15 Jan 2025 23:53:54 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings Message-ID: There few compiler warning disabled in the testlibary build. They should be fixed or localized and removed from build to prevent new possible issues. The main goal is to avoid new such issues in the testlibrary. Tested with tier1-5 to ensure that all tests were passed. ------------- Commit messages: - copyrights updates - dangling fixed - Merge branch 'master' of https://github.com/openjdk/jdk into warnings - restricted removed - cast removed - deprecation remove - try removed - preview reviewed - serial removed - rawtypes removed - ... and 2 more: https://git.openjdk.org/jdk/compare/a3be97e2...ae302c9c Changes: https://git.openjdk.org/jdk/pull/23143/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347840 Stats: 86 lines in 30 files changed: 23 ins; 4 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/23143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23143/head:pull/23143 PR: https://git.openjdk.org/jdk/pull/23143 From dholmes at openjdk.org Thu Jan 16 06:09:46 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Jan 2025 06:09:46 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik wrote: > There few compiler warning disabled in the testlibary build. > They should be fixed or localized and removed from build to prevent new possible issues. > > The main goal is to avoid new such issues in the testlibrary. > Tested with tier1-5 to ensure that all tests were passed. Overall looks good - sometimes a bit of a puzzler understanding what warning is being addressed. :) Only one thing I'm concerned may be an issue. Also a couple of suggestions. Thanks test/lib/jdk/test/lib/format/ArrayDiff.java line 110: > 108: * @return an ArrayDiff instance for the two arrays and formatting parameters provided > 109: */ > 110: @SuppressWarnings({"rawtypes", "unchecked"}) Just wondering where the unchecked warning arises in the code? test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java line 42: > 40: * > 41: * @author Bill Foote > 42: */ I would suggest deleting any comment blocks that just have the @author tag, and deleting the @author elsewhere. All these files (lib/hprof) already have an author attribution comment. test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46: > 44: public int getInt(long pos) throws IOException; > 45: public long getLong(long pos) throws IOException; > 46: public void close() throws IOException; Why was this redefined to throw IOException rather than just Exception? test/lib/jdk/test/lib/hprof/parser/Reader.java line 96: > 94: } else if ((i >>> 8) == GZIP_HEADER_MAGIC) { > 95: // Possible gziped file, try decompress it and get the stack trace. > 96: in.close(); It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below. test/lib/jdk/test/lib/hprof/parser/Reader.java line 169: > 167: } else if ((i >>> 8) == GZIP_HEADER_MAGIC) { > 168: // Possible gziped file, try decompress it and get the stack trace. > 169: in.close(); It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below. test/lib/jdk/test/lib/thread/VThreadRunner.java line 100: > 98: if ((X) ex == ex) { > 99: throw (X) ex; > 100: } This doesn't make sense to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2554831705 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917773365 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917775999 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917780287 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917795069 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917795554 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917787207 From alanb at openjdk.org Thu Jan 16 07:12:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Jan 2025 07:12:36 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik wrote: > There few compiler warning disabled in the testlibary build. > They should be fixed or localized and removed from build to prevent new possible issues. > > The main goal is to avoid new such issues in the testlibrary. > Tested with tier1-5 to ensure that all tests were passed. test/lib/jdk/test/lib/thread/VThreadPinner.java line 97: > 95: * virtual thread then it invokes the task directly. > 96: */ > 97: @SuppressWarnings("unchecked") If you change the code to the follow, same in VThreadRunner then it would avoid the the SW on the method and avoid the other change you have to VThreadRunner. @SuppressWarnings("unchecked") var x = (X) ex; throw x; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917853893 From rafael.wth at gmail.com Thu Jan 16 07:13:17 2025 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Thu, 16 Jan 2025 08:13:17 +0100 Subject: Factory methods for SequencedSet and SequencedMap Message-ID: Hello, I am happily taking SequencedSet and SequencedMap into use, but one inconvenience I encounter is the lack of factory methods for the two. In code where many (initial) collections have zero or one element (for later aggregation), I now write Set.of()/Set.of(one) and Map.of()/Map.of(key, value), as it makes the code shorter and more readable. Those collections are of course implicitly sequenced, but now I must make the variable type of the surrounding monad Set and Map, and simply assume that a LinkedHashSet or LinkedHashMap is used when a collection of more than one element is set, without requiring the interface type. This does not require any type casting, as I rely on the iteration order only, but the code loses some of its expressiveness. I did not find any discussion around introducing factories for SequencedSet.of(...) and SequencedMap.of(...), similar to those that exist in the Set and Map interfaces. Was this ever considered, and if not, could it be? Best regards, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwaters at openjdk.org Thu Jan 16 07:17:35 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 16 Jan 2025 07:17:35 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test I went to sleep before actually testing the change, sorry about that. Same thing that Jorn reports, it seems to work fine apart from a warning ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2594695629 From forax at univ-mlv.fr Thu Jan 16 07:44:15 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 16 Jan 2025 08:44:15 +0100 (CET) Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: Message-ID: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> > From: "Rafael Winterhalter" > To: "core-libs-dev" > Sent: Thursday, January 16, 2025 8:13:17 AM > Subject: Factory methods for SequencedSet and SequencedMap > Hello, Hello, > I am happily taking SequencedSet and SequencedMap into use, but one > inconvenience I encounter is the lack of factory methods for the two. > In code where many (initial) collections have zero or one element (for later > aggregation), I now write Set.of()/Set.of(one) and Map.of()/Map.of(key, value), > as it makes the code shorter and more readable. Those collections are of course > implicitly sequenced, but now I must make the variable type of the surrounding > monad Set and Map, and simply assume that a LinkedHashSet or LinkedHashMap is > used when a collection of more than one element is set, without requiring the > interface type. This does not require any type casting, as I rely on the > iteration order only, but the code loses some of its expressiveness. > I did not find any discussion around introducing factories for > SequencedSet.of(...) and SequencedMap.of(...), similar to those that exist in > the Set and Map interfaces. Was this ever considered, and if not, could it be? Thanks for re-starting that discussion, it was talked a bit, but not as it should be. So the issue is that currently we do not have any compact, unmodifiable and ordered Set/Map implementation, one use case is when you have data that comes from a JSON object as a Map and you want to keep the inserted order, if by example the JSON is a config file editable by a human, an other example is in unit tests where you want to help the dev to read the output of the test so the code that creates a Set/Map and what is outputed by the test should be in the same order. Currently there is no good solution for those use cases because Set|Map.copyOf() does not keep the ordering. I see two solutions, either we add a new SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of Set|Map.of()/copyOf(). Python had gone for the latter solution, which has the advantage a being simple from the user POV, but from an algorithm expert POV, a Set and a SequencedSet are different concepts we may want to emphasis ? > Best regards, Rafael regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Thu Jan 16 10:20:37 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Jan 2025 10:20:37 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v14] In-Reply-To: References: Message-ID: <-dgLGMdqeaafRBUkB8Jlr_7T55td5ytyDfUA_SdLP5M=.20d36d35-6fc8-45fa-afa4-30a14ae85875@github.com> On Wed, 15 Jan 2025 16:13:38 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use invokeExact semantics in the tests >> - Clean up > > src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 288: > >> 286: >> 287: // Using an int lock is faster than CASing a reference field >> 288: private int lock; > > can this be a `boolean`? Or, maybe keep the int, but declare useful static constants, like "READY", "IN_USE" etc. `int` is the fastest. I've tried `boolean`, `byte` and `short` as well. I will add constants. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1918192669 From mcimadamore at openjdk.org Thu Jan 16 10:30:36 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 16 Jan 2025 10:30:36 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: <4tRN0ulJaPZ-gXJsRNb3sN48_XWZHwdXI9uQNb__80Y=.f316342a-4518-4716-8e79-bb7bb7d469a4@github.com> On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test Marked as reviewed by mcimadamore (Reviewer). Works as expected (except for the warnings). I think it's good to go, at least for the time being. I tried creating project (with `java.base` and `jdk.compiler`), tried to open files, build the jdk from the IDE and opening and run some tests using the jtreg plugin. All worked as expected. ------------- PR Review: https://git.openjdk.org/jdk/pull/23140#pullrequestreview-2555502061 PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2595141302 From pminborg at openjdk.org Thu Jan 16 10:35:01 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Jan 2025 10:35:01 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v15] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) > > This is a ~3x improvement for both the happy and the error path. > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Break out the pool to a separate package and reorganize code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/410508ed..8ff211b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=13-14 Stats: 408 lines in 4 files changed: 336 ins; 28 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From pminborg at openjdk.org Thu Jan 16 11:58:20 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Jan 2025 11:58:20 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v16] In-Reply-To: References: Message-ID: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) > > This is a ~3x improvement for both the happy and the error path. > > > Tested and passed tiers 1-3. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove unused class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22391/files - new: https://git.openjdk.org/jdk/pull/22391/files/8ff211b1..520b1e80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22391&range=14-15 Stats: 71 lines in 1 file changed: 0 ins; 71 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22391/head:pull/22391 PR: https://git.openjdk.org/jdk/pull/22391 From aturbanov at openjdk.org Thu Jan 16 13:02:34 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 16 Jan 2025 13:02:34 GMT Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily [v2] In-Reply-To: References: Message-ID: > There are 3 methods in `java.util.TimeZone` which are `public static` and marked as `synchronized`: > 1. getTimeZone(String) > 2. getAvailableIDs(int) > 3. getAvailableIDs() > > This means it is a bottle neck for the whole VM. > I've checked the implementation and concluded that `synchronized` is unnecessary. Andrey Turbanov 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 remote-tracking branch 'refs/remotes/origin/master' into JDK-8291027-TimeZone-synchronized # Conflicts: # src/java.base/share/classes/java/util/TimeZone.java - 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily ------------- Changes: https://git.openjdk.org/jdk/pull/17441/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17441&range=01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17441.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17441/head:pull/17441 PR: https://git.openjdk.org/jdk/pull/17441 From vklang at openjdk.org Thu Jan 16 13:51:46 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 16 Jan 2025 13:51:46 GMT Subject: RFR: 8347842: ThreadPoolExecutor specification discusses RuntimePermission Message-ID: Removes ThreadPoolExecutor javadoc which mentions RuntimePermission. ------------- Commit messages: - Removing reference to RuntimePermission in the ThreadPoolExecutor javadoc Changes: https://git.openjdk.org/jdk/pull/23156/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23156&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347842 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23156.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23156/head:pull/23156 PR: https://git.openjdk.org/jdk/pull/23156 From erikj at openjdk.org Thu Jan 16 14:16:37 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 16 Jan 2025 14:16:37 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23140#pullrequestreview-2556284336 From ihse at openjdk.org Thu Jan 16 14:28:49 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 16 Jan 2025 14:28:49 GMT Subject: Integrated: 8347825: Make IDEA ide support use proper build system mechanisms In-Reply-To: References: Message-ID: <7oMPOLhVm_8vMtc66Q9Jk3dhAZeWGY7-hC-IcNcxvxo=.c438a636-e9bc-4052-b9b9-aadeb55029d9@github.com> On Wed, 15 Jan 2025 15:33:14 GMT, Magnus Ihse Bursie wrote: > The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. > > I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. This pull request has now been integrated. Changeset: 3b6e5767 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/3b6e57670cfc8b45b0be228198ebe6033bed3064 Stats: 129 lines in 5 files changed: 65 ins; 58 del; 6 mod 8347825: Make IDEA ide support use proper build system mechanisms Reviewed-by: mcimadamore, erikj ------------- PR: https://git.openjdk.org/jdk/pull/23140 From ihse at openjdk.org Thu Jan 16 14:28:46 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 16 Jan 2025 14:28:46 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test Thanks for the testing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2595868931 From alanb at openjdk.org Thu Jan 16 14:48:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Jan 2025 14:48:44 GMT Subject: RFR: 8347842: ThreadPoolExecutor specification discusses RuntimePermission In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 13:46:16 GMT, Viktor Klang wrote: > Removes ThreadPoolExecutor javadoc which mentions RuntimePermission. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23156#pullrequestreview-2556383329 From mcimadamore at openjdk.org Thu Jan 16 14:54:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 16 Jan 2025 14:54:39 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v16] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 11:58:20 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op >> CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op >> CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op >> CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) >> >> This is a ~3x improvement for both the happy and the error path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused class src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 289: > 287: > 288: > 289: private static final Supplier FACTORY = new Supplier<>() { I think turning factory and recycler into abstract methods in the superclass might lead to cleaner code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1918700262 From duke at openjdk.org Thu Jan 16 15:21:40 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 16 Jan 2025 15:21:40 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v16] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 11:58:20 GMT, Per Minborg wrote: >> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. >> >> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. >> >> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. >> >> Here are some benchmarks: >> >> >> Benchmark Mode Cnt Score Error Units >> CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op >> CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op >> CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op >> CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op >> >> >> Explicit allocation: >> >> try (var arena = Arena.ofConfined()) { >> return (int) HANDLE.invoke(arena.allocate(4), 0, 0); >> } >> >> >> Thread Local (tl): >> >> return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); >> >> >> The graph below shows the difference in latency for a successful call: >> >> ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) >> >> This is a ~3x improvement for both the happy and the error path. >> >> >> Tested and passed tiers 1-3. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused class As mentioned in https://mail.openjdk.org/pipermail/panama-dev/2025-January/020882.html, I've been looking at pretty much exactly the same thing for another buffer required in the call sequence, with slightly different takeaways: * the implementation in your PR always leaves ownership of the segments inside the thread-local. Borrowing/releasing threads need to check "can I take this", "am I still on the right carrier, trying to return this to the right slot?". I find it easier to actually remove the elements from the cache slot, and potentially return them to the cache slot of a different CT. Ownership and responsibilities seem clearer to me this way. * I've built on the assumption that the "CTL.get.test/modify" sequences are actually atomic wrt virtual-thread-scheduling (seeing NIO code that seems to rely on the same) and no mounting/unmounting will happen inside them (but _may_ happen on the acquire-invoke-release bracket; this I have actually observed to be the case between invoke and release). If rescheduling can happen inside these sequences and we have multiple threads contending for the CT-local element, I'm not 100% sure that there is a point to using CTL in the first place? src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 333: > 331: SegmentPool cache = TL_POOLS.get(); > 332: if (cache == null) { > 333: TL_POOLS.set(cache = new SegmentPool()); Why not use `initialValue`? src/java.base/share/classes/jdk/internal/util/SingleElementPool.java line 124: > 122: public void close() { > 123: if (UNSAFE.compareAndSetInt(this, CLOSED_OFFSET, FALSE, TRUE)) { > 124: if (UNSAFE.getIntVolatile(this, POOLED_ELEMENT_TAKEN_OFFSET) == FALSE) { If we follow the premise that "any scheduling can happen", then this `close` could be racing with another thread trying to borrow the pooled element of this already-dead carrier thread: VT at CT1: pool = tl.get() unmount CT1 dies => pool1.close taken == false => recycle VT at CT2 mount pool.take() succeeds since `taken` still false BOOM I believe the close action would need to "take" the element before recycling it. Wouldn't this obviate the need for a separate "closed" slot? Again, I'm not sure whether this scheduling is actually possible at this time. src/java.base/share/classes/jdk/internal/util/SingleElementPool.java line 132: > 130: @ForceInline > 131: private boolean takePooledElement() { > 132: return UNSAFE.getAndSetInt(this, POOLED_ELEMENT_TAKEN_OFFSET, TRUE) == FALSE; Does this need to use atomics? Looking at similar code in sun.nio.ch.Util.BufferCache which seems to be working without. My interpretation is that BufferCache relies on a virtual thread to not get preempted inside the { CTL.get().takeElement } sequence? Would the same reasoning not work here? I.e. element = carrierThreadLocal.get() [1] if (element.x) [2] a) can this virtual thread be moved to another carrier on [2] or [3] element.y [3] b) can this virtual thread be suspended and another one schedule between [1] and [2]/[3]? My understanding is that in the current implementation of virtual threads, this does not happen and we can manage the cache element with straight non-atomic code (correct)? If not correct, how does the BufferCache manage (pinned somewhere?)? src/java.base/share/classes/jdk/internal/util/SingleElementPool.java line 137: > 135: @ForceInline > 136: private void releasePooledElement() { > 137: UNSAFE.putIntVolatile(this, POOLED_ELEMENT_TAKEN_OFFSET, FALSE); Similar to above: the use of volatile suggests that you're concerned about a virtual thread switch. Would be good to have clarification on this. ------------- PR Review: https://git.openjdk.org/jdk/pull/22391#pullrequestreview-2556247903 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1918610681 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1918706463 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1918637436 PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1918648090 From danielaveryj at gmail.com Fri Jan 10 03:01:15 2025 From: danielaveryj at gmail.com (Daniel Avery) Date: Thu, 9 Jan 2025 20:01:15 -0700 Subject: Minor optimizations / questions about stream implementation Message-ID: Hi, I recently finished a deep-dive through the code in java.util.stream, and came across a few corners that stuck out to me as being odd, in a "small missed opportunity" kind of way. I figured I'd raise them here just in case any are legitimate, or I could get some better insight. I am looking at JDK 24 [build 30] ( https://github.com/openjdk/jdk/tree/jdk-24%2B30/src/java.base/share/classes/java ). 1. AbstractPipeline.wrap() is passed isParallel(), which ultimately (only) plays into determining if StreamSpliterators.AbstractWrappingSpliterator is allowed to split. It looks like the code could be more lenient, and instead pass (isParallel() || !hasAnyStateful()), i.e. allow splitting the spliterator() from sequential streams that do not have stateful ops. 2. It looks like StreamSpliterators.UnorderedSliceSpliterator.trySplit() should disable splitting if (permitStatus == NO_MORE), instead of (permits.get() == 0). As is, it would appear to unnecessarily disable splitting after skipping, in the skip-only case. 3. It looks like SortedOps could override opEvaluateParallelLazy to no-op in the already-sorted case, similar to DistinctOps in the already-distinct case. 4. It looks like SliceOps.makeRef() could fuse adjacent skip()/limit() ops (though I could see that being an overly niche optimization, especially if it makes linked/consumed handling painful). 5. It looks like there is some dead code in StreamOpFlag? I don't see a path where isPreserved() would return true in practice (it appears to only be called in exactly 2 'minor optimization' places: SliceTask.doLeaf() and DropWhileTask.doLeaf()). With the way StreamOpFlag.combineOpFlags() works, it looks like in practice 0b00 is used to preserve, rather than 0b11. I also don't see Type.OP, Type.TERMINAL_OP, or Type.UPSTREAM_TERMINAL_OP being used anywhere. I assume some of the methods here are intended for tests only (isStreamFlag(), canSet())... But given how much of this class I'm not seeing being used, I'm wondering if I'm just missing something. Thank you, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Tue Jan 7 15:18:29 2025 From: rengels at ix.netcom.com (robert engels) Date: Tue, 7 Jan 2025 09:18:29 -0600 Subject: Does anyone have context on jdk.httpserver? In-Reply-To: References: <45a03625-12fb-4c6b-8b67-18c4fffad732@oracle.com> <1CF18B51-7710-4035-965B-73D08C09CEC7@ix.netcom.com> Message-ID: <3C2AA0D2-B54A-4AC2-A843-06045BFE2B7F@ix.netcom.com> Hi, I would like to revisit this. I have signed the OCA for another PR I worked on - I believe it covers all of my contributions. The websockets license looks to be very permissive. But it seems like this is something Oracle could reach out to the authors to resolve. I could also simply create a whiteroom ws impl, as I did for the http2 support - it?s a pretty small surface api. I am more than willing to work on this, but I need to know what the feasibility is of it actually being included. Even if the work was limited to ?better support for vt?, some of the changes are more extensive (like the SSL handling). Regards, Robert > On Jan 22, 2024, at 3:08 AM, Alan Bateman wrote: > > On 22/01/2024 08:43, Robert Engels wrote: >> See github.com/robaho/httpserver for a more capable fork of the JDK code. >> >> Would love to create a PR to move the core changes back into the JDK but the net-dev folks don?t seem to be interested > > As I recall, it wasn't really possible to do any assessment because the "contribution" wasn't covered by the OCA. In addition, I think you said in one of the mails that it includes code from another project (for websocket or HTTP upgrade?) and it's a big deal to have to import and work through the license issues with 3rd party code. > > At a high level it seems reasonable to update the HTTP server implementation to work better with virtual threads but updating it to be a more fully featured HTTP server goes beyond what this HTTP server was/is intended for. > > -Alan > > From rengels at ix.netcom.com Wed Jan 8 14:05:23 2025 From: rengels at ix.netcom.com (Robert Engels) Date: Wed, 8 Jan 2025 08:05:23 -0600 Subject: Does anyone have context on jdk.httpserver? In-Reply-To: References: Message-ID: Ok, based on this I don?t think VT (virtual threads) related structure and performance improvements make sense. If you can?t do the other elements you?re forced to use a different implementation anyway and the performance issues can be addressed there. Thanks for the feedback. Robert > On Jan 8, 2025, at 2:04?AM, Alan Bateman wrote: > > ? On 07/01/2025 15:18, robert engels wrote: >> Hi, >> >> I would like to revisit this. I have signed the OCA for another PR I worked on - I believe it covers all of my contributions. >> >> The websockets license looks to be very permissive. But it seems like this is something Oracle could reach out to the authors to resolve. > > The simple HTTP server in the JDK was never meant to be a fully featured and high performance server. Instead it's meant for very simple usages, so think getting started, the rite of passage to serve up a file, and local testing. If someone wants a production ready server then there are dozens to choose from. > > So I think highly questionable as to whether it's worth putting any time into adding websockets or HTTP/2 support. > > >> I could also simply create a whiteroom ws impl, as I did for the http2 support - it?s a pretty small surface api. >> >> I am more than willing to work on this, but I need to know what the feasibility is of it actually being included. >> >> Even if the work was limited to ?better support for vt?, some of the changes are more extensive (like the SSL handling). > There may be a few small things that would make sense to bring to net-dev to discuss. I assume "vt" means virtual threads so if there is some issues there then bring them to the mailing list to get some agreement that they are worth doing. > > -Alan. From rgiulietti at openjdk.org Thu Jan 16 15:50:42 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 16 Jan 2025 15:50:42 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v4] In-Reply-To: References: Message-ID: <0cW_C6u4YgOV3sogGmWfsDi3W2zFtOj5ECPGm_QUqZg=.2517e6a7-3c7d-4354-83c3-36ac5bdf6c6a@github.com> On Mon, 9 Dec 2024 15:22:13 GMT, Shaojin Wen wrote: >> Shaojin Wen 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 17 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 >> - fix unsafe address overflow >> - add benchmark >> - remove comments, from @liach >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202410 >> - fix Helper >> - fix Helper >> - fix Helper >> - ... and 7 more: https://git.openjdk.org/jdk/compare/cb2ff2dc...a05c2f5f > > @cl4es Could you please review this PR? @wenshao I'll have a look on this PR and on PR22919 in the next days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2596077358 From duke at openjdk.org Thu Jan 16 15:55:47 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 16 Jan 2025 15:55:47 GMT Subject: RFR: 8347408: Create an internal method handle adapter for system calls with errno [v16] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 14:16:15 GMT, Matthias Ernst wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused class > > src/java.base/share/classes/jdk/internal/util/SingleElementPool.java line 132: > >> 130: @ForceInline >> 131: private boolean takePooledElement() { >> 132: return UNSAFE.getAndSetInt(this, POOLED_ELEMENT_TAKEN_OFFSET, TRUE) == FALSE; > > Does this need to use atomics? Looking at similar code in sun.nio.ch.Util.BufferCache which seems to be working without. My interpretation is that BufferCache relies on a virtual thread to not get preempted inside the { CTL.get().takeElement } sequence? Would the same reasoning not work here? > > I.e. > > element = carrierThreadLocal.get() [1] > if (element.x) [2] a) can this virtual thread be moved to another carrier on [2] or [3] > element.y [3] b) can this virtual thread be suspended and another one schedule between [1] and [2]/[3]? > > > My understanding is that in the current implementation of virtual threads, this does not happen and we can manage the cache element with straight non-atomic code (correct)? If not correct, how does the BufferCache manage (pinned somewhere?)? Hah, I have now discovered `Continuation.pin`. I believe with that this cache would better use pinned sections around the CTL elements and in return not require any atomics. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1918800055 From rgiulietti at openjdk.org Thu Jan 16 17:25:21 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 16 Jan 2025 17:25:21 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v6] In-Reply-To: References: Message-ID: <0FIbRT8u5KnjNE8o4tsd44q5wC0wYrYbcRkEDps5EnY=.7bded3d2-1a7f-4879-b0f7-b06a90b587e7@github.com> On Wed, 11 Dec 2024 22:30:32 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen 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 19 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - form @cl4es > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - fix unsafe address overflow > - add benchmark > - remove comments, from @liach > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202410 > - fix Helper > - ... and 9 more: https://git.openjdk.org/jdk/compare/9137241a...8122c1bf src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 42: > 40: > 41: /** > 42: * Each element of the array represents the packaging of two ascii characters based on little endian:

The table below contradicts itself. For example * 02 -> '2' | ('0' << 8) -> 0x3230 should instead read * 02 -> '2' | ('0' << 8) -> 0x3032 and so on. Please adjust the comment and check that everything related to `DIGITS` is used consistently. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1918929765 From lmesnik at openjdk.org Thu Jan 16 18:09:59 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 16 Jan 2025 18:09:59 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings [v2] In-Reply-To: References: Message-ID: <6Nzo-XUtQRZNsZlfAmV8-4tF36VpdbUamSV195gwQ1g=.7f8807ad-d00e-487a-9c4a-12ebc7be7676@github.com> > There few compiler warning disabled in the testlibary build. > They should be fixed or localized and removed from build to prevent new possible issues. > > The main goal is to avoid new such issues in the testlibrary. > Tested with tier1-5 to ensure that all tests were passed. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23143/files - new: https://git.openjdk.org/jdk/pull/23143/files/ae302c9c..6a23012e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=00-01 Stats: 52 lines in 10 files changed: 6 ins; 42 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23143/head:pull/23143 PR: https://git.openjdk.org/jdk/pull/23143 From lmesnik at openjdk.org Thu Jan 16 18:18:15 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 16 Jan 2025 18:18:15 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3] In-Reply-To: References: Message-ID: > There few compiler warning disabled in the testlibary build. > They should be fixed or localized and removed from build to prevent new possible issues. > > The main goal is to avoid new such issues in the testlibrary. > Tested with tier1-5 to ensure that all tests were passed. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: revert change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23143/files - new: https://git.openjdk.org/jdk/pull/23143/files/6a23012e..7a1c35da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23143/head:pull/23143 PR: https://git.openjdk.org/jdk/pull/23143 From lmesnik at openjdk.org Thu Jan 16 18:18:16 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 16 Jan 2025 18:18:16 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 05:31:44 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> revert change > > test/lib/jdk/test/lib/format/ArrayDiff.java line 110: > >> 108: * @return an ArrayDiff instance for the two arrays and formatting parameters provided >> 109: */ >> 110: @SuppressWarnings({"rawtypes", "unchecked"}) > > Just wondering where the unchecked warning arises in the code? It is in the line 123. > test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java line 42: > >> 40: * >> 41: * @author Bill Foote >> 42: */ > > I would suggest deleting any comment blocks that just have the @author tag, and deleting the @author elsewhere. All these files (lib/hprof) already have an author attribution comment. done > test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46: > >> 44: public int getInt(long pos) throws IOException; >> 45: public long getLong(long pos) throws IOException; >> 46: public void close() throws IOException; > > Why was this redefined to throw IOException rather than just Exception? The javac complains about potential InterruptedException, so I changed type. See https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html `Implementers of this interface are also strongly advised to not have the close method throw [InterruptedException](https://docs.oracle.com/javase/8/docs/api/java/lang/InterruptedException.html). This exception interacts with a thread's interrupted status, and runtime misbehavior is likely to occur if an InterruptedException is [suppressed](https://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSuppressed-java.lang.Throwable-). More generally, if it would cause problems for an exception to be suppressed, the AutoCloseable.close method should not throw it.` > test/lib/jdk/test/lib/hprof/parser/Reader.java line 96: > >> 94: } else if ((i >>> 8) == GZIP_HEADER_MAGIC) { >> 95: // Possible gziped file, try decompress it and get the stack trace. >> 96: String deCompressedFile = "heapdump" + System.currentTimeMillis() + ".hprof"; > > It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below. Thanks for catching this. I missed that we try to re-open the same fail in else branch. > test/lib/jdk/test/lib/thread/VThreadRunner.java line 100: > >> 98: if ((X) ex == ex) { >> 99: throw (X) ex; >> 100: } > > This doesn't make sense to me. Sorry for mess, this shouldn't have been committed at all, just some drafting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918956737 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918960995 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918969394 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918976104 PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918981965 From lmesnik at openjdk.org Thu Jan 16 18:18:16 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 16 Jan 2025 18:18:16 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 07:09:46 GMT, Alan Bateman wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> revert change > > test/lib/jdk/test/lib/thread/VThreadPinner.java line 97: > >> 95: * virtual thread then it invokes the task directly. >> 96: */ >> 97: @SuppressWarnings("unchecked") > > If you change the code to the follow, same in VThreadRunner then it would avoid the the SW on the method and avoid the other change you have to VThreadRunner. > > @SuppressWarnings("unchecked") > var x = (X) ex; > throw x; Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918978915 From lmesnik at openjdk.org Thu Jan 16 18:18:15 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 16 Jan 2025 18:18:15 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 18:14:39 GMT, Leonid Mesnik wrote: >> There few compiler warning disabled in the testlibary build. >> They should be fixed or localized and removed from build to prevent new possible issues. >> >> The main goal is to avoid new such issues in the testlibrary. >> Tested with tier1-5 to ensure that all tests were passed. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert change See answer and updated vewrsion. ------------- PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2556833136 From never at openjdk.org Thu Jan 16 18:37:36 2025 From: never at openjdk.org (Tom Rodriguez) Date: Thu, 16 Jan 2025 18:37:36 GMT Subject: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v2] In-Reply-To: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> Message-ID: > Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309. In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure. Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt. Tom Rodriguez 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: - adjust OOMEInStampedLock.java too - Merge branch 'master' into tkr-oomeinaqs-ea - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21745/files - new: https://git.openjdk.org/jdk/pull/21745/files/5c105736..98f63ef0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21745&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21745&range=00-01 Stats: 676957 lines in 10197 files changed: 356680 ins; 262882 del; 57395 mod Patch: https://git.openjdk.org/jdk/pull/21745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21745/head:pull/21745 PR: https://git.openjdk.org/jdk/pull/21745 From pminborg at openjdk.org Thu Jan 16 18:51:46 2025 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 16 Jan 2025 18:51:46 GMT Subject: Withdrawn: 8347408: Create an internal method handle adapter for system calls with errno In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 15:04:51 GMT, Per Minborg wrote: > Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity. > > Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`. > > It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one. > > Here are some benchmarks: > > > Benchmark Mode Cnt Score Error Units > CaptureStateUtilBench.explicitAllocationFail avgt 30 41.615 ? 1.203 ns/op > CaptureStateUtilBench.explicitAllocationSuccess avgt 30 23.094 ? 0.580 ns/op > CaptureStateUtilBench.threadLocalFail avgt 30 14.760 ? 0.078 ns/op > CaptureStateUtilBench.threadLocalReuseSuccess avgt 30 7.189 ? 0.151 ns/op > > > Explicit allocation: > > try (var arena = Arena.ofConfined()) { > return (int) HANDLE.invoke(arena.allocate(4), 0, 0); > } > > > Thread Local (tl): > > return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0); > > > The graph below shows the difference in latency for a successful call: > > ![image](https://github.com/user-attachments/assets/58fbef01-5d06-406c-87e6-75f468227fc6) > > This is a ~3x improvement for both the happy and the error path. > > > Tested and passed tiers 1-3. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22391 From jens at lidestrom.se Thu Jan 16 19:27:03 2025 From: jens at lidestrom.se (=?UTF-8?Q?Jens_Lidestr=C3=B6m?=) Date: Thu, 16 Jan 2025 20:27:03 +0100 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> Having the result Map.of and Set.of preserve the insertion order would often be convenient. More often than not programs iterate over the contents of a maps and sets at some point. For example to present the values in a GUI, for serialisation, or even for error printouts. In all those cases having a fixed iteration order is much better than having a random iteration order. Often it is even a subtle bug to have a random iteration order. For example, I ran in to a situation where jdeps printed a error message containing a list of modules. But the list was in a different order on each run of the program! It took me a while to figure out that it was actually the same list. A possible explanation is that jdeps is implemented using Map.of or Set.of. Because of this I think I would be better if the most commonly used standard collection factories produced collections with a fixed iteration order. Guavas ImmutableMap and ImmutableSet also preserve insertion order. Regards, Jens Lidestr?m On 2025-01-16 08:44, Remi Forax wrote: > ------------------------- > >> From: "Rafael Winterhalter" >> To: "core-libs-dev" >> Sent: Thursday, January 16, 2025 8:13:17 AM >> Subject: Factory methods for SequencedSet and SequencedMap > >> Hello, > > Hello, > >> I am happily taking SequencedSet and SequencedMap into use, but one >> inconvenience I encounter is the lack of factory methods for the two. >> In code where many (initial) collections have zero or one element (for >> later aggregation), I now write Set.of()/Set.of(one) and >> Map.of()/Map.of(key, value), as it makes the code shorter and more >> readable. Those collections are of course implicitly sequenced, but >> now I must make the variable type of the surrounding monad Set and >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is used >> when a collection of more than one element is set, without requiring >> the interface type. This does not require any type casting, as I rely >> on the iteration order only, but the code loses some of its >> expressiveness. >> I did not find any discussion around introducing factories for >> SequencedSet.of(...) and SequencedMap.of(...), similar to those that >> exist in the Set and Map interfaces. Was this ever considered, and if >> not, could it be? > > Thanks for re-starting that discussion, it was talked a bit, but not as > it should be. > > So the issue is that currently we do not have any compact, unmodifiable > and ordered Set/Map implementation, > one use case is when you have data that comes from a JSON object as a > Map and you want to keep the inserted order, if by example the JSON is > a config file editable by a human, an other example is in unit tests > where you want to help the dev to read the output of the test so the > code that creates a Set/Map and what is outputed by the test should be > in the same order. > Currently there is no good solution for those use cases because > Set|Map.copyOf() does not keep the ordering. > > I see two solutions, either we add a new > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of > Set|Map.of()/copyOf(). > Python had gone for the latter solution, which has the advantage a > being simple from the user POV, but from an algorithm expert POV, a Set > and a SequencedSet are different concepts we may want to emphasis ? > >> Best regards, Rafael > > regards, > R?mi From dholmes at openjdk.org Thu Jan 16 20:41:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Jan 2025 20:41:36 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 21:26:49 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the Windows test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8347740: Change Windows exceptionExpected to be based on build number Maybe I'm missing some subtlety here but shouldn't these special names always fail on all Windows versions, so we just need to check Platform.isWindows() from the test library? ------------- PR Review: https://git.openjdk.org/jdk/pull/23117#pullrequestreview-2557247670 From eirbjo at openjdk.org Thu Jan 16 20:42:52 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 16 Jan 2025 20:42:52 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes Message-ID: Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. The classes were identified using an automated analysis. See CSR for details. Besides simply adding the `final` access modifier, the PR: * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` * Updates the copyright year of affected source files ------------- Commit messages: - Merge branch 'master' into non-subclassable-final - Update copyright years - Runtime class is marked final, remove it from the CheckCSMs test - Leave out the constructor access for now since the are not relevant for the CSR review - Reword note about immutability and object immutability to reference object instances instead of the class. - Resurrect note about immutability and object identity, but without any reference to subtypes - Mark non-subclassable classes in 'java.base' final Changes: https://git.openjdk.org/jdk/pull/22389/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22389&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344943 Stats: 35 lines in 22 files changed: 0 ins; 3 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/22389.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22389/head:pull/22389 PR: https://git.openjdk.org/jdk/pull/22389 From eirbjo at openjdk.org Thu Jan 16 20:42:53 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 16 Jan 2025 20:42:53 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 18:49:07 GMT, Alan Bateman wrote: >> Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. >> >> The classes were identified using an automated analysis. See CSR for details. >> >> Besides simply adding the `final` access modifier, the PR: >> >> * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. >> * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` >> * Updates the copyright year of affected source files > > src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 1318: > >> 1316: Version version, >> 1317: Set modifiers, >> 1318: Set requires, > > I assume you'll fix the alignment if this goes ahead. Thanks! Yes, that's good feedback. There are some non-API changes that I'd like to make, such as this and updating the comment for the `InterfaceAddress` constructor. I prefered to make the initial PR draft contain just the CSR changes, such that PR would be useful and clean as a Specification change, since the diff is a bit noisy. I'll keep your review comment here unresolved for now and get back to it pending CSR approval. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859084454 From alanb at openjdk.org Thu Jan 16 20:42:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 16 Jan 2025 20:42:53 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. > > The classes were identified using an automated analysis. See CSR for details. > > Besides simply adding the `final` access modifier, the PR: > > * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. > * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` > * Updates the copyright year of affected source files src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 1318: > 1316: Version version, > 1317: Set modifiers, > 1318: Set requires, I assume you'll fix the alignment if this goes ahead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859076834 From eirbjo at openjdk.org Thu Jan 16 20:42:52 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 16 Jan 2025 20:42:52 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 18:00:21 GMT, Chen Liang wrote: >> Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. >> >> The classes were identified using an automated analysis. See CSR for details. >> >> Besides simply adding the `final` access modifier, the PR: >> >> * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. >> * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` >> * Updates the copyright year of affected source files > > Changes requested by liach (Reviewer). Following some offline discussion with @liach, we decided to leave out the constructor access updates in `ModuleDescriptor` and `InterfaceAddress` for now. They are not considered a specification change and adds noise for the CSR review. These changes may be revisited in this PR pending CSR approval, or can be addressed in follow-up PRs. > src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java line 44: > >> 42: * {@code invokedynamic} call site. >> 43: * >> 44: *

This class is immutable and its behavior does not rely on object identity > > Suggestion: > > *

A {@code DynamicCallSiteDesc} is immutable and its behavior does not > * rely on object identity. > > This describes an object, not a class, and please close sentences with a period. > (We use fragments for param and return block tags instead) Thanks, fixed in 6156b46 :) > src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java line 45: > >> 43: * >> 44: *

Concrete subtypes of {@linkplain DynamicCallSiteDesc} should be immutable >> 45: * and their behavior should not rely on object identity. > > Please reword this to something like: > > {@code DynamicCallSiteDesc} is immutable and its behavior does not rely on object identity. > > This is given in `ConstantDesc`, but `DynamicCallSiteDesc` does not extend `ConstantDesc` so the removal is dubious. Thanks, I've updated the PR and CSR to retain the note about immutability and object identity, removing the reference to subtypes: This class is immutable and its behavior does not rely on object identity I opted to replace the self-reference `{@code DynamicCallSiteDesc}` with just "This class" here. Let me know if you prefer spelling out the class name. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22389#issuecomment-2501808953 PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859123165 PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859051463 From eirbjo at openjdk.org Thu Jan 16 20:42:52 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 16 Jan 2025 20:42:52 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: <_1XUsFhYyvc8iVWXtjOIkOD_zIsfb8LTT5HwgMq3I_g=.4c6b4570-5a83-4be6-ab30-37878978313e@github.com> On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. > > The classes were identified using an automated analysis. See CSR for details. > > Besides simply adding the `final` access modifier, the PR: > > * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. > * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` > * Updates the copyright year of affected source files Now that the CSR for this change is "final-ly" approved, I'm marking this PR ready for review. Since the CSR approval, the PR has merged with a recent master and the copyright headers are updated for 2025. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22389#issuecomment-2596848026 From liach at openjdk.org Thu Jan 16 20:42:52 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Jan 2025 20:42:52 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. > > The classes were identified using an automated analysis. See CSR for details. > > Besides simply adding the `final` access modifier, the PR: > > * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. > * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` > * Updates the copyright year of affected source files Changes requested by liach (Reviewer). Looks good for 25. src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java line 44: > 42: * {@code invokedynamic} call site. > 43: * > 44: *

This class is immutable and its behavior does not rely on object identity Suggestion: *

A {@code DynamicCallSiteDesc} is immutable and its behavior does not * rely on object identity. This describes an object, not a class, and please close sentences with a period. (We use fragments for param and return block tags instead) src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.java line 45: > 43: * > 44: *

Concrete subtypes of {@linkplain DynamicCallSiteDesc} should be immutable > 45: * and their behavior should not rely on object identity. Please reword this to something like: {@code DynamicCallSiteDesc} is immutable and its behavior does not rely on object identity. This is given in `ConstantDesc`, but `DynamicCallSiteDesc` does not extend `ConstantDesc` so the removal is dubious. src/java.base/share/classes/java/net/InterfaceAddress.java line 45: > 43: > 44: /* > 45: * Package private constructor. Can't be built directly, instances are The comment is outdated. This constructor is actually called via JNI like `(*env)->NewObject(env, ni_ibcls, ni_ibctrID)` in `NetworkInterface.c`. I think we need to consult a network engineer to decide what is the best way to comment on this constructor. ------------- PR Review: https://git.openjdk.org/jdk/pull/22389#pullrequestreview-2462343034 Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22389#pullrequestreview-2500067616 PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859112730 PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859019019 PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859157909 From eirbjo at openjdk.org Thu Jan 16 20:42:53 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 16 Jan 2025 20:42:53 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 18:55:50 GMT, Eirik Bj?rsn?s wrote: >> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 1318: >> >>> 1316: Version version, >>> 1317: Set modifiers, >>> 1318: Set requires, >> >> I assume you'll fix the alignment if this goes ahead. > > Thanks! Yes, that's good feedback. There are some non-API changes that I'd like to make, such as this and updating the comment for the `InterfaceAddress` constructor. > > I prefered to make the initial PR draft contain just the CSR changes, such that PR would be useful and clean as a Specification change, since the diff is a bit noisy. > > I'll keep your review comment here unresolved for now and get back to it pending CSR approval. For the record: It was not completely clear to me whether restricting these two package-private constructors to private is considered a specification change in the CSR sense. I opted to point them out in the CSR, just to make the change abundantly clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859098445 From liach at openjdk.org Thu Jan 16 20:42:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Jan 2025 20:42:53 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 19:08:26 GMT, Eirik Bj?rsn?s wrote: >> Thanks! Yes, that's good feedback. There are some non-API changes that I'd like to make, such as this and updating the comment for the `InterfaceAddress` constructor. >> >> I prefered to make the initial PR draft contain just the CSR changes, such that PR would be useful and clean as a Specification change, since the diff is a bit noisy. >> >> I'll keep your review comment here unresolved for now and get back to it pending CSR approval. > > For the record: > > It was not completely clear to me whether restricting these two package-private constructors to private is considered a specification change in the CSR sense. I opted to point them out in the CSR, just to make the change abundantly clear. This constructor is not part of the public API: package-private is not accessible, and it does not appear in the API docs: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/module/ModuleDescriptor.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859114697 From liach at openjdk.org Thu Jan 16 20:42:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 16 Jan 2025 20:42:53 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: <4ifcIGdOnz0NbgxfK5Yn8YMoEOKHOvRv4rrG7XOvwZQ=.9d79707f-3c28-4a3a-86a1-bd1c7f5233c3@github.com> On Tue, 26 Nov 2024 20:03:39 GMT, Chen Liang wrote: >> Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. >> >> The classes were identified using an automated analysis. See CSR for details. >> >> Besides simply adding the `final` access modifier, the PR: >> >> * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. >> * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` >> * Updates the copyright year of affected source files > > src/java.base/share/classes/java/net/InterfaceAddress.java line 45: > >> 43: >> 44: /* >> 45: * Package private constructor. Can't be built directly, instances are > > The comment is outdated. This constructor is actually called via JNI like `(*env)->NewObject(env, ni_ibcls, ni_ibctrID)` in `NetworkInterface.c`. I think we need to consult a network engineer to decide what is the best way to comment on this constructor. A pleasant surprise - since we aren't modifying constructor modifiers, we can put these intricacies on hold. Thanks for limiting the scope of this patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859162790 From eirbjo at openjdk.org Thu Jan 16 20:42:53 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 16 Jan 2025 20:42:53 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: <4ifcIGdOnz0NbgxfK5Yn8YMoEOKHOvRv4rrG7XOvwZQ=.9d79707f-3c28-4a3a-86a1-bd1c7f5233c3@github.com> References: <4ifcIGdOnz0NbgxfK5Yn8YMoEOKHOvRv4rrG7XOvwZQ=.9d79707f-3c28-4a3a-86a1-bd1c7f5233c3@github.com> Message-ID: <1Osv6B_tLqnArJDx89PKGl7Qy_o_oBU5Nxb2wpKiSQY=.59527d3c-7ded-49d8-8944-b84bf154d501@github.com> On Tue, 26 Nov 2024 20:08:28 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/net/InterfaceAddress.java line 45: >> >>> 43: >>> 44: /* >>> 45: * Package private constructor. Can't be built directly, instances are >> >> The comment is outdated. This constructor is actually called via JNI like `(*env)->NewObject(env, ni_ibcls, ni_ibctrID)` in `NetworkInterface.c`. I think we need to consult a network engineer to decide what is the best way to comment on this constructor. > > A pleasant surprise - since we aren't modifying constructor modifiers, we can put these intricacies on hold. Thanks for limiting the scope of this patch. Indeed, this makes this PR much simpler. I have filed separate JBS issues to track these constructor updates: https://bugs.openjdk.org/browse/JDK-8345074 for`InterfaceAddress` https://bugs.openjdk.org/browse/JDK-8345075 for `ModuleDescriptor` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22389#discussion_r1859196447 From bpb at openjdk.org Thu Jan 16 21:02:30 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 16 Jan 2025 21:02:30 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 20:38:40 GMT, David Holmes wrote: > Maybe I'm missing some subtlety here but shouldn't these special names always fail on all Windows versions, so we just need to check Platform.isWindows() from the test library? There was a change in Windows 11 as to which special names are allowed or disallowed (see [JDK-8274122](https://bugs.openjdk.org/browse/JDK-8274122)), so I think we either have to deal with the versioning or just drop the part of the test which deals with these special names. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23117#issuecomment-2596851705 From dholmes at openjdk.org Thu Jan 16 21:42:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Jan 2025 21:42:35 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: Message-ID: <4HS8G8NVbIoPzOaU-T0VuEe2UQEWOIOGF5sHU-8Un60=.6f98f13c-c07e-49d9-ab9a-719125ea8fce@github.com> On Wed, 15 Jan 2025 21:26:49 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the Windows test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8347740: Change Windows exceptionExpected to be based on build number Interesting, I can't find anything to suggest there was an API change in Windows 11 that would account for this. AFAICS as long as you use the NT namespace and not the Win32 namespace then the reserved device names should be illegal. Not sure it is worth all this effort, but that's a core-libs decision. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23117#issuecomment-2596946496 From jlu at openjdk.org Thu Jan 16 22:26:10 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Jan 2025 22:26:10 GMT Subject: RFR: 8347949: Currency method to stream available Currencies Message-ID: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. The motivation can be found in the CSR. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/23165/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347949 Stats: 77 lines in 2 files changed: 69 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165 PR: https://git.openjdk.org/jdk/pull/23165 From jlu at openjdk.org Thu Jan 16 22:39:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 16 Jan 2025 22:39:52 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v2] In-Reply-To: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: > Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. > > The motivation can be found in the CSR. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: synchronize init method over block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23165/files - new: https://git.openjdk.org/jdk/pull/23165/files/45888169..bf705a2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=00-01 Stats: 40 lines in 1 file changed: 1 ins; 3 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/23165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165 PR: https://git.openjdk.org/jdk/pull/23165 From bpb at openjdk.org Thu Jan 16 22:47:34 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 16 Jan 2025 22:47:34 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: <4HS8G8NVbIoPzOaU-T0VuEe2UQEWOIOGF5sHU-8Un60=.6f98f13c-c07e-49d9-ab9a-719125ea8fce@github.com> References: <4HS8G8NVbIoPzOaU-T0VuEe2UQEWOIOGF5sHU-8Un60=.6f98f13c-c07e-49d9-ab9a-719125ea8fce@github.com> Message-ID: On Thu, 16 Jan 2025 21:39:50 GMT, David Holmes wrote: > Not sure it is worth all this effort, but that's a core-libs decision. Neither am I. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23117#issuecomment-2597058064 From davidalayachew at gmail.com Thu Jan 16 23:25:25 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 16 Jan 2025 18:25:25 -0500 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> Message-ID: I guess let me ask the obvious question. Chesterton's fence -- why wasn't this done before? I refuse to believe that this idea wasn't thought up years ago, which leads me to believe there was a reason that it hasn't been done. Is there any way we can look this up in the bug database or something? On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m wrote: > Having the result Map.of and Set.of preserve the insertion order would > often be convenient. > > More often than not programs iterate over the contents of a maps and > sets at some point. For example to present the values in a GUI, for > serialisation, or even for error printouts. In all those cases having a > fixed iteration order is much better than having a random iteration > order. > > Often it is even a subtle bug to have a random iteration order. For > example, I ran in to a situation where jdeps printed a error message > containing a list of modules. But the list was in a different order on > each run of the program! It took me a while to figure out that it was > actually the same list. A possible explanation is that jdeps is > implemented using Map.of or Set.of. > > Because of this I think I would be better if the most commonly used > standard collection factories produced collections with a fixed > iteration order. > > Guavas ImmutableMap and ImmutableSet also preserve insertion order. > > Regards, > Jens Lidestr?m > > > On 2025-01-16 08:44, Remi Forax wrote: > > > ------------------------- > > > >> From: "Rafael Winterhalter" > >> To: "core-libs-dev" > >> Sent: Thursday, January 16, 2025 8:13:17 AM > >> Subject: Factory methods for SequencedSet and SequencedMap > > > >> Hello, > > > > Hello, > > > >> I am happily taking SequencedSet and SequencedMap into use, but one > >> inconvenience I encounter is the lack of factory methods for the two. > >> In code where many (initial) collections have zero or one element (for > >> later aggregation), I now write Set.of()/Set.of(one) and > >> Map.of()/Map.of(key, value), as it makes the code shorter and more > >> readable. Those collections are of course implicitly sequenced, but > >> now I must make the variable type of the surrounding monad Set and > >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is used > >> when a collection of more than one element is set, without requiring > >> the interface type. This does not require any type casting, as I rely > >> on the iteration order only, but the code loses some of its > >> expressiveness. > >> I did not find any discussion around introducing factories for > >> SequencedSet.of(...) and SequencedMap.of(...), similar to those that > >> exist in the Set and Map interfaces. Was this ever considered, and if > >> not, could it be? > > > > Thanks for re-starting that discussion, it was talked a bit, but not as > > it should be. > > > > So the issue is that currently we do not have any compact, unmodifiable > > and ordered Set/Map implementation, > > one use case is when you have data that comes from a JSON object as a > > Map and you want to keep the inserted order, if by example the JSON is > > a config file editable by a human, an other example is in unit tests > > where you want to help the dev to read the output of the test so the > > code that creates a Set/Map and what is outputed by the test should be > > in the same order. > > Currently there is no good solution for those use cases because > > Set|Map.copyOf() does not keep the ordering. > > > > I see two solutions, either we add a new > > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of > > Set|Map.of()/copyOf(). > > Python had gone for the latter solution, which has the advantage a > > being simple from the user POV, but from an algorithm expert POV, a Set > > and a SequencedSet are different concepts we may want to emphasis ? > > > >> Best regards, Rafael > > > > regards, > > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Thu Jan 16 23:35:57 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 16 Jan 2025 18:35:57 -0500 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> Message-ID: I should also add, the documentation went out of their way to specify that iteration order is unspecified. Also, I see R?mi's comment, but that's even more unconvincing to me. Map.of has an upper limit of 10 entries, and Map.ofEntries has an upper limit of that Java max file size limit thing. You all know what I am talking about. Point is, both of these static factories were meant to be used on a small number of entries. If it truly has just been not done until now, then the bug database will confirm that easily. When I get back, I can check myself. On Thu, Jan 16, 2025, 6:25?PM David Alayachew wrote: > I guess let me ask the obvious question. > > Chesterton's fence -- why wasn't this done before? I refuse to believe > that this idea wasn't thought up years ago, which leads me to believe there > was a reason that it hasn't been done. > > Is there any way we can look this up in the bug database or something? > > On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m wrote: > >> Having the result Map.of and Set.of preserve the insertion order would >> often be convenient. >> >> More often than not programs iterate over the contents of a maps and >> sets at some point. For example to present the values in a GUI, for >> serialisation, or even for error printouts. In all those cases having a >> fixed iteration order is much better than having a random iteration >> order. >> >> Often it is even a subtle bug to have a random iteration order. For >> example, I ran in to a situation where jdeps printed a error message >> containing a list of modules. But the list was in a different order on >> each run of the program! It took me a while to figure out that it was >> actually the same list. A possible explanation is that jdeps is >> implemented using Map.of or Set.of. >> >> Because of this I think I would be better if the most commonly used >> standard collection factories produced collections with a fixed >> iteration order. >> >> Guavas ImmutableMap and ImmutableSet also preserve insertion order. >> >> Regards, >> Jens Lidestr?m >> >> >> On 2025-01-16 08:44, Remi Forax wrote: >> >> > ------------------------- >> > >> >> From: "Rafael Winterhalter" >> >> To: "core-libs-dev" >> >> Sent: Thursday, January 16, 2025 8:13:17 AM >> >> Subject: Factory methods for SequencedSet and SequencedMap >> > >> >> Hello, >> > >> > Hello, >> > >> >> I am happily taking SequencedSet and SequencedMap into use, but one >> >> inconvenience I encounter is the lack of factory methods for the two. >> >> In code where many (initial) collections have zero or one element (for >> >> later aggregation), I now write Set.of()/Set.of(one) and >> >> Map.of()/Map.of(key, value), as it makes the code shorter and more >> >> readable. Those collections are of course implicitly sequenced, but >> >> now I must make the variable type of the surrounding monad Set and >> >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is used >> >> when a collection of more than one element is set, without requiring >> >> the interface type. This does not require any type casting, as I rely >> >> on the iteration order only, but the code loses some of its >> >> expressiveness. >> >> I did not find any discussion around introducing factories for >> >> SequencedSet.of(...) and SequencedMap.of(...), similar to those that >> >> exist in the Set and Map interfaces. Was this ever considered, and if >> >> not, could it be? >> > >> > Thanks for re-starting that discussion, it was talked a bit, but not as >> > it should be. >> > >> > So the issue is that currently we do not have any compact, unmodifiable >> > and ordered Set/Map implementation, >> > one use case is when you have data that comes from a JSON object as a >> > Map and you want to keep the inserted order, if by example the JSON is >> > a config file editable by a human, an other example is in unit tests >> > where you want to help the dev to read the output of the test so the >> > code that creates a Set/Map and what is outputed by the test should be >> > in the same order. >> > Currently there is no good solution for those use cases because >> > Set|Map.copyOf() does not keep the ordering. >> > >> > I see two solutions, either we add a new >> > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of >> > Set|Map.of()/copyOf(). >> > Python had gone for the latter solution, which has the advantage a >> > being simple from the user POV, but from an algorithm expert POV, a Set >> > and a SequencedSet are different concepts we may want to emphasis ? >> > >> >> Best regards, Rafael >> > >> > regards, >> > R?mi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Thu Jan 16 23:43:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 16 Jan 2025 23:43:44 GMT Subject: RFR: 8347841: Test fixes that use deprecated time zone IDs Message-ID: This fix is a follow on for [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes usages of those deprecated time zone ids in tests. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/23166/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23166&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347841 Stats: 213 lines in 27 files changed: 67 ins; 34 del; 112 mod Patch: https://git.openjdk.org/jdk/pull/23166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23166/head:pull/23166 PR: https://git.openjdk.org/jdk/pull/23166 From swen at openjdk.org Fri Jan 17 00:09:11 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 17 Jan 2025 00:09:11 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v7] In-Reply-To: References: Message-ID: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix comment, from @rgiulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22023/files - new: https://git.openjdk.org/jdk/pull/22023/files/8122c1bf..14499590 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=05-06 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023 PR: https://git.openjdk.org/jdk/pull/22023 From swen at openjdk.org Fri Jan 17 00:09:14 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 17 Jan 2025 00:09:14 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v6] In-Reply-To: <0FIbRT8u5KnjNE8o4tsd44q5wC0wYrYbcRkEDps5EnY=.7bded3d2-1a7f-4879-b0f7-b06a90b587e7@github.com> References: <0FIbRT8u5KnjNE8o4tsd44q5wC0wYrYbcRkEDps5EnY=.7bded3d2-1a7f-4879-b0f7-b06a90b587e7@github.com> Message-ID: <0s3sQ_sngeHasBQNMmGWjxNeFEugQFGKBVFdxTEuZ2I=.77553eb4-3f45-4bd3-87bb-829185368e2e@github.com> On Thu, 16 Jan 2025 17:22:50 GMT, Raffaello Giulietti wrote: >> Shaojin Wen 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 19 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 >> - form @cl4es >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 >> - fix unsafe address overflow >> - add benchmark >> - remove comments, from @liach >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202410 >> - fix Helper >> - ... and 9 more: https://git.openjdk.org/jdk/compare/2ec55f08...8122c1bf > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 42: > >> 40: >> 41: /** >> 42: * Each element of the array represents the packaging of two ascii characters based on little endian:

> > The table below contradicts itself. > For example > > * 02 -> '2' | ('0' << 8) -> 0x3230 > > should instead read > > * 02 -> '2' | ('0' << 8) -> 0x3032 > > and so on. > > Please adjust the comment and check that everything related to `DIGITS` is used consistently. fixed it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1919387362 From jlu at openjdk.org Fri Jan 17 00:33:36 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 00:33:36 GMT Subject: RFR: 8347841: Test fixes that use deprecated time zone IDs In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 23:38:48 GMT, Naoto Sato wrote: > This fix is a follow on for [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes usages of those deprecated time zone ids in tests. Looks good. test/jdk/java/text/Format/DateFormat/DateFormatTest.java line 190: > 188: //logln(((SimpleDateFormat)fmt).toPattern()); > 189: TimeZone save = TimeZone.getDefault(); > 190: TimeZone PST = TimeZone.getTimeZone("America/Los_Angeles"); nit: extra space after "PST" here and below. test/jdk/java/util/TimeZone/TimeZoneBoundaryTest.java line 417: > 415: //findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("EST"), 2); > 416: findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("HST"), 0); > 417: findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("PST"), 2); "PST" to "America/Los_Angeles" not needed? ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/23166#pullrequestreview-2557677590 PR Review Comment: https://git.openjdk.org/jdk/pull/23166#discussion_r1919401497 PR Review Comment: https://git.openjdk.org/jdk/pull/23166#discussion_r1919380627 From naoto at openjdk.org Fri Jan 17 00:45:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Jan 2025 00:45:54 GMT Subject: RFR: 8347841: Test fixes that use deprecated time zone IDs [v2] In-Reply-To: References: Message-ID: > This fix is a follow on for [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes usages of those deprecated time zone ids in tests. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed extra spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23166/files - new: https://git.openjdk.org/jdk/pull/23166/files/e5b58ef7..f3531f26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23166&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23166&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23166/head:pull/23166 PR: https://git.openjdk.org/jdk/pull/23166 From naoto at openjdk.org Fri Jan 17 00:45:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Jan 2025 00:45:54 GMT Subject: RFR: 8347841: Test fixes that use deprecated time zone IDs [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 23:54:04 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed extra spaces > > test/jdk/java/util/TimeZone/TimeZoneBoundaryTest.java line 417: > >> 415: //findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("EST"), 2); >> 416: findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("HST"), 0); >> 417: findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("PST"), 2); > > "PST" to "America/Los_Angeles" not needed? It's already there at L421 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23166#discussion_r1919409359 From jlu at openjdk.org Fri Jan 17 00:49:36 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 00:49:36 GMT Subject: RFR: 8347841: Test fixes that use deprecated time zone IDs [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 00:45:54 GMT, Naoto Sato wrote: >> This fix is a follow on for [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes usages of those deprecated time zone ids in tests. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed extra spaces Marked as reviewed by jlu (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23166#pullrequestreview-2557758662 From jlu at openjdk.org Fri Jan 17 00:49:37 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 00:49:37 GMT Subject: RFR: 8347841: Test fixes that use deprecated time zone IDs [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 00:42:03 GMT, Naoto Sato wrote: >> test/jdk/java/util/TimeZone/TimeZoneBoundaryTest.java line 417: >> >>> 415: //findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("EST"), 2); >>> 416: findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("HST"), 0); >>> 417: findBoundariesStepwise(1997, ONE_DAY, TimeZone.getTimeZone("PST"), 2); >> >> "PST" to "America/Los_Angeles" not needed? > > It's already there at L421 Right, looks good then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23166#discussion_r1919412033 From dholmes at openjdk.org Fri Jan 17 06:01:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Jan 2025 06:01:48 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 18:18:15 GMT, Leonid Mesnik wrote: >> There few compiler warning disabled in the testlibary build. >> They should be fixed or localized and removed from build to prevent new possible issues. >> >> The main goal is to avoid new such issues in the testlibrary. >> Tested with tier1-5 to ensure that all tests were passed. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert change Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2558035645 From dholmes at openjdk.org Fri Jan 17 06:01:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Jan 2025 06:01:49 GMT Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 17:53:48 GMT, Leonid Mesnik wrote: >> test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46: >> >>> 44: public int getInt(long pos) throws IOException; >>> 45: public long getLong(long pos) throws IOException; >>> 46: public void close() throws IOException; >> >> Why was this redefined to throw IOException rather than just Exception? > > The javac complains about potential InterruptedException, so I changed type. > See > https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html > `Implementers of this interface are also strongly advised to not have the close method throw [InterruptedException](https://docs.oracle.com/javase/8/docs/api/java/lang/InterruptedException.html). This exception interacts with a thread's interrupted status, and runtime misbehavior is likely to occur if an InterruptedException is [suppressed](https://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSuppressed-java.lang.Throwable-). More generally, if it would cause problems for an exception to be suppressed, the AutoCloseable.close method should not throw it.` Ugggh! That is an annoyance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1919602558 From rafael.wth at gmail.com Fri Jan 17 07:26:08 2025 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 17 Jan 2025 08:26:08 +0100 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> Message-ID: Would it even be possible to change the return types of Set.of(...) and Map.of(...) without breaking binary compatibility? I also think that the randomization of Set.of(...) and Map.of(...) is a good property as it uncovers bugs early if one relies on iteration order. This especially since those methods are often used in tests where production code would use a proper HashSet which cannot guarantee iteration order for good reasons. Exactly here I think the new interfaces are a good addition as it uncovers such misconceptions. If code relies on insertion order, providing a Set.of(...) does no longer compile, what is a good thing. To me, adding SequencedSet.of(...) and SequencedMap.of(...) sounds like the right approach, with implementations similar to that of Set.of(...) and Map.of(...). As for megamorphism, I think the chance of encounter at a call site is similar, as Set12 and SetN from the Set interface are typically combined with HashMap. As for a possible SequencedSet12 and SequencedSetN, I think they would normally be seen with LinkedHashSet. Best regards, Rafael Am Fr., 17. Jan. 2025 um 00:36 Uhr schrieb David Alayachew < davidalayachew at gmail.com>: > I should also add, the documentation went out of their way to specify that > iteration order is unspecified. > > Also, I see R?mi's comment, but that's even more unconvincing to me. > > Map.of has an upper limit of 10 entries, and Map.ofEntries has an upper > limit of that Java max file size limit thing. You all know what I am > talking about. > > Point is, both of these static factories were meant to be used on a small > number of entries. If it truly has just been not done until now, then the > bug database will confirm that easily. > > When I get back, I can check myself. > > On Thu, Jan 16, 2025, 6:25?PM David Alayachew > wrote: > >> I guess let me ask the obvious question. >> >> Chesterton's fence -- why wasn't this done before? I refuse to believe >> that this idea wasn't thought up years ago, which leads me to believe there >> was a reason that it hasn't been done. >> >> Is there any way we can look this up in the bug database or something? >> >> On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m wrote: >> >>> Having the result Map.of and Set.of preserve the insertion order would >>> often be convenient. >>> >>> More often than not programs iterate over the contents of a maps and >>> sets at some point. For example to present the values in a GUI, for >>> serialisation, or even for error printouts. In all those cases having a >>> fixed iteration order is much better than having a random iteration >>> order. >>> >>> Often it is even a subtle bug to have a random iteration order. For >>> example, I ran in to a situation where jdeps printed a error message >>> containing a list of modules. But the list was in a different order on >>> each run of the program! It took me a while to figure out that it was >>> actually the same list. A possible explanation is that jdeps is >>> implemented using Map.of or Set.of. >>> >>> Because of this I think I would be better if the most commonly used >>> standard collection factories produced collections with a fixed >>> iteration order. >>> >>> Guavas ImmutableMap and ImmutableSet also preserve insertion order. >>> >>> Regards, >>> Jens Lidestr?m >>> >>> >>> On 2025-01-16 08:44, Remi Forax wrote: >>> >>> > ------------------------- >>> > >>> >> From: "Rafael Winterhalter" >>> >> To: "core-libs-dev" >>> >> Sent: Thursday, January 16, 2025 8:13:17 AM >>> >> Subject: Factory methods for SequencedSet and SequencedMap >>> > >>> >> Hello, >>> > >>> > Hello, >>> > >>> >> I am happily taking SequencedSet and SequencedMap into use, but one >>> >> inconvenience I encounter is the lack of factory methods for the two. >>> >> In code where many (initial) collections have zero or one element >>> (for >>> >> later aggregation), I now write Set.of()/Set.of(one) and >>> >> Map.of()/Map.of(key, value), as it makes the code shorter and more >>> >> readable. Those collections are of course implicitly sequenced, but >>> >> now I must make the variable type of the surrounding monad Set and >>> >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is used >>> >> when a collection of more than one element is set, without requiring >>> >> the interface type. This does not require any type casting, as I rely >>> >> on the iteration order only, but the code loses some of its >>> >> expressiveness. >>> >> I did not find any discussion around introducing factories for >>> >> SequencedSet.of(...) and SequencedMap.of(...), similar to those that >>> >> exist in the Set and Map interfaces. Was this ever considered, and if >>> >> not, could it be? >>> > >>> > Thanks for re-starting that discussion, it was talked a bit, but not >>> as >>> > it should be. >>> > >>> > So the issue is that currently we do not have any compact, >>> unmodifiable >>> > and ordered Set/Map implementation, >>> > one use case is when you have data that comes from a JSON object as a >>> > Map and you want to keep the inserted order, if by example the JSON is >>> > a config file editable by a human, an other example is in unit tests >>> > where you want to help the dev to read the output of the test so the >>> > code that creates a Set/Map and what is outputed by the test should be >>> > in the same order. >>> > Currently there is no good solution for those use cases because >>> > Set|Map.copyOf() does not keep the ordering. >>> > >>> > I see two solutions, either we add a new >>> > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of >>> > Set|Map.of()/copyOf(). >>> > Python had gone for the latter solution, which has the advantage a >>> > being simple from the user POV, but from an algorithm expert POV, a >>> Set >>> > and a SequencedSet are different concepts we may want to emphasis ? >>> > >>> >> Best regards, Rafael >>> > >>> > regards, >>> > R?mi >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Fri Jan 17 07:28:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 17 Jan 2025 07:28:03 GMT Subject: RFR: 8299504: Resolve `uses` and `provides` at run time if optional services are missing Message-ID: Extend the support for optional dependences to allow for a service to be optional. The post-resolution consistency check specified by `Configuration.resolve` is relaxed to allow for the possibility that the service may be module that is not in the module graph. ConfigurationTest is ported from TestNG to JUnit and updated to add new tests testUsesOptionalService$N and testProvidesOptionalService$N. The port to JUnit is mostly trivial/mechanical changes but it does create a bit of noise - I can move this port to another issue if it makes the harder to see the additions to the test. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/23147/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299504 Stats: 520 lines in 3 files changed: 220 ins; 51 del; 249 mod Patch: https://git.openjdk.org/jdk/pull/23147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23147/head:pull/23147 PR: https://git.openjdk.org/jdk/pull/23147 From viktor.klang at oracle.com Fri Jan 17 10:32:02 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Fri, 17 Jan 2025 10:32:02 +0000 Subject: Minor optimizations / questions about stream implementation In-Reply-To: References: Message-ID: Hi Daniel, Thanks for your patience. What kind of feedback/responses are you looking for primarily? Have you attempted to make changes and run any of the openjdk stream benches (after running the tests)? Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev on behalf of Daniel Avery Sent: Friday, 10 January 2025 04:01 To: core-libs-dev at openjdk.org Subject: Minor optimizations / questions about stream implementation Hi, I recently finished a deep-dive through the code in java.util.stream, and came across a few corners that stuck out to me as being odd, in a "small missed opportunity" kind of way. I figured I'd raise them here just in case any are legitimate, or I could get some better insight. I am looking at JDK 24 [build 30] (https://github.com/openjdk/jdk/tree/jdk-24%2B30/src/java.base/share/classes/java). 1. AbstractPipeline.wrap() is passed isParallel(), which ultimately (only) plays into determining if StreamSpliterators.AbstractWrappingSpliterator is allowed to split. It looks like the code could be more lenient, and instead pass (isParallel() || !hasAnyStateful()), i.e. allow splitting the spliterator() from sequential streams that do not have stateful ops. 2. It looks like StreamSpliterators.UnorderedSliceSpliterator.trySplit() should disable splitting if (permitStatus == NO_MORE), instead of (permits.get() == 0). As is, it would appear to unnecessarily disable splitting after skipping, in the skip-only case. 3. It looks like SortedOps could override opEvaluateParallelLazy to no-op in the already-sorted case, similar to DistinctOps in the already-distinct case. 4. It looks like SliceOps.makeRef() could fuse adjacent skip()/limit() ops (though I could see that being an overly niche optimization, especially if it makes linked/consumed handling painful). 5. It looks like there is some dead code in StreamOpFlag? I don't see a path where isPreserved() would return true in practice (it appears to only be called in exactly 2 'minor optimization' places: SliceTask.doLeaf() and DropWhileTask.doLeaf()). With the way StreamOpFlag.combineOpFlags() works, it looks like in practice 0b00 is used to preserve, rather than 0b11. I also don't see Type.OP, Type.TERMINAL_OP, or Type.UPSTREAM_TERMINAL_OP being used anywhere. I assume some of the methods here are intended for tests only (isStreamFlag(), canSet())... But given how much of this class I'm not seeing being used, I'm wondering if I'm just missing something. Thank you, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski at openjdk.org Fri Jan 17 11:06:41 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 17 Jan 2025 11:06:41 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 21:26:49 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the Windows test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8347740: Change Windows exceptionExpected to be based on build number test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 95: > 93: > 94: String cmd = "Systeminfo"; > 95: Process p = Runtime.getRuntime().exec(new String[] {cmd}); I'm not a big fan of running third-party tools in our tests; did you try fixing the regex expression? Replace: `"^.*[11|2025]$"` (character class) -> `"^.*(11|2025)$"` (alternative strings) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1919992782 From djelinski at openjdk.org Fri Jan 17 12:28:39 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 17 Jan 2025 12:28:39 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. > > The classes were identified using an automated analysis. See CSR for details. > > Besides simply adding the `final` access modifier, the PR: > > * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. > * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` > * Updates the copyright year of affected source files LGTM, the class changes are pretty trivial. I suppose the CheckCSMs test could be cleaned up a little (will we ever need KNOWN_NON_FINAL_CSMS again?), but that can be done in a separate PR. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22389#pullrequestreview-2558892291 From davidalayachew at gmail.com Fri Jan 17 12:57:16 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 17 Jan 2025 07:57:16 -0500 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> Message-ID: Sure, changing the return type to a more specialized type is never a problem. And even if it was, the explicit documentation on those factory methods was that the actual implementation is subject to change, and should not be depended on. Also, your argument about iteration order doesn't make sense. It won't uncover bugs deterministically. It all depends on how things get grouped. Also, if we are going to be returning a SequencedSet, then it would make good sense to change the javadoc to reflect the fact that iteration order can now be depended upon. Either way, I don't really care which way we go. But I certainly think that altering Set.of to return SequencedSet is the stronger move, and I haven't heard any solid arguments against it. On Fri, Jan 17, 2025, 2:26?AM Rafael Winterhalter wrote: > > Would it even be possible to change the return types of Set.of(...) and > Map.of(...) without breaking binary compatibility? > > I also think that the randomization of Set.of(...) and Map.of(...) is a > good property as it uncovers bugs early if one relies on iteration order. > This especially since those methods are often used in tests where > production code would use a proper HashSet which cannot guarantee iteration > order for good reasons. Exactly here I think the new interfaces are a good > addition as it uncovers such misconceptions. If code relies on insertion > order, providing a Set.of(...) does no longer compile, what is a good thing. > > To me, adding SequencedSet.of(...) and SequencedMap.of(...) sounds like > the right approach, with implementations similar to that of Set.of(...) and > Map.of(...). As for megamorphism, I think the chance of encounter at a call > site is similar, as Set12 and SetN from the Set interface are typically > combined with HashMap. As for a possible SequencedSet12 and SequencedSetN, > I think they would normally be seen with LinkedHashSet. > > Best regards, Rafael > > Am Fr., 17. Jan. 2025 um 00:36 Uhr schrieb David Alayachew < > davidalayachew at gmail.com>: > >> I should also add, the documentation went out of their way to specify >> that iteration order is unspecified. >> >> Also, I see R?mi's comment, but that's even more unconvincing to me. >> >> Map.of has an upper limit of 10 entries, and Map.ofEntries has an upper >> limit of that Java max file size limit thing. You all know what I am >> talking about. >> >> Point is, both of these static factories were meant to be used on a small >> number of entries. If it truly has just been not done until now, then the >> bug database will confirm that easily. >> >> When I get back, I can check myself. >> >> On Thu, Jan 16, 2025, 6:25?PM David Alayachew >> wrote: >> >>> I guess let me ask the obvious question. >>> >>> Chesterton's fence -- why wasn't this done before? I refuse to believe >>> that this idea wasn't thought up years ago, which leads me to believe there >>> was a reason that it hasn't been done. >>> >>> Is there any way we can look this up in the bug database or something? >>> >>> On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m wrote: >>> >>>> Having the result Map.of and Set.of preserve the insertion order would >>>> often be convenient. >>>> >>>> More often than not programs iterate over the contents of a maps and >>>> sets at some point. For example to present the values in a GUI, for >>>> serialisation, or even for error printouts. In all those cases having a >>>> fixed iteration order is much better than having a random iteration >>>> order. >>>> >>>> Often it is even a subtle bug to have a random iteration order. For >>>> example, I ran in to a situation where jdeps printed a error message >>>> containing a list of modules. But the list was in a different order on >>>> each run of the program! It took me a while to figure out that it was >>>> actually the same list. A possible explanation is that jdeps is >>>> implemented using Map.of or Set.of. >>>> >>>> Because of this I think I would be better if the most commonly used >>>> standard collection factories produced collections with a fixed >>>> iteration order. >>>> >>>> Guavas ImmutableMap and ImmutableSet also preserve insertion order. >>>> >>>> Regards, >>>> Jens Lidestr?m >>>> >>>> >>>> On 2025-01-16 08:44, Remi Forax wrote: >>>> >>>> > ------------------------- >>>> > >>>> >> From: "Rafael Winterhalter" >>>> >> To: "core-libs-dev" >>>> >> Sent: Thursday, January 16, 2025 8:13:17 AM >>>> >> Subject: Factory methods for SequencedSet and SequencedMap >>>> > >>>> >> Hello, >>>> > >>>> > Hello, >>>> > >>>> >> I am happily taking SequencedSet and SequencedMap into use, but one >>>> >> inconvenience I encounter is the lack of factory methods for the two. >>>> >> In code where many (initial) collections have zero or one element >>>> (for >>>> >> later aggregation), I now write Set.of()/Set.of(one) and >>>> >> Map.of()/Map.of(key, value), as it makes the code shorter and more >>>> >> readable. Those collections are of course implicitly sequenced, but >>>> >> now I must make the variable type of the surrounding monad Set and >>>> >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is used >>>> >> when a collection of more than one element is set, without requiring >>>> >> the interface type. This does not require any type casting, as I >>>> rely >>>> >> on the iteration order only, but the code loses some of its >>>> >> expressiveness. >>>> >> I did not find any discussion around introducing factories for >>>> >> SequencedSet.of(...) and SequencedMap.of(...), similar to those that >>>> >> exist in the Set and Map interfaces. Was this ever considered, and >>>> if >>>> >> not, could it be? >>>> > >>>> > Thanks for re-starting that discussion, it was talked a bit, but not >>>> as >>>> > it should be. >>>> > >>>> > So the issue is that currently we do not have any compact, >>>> unmodifiable >>>> > and ordered Set/Map implementation, >>>> > one use case is when you have data that comes from a JSON object as a >>>> > Map and you want to keep the inserted order, if by example the JSON >>>> is >>>> > a config file editable by a human, an other example is in unit tests >>>> > where you want to help the dev to read the output of the test so the >>>> > code that creates a Set/Map and what is outputed by the test should >>>> be >>>> > in the same order. >>>> > Currently there is no good solution for those use cases because >>>> > Set|Map.copyOf() does not keep the ordering. >>>> > >>>> > I see two solutions, either we add a new >>>> > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of >>>> > Set|Map.of()/copyOf(). >>>> > Python had gone for the latter solution, which has the advantage a >>>> > being simple from the user POV, but from an algorithm expert POV, a >>>> Set >>>> > and a SequencedSet are different concepts we may want to emphasis ? >>>> > >>>> >> Best regards, Rafael >>>> > >>>> > regards, >>>> > R?mi >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mullan at openjdk.org Fri Jan 17 13:51:45 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 17 Jan 2025 13:51:45 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. > > The classes were identified using an automated analysis. See CSR for details. > > Besides simply adding the `final` access modifier, the PR: > > * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. > * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` > * Updates the copyright year of affected source files @bradfordwetmore @wangweij please review the change to `DRBGParameters` and make sure we are ok with it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22389#issuecomment-2598407604 From ethan at mccue.dev Fri Jan 17 15:21:24 2025 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 17 Jan 2025 10:21:24 -0500 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> Message-ID: Just so there are some strawman arguments against: * Does altering Set.of to maintain order increase its memory footprint? If the answer is yes, does that matter? If the answer is no, is there a new standalone collection type to add? SetThatIsOrderedInTheSameMannerAsPythonsSetIsOrderedAndThusHasNoNotableMemoryOverheadOrItHasMoreOverheadButItsWorthIt? * Would it create an inconsistency between Set.copyOf and Set.of? I.E. Can both be ordered or just Set.of * At a certain point it was decided to randomize iteration order of collections between runs. Will there be any place where that behavior would catch bugs that will now go uncaught. I.E. if code today is given a value of Set.copyOf(...) but that caller later updates what they provide to be new HashSet<>(Set.copyOf(...)). If so, does this outweigh the benefits of making it ordered? Is there any reason to make SequencedSet.of and Set.of return different kinds of sets? On Fri, Jan 17, 2025 at 7:58?AM David Alayachew wrote: > Sure, changing the return type to a more specialized type is never a > problem. And even if it was, the explicit documentation on those factory > methods was that the actual implementation is subject to change, and should > not be depended on. > > Also, your argument about iteration order doesn't make sense. It won't > uncover bugs deterministically. It all depends on how things get grouped. > > Also, if we are going to be returning a SequencedSet, then it would make > good sense to change the javadoc to reflect the fact that iteration order > can now be depended upon. > > Either way, I don't really care which way we go. But I certainly think > that altering Set.of to return SequencedSet is the stronger move, and I > haven't heard any solid arguments against it. > > On Fri, Jan 17, 2025, 2:26?AM Rafael Winterhalter > wrote: > >> >> Would it even be possible to change the return types of Set.of(...) and >> Map.of(...) without breaking binary compatibility? >> >> I also think that the randomization of Set.of(...) and Map.of(...) is a >> good property as it uncovers bugs early if one relies on iteration order. >> This especially since those methods are often used in tests where >> production code would use a proper HashSet which cannot guarantee iteration >> order for good reasons. Exactly here I think the new interfaces are a good >> addition as it uncovers such misconceptions. If code relies on insertion >> order, providing a Set.of(...) does no longer compile, what is a good thing. >> >> To me, adding SequencedSet.of(...) and SequencedMap.of(...) sounds like >> the right approach, with implementations similar to that of Set.of(...) and >> Map.of(...). As for megamorphism, I think the chance of encounter at a call >> site is similar, as Set12 and SetN from the Set interface are typically >> combined with HashMap. As for a possible SequencedSet12 and SequencedSetN, >> I think they would normally be seen with LinkedHashSet. >> >> Best regards, Rafael >> >> Am Fr., 17. Jan. 2025 um 00:36 Uhr schrieb David Alayachew < >> davidalayachew at gmail.com>: >> >>> I should also add, the documentation went out of their way to specify >>> that iteration order is unspecified. >>> >>> Also, I see R?mi's comment, but that's even more unconvincing to me. >>> >>> Map.of has an upper limit of 10 entries, and Map.ofEntries has an upper >>> limit of that Java max file size limit thing. You all know what I am >>> talking about. >>> >>> Point is, both of these static factories were meant to be used on a >>> small number of entries. If it truly has just been not done until now, then >>> the bug database will confirm that easily. >>> >>> When I get back, I can check myself. >>> >>> On Thu, Jan 16, 2025, 6:25?PM David Alayachew >>> wrote: >>> >>>> I guess let me ask the obvious question. >>>> >>>> Chesterton's fence -- why wasn't this done before? I refuse to believe >>>> that this idea wasn't thought up years ago, which leads me to believe there >>>> was a reason that it hasn't been done. >>>> >>>> Is there any way we can look this up in the bug database or something? >>>> >>>> On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m wrote: >>>> >>>>> Having the result Map.of and Set.of preserve the insertion order would >>>>> often be convenient. >>>>> >>>>> More often than not programs iterate over the contents of a maps and >>>>> sets at some point. For example to present the values in a GUI, for >>>>> serialisation, or even for error printouts. In all those cases having >>>>> a >>>>> fixed iteration order is much better than having a random iteration >>>>> order. >>>>> >>>>> Often it is even a subtle bug to have a random iteration order. For >>>>> example, I ran in to a situation where jdeps printed a error message >>>>> containing a list of modules. But the list was in a different order on >>>>> each run of the program! It took me a while to figure out that it was >>>>> actually the same list. A possible explanation is that jdeps is >>>>> implemented using Map.of or Set.of. >>>>> >>>>> Because of this I think I would be better if the most commonly used >>>>> standard collection factories produced collections with a fixed >>>>> iteration order. >>>>> >>>>> Guavas ImmutableMap and ImmutableSet also preserve insertion order. >>>>> >>>>> Regards, >>>>> Jens Lidestr?m >>>>> >>>>> >>>>> On 2025-01-16 08:44, Remi Forax wrote: >>>>> >>>>> > ------------------------- >>>>> > >>>>> >> From: "Rafael Winterhalter" >>>>> >> To: "core-libs-dev" >>>>> >> Sent: Thursday, January 16, 2025 8:13:17 AM >>>>> >> Subject: Factory methods for SequencedSet and SequencedMap >>>>> > >>>>> >> Hello, >>>>> > >>>>> > Hello, >>>>> > >>>>> >> I am happily taking SequencedSet and SequencedMap into use, but one >>>>> >> inconvenience I encounter is the lack of factory methods for the >>>>> two. >>>>> >> In code where many (initial) collections have zero or one element >>>>> (for >>>>> >> later aggregation), I now write Set.of()/Set.of(one) and >>>>> >> Map.of()/Map.of(key, value), as it makes the code shorter and more >>>>> >> readable. Those collections are of course implicitly sequenced, but >>>>> >> now I must make the variable type of the surrounding monad Set and >>>>> >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is >>>>> used >>>>> >> when a collection of more than one element is set, without >>>>> requiring >>>>> >> the interface type. This does not require any type casting, as I >>>>> rely >>>>> >> on the iteration order only, but the code loses some of its >>>>> >> expressiveness. >>>>> >> I did not find any discussion around introducing factories for >>>>> >> SequencedSet.of(...) and SequencedMap.of(...), similar to those >>>>> that >>>>> >> exist in the Set and Map interfaces. Was this ever considered, and >>>>> if >>>>> >> not, could it be? >>>>> > >>>>> > Thanks for re-starting that discussion, it was talked a bit, but not >>>>> as >>>>> > it should be. >>>>> > >>>>> > So the issue is that currently we do not have any compact, >>>>> unmodifiable >>>>> > and ordered Set/Map implementation, >>>>> > one use case is when you have data that comes from a JSON object as >>>>> a >>>>> > Map and you want to keep the inserted order, if by example the JSON >>>>> is >>>>> > a config file editable by a human, an other example is in unit tests >>>>> > where you want to help the dev to read the output of the test so the >>>>> > code that creates a Set/Map and what is outputed by the test should >>>>> be >>>>> > in the same order. >>>>> > Currently there is no good solution for those use cases because >>>>> > Set|Map.copyOf() does not keep the ordering. >>>>> > >>>>> > I see two solutions, either we add a new >>>>> > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation >>>>> of >>>>> > Set|Map.of()/copyOf(). >>>>> > Python had gone for the latter solution, which has the advantage a >>>>> > being simple from the user POV, but from an algorithm expert POV, a >>>>> Set >>>>> > and a SequencedSet are different concepts we may want to emphasis ? >>>>> > >>>>> >> Best regards, Rafael >>>>> > >>>>> > regards, >>>>> > R?mi >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From galder at openjdk.org Fri Jan 17 15:31:46 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Fri, 17 Jan 2025 15:31:46 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v9] In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> <5LxTINpzicabL2086ATQoudlqUMANni986510N1nk_k=.499ecef8-bb25-41de-91d6-b368888c90d2@github.com> Message-ID: On Tue, 14 Jan 2025 08:33:36 GMT, Emanuel Peter wrote: >> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: >> >> Make sure it runs with cpus with either avx512 or asimd > > test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 107: > >> 105: int aboveCount, abovePercent; >> 106: >> 107: // Iterate until you find a set that matches the requirement probability > > Can you give a high-level definition / explanation what this does? > Also: what is the expected number of rounds you iterate here? I'm asking because I would like to be sure that a timeout is basically impossible because the probability is too low. Sure I'll add. It's an approximation to make it run fast as sizes increase. In the worst case I've seen it take 15 rounds when size was 100, 50% probability and got 50 below max and 50 above. But with bigger array sizes, say 10'000, and 50% probability aim, it can take 1 or 2 rounds ending up with 5027 above max, 4973 below max. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1920359437 From archie.cobbs at gmail.com Fri Jan 17 15:34:50 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Fri, 17 Jan 2025 09:34:50 -0600 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> Message-ID: On Fri, Jan 17, 2025 at 9:22?AM Ethan McCue wrote: > Just so there are some strawman arguments against: > To pile on... If I go to a restaurant and order a hamburger and they bring me a cheeseburger and also charge me extra for it, I'm going to complain! A Set and a SequencedSet are two different things. The latter comes with cheese but also has a higher cost. If I order a Set and get a SequencedSet, I am going to wonder why am I paying extra for preserving insertion order? If I order a Set and get a SortedSet, I am going to wonder why am I paying extra for keeping the elements sorted? If I order a SortedSet and get a NavigableSet, I am going to wonder why am I paying extra for navigation? If I had wanted a SequencedSet, I would have asked for one. So YES I am also agreeing here that there should be a SequencedSet.of() method to handle this need. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmesnik at openjdk.org Fri Jan 17 15:45:49 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Jan 2025 15:45:49 GMT Subject: Integrated: 8347840: Fix testlibrary compilation warnings In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik wrote: > There few compiler warning disabled in the testlibary build. > They should be fixed or localized and removed from build to prevent new possible issues. > > The main goal is to avoid new such issues in the testlibrary. > Tested with tier1-5 to ensure that all tests were passed. This pull request has now been integrated. Changeset: 2ca1b4d4 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/2ca1b4d48da7eb9b5baf0ac213f3ce87f47dd316 Stats: 120 lines in 30 files changed: 25 ins; 42 del; 53 mod 8347840: Fix testlibrary compilation warnings Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/23143 From rgiulietti at openjdk.org Fri Jan 17 15:47:38 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 17 Jan 2025 15:47:38 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v6] In-Reply-To: <0s3sQ_sngeHasBQNMmGWjxNeFEugQFGKBVFdxTEuZ2I=.77553eb4-3f45-4bd3-87bb-829185368e2e@github.com> References: <0FIbRT8u5KnjNE8o4tsd44q5wC0wYrYbcRkEDps5EnY=.7bded3d2-1a7f-4879-b0f7-b06a90b587e7@github.com> <0s3sQ_sngeHasBQNMmGWjxNeFEugQFGKBVFdxTEuZ2I=.77553eb4-3f45-4bd3-87bb-829185368e2e@github.com> Message-ID: On Fri, 17 Jan 2025 00:05:25 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 42: >> >>> 40: >>> 41: /** >>> 42: * Each element of the array represents the packaging of two ascii characters based on little endian:

>> >> The table below contradicts itself. >> For example >> >> * 02 -> '2' | ('0' << 8) -> 0x3230 >> >> should instead read >> >> * 02 -> '2' | ('0' << 8) -> 0x3032 >> >> and so on. >> >> Please adjust the comment and check that everything related to `DIGITS` is used consistently. > > fixed it Sorry, I was just reading the comment and not how DIGITS is initialized and used. The _correct_ comment should be something like * 97 -> '9' | ('7' << 8) -> 0x3739 so the `short` value was correct before, but not the expression to construct it. Again, sorry for the confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920360270 From rgiulietti at openjdk.org Fri Jan 17 15:47:46 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 17 Jan 2025 15:47:46 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v7] In-Reply-To: References: Message-ID: <_w9p7LGkOiBjAYk-nC7bJ9jSd8zqv2MXOnLiWMjUouM=.96f773c9-81f6-400d-a79b-3528e73ab785@github.com> On Fri, 17 Jan 2025 00:09:11 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix comment, from @rgiulietti src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 171: > 169: > 170: // We know there are at most two digits left at this point. > 171: if (i < -9) { I know this was just copy&paste, but it would be more stylistically more consistent with the `while` above to have Suggestion: if (i <= -10) { src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 213: > 211: > 212: // Get 2 digits/iteration using longs until quotient fits into an int > 213: while (i <= Integer.MIN_VALUE) { I think this can be Suggestion: while (i < Integer.MIN_VALUE) { src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 231: > 229: > 230: // We know there are at most two digits left at this point. > 231: if (i2 < -9) { Same as above src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 267: > 265: while (i <= -100) { > 266: q = i / 100; > 267: r = (q * 100) - i; Can we eliminate `r` to have the same code shape as the rest? src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 274: > 272: > 273: // We know there are at most two digits left at this point. > 274: if (i < -9) { Same as above src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 308: > 306: > 307: // Get 2 digits/iteration using longs until quotient fits into an int > 308: while (i <= Integer.MIN_VALUE) { Same as above src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 326: > 324: > 325: // We know there are at most two digits left at this point. > 326: if (i2 < -9) { Same as above src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 359: > 357: > 358: // Get 2 digits/iteration using longs until quotient fits into an int > 359: while (i <= Integer.MIN_VALUE) { Same as above src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 377: > 375: > 376: // We know there are at most two digits left at this point. > 377: if (i2 < -9) { Same as above test/micro/org/openjdk/bench/java/lang/StringBuilders.java line 76: > 74: int size = 16; > 75: intsArray = new int[size]; > 76: longArray = new long[size]; Suggestion: intArray = new int[size]; longArray = new long[size]; or Suggestion: intsArray = new int[size]; longsArray = new long[size]; Either both plural, or both singular test/micro/org/openjdk/bench/java/lang/StringBuilders.java line 240: > 238: StringBuilder buf = sbLatin1; > 239: buf.setLength(0); > 240: for (long l : longArray) { I believe this should be Suggestion: for (int l : intsArray) { test/micro/org/openjdk/bench/java/lang/StringBuilders.java line 251: > 249: buf.setLength(0); > 250: buf.setLength(0); > 251: for (long l : longArray) { Same as above ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920365244 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920366336 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920365341 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920368290 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920368614 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920368895 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920369116 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920369796 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920369660 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920377205 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920375564 PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920375823 From galder at openjdk.org Fri Jan 17 15:48:43 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Fri, 17 Jan 2025 15:48:43 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: <3rstCr_f43zEJRn6I1q5D-oUKH84wNWO4h_I6ZrOGc4=.014f8a93-2471-45d0-9634-73dbd086c428@github.com> On Tue, 14 Jan 2025 05:07:55 GMT, Galder Zamarre?o wrote: >> @galderz So you want me to review again? > > @eme64 I've fixed the test issue, it's ready to be reviewed > @galderz I don't remember from above, but did you ever run the Long Min/Max benchmarks from this? https://github.com/openjdk/jdk/pull/21032 Would just be nice to see that they have an improvement after this change :) Looking at the benchmark the arrays are loaded with random data with no control over which branch side will be taken. So there's no guarantees that you will see an improvement for the reasons I explained in https://github.com/openjdk/jdk/pull/20098#issuecomment-2379386872. To summarise what was observed there: * In AVX-512 you will only see an improvement when one of the min/max branches is taken ~100% of the time. * In non-AVX-512 this patch will create a regression when one of the min/max branches is taken ~100% of time. If it helps I'm happy to document this in detail in the `MinMaxVector` benchmark added here. I would expect a similar thing to happen when it comes to asimd envs with max vector size >= 32 (e.g. Graviton 3). Those will see vectorization occur and improvements kick in at 100%. Other systems (e.g. Graviton 4) will see a regression at 100%. This means that your work in https://github.com/openjdk/jdk/pull/20098#discussion_r1901576209 to avoid the max vector size limitation might become more important once my PR here goes in. I'm wondering if the long min/max benchmarks introduced in https://github.com/openjdk/jdk/pull/21032 should remain because their results are not predictable and that's not a good situation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2598645987 From rgiulietti at openjdk.org Fri Jan 17 15:50:41 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 17 Jan 2025 15:50:41 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v7] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 00:09:11 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix comment, from @rgiulietti src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 434: > 432: > 433: private static void putCharUTF16(byte[] buf, int charPos, int c) { > 434: UNSAFE.putChar(buf, ARRAY_BYTE_BASE_OFFSET + ((long) charPos << 1), (char) c); I'm not sure we can put a `char` into a `byte[]`. @cl4es is this safe on all platforms? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920383426 From lmesnik at openjdk.org Fri Jan 17 15:59:50 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Jan 2025 15:59:50 GMT Subject: RFR: 8338428: Add logging if final VM flags while setting properties [v5] In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> Message-ID: > Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. > > I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". > > Update: > There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: copyrights updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23054/files - new: https://git.openjdk.org/jdk/pull/23054/files/28b05e9b..b28439c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=03-04 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23054/head:pull/23054 PR: https://git.openjdk.org/jdk/pull/23054 From jbhateja at openjdk.org Fri Jan 17 16:02:55 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 17 Jan 2025 16:02:55 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review suggestions incorporated. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22754/files - new: https://git.openjdk.org/jdk/pull/22754/files/43aa3eb7..692de9c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=09-10 Stats: 116 lines in 6 files changed: 67 ins; 17 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From jbhateja at openjdk.org Fri Jan 17 16:02:55 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 17 Jan 2025 16:02:55 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v9] In-Reply-To: References: <_SCKY9fuTqNDfR6K1y-FuMvursDMuOx39sKrXMj0Tdg=.225da2f1-fcdc-4418-a753-6d7404b4a83e@github.com> Message-ID: On Wed, 15 Jan 2025 00:28:50 GMT, Paul Sandoz wrote: >> Hi @PaulSandoz , >> >> In above code snippet the return type 'short' of intrinsic call does not comply with the value being returned which is of box type, thereby mandating addition glue code. >> >> Regular primitive type boxing APIs are lazily intrinsified, thereby generating an intrinsifiable Call IR during parsing. >> LoadNode?s idealization can fetch a boxed value from the input of boxing call IR and directly forward it to users. >> >> Q1. What is the problem in directly passing Float16 boxes to FMA and SQRT intrinsic entry points? >> >> A. The compiler will have to unbox them before the actual operation. There are multiple schemes to perform unboxing, such as name-based, offset-based, and index-based field lookup. >> Vector API unbox expansion uses an offset-based payload field lookup, for this it bookkeeps the payload?s offset over runtime representation of VectorPayload class created as part of VM initialization. >> However, VM can only bookkeep this information for classes that are part of java.base module, Float16 being part of incubation module cannot use offset-based field lookup. Thus only viable alternative is to unbox using field name/index based lookup. >> For this compiler will first verify that the incoming oop is of Float16 type and then use a hardcoded name-based lookup to Load the field value. This looks fragile as it establishes an unwanted dependency b/w Float16 field names and compiler implementation, same applies to index-based lookup as index values are dependent onthe combined field count of class and instance-specific fields, thus any addition or deletion of a class-level static helper field before the field of interest can invalidate any hardcoded index value used by the compiler. >> All in all, for safe and reliable unboxing by compiler, it's necessary to create an upfront VM representation like vector_VectorPayload. >> >> Q2. What are the pros and cons of passing both the unboxed value and boxed values to the intrinsic entry point? >> A. >> Pros: >> - This will save unsafe unboxing implementation if the holder class is not part of java.base module. >> - We can leverage existing box intrinsification infrastructure which directly forwards the embedded values to its users. >> - Also, it will minimize the changes in the Java side implementation. >> >> Cons: >> - It's suboptimal in case the call is neither intrinsified or inlined, as it will add additional spills before the call. >> >> Q3. Primitive box class boxing API ?valueOf? accepts... > >> Given the above observations passing 3 additional box arguments to intrinsic and returning a box value needs additional changes in the compiler while minor re-structuring in Java implementation packed with in the glue logic looks like a reasonable approach. > > Did you mean to say *no* additional changes in the compiler? Otherwise, if not what would those changes be? Hi @PaulSandoz , Many thanks for your suggestion. From a compiler standpoint, changes are mainly around unboxing/boxing arguments and return values. Since the _Float16_ class is defined in the incubation module, we cannot refer to it in the wrapper class _Float16Math_ which is part of _java.base_ module. Thus, lambda must pass the boxes as _java.lang.Object_ type arguments will introduce additional type sharpening casts in lambda and defeat our purpose of preserving unmodified code in lambda. The current scheme only deals in intrinsic with short parameters and return values and is free from these concerns. The user may declare MUL and ADD as separate operations, and to honor JLS specification and precise floating-point model semantics we should not infer an FMA scalar operation, thus, intrinsification is appropriate here rather than a pattern match. With this incremental commit, I am trying to minimize the Java side changes. Let me know if this looks fine to you. Verified that auto-vectorization planned for follow-on patch is aligned with new changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1920398466 From rgiulietti at openjdk.org Fri Jan 17 16:08:41 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 17 Jan 2025 16:08:41 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v7] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 15:46:25 GMT, Raffaello Giulietti wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix comment, from @rgiulietti > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 434: > >> 432: >> 433: private static void putCharUTF16(byte[] buf, int charPos, int c) { >> 434: UNSAFE.putChar(buf, ARRAY_BYTE_BASE_OFFSET + ((long) charPos << 1), (char) c); > > I'm not sure we can put a `char` into a `byte[]`. > @cl4es is this safe on all platforms? The doc of `Unsafe::putChar()` delegates to the doc of `Unsafe::putInt()` which clearly states that the `Object` and `offset` arguments must locate a variable of the same type as the one of argument `x`, which is not the case here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920409624 From bpb at openjdk.org Fri Jan 17 16:49:40 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Jan 2025 16:49:40 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 11:04:09 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8347740: Change Windows exceptionExpected to be based on build number > > test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 95: > >> 93: >> 94: String cmd = "Systeminfo"; >> 95: Process p = Runtime.getRuntime().exec(new String[] {cmd}); > > I'm not a big fan of running third-party tools in our tests; did you try fixing the regex expression? > Replace: `"^.*[11|2025]$"` (character class) -> `"^.*(11|2025)$"` (alternative strings) No, I replaced it with splitting the OS version string. In any case, would that cover, e.g., the hypothetical cases Windows 27, Windows Server 2038, etc.? Unfortunately Miscrosoft does not provide a reliable API to obtain the build number. `GetVersionEx` is deprecated. [KUSER_SHARED_DATA](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-kuser_shared_data) contains `NtBuildNumber` but some device driver kit has to be installed to use it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1920468864 From rriggs at openjdk.org Fri Jan 17 16:52:42 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 17 Jan 2025 16:52:42 GMT Subject: RFR: 8338428: Add logging if final VM flags while setting properties [v5] In-Reply-To: References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> Message-ID: On Fri, 17 Jan 2025 15:59:50 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". >> >> Update: >> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > copyrights updated This has a very broad impact on all tests and should have a second reviewer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2598774949 From danielaveryj at gmail.com Fri Jan 17 17:06:28 2025 From: danielaveryj at gmail.com (Daniel Avery) Date: Fri, 17 Jan 2025 10:06:28 -0700 Subject: Minor optimizations / questions about stream implementation In-Reply-To: References: Message-ID: Hi Viktor. I guess for 1-4 I'm just looking for a quick eyeball to check if my takeaways are valid, nothing too committal. I'm a little more interested in 5, because I'm currently building a document that is attempting to capture how the stream internals fit together, including visualizing stream performance characteristics. How op flags are set/cleared/propagated plays a big part in what I've prepared. I want to make sure I don't oversimplify how they work. I have not attempted to make/test changes to the source. I guess I didn't presume I could contribute in that way, but I can look into it if you think it's worth it :) Thanks, Daniel On Fri, Jan 17, 2025 at 3:32?AM Viktor Klang wrote: > Hi Daniel, > > Thanks for your patience. > > What kind of feedback/responses are you looking for primarily? > > Have you attempted to make changes and run any of the openjdk stream > benches (after running the tests)? > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of > Daniel Avery > *Sent:* Friday, 10 January 2025 04:01 > *To:* core-libs-dev at openjdk.org > *Subject:* Minor optimizations / questions about stream implementation > > Hi, > > I recently finished a deep-dive through the code in java.util.stream, and > came across a few corners that stuck out to me as being odd, in a "small > missed opportunity" kind of way. I figured I'd raise them here just in case > any are legitimate, or I could get some better insight. I am looking at JDK > 24 [build 30] ( > https://github.com/openjdk/jdk/tree/jdk-24%2B30/src/java.base/share/classes/java > ). > > 1. AbstractPipeline.wrap() is passed isParallel(), which ultimately (only) > plays into determining if StreamSpliterators.AbstractWrappingSpliterator is > allowed to split. It looks like the code could be more lenient, and instead > pass (isParallel() || !hasAnyStateful()), i.e. allow splitting the > spliterator() from sequential streams that do not have stateful ops. > > 2. It looks like StreamSpliterators.UnorderedSliceSpliterator.trySplit() > should disable splitting if (permitStatus == NO_MORE), instead of > (permits.get() == 0). As is, it would appear to unnecessarily disable > splitting after skipping, in the skip-only case. > > 3. It looks like SortedOps could override opEvaluateParallelLazy to no-op > in the already-sorted case, similar to DistinctOps in the already-distinct > case. > > 4. It looks like SliceOps.makeRef() could fuse adjacent skip()/limit() ops > (though I could see that being an overly niche optimization, especially if > it makes linked/consumed handling painful). > > 5. It looks like there is some dead code in StreamOpFlag? I don't see a > path where isPreserved() would return true in practice (it appears to only > be called in exactly 2 'minor optimization' places: SliceTask.doLeaf() and > DropWhileTask.doLeaf()). With the way StreamOpFlag.combineOpFlags() works, > it looks like in practice 0b00 is used to preserve, rather than 0b11. I > also don't see Type.OP, Type.TERMINAL_OP, or Type.UPSTREAM_TERMINAL_OP > being used anywhere. I assume some of the methods here are intended for > tests only (isStreamFlag(), canSet())... But given how much of this class > I'm not seeing being used, I'm wondering if I'm just missing something. > > Thank you, > Daniel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski at openjdk.org Fri Jan 17 17:08:36 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 17 Jan 2025 17:08:36 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: Message-ID: <0jB4Wx3MnuXgB0QVnLKel-tspOYEULw9zxaspD774LY=.9d70090e-affc-4938-9a1f-cf92b43a4243@github.com> On Fri, 17 Jan 2025 16:46:58 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 95: >> >>> 93: >>> 94: String cmd = "Systeminfo"; >>> 95: Process p = Runtime.getRuntime().exec(new String[] {cmd}); >> >> I'm not a big fan of running third-party tools in our tests; did you try fixing the regex expression? >> Replace: `"^.*[11|2025]$"` (character class) -> `"^.*(11|2025)$"` (alternative strings) > > No, I replaced it with splitting the OS version string. In any case, would that cover, e.g., the hypothetical cases Windows 27, Windows Server 2038, etc.? > > Unfortunately Miscrosoft does not provide a reliable API to obtain the build number. `GetVersionEx` is deprecated. [KUSER_SHARED_DATA](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-kuser_shared_data) contains `NtBuildNumber` but some device driver kit has to be installed to use it. > > Also, [IsWindows10OrGreater](https://learn.microsoft.com/en-us/windows/win32/api/versionhelpers/nf-versionhelpers-iswindows10orgreater) returned `false` on my Windows 11 machine so it is suspicious, and [IsWindowsVersionOrGreater](https://learn.microsoft.com/en-us/windows/win32/api/versionhelpers/nf-versionhelpers-iswindowsversionorgreater) would require being able to know the service pack number of a particular build which I am not sure is possible, No, it wouldn't cover any future Windows versions, but it would definitely buy us a few years. Regarding a more permanent solution: the test is supposed to verify the fix for [JDK-8013827](https://bugs.openjdk.org/browse/JDK-8013827). I think it should accept both outcomes (success and the specific exception); the only unacceptable outcomes are: - timeout, - unexpected exception. We don't need to know the exact Windows version to verify that the test doesn't time out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1920491885 From bpb at openjdk.org Fri Jan 17 17:12:40 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Jan 2025 17:12:40 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: <0jB4Wx3MnuXgB0QVnLKel-tspOYEULw9zxaspD774LY=.9d70090e-affc-4938-9a1f-cf92b43a4243@github.com> References: <0jB4Wx3MnuXgB0QVnLKel-tspOYEULw9zxaspD774LY=.9d70090e-affc-4938-9a1f-cf92b43a4243@github.com> Message-ID: On Fri, 17 Jan 2025 17:05:56 GMT, Daniel Jeli?ski wrote: > I think it should accept both outcomes (success and the specific exception) But whether there's an exception varies by Windows version / build number. I'll take another look and see whether there is some other way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1920496334 From rriggs at openjdk.org Fri Jan 17 17:30:38 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 17 Jan 2025 17:30:38 GMT Subject: RFR: 8338428: Add logging if final VM flags while setting properties [v5] In-Reply-To: References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> Message-ID: On Fri, 17 Jan 2025 15:59:50 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". >> >> Update: >> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > copyrights updated This seems like overkill for a weak use case. The resulting log file is in the scratch directory so it will not be retained for long. In local builds, whoever is running the test could add the arguments. Have there been any negative interactions with any of the test tiers due to the addition of extra logging flags? test/hotspot/jtreg/TEST.ROOT line 51: > 49: requires.extraPropDefns.javacOpts = --add-exports java.base/jdk.internal.foreign=ALL-UNNAMED > 50: requires.extraPropDefns.vmOpts = \ > 51: -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:-DisplayVMOutput -XX:LogFile=vmprops.flags.final.vm.log \ The -XX:+UnlockDiagnosticVMOptions is repeated, that shouldn't be necessary. (in either TEST.ROOT) ------------- PR Review: https://git.openjdk.org/jdk/pull/23054#pullrequestreview-2559549496 PR Review Comment: https://git.openjdk.org/jdk/pull/23054#discussion_r1920505779 From joe.darcy at oracle.com Fri Jan 17 17:30:40 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 17 Jan 2025 09:30:40 -0800 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> Message-ID: <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> On 1/16/2025 11:26 PM, Rafael Winterhalter wrote: > Would it even be possible to change the return types of Set.of(...) > and Map.of(...) without breaking binary compatibility? In short, no. The methods in question are *static* methods. Switching to covariant overrides with more precise return types works for subclasses because of bridge methods. In a bit more detail, in a covariant override a single method in the source code gets translated into multiply methods in the class file. References to methods in the class file use the argument types and return type so if an old class file refers to the previously declared source-level return type, there is the bridge method present to be linked to (for binary compatibility) and then executed. -Joe > > I also think that the randomization of Set.of(...) and Map.of(...) is > a good property as it uncovers bugs early if one relies on iteration > order. This especially since those methods are often used in tests > where production code would use a proper HashSet which cannot > guarantee iteration order for good reasons. Exactly here I think the > new interfaces are a good addition as it uncovers such misconceptions. > If code relies on insertion order, providing a Set.of(...) does no > longer compile, what is a good thing. > > To me, adding SequencedSet.of(...) and SequencedMap.of(...) sounds > like the right approach, with implementations similar to that of > Set.of(...) and Map.of(...). As for megamorphism, I think the chance > of encounter at a call site is similar, as Set12 and SetN from the Set > interface are typically combined with HashMap. As for a possible > SequencedSet12 and SequencedSetN, I think they would normally be seen > with LinkedHashSet. > > Best regards, Rafael > > Am Fr., 17. Jan. 2025 um 00:36?Uhr schrieb David Alayachew > : > > I should also add, the documentation went out of their way to > specify that iteration order is unspecified. > > Also, I see R?mi's comment, but that's even more unconvincing to me. > > Map.of has an upper limit of 10 entries, and Map.ofEntries has an > upper limit of that Java max file size limit thing. You all know > what I am talking about. > > Point is, both of these static factories were meant to be used on > a small number of entries. If it truly has just been not done > until now, then the bug database will confirm that easily. > > When I get back, I can check myself. > > > On Thu, Jan 16, 2025, 6:25?PM David Alayachew > wrote: > > I guess let me ask the obvious question. > > Chesterton's fence -- why wasn't this done before? I refuse to > believe that this idea wasn't thought up years ago, which > leads me to believe there was a reason that it hasn't been done. > > Is there any way we can look this up in the bug database or > something? > > > On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m > wrote: > > Having the result Map.of and Set.of preserve the insertion > order would > often be convenient. > > More often than not programs iterate over the contents of > a maps and > sets at some point. For example to present the values in a > GUI, for > serialisation, or even for error printouts. In all those > cases having a > fixed iteration order is much better than having a random > iteration > order. > > Often it is even a subtle bug to have a random iteration > order. For > example, I ran in to a situation where jdeps printed a > error message > containing a list of modules. But the list was in a > different order on > each run of the program! It took me a while to figure out > that it was > actually the same list. A possible explanation is that > jdeps is > implemented using Map.of or Set.of. > > Because of this I think I would be better if the most > commonly used > standard collection factories produced collections with a > fixed > iteration order. > > Guavas ImmutableMap and ImmutableSet also preserve > insertion order. > > Regards, > Jens Lidestr?m > > > On 2025-01-16 08:44, Remi Forax wrote: > > > ------------------------- > > > >> From: "Rafael Winterhalter" > >> To: "core-libs-dev" > >> Sent: Thursday, January 16, 2025 8:13:17 AM > >> Subject: Factory methods for SequencedSet and SequencedMap > > > >> Hello, > > > > Hello, > > > >> I am happily taking SequencedSet and SequencedMap into > use, but one > >> inconvenience I encounter is the lack of factory > methods for the two. > >> In code where many (initial) collections have zero or > one element (for > >> later aggregation), I now write Set.of()/Set.of(one) and > >> Map.of()/Map.of(key, value), as it makes the code > shorter and more > >> readable. Those collections are of course implicitly > sequenced, but > >> now I must make the variable type of the surrounding > monad Set and > >> Map, and simply assume that a LinkedHashSet or > LinkedHashMap is used > >> when a collection of more than one element is set, > without requiring > >> the interface type. This does not require any type > casting, as I rely > >> on the iteration order only, but the code loses some of > its > >> expressiveness. > >> I did not find any discussion around introducing > factories for > >> SequencedSet.of(...) and SequencedMap.of(...), similar > to those that > >> exist in the Set and Map interfaces. Was this ever > considered, and if > >> not, could it be? > > > > Thanks for re-starting that discussion, it was talked a > bit, but not as > > it should be. > > > > So the issue is that currently we do not have any > compact, unmodifiable > > and ordered Set/Map implementation, > > one use case is when you have data that comes from a > JSON object as a > > Map and you want to keep the inserted order, if by > example the JSON is > > a config file editable by a human, an other example is > in unit tests > > where you want to help the dev to read the output of the > test so the > > code that creates a Set/Map and what is outputed by the > test should be > > in the same order. > > Currently there is no good solution for those use cases > because > > Set|Map.copyOf() does not keep the ordering. > > > > I see two solutions, either we add a new > > SequenceSet|SequenceMap.of/copyOf, or we change the > impleemntation of > > Set|Map.of()/copyOf(). > > Python had gone for the latter solution, which has the > advantage a > > being simple from the user POV, but from an algorithm > expert POV, a Set > > and a SequencedSet are different concepts we may want to > emphasis ? > > > >> Best regards, Rafael > > > > regards, > > R?mi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From galder at openjdk.org Fri Jan 17 17:45:25 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Fri, 17 Jan 2025 17:45:25 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v10] In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: > This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. > > Currently vectorization does not kick in for loops containing either of these calls because of the following error: > > > VLoop::check_preconditions: failed: control flow in loop not allowed > > > The control flow is due to the java implementation for these methods, e.g. > > > public static long max(long a, long b) { > return (a >= b) ? a : b; > } > > > This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. > By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. > E.g. > > > SuperWord::transform_loop: > Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined > 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) > > > Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1155 > long max 1173 > > > After the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1042 > long max 1042 > > > This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. > Therefore, it still relies on the macro expansion to transform those into CMoveL. > > I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 2500 2500 0 0 >>> jtreg:test/jdk:tier1 ... Galder Zamarre?o has updated the pull request incrementally with two additional commits since the last revision: - Renaming methods and variables and add docu on algorithms - Fix copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20098/files - new: https://git.openjdk.org/jdk/pull/20098/files/abbaf875..f83d8863 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=08-09 Stats: 38 lines in 3 files changed: 25 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20098.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098 PR: https://git.openjdk.org/jdk/pull/20098 From galder at openjdk.org Fri Jan 17 17:45:25 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Fri, 17 Jan 2025 17:45:25 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: <4NGZx_gqvc7xMcXCTef2c_ns-nMxznsB42NnlQJqX4Q=.8cdc00f9-c9a7-409a-b5c3-885d0677b952@github.com> On Tue, 14 Jan 2025 08:54:34 GMT, Emanuel Peter wrote: >> @eme64 I've fixed the test issue, it's ready to be reviewed > > @galderz I ran some testing on our side, feel free to ping me in 1-2 days for the results. @eme64 I've addressed all the comments. I've not run the `VectorReduction2` for the reasons explained in the previous comment. Happy to add more details to `MinMaxVector` if you feel it's necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2598873155 From galder at openjdk.org Fri Jan 17 17:53:24 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Fri, 17 Jan 2025 17:53:24 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v11] In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: <6-Fgj-Lrd7GSpR0ZAi8YFlOZB12hCBB6p3oGZ1xodvA=.1ce2fa12-daff-4459-8fb8-1052acaf5639@github.com> > This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. > > Currently vectorization does not kick in for loops containing either of these calls because of the following error: > > > VLoop::check_preconditions: failed: control flow in loop not allowed > > > The control flow is due to the java implementation for these methods, e.g. > > > public static long max(long a, long b) { > return (a >= b) ? a : b; > } > > > This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. > By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. > E.g. > > > SuperWord::transform_loop: > Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined > 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) > > > Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1155 > long max 1173 > > > After the patch, on darwin/aarch64 (M1): > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java > 1 1 0 0 > ============================== > TEST SUCCESS > > long min 1042 > long max 1042 > > > This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. > Therefore, it still relies on the macro expansion to transform those into CMoveL. > > I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 2500 2500 0 0 >>> jtreg:test/jdk:tier1 ... Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20098/files - new: https://git.openjdk.org/jdk/pull/20098/files/f83d8863..724a346a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20098.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098 PR: https://git.openjdk.org/jdk/pull/20098 From joehw at openjdk.org Fri Jan 17 18:06:45 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 17 Jan 2025 18:06:45 GMT Subject: RFR: 8347841: Test fixes that use deprecated time zone IDs [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 00:45:54 GMT, Naoto Sato wrote: >> This fix is a follow on for [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes usages of those deprecated time zone ids in tests. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed extra spaces Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23166#pullrequestreview-2559648516 From djelinski at openjdk.org Fri Jan 17 18:14:35 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 17 Jan 2025 18:14:35 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: <0jB4Wx3MnuXgB0QVnLKel-tspOYEULw9zxaspD774LY=.9d70090e-affc-4938-9a1f-cf92b43a4243@github.com> Message-ID: On Fri, 17 Jan 2025 17:09:51 GMT, Brian Burkhalter wrote: >> No, it wouldn't cover any future Windows versions, but it would definitely buy us a few years. >> >> Regarding a more permanent solution: the test is supposed to verify the fix for [JDK-8013827](https://bugs.openjdk.org/browse/JDK-8013827). I think it should accept both outcomes (success and the specific exception); the only unacceptable outcomes are: >> - timeout, >> - unexpected exception. >> >> We don't need to know the exact Windows version to verify that the test doesn't time out. > >> I think it should accept both outcomes (success and the specific exception) > > But whether there's an exception varies by Windows version / build number. I'll take another look and see whether there is some other way. we don't care if there's an exception or not. It's not part of the spec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1920573994 From bpb at openjdk.org Fri Jan 17 18:17:39 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Jan 2025 18:17:39 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: <0jB4Wx3MnuXgB0QVnLKel-tspOYEULw9zxaspD774LY=.9d70090e-affc-4938-9a1f-cf92b43a4243@github.com> Message-ID: On Fri, 17 Jan 2025 18:12:00 GMT, Daniel Jeli?ski wrote: >>> I think it should accept both outcomes (success and the specific exception) >> >> But whether there's an exception varies by Windows version / build number. I'll take another look and see whether there is some other way. > > we don't care if there's an exception or not. It's not part of the spec. Yes, I think I'll rework this. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1920577337 From eirbjo at openjdk.org Fri Jan 17 18:19:56 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 17 Jan 2025 18:19:56 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes [v2] In-Reply-To: References: Message-ID: > Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. > > The classes were identified using an automated analysis. See CSR for details. > > Besides simply adding the `final` access modifier, the PR: > > * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. > * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` > * Updates the copyright year of affected source files Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Update copyright headers for 2025 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22389/files - new: https://git.openjdk.org/jdk/pull/22389/files/d93dcf8b..12c3e153 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22389&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22389&range=00-01 Stats: 19 lines in 19 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/22389.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22389/head:pull/22389 PR: https://git.openjdk.org/jdk/pull/22389 From eirbjo at openjdk.org Fri Jan 17 18:38:25 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 17 Jan 2025 18:38:25 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: Message-ID: > Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. > > Links in `java.security` and `share/data/tzdata` are excluded from this PR. > > This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. > > There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). > > Changes beyond the obvious are as follows: > > `linux/native/libsimdsort/xss-common-qsort.h`: > The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170 > > `share/man/keytool.1`: > www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well? > > `unix/classes/sun/net/PortConfig.java` > The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. > > `unix/native/libjava/*`, > Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs > > `unix/native/libjava/ProcessImpl_md.c` > A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to. Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into links-use-https - Re-fix link to "Oracle Java Root Certificate program" in keytool.md - Merge branch 'master' into links-use-https # Conflicts: # src/java.base/share/man/keytool.1 - Remove accidental "'" - Use Wayback link - Update copyright year - Update links in java.base to use https:// ------------- Changes: https://git.openjdk.org/jdk/pull/21633/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21633&range=02 Stats: 14 lines in 8 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/21633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21633/head:pull/21633 PR: https://git.openjdk.org/jdk/pull/21633 From lmesnik at openjdk.org Fri Jan 17 18:50:22 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Jan 2025 18:50:22 GMT Subject: RFR: 8338428: Add logging if final VM flags while setting properties [v6] In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> Message-ID: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> > Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. > > I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". > > Update: > There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated flags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23054/files - new: https://git.openjdk.org/jdk/pull/23054/files/b28439c0..5f87d72f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23054&range=04-05 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23054/head:pull/23054 PR: https://git.openjdk.org/jdk/pull/23054 From eirbjo at openjdk.org Fri Jan 17 19:08:35 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 17 Jan 2025 19:08:35 GMT Subject: RFR: 8342807: Update links in java.base to use https:// In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 19:29:43 GMT, Eirik Bj?rsn?s wrote: >> FWIW: I don't believe a change to a link in a comment in an internal class requires a CSR. >> For PortConfig.java - it would be good to have someone involved in the AIX port comment on the proposed changes. >> Removing the obsolete link altogether is also a possibility. > >> For PortConfig.java - it would be good to have someone involved in the AIX port comment on the proposed changes. Removing the obsolete link altogether is also a possibility. > > The context for the link in PortConfig.java is: > > > // The ephemeral port is OS version dependent on AIX: > // http://publib.boulder.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.rsct315.admin/bl503_ephport.htm > // However, on AIX 5.3 / 6.1 / 7.1 we always see the > // settings below by using: > // /usr/sbin/no -a | fgrep ephemeral > defaultLower = 32768; > defaultUpper = 65535; > > > So while the FAQ link I changed this to confirms the port numbers here, it probably makes the comment "The ephemeral port is OS version dependent on AIX" somewhat stale. Seems the original linked document somehow contradicted the observed settings? So if we use my suggested FAQ link, perhaps it is better to remove the surrounding comment altogether, as it seems stale. > > For `ProcessImpl_md.c`, the obsolete link was to a request for clarification to what I think may be an early version of some POSIX standard. If I'm right, the current version is https://www.iso.org/standard/50516.html, which is not publicly available (requires paid access). > > But yes, would be nice if some AIX people could have a look at this. > @eirbjo This seemed like a valuable and worthwhile contribution, and I think it is a bit sad to see it closed due to inactivity. Was it the lack of volunteering reviewers that made you let it go? Thanks for looking at this Magnus, I agree cleaning this up would be good. Although most of the link updates are trivial and safe, I think we just got stuck on the two links which were not completely clear how to update: `PortConfig.java`: This file includes a link to some legacy IBM documentation on ephemral ports on AIX which is no longer accessible. I found an IBM FAQ page which mentions ephemral port ranges and suggest this as the replacement. @dfuch suggested:"it would be good to have someone involved in the AIX port comment on the proposed changes", however this never happened. I'm not sure who to ask. We can make progress here by getting someone with AIX experience to review, or we can simply remove the link. I personally think the replacement link I found is "good enough", although I've never actually seen the current link contents. `ProcessImpl_md.c`: This file includes a link to `www.pasc.org` for an unofficial interpretation of an early POSIX standard. This document now requires authentication. The PR currently links to a Wayback page, but maybe we should should rather remove this link altogether since it was always considered "unofficial" and the interpretation in question has long been baked into the standard. So based on the above, my "call to action" for this PR in the current state is: a) Find out who we can invite with AIX experience to look at the updates to `PortConfig.java` b) If that fails, I'll remove the link and ask for a review of that c) I would like feedback on the proposal to remove the link to the www.pasc.org "unofficial" interpretation document in `ProcessImpl_mc.c` Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2599018576 From lmesnik at openjdk.org Fri Jan 17 19:17:36 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 17 Jan 2025 19:17:36 GMT Subject: RFR: 8338428: Add logging if final VM flags while setting properties [v5] In-Reply-To: References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> Message-ID: On Fri, 17 Jan 2025 17:27:32 GMT, Roger Riggs wrote: > This seems like overkill for a weak use case. > > The resulting log file is in the scratch directory so it will not be retained for long. In local builds, whoever is running the test could add the arguments. Thanks for your feedback. Currently, typical size of artifacts for *passed* run take a tens of MB, so it is less then 0.5% increase. The main consumer are .jtr files. > > Have there been any negative interactions with any of the test tiers due to the addition of extra logging flags? Which negative interactions you suppose? This fix shouldn't interfere with executed tests completely. The only restriction is that we shouldn't use added XX:+LogVMOutput -XX:-DisplayVMOutput -XX:LogFile in VMProps to calclulate their final values. However, they are not used in \requires` at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2599032748 From bpb at openjdk.org Fri Jan 17 20:00:16 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Jan 2025 20:00:16 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v4] In-Reply-To: References: Message-ID: > Fix the means of determining whether an exception is to be expected in the Windows test. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8347740: Remove Windows version check and ignore IOException thrown by File.createTempFile ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23117/files - new: https://git.openjdk.org/jdk/pull/23117/files/f6e7cfa8..51336af4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=02-03 Stats: 53 lines in 1 file changed: 11 ins; 31 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/23117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23117/head:pull/23117 PR: https://git.openjdk.org/jdk/pull/23117 From bpb at openjdk.org Fri Jan 17 20:02:38 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Jan 2025 20:02:38 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v3] In-Reply-To: References: <0jB4Wx3MnuXgB0QVnLKel-tspOYEULw9zxaspD774LY=.9d70090e-affc-4938-9a1f-cf92b43a4243@github.com> Message-ID: <2bu5REYjuEBk4tpTWsmtV4n190CF6s58w6KH7v8WF-g=.95c7f620-7965-4f13-9b35-3f01a3155838@github.com> On Fri, 17 Jan 2025 18:15:17 GMT, Brian Burkhalter wrote: >> we don't care if there's an exception or not. It's not part of the spec. > > Yes, I think I'll rework this. Thanks. The build number could be obtained from the value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CurrentBuildNumber but it seems not to be worth the trouble. In 51336af I instead changed the test of reserved names on Windows to ignore any `IOException` thrown by `File.createTempFile`. The change was verified on the aforementioned Windows variants and on Linux and macOS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1920681659 From weijun at openjdk.org Fri Jan 17 20:05:38 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 17 Jan 2025 20:05:38 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes [v2] In-Reply-To: References: Message-ID: <3_SAo71Dt1lxEL32D0GqZyLdm6aQjgk46bCJMIIgO84=.b9a6acd6-ae8c-485b-8145-e09eb594cf1d@github.com> On Fri, 17 Jan 2025 18:19:56 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. >> >> The classes were identified using an automated analysis. See CSR for details. >> >> Besides simply adding the `final` access modifier, the PR: >> >> * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. >> * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` >> * Updates the copyright year of affected source files > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright headers for 2025 Marked as reviewed by weijun (Reviewer). The `DRBGParameters` change looks good. It?s a utility class with static methods and a private constructor, so any attempt to extend it should result in a compile-time error. ------------- PR Review: https://git.openjdk.org/jdk/pull/22389#pullrequestreview-2559870005 PR Comment: https://git.openjdk.org/jdk/pull/22389#issuecomment-2599101417 From djelinski at openjdk.org Fri Jan 17 20:20:39 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 17 Jan 2025 20:20:39 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v4] In-Reply-To: References: Message-ID: <2oC2wEyLE3mDQh1l6NTtkPZLi4whxHzChk02cMWmXT8=.88fba174-b627-43a2-90c5-763a9aca20a4@github.com> On Fri, 17 Jan 2025 20:00:16 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the Windows test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8347740: Remove Windows version check and ignore IOException thrown by File.createTempFile This looks reasonable to me. test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 42: > 40: > 41: public class SpecialTempFile { > 42: private static final int WINDOWS_11_MINIMUM_BUILD = 22000; this is no longer used ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23117#pullrequestreview-2559883945 PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1920691888 From bpb at openjdk.org Fri Jan 17 20:27:54 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Jan 2025 20:27:54 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v5] In-Reply-To: References: Message-ID: > Fix the means of determining whether an exception is to be expected in the Windows test. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8347740: Remove vestigial constant WINDOWS_11_MINIMUM_BUILD ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23117/files - new: https://git.openjdk.org/jdk/pull/23117/files/51336af4..3eea3899 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23117&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23117/head:pull/23117 PR: https://git.openjdk.org/jdk/pull/23117 From bpb at openjdk.org Fri Jan 17 20:27:55 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Jan 2025 20:27:55 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v4] In-Reply-To: <2oC2wEyLE3mDQh1l6NTtkPZLi4whxHzChk02cMWmXT8=.88fba174-b627-43a2-90c5-763a9aca20a4@github.com> References: <2oC2wEyLE3mDQh1l6NTtkPZLi4whxHzChk02cMWmXT8=.88fba174-b627-43a2-90c5-763a9aca20a4@github.com> Message-ID: On Fri, 17 Jan 2025 20:12:43 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8347740: Remove Windows version check and ignore IOException thrown by File.createTempFile > > test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 42: > >> 40: >> 41: public class SpecialTempFile { >> 42: private static final int WINDOWS_11_MINIMUM_BUILD = 22000; > > this is no longer used Removed in 3eea389. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23117#discussion_r1920701106 From bpb at openjdk.org Fri Jan 17 21:05:37 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 17 Jan 2025 21:05:37 GMT Subject: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 00:36:44 GMT, Brian Burkhalter wrote: > Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class. continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2599206123 From naoto at openjdk.org Fri Jan 17 22:14:35 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Jan 2025 22:14:35 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v2] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: On Thu, 16 Jan 2025 22:39:52 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > synchronize init method over block Looks good. src/java.base/share/classes/java/util/Currency.java line 467: > 465: private static synchronized void initAvailableCurrencies() { > 466: if (available == null) { > 467: available = new HashSet<>(256); Not related to your change, but this should be `HashSet.newHashSet(256)`. In fact 256*0.75 is 192, which is smaller than the current number of currencies (230, as of JDK24) ------------- PR Review: https://git.openjdk.org/jdk/pull/23165#pullrequestreview-2560069311 PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1920818979 From jlu at openjdk.org Fri Jan 17 22:34:45 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 22:34:45 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update Message-ID: Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. Once this pull request is integrated, it will be back-ported to the jdk24 branch. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/23184/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23184&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347498 Stats: 93 lines in 26 files changed: 33 ins; 15 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/23184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23184/head:pull/23184 PR: https://git.openjdk.org/jdk/pull/23184 From jlu at openjdk.org Fri Jan 17 22:39:14 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 22:39:14 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v3] In-Reply-To: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: > Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. > > The motivation can be found in the CSR. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: init hashset w/ accurate size via HashSet.newHashSet(int) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23165/files - new: https://git.openjdk.org/jdk/pull/23165/files/bf705a2d..c94ba944 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165 PR: https://git.openjdk.org/jdk/pull/23165 From jlu at openjdk.org Fri Jan 17 22:39:14 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 22:39:14 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v2] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: <78a0SJk9B3pH5UeoKnWgxbdFmbNDbH4WocepYWAvxwg=.4ef4d116-fb04-42a7-af93-dbc14a0e0b2e@github.com> On Fri, 17 Jan 2025 22:11:51 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> synchronize init method over block > > src/java.base/share/classes/java/util/Currency.java line 467: > >> 465: private static synchronized void initAvailableCurrencies() { >> 466: if (available == null) { >> 467: available = new HashSet<>(256); > > Not related to your change, but this should be `HashSet.newHashSet(256)`. In fact 256*0.75 is 192, which is smaller than the current number of currencies (230, as of JDK24) Fixed in https://github.com/openjdk/jdk/pull/23165/commits/c94ba9447cf3d24ba6e4162890a9be5d611dbfa7 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1920836146 From dnguyen at openjdk.org Fri Jan 17 22:41:36 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 17 Jan 2025 22:41:36 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 80: > 78: err.no.module.path=--module-path-Option muss mit --add-modules ALL-MODULE-PATH angegeben werden > 79: err.empty.module.path=Kein Modul im Modulpfad "{0}" mit --add-modules ALL-MODULE-PATH gefunden > 80: err.limit.modules=--limit-modules nicht mit --add-modules ALL-MODULE-PATH zul?ssig I see German has more being changed when compared to Japanese & Chinese. Are these updated translations for German specifically? I see no related change for the other 2 languages for say `err.runtime.link.not.linkable.runtime`. src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 60: > 58: main.opt.target-platform.arg=target-platform > 59: main.opt.module-path=Modulpfad > 60: main.opt.hash-modules=Berechnet und erfasst Hashes zur Bindung eines verpackten Moduls an Module, die dem angegebenen entsprechen und direkt oder indirekt davon abh?ngen. Die Hashes werden in der erstellten JMOD-Datei oder in einer JMOD- oder modularen JAR-Datei in dem Modulpfad erfasst, der im jmod-Hashbefehl angegeben ist. I assume this is more evidence that the German differences are just updated translations for German? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920837067 PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920837417 From jlu at openjdk.org Fri Jan 17 22:44:36 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 22:44:36 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:37:35 GMT, Damon Nguyen wrote: >> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. >> >> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. >> >> Once this pull request is integrated, it will be back-ported to the jdk24 branch. > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 80: > >> 78: err.no.module.path=--module-path-Option muss mit --add-modules ALL-MODULE-PATH angegeben werden >> 79: err.empty.module.path=Kein Modul im Modulpfad "{0}" mit --add-modules ALL-MODULE-PATH gefunden >> 80: err.limit.modules=--limit-modules nicht mit --add-modules ALL-MODULE-PATH zul?ssig > > I see German has more being changed when compared to Japanese & Chinese. Are these updated translations for German specifically? I see no related change for the other 2 languages for say `err.runtime.link.not.linkable.runtime`. Yes, see the other comment. > src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 60: > >> 58: main.opt.target-platform.arg=target-platform >> 59: main.opt.module-path=Modulpfad >> 60: main.opt.hash-modules=Berechnet und erfasst Hashes zur Bindung eines verpackten Moduls an Module, die dem angegebenen entsprechen und direkt oder indirekt davon abh?ngen. Die Hashes werden in der erstellten JMOD-Datei oder in einer JMOD- oder modularen JAR-Datei in dem Modulpfad erfasst, der im jmod-Hashbefehl angegeben ist. > > I assume this is more evidence that the German differences are just updated translations for German? Yes, there were standalone German translation updates. Some were also reverts to fixes we made last time for German translations specifically, as they were rejected by the translation team. In any case, I think it is probably best not to deviate from their translations unless they are incorrect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920839939 PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920839823 From dnguyen at openjdk.org Fri Jan 17 22:56:36 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 17 Jan 2025 22:56:36 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. File changes LGTM. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2560114901 From dnguyen at openjdk.org Fri Jan 17 22:56:37 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 17 Jan 2025 22:56:37 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:42:05 GMT, Justin Lu wrote: >> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 60: >> >>> 58: main.opt.target-platform.arg=target-platform >>> 59: main.opt.module-path=Modulpfad >>> 60: main.opt.hash-modules=Berechnet und erfasst Hashes zur Bindung eines verpackten Moduls an Module, die dem angegebenen entsprechen und direkt oder indirekt davon abh?ngen. Die Hashes werden in der erstellten JMOD-Datei oder in einer JMOD- oder modularen JAR-Datei in dem Modulpfad erfasst, der im jmod-Hashbefehl angegeben ist. >> >> I assume this is more evidence that the German differences are just updated translations for German? > > Yes, there were standalone German translation updates. Some were also reverts to fixes we made last time for German translations specifically, as they were rejected by the translation team. In any case, I think it is probably best not to deviate from their translations unless they are incorrect. Makes sense. I agree then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1920847170 From rriggs at openjdk.org Fri Jan 17 22:57:36 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 17 Jan 2025 22:57:36 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v3] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: On Fri, 17 Jan 2025 22:39:14 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > init hashset w/ accurate size via HashSet.newHashSet(int) src/java.base/share/classes/java/util/Currency.java line 439: > 437: * contains all the available currencies, which may include currencies > 438: * that represent obsolete ISO 4217 codes. If there is no currency available > 439: * in the runtime, the returned set is empty. The set can be modified An apiNote might be appropriate to refer/recommend using the new `availableCurrencies()` API. And/or an @see link to the method. src/java.base/share/classes/java/util/Currency.java line 456: > 454: * > 455: * @implNote Unlike {@link #getAvailableCurrencies()}, this method does > 456: * not create a defensive copy of the {@code Currency} set. An @see link to `getAvailableCurrencies` might be useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1920844677 PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1920846876 From naoto at openjdk.org Fri Jan 17 23:08:35 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Jan 2025 23:08:35 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. Should the copyright years be 2025, unless they were *published* in 2024? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2599351096 From jlu at openjdk.org Fri Jan 17 23:10:54 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 23:10:54 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v4] In-Reply-To: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: > Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. > > The motivation can be found in the CSR. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect Roger's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23165/files - new: https://git.openjdk.org/jdk/pull/23165/files/c94ba944..dcb4a9bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=02-03 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165 PR: https://git.openjdk.org/jdk/pull/23165 From jlu at openjdk.org Fri Jan 17 23:10:55 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 23:10:55 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v3] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: On Fri, 17 Jan 2025 22:49:07 GMT, Roger Riggs wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> init hashset w/ accurate size via HashSet.newHashSet(int) > > src/java.base/share/classes/java/util/Currency.java line 439: > >> 437: * contains all the available currencies, which may include currencies >> 438: * that represent obsolete ISO 4217 codes. If there is no currency available >> 439: * in the runtime, the returned set is empty. The set can be modified > > An apiNote might be appropriate to refer/recommend using the new `availableCurrencies()` API. > And/or an @see link to the method. Thanks Roger, incorporated both your suggestions in https://github.com/openjdk/jdk/pull/23165/commits/dcb4a9bfea1002044483aea483af8e6107eb525d. Note, I intentionally did not add any wording regarding the defensive copy in the `apiNote`, considering that is an implementation specific caveat. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1920856865 From rriggs at openjdk.org Fri Jan 17 23:11:37 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 17 Jan 2025 23:11:37 GMT Subject: RFR: 8338428: Add logging if final VM flags while setting properties [v6] In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> Message-ID: On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". >> >> Update: >> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated flags I don't see when these new flags come into use. I built the PR and ran tests through make and did not see the flags (PrintFinalFlags) used when running the tests in the resulting jtr files. (I ran a subset of both jdk and hotspot/jtreg tests.) Is there an examine test showing the flags working? Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2599353392 From vaivanov at openjdk.org Fri Jan 17 23:13:10 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 17 Jan 2025 23:13:10 GMT Subject: RFR: 8346230: [perf] scalability issue for the specjvm2008::xml.transform workload Message-ID: The synchronized scope was reduced from whole methods to sections that need hash map access control. The tier1 and jaxp tests are OK. The score of the specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported scores are: original: 1vCPU - 148.4, 112vCPU - 12743.4, 224vCPU - 13481.31 ops/m patched: 1vCPU - 149.77, 112vCPU - 13122.82, 224vCPU - 14751.57 ops/m According to the JFR the locking time for XMLReader object reduced from ~27sec to ~20sec for 224vCPU run. ------------- Commit messages: - 8346230 [perf] scalability issue for the specjvm2008::xml.transform workload Changes: https://git.openjdk.org/jdk/pull/23185/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346230 Stats: 46 lines in 1 file changed: 18 ins; 10 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/23185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23185/head:pull/23185 PR: https://git.openjdk.org/jdk/pull/23185 From jlu at openjdk.org Fri Jan 17 23:21:35 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 23:21:35 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: <3jNTKD4ifvL8RtWl-nr2Jl_QjSv4ohkQnjf2MMo-M-w=.832c9b8f-0fe4-4851-96ce-89e979f228b4@github.com> On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. > Should the copyright years be 2025, unless they were _published_ in 2024? I noticed that too. Those copyrights are automatically updated by the translation team. Since the English changes were made in 2024, it seems reasonable that the corresponding l10n changes also have a copyright year of 2024. Conceptually I'm treating it like a backport, where the copyright year should reflect the year of the original change, not the current year. But these are different cases of course, please let me know if I should change it to 2025, I am not fully sure in this scenario. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2599361579 From dnguyen at openjdk.org Fri Jan 17 23:21:35 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 17 Jan 2025 23:21:35 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: <3jNTKD4ifvL8RtWl-nr2Jl_QjSv4ohkQnjf2MMo-M-w=.832c9b8f-0fe4-4851-96ce-89e979f228b4@github.com> References: <3jNTKD4ifvL8RtWl-nr2Jl_QjSv4ohkQnjf2MMo-M-w=.832c9b8f-0fe4-4851-96ce-89e979f228b4@github.com> Message-ID: On Fri, 17 Jan 2025 23:18:43 GMT, Justin Lu wrote: > Should the copyright years be 2025, unless they were _published_ in 2024? I saw the same but forgot to mention it after looking up the original files to compare to German. I'm also not sure if this should be 2024 vs 2025. I'd assume 2024 since most of the files say "edited on Dec 2024", but not sure if it's based on the original file's date or this translated file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2599361641 From rriggs at openjdk.org Fri Jan 17 23:27:36 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 17 Jan 2025 23:27:36 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v4] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: On Fri, 17 Jan 2025 23:10:54 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect Roger's review test/jdk/java/util/Currency/AvailableCurrenciesTest.java line 44: > 42: public void streamEqualsSetTest() { > 43: var currencies = Currency.getAvailableCurrencies(); > 44: assertEquals(currencies, Currency.availableCurrencies().collect(Collectors.toSet())); Generally, a message describing the failure is more useful than just a stacktrace. (the 3rd arg on assertEquals override.) It avoids needing to find the source code to create the bug report. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1920868545 From jlu at openjdk.org Fri Jan 17 23:33:50 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 17 Jan 2025 23:33:50 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> > Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. > > The motivation can be found in the CSR. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: provide message for test assertion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23165/files - new: https://git.openjdk.org/jdk/pull/23165/files/dcb4a9bf..46dcf78e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165 PR: https://git.openjdk.org/jdk/pull/23165 From naoto at openjdk.org Fri Jan 17 23:55:37 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 17 Jan 2025 23:55:37 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. IANAL, but my understanding is that it reflects the year the last change was open to the public. It does not seem to matter from copyright point if the file is a translation of English one or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2599385743 From lmesnik at openjdk.org Sat Jan 18 00:44:36 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 18 Jan 2025 00:44:36 GMT Subject: RFR: 8338428: Add logging if final VM flags while setting properties [v6] In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> Message-ID: On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". >> >> Update: >> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated flags This flag is not used while tests are executed. It is used only when jtreg run VMProps, executed before all tests are run and you can find result in scratch directory. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2599422465 From davidalayachew at gmail.com Sat Jan 18 01:00:54 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 17 Jan 2025 20:00:54 -0500 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> Message-ID: Thanks for the corrections folks. I was thinking from the perspective of LSP. I now see that there is the performance perspective to consider too. Now that said, I don't understand your comment Joe Darcy. Could you explain it in more detail? My initial pick up of your comment is that, the parameter types and the return types of a method must match the types exactly between releases, otherwise there are no bridge methods FOR STATIC TYPES. But as for why, I don't understand. I know that static methods are not so much inherited as they are just given as is (hence why there is not really a static abstract method). But I don't quite see the line connecting that with no bridge methods for static. Maybe I don't understand bridge methods well enough. On Fri, Jan 17, 2025, 12:32?PM Joseph D. Darcy wrote: > On 1/16/2025 11:26 PM, Rafael Winterhalter wrote: > > > Would it even be possible to change the return types of Set.of(...) and > Map.of(...) without breaking binary compatibility? > > > In short, no. > > The methods in question are *static* methods. Switching to covariant > overrides with more precise return types works for subclasses because of > bridge methods. > > In a bit more detail, in a covariant override a single method in the > source code gets translated into multiply methods in the class file. > References to methods in the class file use the argument types and return > type so if an old class file refers to the previously declared source-level > return type, there is the bridge method present to be linked to (for binary > compatibility) and then executed. > > -Joe > > > > I also think that the randomization of Set.of(...) and Map.of(...) is a > good property as it uncovers bugs early if one relies on iteration order. > This especially since those methods are often used in tests where > production code would use a proper HashSet which cannot guarantee iteration > order for good reasons. Exactly here I think the new interfaces are a good > addition as it uncovers such misconceptions. If code relies on insertion > order, providing a Set.of(...) does no longer compile, what is a good thing. > > To me, adding SequencedSet.of(...) and SequencedMap.of(...) sounds like > the right approach, with implementations similar to that of Set.of(...) and > Map.of(...). As for megamorphism, I think the chance of encounter at a call > site is similar, as Set12 and SetN from the Set interface are typically > combined with HashMap. As for a possible SequencedSet12 and SequencedSetN, > I think they would normally be seen with LinkedHashSet. > > Best regards, Rafael > > Am Fr., 17. Jan. 2025 um 00:36 Uhr schrieb David Alayachew < > davidalayachew at gmail.com>: > >> I should also add, the documentation went out of their way to specify >> that iteration order is unspecified. >> >> Also, I see R?mi's comment, but that's even more unconvincing to me. >> >> Map.of has an upper limit of 10 entries, and Map.ofEntries has an upper >> limit of that Java max file size limit thing. You all know what I am >> talking about. >> >> Point is, both of these static factories were meant to be used on a small >> number of entries. If it truly has just been not done until now, then the >> bug database will confirm that easily. >> >> When I get back, I can check myself. >> >> On Thu, Jan 16, 2025, 6:25?PM David Alayachew >> wrote: >> >>> I guess let me ask the obvious question. >>> >>> Chesterton's fence -- why wasn't this done before? I refuse to believe >>> that this idea wasn't thought up years ago, which leads me to believe there >>> was a reason that it hasn't been done. >>> >>> Is there any way we can look this up in the bug database or something? >>> >>> On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m wrote: >>> >>>> Having the result Map.of and Set.of preserve the insertion order would >>>> often be convenient. >>>> >>>> More often than not programs iterate over the contents of a maps and >>>> sets at some point. For example to present the values in a GUI, for >>>> serialisation, or even for error printouts. In all those cases having a >>>> fixed iteration order is much better than having a random iteration >>>> order. >>>> >>>> Often it is even a subtle bug to have a random iteration order. For >>>> example, I ran in to a situation where jdeps printed a error message >>>> containing a list of modules. But the list was in a different order on >>>> each run of the program! It took me a while to figure out that it was >>>> actually the same list. A possible explanation is that jdeps is >>>> implemented using Map.of or Set.of. >>>> >>>> Because of this I think I would be better if the most commonly used >>>> standard collection factories produced collections with a fixed >>>> iteration order. >>>> >>>> Guavas ImmutableMap and ImmutableSet also preserve insertion order. >>>> >>>> Regards, >>>> Jens Lidestr?m >>>> >>>> >>>> On 2025-01-16 08:44, Remi Forax wrote: >>>> >>>> > ------------------------- >>>> > >>>> >> From: "Rafael Winterhalter" >>>> >> To: "core-libs-dev" >>>> >> Sent: Thursday, January 16, 2025 8:13:17 AM >>>> >> Subject: Factory methods for SequencedSet and SequencedMap >>>> > >>>> >> Hello, >>>> > >>>> > Hello, >>>> > >>>> >> I am happily taking SequencedSet and SequencedMap into use, but one >>>> >> inconvenience I encounter is the lack of factory methods for the two. >>>> >> In code where many (initial) collections have zero or one element >>>> (for >>>> >> later aggregation), I now write Set.of()/Set.of(one) and >>>> >> Map.of()/Map.of(key, value), as it makes the code shorter and more >>>> >> readable. Those collections are of course implicitly sequenced, but >>>> >> now I must make the variable type of the surrounding monad Set and >>>> >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is used >>>> >> when a collection of more than one element is set, without requiring >>>> >> the interface type. This does not require any type casting, as I >>>> rely >>>> >> on the iteration order only, but the code loses some of its >>>> >> expressiveness. >>>> >> I did not find any discussion around introducing factories for >>>> >> SequencedSet.of(...) and SequencedMap.of(...), similar to those that >>>> >> exist in the Set and Map interfaces. Was this ever considered, and >>>> if >>>> >> not, could it be? >>>> > >>>> > Thanks for re-starting that discussion, it was talked a bit, but not >>>> as >>>> > it should be. >>>> > >>>> > So the issue is that currently we do not have any compact, >>>> unmodifiable >>>> > and ordered Set/Map implementation, >>>> > one use case is when you have data that comes from a JSON object as a >>>> > Map and you want to keep the inserted order, if by example the JSON >>>> is >>>> > a config file editable by a human, an other example is in unit tests >>>> > where you want to help the dev to read the output of the test so the >>>> > code that creates a Set/Map and what is outputed by the test should >>>> be >>>> > in the same order. >>>> > Currently there is no good solution for those use cases because >>>> > Set|Map.copyOf() does not keep the ordering. >>>> > >>>> > I see two solutions, either we add a new >>>> > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation of >>>> > Set|Map.of()/copyOf(). >>>> > Python had gone for the latter solution, which has the advantage a >>>> > being simple from the user POV, but from an algorithm expert POV, a >>>> Set >>>> > and a SequencedSet are different concepts we may want to emphasis ? >>>> > >>>> >> Best regards, Rafael >>>> > >>>> > regards, >>>> > R?mi >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sat Jan 18 01:02:00 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 18 Jan 2025 01:02:00 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v8] In-Reply-To: References: Message-ID: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22023/files - new: https://git.openjdk.org/jdk/pull/22023/files/14499590..3e23ab6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=06-07 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023 PR: https://git.openjdk.org/jdk/pull/22023 From swen at openjdk.org Sat Jan 18 01:02:00 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 18 Jan 2025 01:02:00 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v6] In-Reply-To: References: <0FIbRT8u5KnjNE8o4tsd44q5wC0wYrYbcRkEDps5EnY=.7bded3d2-1a7f-4879-b0f7-b06a90b587e7@github.com> <0s3sQ_sngeHasBQNMmGWjxNeFEugQFGKBVFdxTEuZ2I=.77553eb4-3f45-4bd3-87bb-829185368e2e@github.com> Message-ID: On Fri, 17 Jan 2025 15:29:32 GMT, Raffaello Giulietti wrote: >> fixed it > > Sorry, I was just reading the comment and not how DIGITS is initialized and used. > > The _correct_ comment should be something like > > * 97 -> '9' | ('7' << 8) -> 0x3739 > > so the `short` value was correct before, but not the expression to construct it. > Again, sorry for the confusion. It was my mistake. I made the change without checking it carefully. It has been fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1920913558 From joe.darcy at oracle.com Sat Jan 18 01:14:32 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 17 Jan 2025 17:14:32 -0800 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> Message-ID: On 1/17/2025 5:00 PM, David Alayachew wrote: > > Thanks for the corrections folks. I was thinking from the perspective > of LSP. I now see that there is the performance perspective to > consider too. > > Now that said, I don't understand your comment Joe Darcy. Could you > explain it in more detail? > Say you compile your code against JDK 24 and use the 1-argument Set.Of() method. For that call site, your class file will refer to a method using information akin to ??? "In the class java.util.Set, a method named "of" that *returns a java.util.Set* and take a java.lang.Object as an argument" (The generic information is basically erased in the class file, hence Set rather than Set and Object rather than E.) If we were then in JDK 25 to replace in java.util.Set ??? static Set of(E e1){...} with ??? static SequencedSet of(E e1){...} when your class file ran against JDK 25, there would be no method ??? "In the class java.util.Set, a method named "of" that *returns a java.util.Set* and take a java.lang.Object as an argument" for your class to call and the linkage would fail. For static methods, the change is equivalent to removing a method and adding back a different, same-named method. HTH, -Joe > My initial pick up of your comment is that, the parameter types and > the return types of a method must match the types exactly between > releases, otherwise there are no bridge methods FOR STATIC TYPES. But > as for why, I don't understand. > > I know that static methods are not so much inherited as they are just > given as is (hence why there is not really a static abstract method). > But I don't quite see the line connecting that with no bridge methods > for static. Maybe I don't understand bridge methods well enough. > > > On Fri, Jan 17, 2025, 12:32?PM Joseph D. Darcy > wrote: > > On 1/16/2025 11:26 PM, Rafael Winterhalter wrote: >> Would it even be possible to change the return types of >> Set.of(...) and Map.of(...) without breaking binary compatibility? > > > In short, no. > > The methods in question are *static* methods. Switching to > covariant overrides with more precise return types works for > subclasses because of bridge methods. > > In a bit more detail, in a covariant override a single method in > the source code gets translated into multiply methods in the class > file. References to methods in the class file use the argument > types and return type so if an old class file refers to the > previously declared source-level return type, there is the bridge > method present to be linked to (for binary compatibility) and then > executed. > > -Joe > > >> >> I also think that the randomization of Set.of(...) and >> Map.of(...) is a good property as it uncovers bugs early if one >> relies on iteration order. This especially since those methods >> are often used in tests where production code would use a proper >> HashSet which cannot guarantee iteration order for good reasons. >> Exactly here I think the new interfaces are a good addition as it >> uncovers such misconceptions. If code relies on insertion order, >> providing a Set.of(...) does no longer compile, what is a good thing. >> >> To me, adding SequencedSet.of(...) and SequencedMap.of(...) >> sounds like the right approach, with implementations similar to >> that of Set.of(...) and Map.of(...). As for megamorphism, I think >> the chance of encounter at a call site is similar, as Set12 and >> SetN from the Set interface are typically combined with HashMap. >> As for a possible SequencedSet12 and SequencedSetN, I think they >> would normally be seen with LinkedHashSet. >> >> Best regards, Rafael >> >> Am Fr., 17. Jan. 2025 um 00:36?Uhr schrieb David Alayachew >> : >> >> I should also add, the documentation went out of their way to >> specify that iteration order is unspecified. >> >> Also, I see R?mi's comment, but that's even more unconvincing >> to me. >> >> Map.of has an upper limit of 10 entries, and Map.ofEntries >> has an upper limit of that Java max file size limit thing. >> You all know what I am talking about. >> >> Point is, both of these static factories were meant to be >> used on a small number of entries. If it truly has just been >> not done until now, then the bug database will confirm that >> easily. >> >> When I get back, I can check myself. >> >> >> On Thu, Jan 16, 2025, 6:25?PM David Alayachew >> wrote: >> >> I guess let me ask the obvious question. >> >> Chesterton's fence -- why wasn't this done before? I >> refuse to believe that this idea wasn't thought up years >> ago, which leads me to believe there was a reason that it >> hasn't been done. >> >> Is there any way we can look this up in the bug database >> or something? >> >> >> On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m >> wrote: >> >> Having the result Map.of and Set.of preserve the >> insertion order would >> often be convenient. >> >> More often than not programs iterate over the >> contents of a maps and >> sets at some point. For example to present the values >> in a GUI, for >> serialisation, or even for error printouts. In all >> those cases having a >> fixed iteration order is much better than having a >> random iteration >> order. >> >> Often it is even a subtle bug to have a random >> iteration order. For >> example, I ran in to a situation where jdeps printed >> a error message >> containing a list of modules. But the list was in a >> different order on >> each run of the program! It took me a while to figure >> out that it was >> actually the same list. A possible explanation is >> that jdeps is >> implemented using Map.of or Set.of. >> >> Because of this I think I would be better if the most >> commonly used >> standard collection factories produced collections >> with a fixed >> iteration order. >> >> Guavas ImmutableMap and ImmutableSet also preserve >> insertion order. >> >> Regards, >> Jens Lidestr?m >> >> >> On 2025-01-16 08:44, Remi Forax wrote: >> >> > ------------------------- >> > >> >> From: "Rafael Winterhalter" >> >> To: "core-libs-dev" >> >> Sent: Thursday, January 16, 2025 8:13:17 AM >> >> Subject: Factory methods for SequencedSet and >> SequencedMap >> > >> >> Hello, >> > >> > Hello, >> > >> >> I am happily taking SequencedSet and SequencedMap >> into use, but one >> >> inconvenience I encounter is the lack of factory >> methods for the two. >> >> In code where many (initial) collections have zero >> or one element (for >> >> later aggregation), I now write >> Set.of()/Set.of(one) and >> >> Map.of()/Map.of(key, value), as it makes the code >> shorter and more >> >> readable. Those collections are of course >> implicitly sequenced, but >> >> now I must make the variable type of the >> surrounding monad Set and >> >> Map, and simply assume that a LinkedHashSet or >> LinkedHashMap is used >> >> when a collection of more than one element is set, >> without requiring >> >> the interface type. This does not require any type >> casting, as I rely >> >> on the iteration order only, but the code loses >> some of its >> >> expressiveness. >> >> I did not find any discussion around introducing >> factories for >> >> SequencedSet.of(...) and SequencedMap.of(...), >> similar to those that >> >> exist in the Set and Map interfaces. Was this ever >> considered, and if >> >> not, could it be? >> > >> > Thanks for re-starting that discussion, it was >> talked a bit, but not as >> > it should be. >> > >> > So the issue is that currently we do not have any >> compact, unmodifiable >> > and ordered Set/Map implementation, >> > one use case is when you have data that comes from >> a JSON object as a >> > Map and you want to keep the inserted order, if by >> example the JSON is >> > a config file editable by a human, an other example >> is in unit tests >> > where you want to help the dev to read the output >> of the test so the >> > code that creates a Set/Map and what is outputed by >> the test should be >> > in the same order. >> > Currently there is no good solution for those use >> cases because >> > Set|Map.copyOf() does not keep the ordering. >> > >> > I see two solutions, either we add a new >> > SequenceSet|SequenceMap.of/copyOf, or we change the >> impleemntation of >> > Set|Map.of()/copyOf(). >> > Python had gone for the latter solution, which has >> the advantage a >> > being simple from the user POV, but from an >> algorithm expert POV, a Set >> > and a SequencedSet are different concepts we may >> want to emphasis ? >> > >> >> Best regards, Rafael >> > >> > regards, >> > R?mi >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sat Jan 18 01:28:48 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 18 Jan 2025 01:28:48 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v9] In-Reply-To: References: Message-ID: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - fix benchmark, from rgiulietti - Coding style consistency, from rgiulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22023/files - new: https://git.openjdk.org/jdk/pull/22023/files/3e23ab6a..803a88aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=07-08 Stats: 14 lines in 2 files changed: 0 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/22023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023 PR: https://git.openjdk.org/jdk/pull/22023 From liach at openjdk.org Sat Jan 18 01:31:35 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 18 Jan 2025 01:31:35 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> Message-ID: On Fri, 17 Jan 2025 23:33:50 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > provide message for test assertion src/java.base/share/classes/java/util/Currency.java line 469: > 467: > 468: // Initialize the set of available currencies if needed > 469: private static synchronized void initAvailableCurrencies() { Should we make `available` volatile so we can avoid entering the monitor if the currencies are initialized? (Note: We may get Stable Values very soon, at that point SV is a much better solution) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1920921812 From swen at openjdk.org Sat Jan 18 01:33:36 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 18 Jan 2025 01:33:36 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v10] In-Reply-To: References: Message-ID: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Coding style consistency, from rgiulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22023/files - new: https://git.openjdk.org/jdk/pull/22023/files/803a88aa..d3d9631c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023 PR: https://git.openjdk.org/jdk/pull/22023 From liach at openjdk.org Sat Jan 18 01:36:35 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 18 Jan 2025 01:36:35 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> Message-ID: <_kgxwve-61FiHj2jYN7mqpkBMZCXDuv4ty_1mwtknd4=.c818e9d6-3e17-4459-ba5c-9d51afd6417b@github.com> On Fri, 17 Jan 2025 23:33:50 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > provide message for test assertion test/jdk/java/util/Currency/AvailableCurrenciesTest.java line 46: > 44: assertEquals(currencies, Currency.availableCurrencies().collect(Collectors.toSet()), > 45: "availableCurrencies() and getAvailableCurrencies() do not have the same elements"); > 46: } Should we add a test to ensure `Currency.availableCurrencies()` has no duplicate elements? Currency.availableCurrencies().collect(Collectors.toMap(Function.identity(), Function.identity()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1920922876 From davidalayachew at gmail.com Sat Jan 18 01:49:41 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 17 Jan 2025 20:49:41 -0500 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> Message-ID: It definitely helps. I guess my next question is, there is no bridge method, which is why this fails. Why not add a bridge method? What is stopping Java from doing this? And to be clear, it is obvious to me that SewuencedSet.of is the right answer. I am just trying to understand the point you raised. On Fri, Jan 17, 2025, 8:14?PM Joseph D. Darcy wrote: > > On 1/17/2025 5:00 PM, David Alayachew wrote: > > Thanks for the corrections folks. I was thinking from the perspective of > LSP. I now see that there is the performance perspective to consider too. > > Now that said, I don't understand your comment Joe Darcy. Could you > explain it in more detail? > > Say you compile your code against JDK 24 and use the 1-argument Set.Of() > method. For that call site, your class file will refer to a method using > information akin to > > "In the class java.util.Set, a method named "of" that *returns a > java.util.Set* and take a java.lang.Object as an argument" > > (The generic information is basically erased in the class file, hence Set > rather than Set and Object rather than E.) > > If we were then in JDK 25 to replace in java.util.Set > > static Set of(E e1){...} > > with > > static SequencedSet of(E e1){...} > > when your class file ran against JDK 25, there would be no method > > "In the class java.util.Set, a method named "of" that *returns a > java.util.Set* and take a java.lang.Object as an argument" > > for your class to call and the linkage would fail. > > For static methods, the change is equivalent to removing a method and > adding back a different, same-named method. > > HTH, > > -Joe > > > My initial pick up of your comment is that, the parameter types and the > return types of a method must match the types exactly between releases, > otherwise there are no bridge methods FOR STATIC TYPES. But as for why, I > don't understand. > > I know that static methods are not so much inherited as they are just > given as is (hence why there is not really a static abstract method). But I > don't quite see the line connecting that with no bridge methods for static. > Maybe I don't understand bridge methods well enough. > > On Fri, Jan 17, 2025, 12:32?PM Joseph D. Darcy > wrote: > >> On 1/16/2025 11:26 PM, Rafael Winterhalter wrote: >> >> >> Would it even be possible to change the return types of Set.of(...) and >> Map.of(...) without breaking binary compatibility? >> >> >> In short, no. >> >> The methods in question are *static* methods. Switching to covariant >> overrides with more precise return types works for subclasses because of >> bridge methods. >> >> In a bit more detail, in a covariant override a single method in the >> source code gets translated into multiply methods in the class file. >> References to methods in the class file use the argument types and return >> type so if an old class file refers to the previously declared source-level >> return type, there is the bridge method present to be linked to (for binary >> compatibility) and then executed. >> >> -Joe >> >> >> >> I also think that the randomization of Set.of(...) and Map.of(...) is a >> good property as it uncovers bugs early if one relies on iteration order. >> This especially since those methods are often used in tests where >> production code would use a proper HashSet which cannot guarantee iteration >> order for good reasons. Exactly here I think the new interfaces are a good >> addition as it uncovers such misconceptions. If code relies on insertion >> order, providing a Set.of(...) does no longer compile, what is a good thing. >> >> To me, adding SequencedSet.of(...) and SequencedMap.of(...) sounds like >> the right approach, with implementations similar to that of Set.of(...) and >> Map.of(...). As for megamorphism, I think the chance of encounter at a call >> site is similar, as Set12 and SetN from the Set interface are typically >> combined with HashMap. As for a possible SequencedSet12 and SequencedSetN, >> I think they would normally be seen with LinkedHashSet. >> >> Best regards, Rafael >> >> Am Fr., 17. Jan. 2025 um 00:36 Uhr schrieb David Alayachew < >> davidalayachew at gmail.com>: >> >>> I should also add, the documentation went out of their way to specify >>> that iteration order is unspecified. >>> >>> Also, I see R?mi's comment, but that's even more unconvincing to me. >>> >>> Map.of has an upper limit of 10 entries, and Map.ofEntries has an upper >>> limit of that Java max file size limit thing. You all know what I am >>> talking about. >>> >>> Point is, both of these static factories were meant to be used on a >>> small number of entries. If it truly has just been not done until now, then >>> the bug database will confirm that easily. >>> >>> When I get back, I can check myself. >>> >>> On Thu, Jan 16, 2025, 6:25?PM David Alayachew >>> wrote: >>> >>>> I guess let me ask the obvious question. >>>> >>>> Chesterton's fence -- why wasn't this done before? I refuse to believe >>>> that this idea wasn't thought up years ago, which leads me to believe there >>>> was a reason that it hasn't been done. >>>> >>>> Is there any way we can look this up in the bug database or something? >>>> >>>> On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m wrote: >>>> >>>>> Having the result Map.of and Set.of preserve the insertion order would >>>>> often be convenient. >>>>> >>>>> More often than not programs iterate over the contents of a maps and >>>>> sets at some point. For example to present the values in a GUI, for >>>>> serialisation, or even for error printouts. In all those cases having >>>>> a >>>>> fixed iteration order is much better than having a random iteration >>>>> order. >>>>> >>>>> Often it is even a subtle bug to have a random iteration order. For >>>>> example, I ran in to a situation where jdeps printed a error message >>>>> containing a list of modules. But the list was in a different order on >>>>> each run of the program! It took me a while to figure out that it was >>>>> actually the same list. A possible explanation is that jdeps is >>>>> implemented using Map.of or Set.of. >>>>> >>>>> Because of this I think I would be better if the most commonly used >>>>> standard collection factories produced collections with a fixed >>>>> iteration order. >>>>> >>>>> Guavas ImmutableMap and ImmutableSet also preserve insertion order. >>>>> >>>>> Regards, >>>>> Jens Lidestr?m >>>>> >>>>> >>>>> On 2025-01-16 08:44, Remi Forax wrote: >>>>> >>>>> > ------------------------- >>>>> > >>>>> >> From: "Rafael Winterhalter" >>>>> >> To: "core-libs-dev" >>>>> >> Sent: Thursday, January 16, 2025 8:13:17 AM >>>>> >> Subject: Factory methods for SequencedSet and SequencedMap >>>>> > >>>>> >> Hello, >>>>> > >>>>> > Hello, >>>>> > >>>>> >> I am happily taking SequencedSet and SequencedMap into use, but one >>>>> >> inconvenience I encounter is the lack of factory methods for the >>>>> two. >>>>> >> In code where many (initial) collections have zero or one element >>>>> (for >>>>> >> later aggregation), I now write Set.of()/Set.of(one) and >>>>> >> Map.of()/Map.of(key, value), as it makes the code shorter and more >>>>> >> readable. Those collections are of course implicitly sequenced, but >>>>> >> now I must make the variable type of the surrounding monad Set and >>>>> >> Map, and simply assume that a LinkedHashSet or LinkedHashMap is >>>>> used >>>>> >> when a collection of more than one element is set, without >>>>> requiring >>>>> >> the interface type. This does not require any type casting, as I >>>>> rely >>>>> >> on the iteration order only, but the code loses some of its >>>>> >> expressiveness. >>>>> >> I did not find any discussion around introducing factories for >>>>> >> SequencedSet.of(...) and SequencedMap.of(...), similar to those >>>>> that >>>>> >> exist in the Set and Map interfaces. Was this ever considered, and >>>>> if >>>>> >> not, could it be? >>>>> > >>>>> > Thanks for re-starting that discussion, it was talked a bit, but not >>>>> as >>>>> > it should be. >>>>> > >>>>> > So the issue is that currently we do not have any compact, >>>>> unmodifiable >>>>> > and ordered Set/Map implementation, >>>>> > one use case is when you have data that comes from a JSON object as >>>>> a >>>>> > Map and you want to keep the inserted order, if by example the JSON >>>>> is >>>>> > a config file editable by a human, an other example is in unit tests >>>>> > where you want to help the dev to read the output of the test so the >>>>> > code that creates a Set/Map and what is outputed by the test should >>>>> be >>>>> > in the same order. >>>>> > Currently there is no good solution for those use cases because >>>>> > Set|Map.copyOf() does not keep the ordering. >>>>> > >>>>> > I see two solutions, either we add a new >>>>> > SequenceSet|SequenceMap.of/copyOf, or we change the impleemntation >>>>> of >>>>> > Set|Map.of()/copyOf(). >>>>> > Python had gone for the latter solution, which has the advantage a >>>>> > being simple from the user POV, but from an algorithm expert POV, a >>>>> Set >>>>> > and a SequencedSet are different concepts we may want to emphasis ? >>>>> > >>>>> >> Best regards, Rafael >>>>> > >>>>> > regards, >>>>> > R?mi >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From swen at openjdk.org Sat Jan 18 03:25:25 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 18 Jan 2025 03:25:25 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v11] In-Reply-To: References: Message-ID: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - bug fix - from rgiulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22023/files - new: https://git.openjdk.org/jdk/pull/22023/files/d3d9631c..34bd9d43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=09-10 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023 PR: https://git.openjdk.org/jdk/pull/22023 From duke at openjdk.org Sat Jan 18 12:40:07 2025 From: duke at openjdk.org (Aviad Zer) Date: Sat, 18 Jan 2025 12:40:07 GMT Subject: RFR: JDK-8348030 : Extend Math.min to support multiple parameters Message-ID: This change extends the Math.min function to support multiple parameters, improving its usability and code readability. Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. Benefits: Simplifies code by eliminating the need for nested Math.min calls. Enhances readability, especially when comparing multiple values. Offers consistency with existing Math.min usage patterns. ------------- Commit messages: - Extend Math.min to support unlimited parameters for int, double, long, and float Changes: https://git.openjdk.org/jdk/pull/23138/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348030 Stats: 72 lines in 1 file changed: 72 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23138/head:pull/23138 PR: https://git.openjdk.org/jdk/pull/23138 From duke at openjdk.org Sat Jan 18 12:40:08 2025 From: duke at openjdk.org (Aviad Zer) Date: Sat, 18 Jan 2025 12:40:08 GMT Subject: RFR: JDK-8348030 : Extend Math.min to support multiple parameters In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:26:32 GMT, Aviad Zer wrote: > This change extends the Math.min function to support multiple parameters, improving its usability and code readability. > > Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. > > Benefits: > > Simplifies code by eliminating the need for nested Math.min calls. > Enhances readability, especially when comparing multiple values. > Offers consistency with existing Math.min usage patterns. updating the commit message with relevant BUG-ID ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2599699660 From archie.cobbs at gmail.com Sat Jan 18 15:06:29 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Sat, 18 Jan 2025 09:06:29 -0600 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> Message-ID: On Fri, Jan 17, 2025 at 7:50?PM David Alayachew wrote: > I guess my next question is, there is no bridge method, which is why this > fails. Why not add a bridge method? What is stopping Java from doing this? > In Java class files it's possible to have two methods that differ only in their return type, but that's not allowed in Java source files (you'll get a "method already defined" error). So the only way bridge methods can be created is if the compiler adds them itself. When you override a superclass instance method with a narrower (covariant) return type, this is what happens automatically on your behalf. Static methods are also "inherited" by subclasses but there isn't the same concept of "overriding" - instead there is "hiding". So the compiler adding bridge methods would be inappropriate - or at the very least, they would change the semantics of the language incompatibly. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Sat Jan 18 21:51:40 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 18 Jan 2025 21:51:40 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v7] In-Reply-To: References: Message-ID: <9e8uj_VLiGiqEPKX0miVKCbeCdRsIUP8feWgz3YWf64=.86b15341-cd48-4379-af4b-d1b346872abc@github.com> On Fri, 17 Jan 2025 16:05:32 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 434: >> >>> 432: >>> 433: private static void putCharUTF16(byte[] buf, int charPos, int c) { >>> 434: UNSAFE.putChar(buf, ARRAY_BYTE_BASE_OFFSET + ((long) charPos << 1), (char) c); >> >> I'm not sure we can put a `char` into a `byte[]`. >> @cl4es is this safe on all platforms? > > The doc of `Unsafe::putChar()` delegates to the doc of `Unsafe::putInt()` which clearly states that the `Object` and `offset` arguments must locate a variable of the same type as the one of argument `x`, which is not the case here. This is safe. See https://github.com/openjdk/jdk/blob/3804082cba56e6d26c500880cc5cbe6d4332d8f8/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L129-L132, where `MethodHandles.byteArrayViewVarHandle` implementation does getChar/Short/Int/Long on a byte array. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1921223873 From redestad at openjdk.org Sun Jan 19 02:13:49 2025 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 19 Jan 2025 02:13:49 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v7] In-Reply-To: <9e8uj_VLiGiqEPKX0miVKCbeCdRsIUP8feWgz3YWf64=.86b15341-cd48-4379-af4b-d1b346872abc@github.com> References: <9e8uj_VLiGiqEPKX0miVKCbeCdRsIUP8feWgz3YWf64=.86b15341-cd48-4379-af4b-d1b346872abc@github.com> Message-ID: On Sat, 18 Jan 2025 21:48:39 GMT, Chen Liang wrote: >> The doc of `Unsafe::putChar()` delegates to the doc of `Unsafe::putInt()` which clearly states that the `Object` and `offset` arguments must locate a variable of the same type as the one of argument `x`, which is not the case here. > > This is safe. See https://github.com/openjdk/jdk/blob/3804082cba56e6d26c500880cc5cbe6d4332d8f8/src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template#L129-L132, where `MethodHandles.byteArrayViewVarHandle` implementation does getChar/Short/Int/Long on a byte array. The difference there is the use of `Unsafe.get/putCharUnaligned`. I think `putChar` might work for all current platforms and modes since we're always storing at an index that is divisible by 2 in the byte array, thus aligned up to `char`. That said this might be an abuse of an unspecified behavior and adding `-Unaligned` might be a bit safer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1921350812 From swen at openjdk.org Sun Jan 19 07:00:38 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 19 Jan 2025 07:00:38 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v12] In-Reply-To: References: Message-ID: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: use putCharUnaligned ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22023/files - new: https://git.openjdk.org/jdk/pull/22023/files/34bd9d43..7eb89c91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023 PR: https://git.openjdk.org/jdk/pull/22023 From davidalayachew at gmail.com Sun Jan 19 14:59:19 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 19 Jan 2025 09:59:19 -0500 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> Message-ID: That's the missing link. Thanks Archie. Man, I still don't get the decision-making in 1995 to make it not overridable. It is what it is. On Sat, Jan 18, 2025, 10:06?AM Archie Cobbs wrote: > On Fri, Jan 17, 2025 at 7:50?PM David Alayachew > wrote: > >> I guess my next question is, there is no bridge method, which is why this >> fails. Why not add a bridge method? What is stopping Java from doing this? >> > In Java class files it's possible to have two methods that differ only in > their return type, but that's not allowed in Java source files (you'll get > a "method already defined" error). > > So the only way bridge methods can be created is if the compiler adds them > itself. When you override a superclass instance method with a narrower > (covariant) return type, this is what happens automatically on your behalf. > > Static methods are also "inherited" by subclasses but there isn't the same > concept of "overriding" - instead there is "hiding". So the compiler adding > bridge methods would be inappropriate - or at the very least, they would > change the semantics of the language incompatibly. > > -Archie > > -- > Archie L. Cobbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Jan 19 15:18:42 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 19 Jan 2025 16:18:42 +0100 (CET) Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> Message-ID: <1054038972.68527184.1737299922796.JavaMail.zimbra@univ-eiffel.fr> What can be done is to have Set.of()/Map.of() to delegate to SequenceSet.of()/SequenceMap.of() so there is only one implementation at runtime. Also, technically, there is a way to change the return type in a binary compatible way ... if union types are supported in the language. In that case, Set.of() can be declared like this static Set | SequenceSet of(E... ) { ... } because of erasure, the binary descriptor will use Set, but the Signature will be Set | SequenceSet so the compiler will see the return type as a SequencedSet . Obviously, union types is a far bigger features than adding SequenceSet/SequenceMap so it's a big if, but it may happen in the future. R?mi > From: "joe darcy" > To: "core-libs-dev" > Sent: Friday, January 17, 2025 6:30:40 PM > Subject: Re: Factory methods for SequencedSet and SequencedMap > On 1/16/2025 11:26 PM, Rafael Winterhalter wrote: >> Would it even be possible to change the return types of Set.of(...) and >> Map.of(...) without breaking binary compatibility? > In short, no. [...] > -Joe R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Jan 19 21:09:15 2025 From: duke at openjdk.org (Matthias Ernst) Date: Sun, 19 Jan 2025 21:09:15 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations Message-ID: Certain signatures for foreign function calls require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention ("needsReturnBuffer"). In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. Sample stack trace: java.lang.Thread.State: RUNNABLE at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) at jdk.internal.misc.Unsafe.allocateMemory(java.base at 25-ea/Unsafe.java:636) at jdk.internal.foreign.SegmentFactories.allocateMemoryWrapper(java.base at 25-ea/SegmentFactories.java:215) at jdk.internal.foreign.SegmentFactories.allocateSegment(java.base at 25-ea/SegmentFactories.java:193) at jdk.internal.foreign.ArenaImpl.allocateNoInit(java.base at 25-ea/ArenaImpl.java:55) at jdk.internal.foreign.ArenaImpl.allocate(java.base at 25-ea/ArenaImpl.java:60) at jdk.internal.foreign.ArenaImpl.allocate(java.base at 25-ea/ArenaImpl.java:34) at java.lang.foreign.SegmentAllocator.allocate(java.base at 25-ea/SegmentAllocator.java:645) at jdk.internal.foreign.abi.SharedUtils$2.(java.base at 25-ea/SharedUtils.java:388) at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) at java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.base at 25-ea/DirectMethodHandle$Holder) at java.lang.invoke.LambdaForm$MH/0x000001f00109a400.invoke(java.base at 25-ea/LambdaForm$MH) at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) When does this happen? A fairly easy way to trigger this is through returning a small aggregate like the following: struct Vector2D { double x, y; }; Vector2D Origin() { return {0, 0}; } On AArch64, such a struct is returned in two 128 bit registers v0/v1. The VM's calling convention for the native stub consequently expects an 32 byte output segment argument. The FFM downcall method handle instead expects to create a 16 byte result segment through the application-provided SegmentAllocator, and needs to perform an appropriate adaptation, roughly like so: MemorySegment downcallMH(SegmentAllocator a) { MemorySegment tmp = SharedUtils.allocate(32); try { nativeStub.invoke(tmp); // leaves v0, v1 in tmp MemorySegment result = a.allocate(16); result.setDouble(0, tmp.getDouble(0)); result.setDouble(8, tmp.getDouble(16)); return result; } finally { free(tmp); } } You might argue that this cost is not worse than what happens through the result allocator. However, the application has control over this, and may provide a segment-reusing allocator in a loop: MemorySegment result = allocate(resultLayout); SegmentAllocator allocator = (_, _)->result; loop: mh.invoke(allocator); <= would like to avoid hidden allocations in here To alleviate this, This PR remembers and reuses one single such intermediate buffer per carrier-thread in subsequent calls, very similar to what happens in the sun.nio.ch.Util.BufferCache or sun.nio.fs.NativeBuffers, which face a similar issues. Performance (MBA M3): # VM version: JDK 25-ea, OpenJDK 64-Bit Server VM, 25-ea+3-283 Benchmark Mode Cnt Score Error Units PointsAlloc.circle_by_ptr avgt 5 8.964 ? 0.351 ns/op PointsAlloc.circle_by_ptr:?gc.alloc.rate avgt 5 95.301 ? 3.665 MB/sec PointsAlloc.circle_by_ptr:?gc.alloc.rate.norm avgt 5 0.224 ? 0.001 B/op PointsAlloc.circle_by_ptr:?gc.count avgt 5 2.000 counts PointsAlloc.circle_by_ptr:?gc.time avgt 5 3.000 ms PointsAlloc.circle_by_value avgt 5 46.498 ? 2.336 ns/op PointsAlloc.circle_by_value:?gc.alloc.rate avgt 5 13141.578 ? 650.425 MB/sec PointsAlloc.circle_by_value:?gc.alloc.rate.norm avgt 5 160.224 ? 0.001 B/op PointsAlloc.circle_by_value:?gc.count avgt 5 116.000 counts PointsAlloc.circle_by_value:?gc.time avgt 5 44.000 ms # VM version: JDK 25-internal, OpenJDK 64-Bit Server VM, 25-internal-adhoc.mernst.jdk Benchmark Mode Cnt Score Error Units PointsAlloc.circle_by_ptr avgt 5 9.108 ? 0.477 ns/op PointsAlloc.circle_by_ptr:?gc.alloc.rate avgt 5 93.792 ? 4.898 MB/sec PointsAlloc.circle_by_ptr:?gc.alloc.rate.norm avgt 5 0.224 ? 0.001 B/op PointsAlloc.circle_by_ptr:?gc.count avgt 5 2.000 counts PointsAlloc.circle_by_ptr:?gc.time avgt 5 4.000 ms PointsAlloc.circle_by_value avgt 5 13.180 ? 0.611 ns/op PointsAlloc.circle_by_value:?gc.alloc.rate avgt 5 64.816 ? 2.964 MB/sec PointsAlloc.circle_by_value:?gc.alloc.rate.norm avgt 5 0.224 ? 0.001 B/op PointsAlloc.circle_by_value:?gc.count avgt 5 2.000 counts PointsAlloc.circle_by_value:?gc.time avgt 5 5.000 ms ------------- Commit messages: - tiny stylistic changes - Storing segment addresses instead of objects in the cache appears to be slightly faster. Write barrier? - (c) - unit test - move CallBufferCache out - shave off a couple more nanos - Add comparison benchmark for out-parameter. - copyright header - Benchmark: - move pinned cache lookup out of constructor. - ... and 20 more: https://git.openjdk.org/jdk/compare/8460072f...4a2210df Changes: https://git.openjdk.org/jdk/pull/23142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287788 Stats: 402 lines in 7 files changed: 377 ins; 0 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From jvernee at openjdk.org Sun Jan 19 21:09:15 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Sun, 19 Jan 2025 21:09:15 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 21:39:05 GMT, Matthias Ernst wrote: > Certain signatures for foreign function calls require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention ("needsReturnBuffer"). In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > at jdk.internal.misc.Unsafe.allocateMemory(java.base at 25-ea/Unsafe.java:636) > at jdk.internal.foreign.SegmentFactories.allocateMemoryWrapper(java.base at 25-ea/SegmentFactories.java:215) > at jdk.internal.foreign.SegmentFactories.allocateSegment(java.base at 25-ea/SegmentFactories.java:193) > at jdk.internal.foreign.ArenaImpl.allocateNoInit(java.base at 25-ea/ArenaImpl.java:55) > at jdk.internal.foreign.ArenaImpl.allocate(java.base at 25-ea/ArenaImpl.java:60) > at jdk.internal.foreign.ArenaImpl.allocate(java.base at 25-ea/ArenaImpl.java:34) > at java.lang.foreign.SegmentAllocator.allocate(java.base at 25-ea/SegmentAllocator.java:645) > at jdk.internal.foreign.abi.SharedUtils$2.(java.base at 25-ea/SharedUtils.java:388) > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > at java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.base at 25-ea/DirectMethodHandle$Holder) > at java.lang.invoke.LambdaForm$MH/0x000001f00109a400.invoke(java.base at 25-ea/LambdaForm$MH) > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > When does this happen? A fairly easy way to trigger this is through returning a small aggregate like the following: > > struct Vector2D { > double x, y; > }; > Vector2D Origin() { > return {0, 0}; > } > > > On AArch64, such a struct is returned in two 128 bit registers v0/v1. > The VM's calling convention for the native stub consequently expects an 32 byte output segment argument. > The FFM downcall method handle instead expects to create a 16 byte result segment through the application-provided SegmentAllocator, and needs to perform an appropriate adaptation, roughly like so: > > MemorySegment downcallMH(SegmentAllocator a) { > MemorySegment tmp = SharedUtils.allocate(32); > try { > nativeStub.invoke(tmp); // leaves v0, v1 in tmp > MemorySegment result = a.allocate(16); > result.setDouble(0, tmp.getDouble(0)); > result.setDouble(8, tmp.getDouble(16)); > return result; > ... Could you add the benchmark you're using to the PR as well? The benchmark should be put under `./test/micro/org/openjdk/bench/java/lang/foreign/`. This will allow others to reproduce the results, and longer term, having a benchmark on file would allow us to detect regressions/improvements in performance in the future as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2598550989 From duke at openjdk.org Sun Jan 19 21:09:15 2025 From: duke at openjdk.org (Matthias Ernst) Date: Sun, 19 Jan 2025 21:09:15 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 14:58:37 GMT, Jorn Vernee wrote: > Could you add the benchmark you're using to the PR as well? Done. I slotted it into the "points" BM suite, alas I had to define another "DoublePoint" struct, though, since the existing int/int pair gets packed into a long. Full disclosure, I'm not sure how to run it inside the jdk build structure, ran it outside instead, so I hope it builds (`make test TEST="micro:java.lang.foreign.points"` => `Error: Unable to access jarfile /Users/mernst/IdeaProjects/jdk/build/macosx-aarch64-server-fastdebug/images/test/micro/benchmarks.jar`) It exercises a loop like this: struct DoublePoint { double x; double y; } DoublePoint unit_rotate(double phi); <== HFA requires intermediate buffer void unit_rotate_ptr(DoublePoint* out, double phi); <== reference, no intermediate buffer DoublePoint *points = new DoublePoint[N]; for (i in 0...N) points[i] = unit_rotate(2*pi*i/N); vs for (i in 0...N) unit_rotate_ptr(points+i, 2*pi*i/N); It is now almost competitive and the memory profile looks a lot better: # VM version: JDK 25-ea, OpenJDK 64-Bit Server VM, 25-ea+3-283 Benchmark Mode Cnt Score Error Units PointsAlloc.circle_by_ptr avgt 5 8.964 ? 0.351 ns/op PointsAlloc.circle_by_ptr:?gc.alloc.rate avgt 5 95.301 ? 3.665 MB/sec PointsAlloc.circle_by_ptr:?gc.alloc.rate.norm avgt 5 0.224 ? 0.001 B/op PointsAlloc.circle_by_ptr:?gc.count avgt 5 2.000 counts PointsAlloc.circle_by_ptr:?gc.time avgt 5 3.000 ms PointsAlloc.circle_by_value avgt 5 46.498 ? 2.336 ns/op PointsAlloc.circle_by_value:?gc.alloc.rate avgt 5 13141.578 ? 650.425 MB/sec PointsAlloc.circle_by_value:?gc.alloc.rate.norm avgt 5 160.224 ? 0.001 B/op PointsAlloc.circle_by_value:?gc.count avgt 5 116.000 counts PointsAlloc.circle_by_value:?gc.time avgt 5 44.000 ms # VM version: JDK 25-internal, OpenJDK 64-Bit Server VM, 25-internal-adhoc.mernst.jdk Benchmark Mode Cnt Score Error Units PointsAlloc.circle_by_ptr avgt 5 9.108 ? 0.477 ns/op PointsAlloc.circle_by_ptr:?gc.alloc.rate avgt 5 93.792 ? 4.898 MB/sec PointsAlloc.circle_by_ptr:?gc.alloc.rate.norm avgt 5 0.224 ? 0.001 B/op PointsAlloc.circle_by_ptr:?gc.count avgt 5 2.000 counts PointsAlloc.circle_by_ptr:?gc.time avgt 5 4.000 ms PointsAlloc.circle_by_value avgt 5 13.180 ? 0.611 ns/op PointsAlloc.circle_by_value:?gc.alloc.rate avgt 5 64.816 ? 2.964 MB/sec PointsAlloc.circle_by_value:?gc.alloc.rate.norm avgt 5 0.224 ? 0.001 B/op PointsAlloc.circle_by_value:?gc.count avgt 5 2.000 counts PointsAlloc.circle_by_value:?gc.time avgt 5 5.000 ms ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2599586149 From dholmes at openjdk.org Mon Jan 20 04:28:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jan 2025 04:28:36 GMT Subject: RFR: 8338428: Add logging if final VM flags while setting properties [v6] In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> Message-ID: On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". >> >> Update: >> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated flags Nit: the JBS title should be "Add logging of final VM flags ..." not 'if' ------------- PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2601301926 From duke at openjdk.org Mon Jan 20 07:30:17 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 07:30:17 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v2] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention ("needsReturnBuffer"). In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > at jdk.internal.misc.Unsafe.allocateMemory(java.base at 25-ea/Unsafe.java:636) > at jdk.internal.foreign.SegmentFactories.allocateMemoryWrapper(java.base at 25-ea/SegmentFactories.java:215) > at jdk.internal.foreign.SegmentFactories.allocateSegment(java.base at 25-ea/SegmentFactories.java:193) > at jdk.internal.foreign.ArenaImpl.allocateNoInit(java.base at 25-ea/ArenaImpl.java:55) > at jdk.internal.foreign.ArenaImpl.allocate(java.base at 25-ea/ArenaImpl.java:60) > at jdk.internal.foreign.ArenaImpl.allocate(java.base at 25-ea/ArenaImpl.java:34) > at java.lang.foreign.SegmentAllocator.allocate(java.base at 25-ea/SegmentAllocator.java:645) > at jdk.internal.foreign.abi.SharedUtils$2.(java.base at 25-ea/SharedUtils.java:388) > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > at java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.base at 25-ea/DirectMethodHandle$Holder) > at java.lang.invoke.LambdaForm$MH/0x000001f00109a400.invoke(java.base at 25-ea/LambdaForm$MH) > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > When does this happen? A fairly easy way to trigger this is through returning a small aggregate like the following: > > struct Vector2D { > double x, y; > }; > Vector2D Origin() { > return {0, 0}; > } > > > On AArch64, such a struct is returned in two 128 bit registers v0/v1. > The VM's calling convention for the native stub consequently expects an 32 byte output segment argument. > The FFM downcall method handle instead expects to create a 16 byte result segment through the application-provided SegmentAllocator, and needs to perform an appropriate adaptation, roughly like so: > > MemorySegment downcallMH(SegmentAllocator a) { > MemorySegment tmp = SharedUtils.allocate(32); > try { > nativeStub.invoke(tmp); // leaves v0, v1 in tmp > MemorySegment result = a.allocate(16); > result.setDouble(0, tmp.getDouble(0)); > result.setDouble(8, tmp.getDouble(16)); > return result; > ... Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: Implementation notes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/4a2210df..35a3a156 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=00-01 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From aboldtch at openjdk.org Mon Jan 20 08:02:25 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 20 Jan 2025 08:02:25 GMT Subject: RFR: 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents Message-ID: The proposed change here is the following: 1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object 2. Remove the Context object and its corresponding cleaner (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose. First what goes wrong without this patch. Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection. If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce a bogus oop because the field will not have been tracked (and remapped) correctly. This will cause the crash. The solution in this patch is to remove the Context object and store the `vmdependencies` list head directly in the CallSite object. This avoids any cross generation pointers. An alternative would have been to keep the cleaner and change the GC code to only look at CallSite object which are reachable. However this would require a per-GC adaption and would be a larger change. (Even if it is only really ZGC which would need to do anything, maybe that generational Shenandoah is also affected, but not something I have looked into) I've tried to dig and find why a cleaner was used in the first place as it seems like the GC has cleaned these / removed unloading nmethods for a while. Maybe someone else have more insight. The lifetime of the native memory is now solely tied to the lifetime of the nmthod it tracks a dependency for. This means that it is important that after `add_dependent_nmethod` it will eventually be seen by and can be unlinked by the GC. As far as I can tell this seem to be the case, `add_dependent_nmethod` is called after a nmethod has been created in the code cache. Tested: * Github Actions * Oracle supported platforms tier1 through 8 ------------- Commit messages: - 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents Changes: https://git.openjdk.org/jdk/pull/23194/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23194&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347564 Stats: 168 lines in 13 files changed: 8 ins; 143 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/23194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23194/head:pull/23194 PR: https://git.openjdk.org/jdk/pull/23194 From epeter at openjdk.org Mon Jan 20 08:03:44 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 20 Jan 2025 08:03:44 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: <4NGZx_gqvc7xMcXCTef2c_ns-nMxznsB42NnlQJqX4Q=.8cdc00f9-c9a7-409a-b5c3-885d0677b952@github.com> References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> <4NGZx_gqvc7xMcXCTef2c_ns-nMxznsB42NnlQJqX4Q=.8cdc00f9-c9a7-409a-b5c3-885d0677b952@github.com> Message-ID: On Fri, 17 Jan 2025 17:41:47 GMT, Galder Zamarre?o wrote: >> @galderz I ran some testing on our side, feel free to ping me in 1-2 days for the results. > > @eme64 I've addressed all the comments. I've not run the `VectorReduction2` for the reasons explained in the previous comment. Happy to add more details to `MinMaxVector` if you feel it's necessary. @galderz Ah, right. I understand about the branch probability. Hmm, maybe we should eventually change the `VectorReduction2` benchmark, or just remove the `min/max` benchmark there completely, as it depends on the random input values. Ah, though we have a fixed `seed`, so rerunning the benchmark would at least have consistent branching characteristics. So then it could make sense to run the benchmark, we just don't know the probability. I mean I ran it before for the `in/float/double min/max`, and all of them see a solid speedup. So I would expect the same for `long`, it would be nice to at least see the numbers. You could extend your benchmark to `float / double` as well, to make it complete. But that could also be a follow-up RFE. >I would expect a similar thing to happen when it comes to asimd envs with max vector size >= 32 (e.g. Graviton 3). Those will see vectorization occur and improvements kick in at 100%. Other systems (e.g. Graviton 4) will see a regression at 100%. This means that your work in https://github.com/openjdk/jdk/pull/20098#discussion_r1901576209 to avoid the max vector size limitation might become more important once my PR here goes in. So are you saying there are machines where we are now getting some regressions with your patch (2-element cases)? It would be nice to see the numbers summarized here. I'm losing the overview a little over the 50+ messages now ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2601678386 From pminborg at openjdk.org Mon Jan 20 08:39:37 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 20 Jan 2025 08:39:37 GMT Subject: RFR: JDK-8348030 : Extend Math.min to support multiple parameters In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:26:32 GMT, Aviad Zer wrote: > This change extends the Math.min function to support multiple parameters, improving its usability and code readability. > > Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. > > Benefits: > > Simplifies code by eliminating the need for nested Math.min calls. > Enhances readability, especially when comparing multiple values. > Offers consistency with existing Math.min usage patterns. Was this proposal discussed before providing this PR? Why is just `min()` proposed to change and not others like `max()` and `addExact()`? This PR would require a [CSR](https://wiki.openjdk.org/display/csr/CSR+FAQs) to be filed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2601749527 From vklang at openjdk.org Mon Jan 20 09:48:40 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 20 Jan 2025 09:48:40 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> Message-ID: On Fri, 17 Jan 2025 23:33:50 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > provide message for test assertion src/java.base/share/classes/java/util/Currency.java line 494: > 492: > 493: if (scEntry.cutOverTime == Long.MAX_VALUE > 494: || System.currentTimeMillis() < scEntry.cutOverTime) { It'd be better to obtain the current time once and compare against the same value for all entries rather than potentially using different current times for each comparison. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1922102421 From rgiulietti at openjdk.org Mon Jan 20 09:48:42 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 20 Jan 2025 09:48:42 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v6] In-Reply-To: References: <0FIbRT8u5KnjNE8o4tsd44q5wC0wYrYbcRkEDps5EnY=.7bded3d2-1a7f-4879-b0f7-b06a90b587e7@github.com> <0s3sQ_sngeHasBQNMmGWjxNeFEugQFGKBVFdxTEuZ2I=.77553eb4-3f45-4bd3-87bb-829185368e2e@github.com> Message-ID: On Sat, 18 Jan 2025 00:58:36 GMT, Shaojin Wen wrote: >> Sorry, I was just reading the comment and not how DIGITS is initialized and used. >> >> The _correct_ comment should be something like >> >> * 97 -> '9' | ('7' << 8) -> 0x3739 >> >> so the `short` value was correct before, but not the expression to construct it. >> Again, sorry for the confusion. > > It was my mistake. I made the change without checking it carefully. It has been fixed. @wenshao To be consistent with itself and with how `DIGITS` is initialized and used, the comment should look as explained above, for example * 97 -> '9' | ('7' << 8) -> 0x3739 Also, since the benchmark code was slightly changed, can you rerun it on the platforms available to you? Otherwise the PR looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1922101631 From eosterlund at openjdk.org Mon Jan 20 10:01:44 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 20 Jan 2025 10:01:44 GMT Subject: RFR: 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas wrote: > The proposed change here is the following: > 1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object > 2. Remove the Context object and its corresponding cleaner > > (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose. > > First what goes wrong without this patch. > > Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. > > For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. > > The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection. > > If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. > > For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ... This looks great. Solving the problem by removing pointless code is great. Now it looks much... cleaner. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23194#pullrequestreview-2561911632 From jpai at openjdk.org Mon Jan 20 10:54:36 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 20 Jan 2025 10:54:36 GMT Subject: RFR: 8347842: ThreadPoolExecutor specification discusses RuntimePermission In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 13:46:16 GMT, Viktor Klang wrote: > Removes ThreadPoolExecutor javadoc which mentions RuntimePermission. Hello Viktor, this change looks fine to me. On a related note, the `ForkJoinPool` class has this unused field: static volatile RuntimePermission modifyThreadPermission; which I suspect can be removed too. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23156#pullrequestreview-2562047544 From duke at openjdk.org Mon Jan 20 11:30:37 2025 From: duke at openjdk.org (Aviad Zer) Date: Mon, 20 Jan 2025 11:30:37 GMT Subject: RFR: JDK-8348030 : Extend Math.min to support multiple parameters In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:26:32 GMT, Aviad Zer wrote: > This change extends the Math.min function to support multiple parameters, improving its usability and code readability. > > Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. > > Benefits: > > Simplifies code by eliminating the need for nested Math.min calls. > Enhances readability, especially when comparing multiple values. > Offers consistency with existing Math.min usage patterns. Thank you for reviewing my PR and providing feedback. I apologize for not discussing this enhancement on the mailing list prior to submitting the PR. My focus was on extending Math.min for multiple parameters to simplify code readability and reduce nested calls. Expanding Scope: I chose to focus on min() for this initial contribution to keep the proposal small and manageable. However, I understand the value of symmetry in the API and would be open to extending similar functionality to **max()** and other related methods, such as addExact(), if the community agrees. CSR Requirement: Thank you for pointing out the need for a CSR. I would appreciate any guidance on how to file a CSR and the next steps to ensure that this enhancement aligns with OpenJDK?s standards and processes. I look forward to your guidance and continuing to improve this contribution ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2602169211 From duke at openjdk.org Mon Jan 20 11:43:13 2025 From: duke at openjdk.org (Aviad Zer) Date: Mon, 20 Jan 2025 11:43:13 GMT Subject: RFR: JDK-8348030 : Extend Math.min and Math.max to support multiple parameters [v2] In-Reply-To: References: Message-ID: > This change extends the Math.min function to support multiple parameters, improving its usability and code readability. > > Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. > > Benefits: > > Simplifies code by eliminating the need for nested Math.min calls. > Enhances readability, especially when comparing multiple values. > Offers consistency with existing Math.min usage patterns. Aviad Zer has updated the pull request incrementally with one additional commit since the last revision: Update Math.java by adding extended max function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23138/files - new: https://git.openjdk.org/jdk/pull/23138/files/be5728d8..3e333ee6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23138&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23138&range=00-01 Stats: 71 lines in 1 file changed: 71 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23138/head:pull/23138 PR: https://git.openjdk.org/jdk/pull/23138 From duke at openjdk.org Mon Jan 20 11:43:13 2025 From: duke at openjdk.org (Aviad Zer) Date: Mon, 20 Jan 2025 11:43:13 GMT Subject: RFR: JDK-8348030 : Extend Math.min and Math.max to support multiple parameters In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:26:32 GMT, Aviad Zer wrote: > This change extends the Math.min function to support multiple parameters, improving its usability and code readability. > > Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. > > Benefits: > > Simplifies code by eliminating the need for nested Math.min calls. > Enhances readability, especially when comparing multiple values. > Offers consistency with existing Math.min usage patterns. I have updated the PR to include an extended Math.max function, similar to the changes made for Math.min. This ensures consistency in the API and provides a unified approach for handling multiple parameters across both methods. Additionally, I have updated the PR title to reflect these enhancements. Please let me know if further changes are required. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2602194597 From duke at openjdk.org Mon Jan 20 11:50:35 2025 From: duke at openjdk.org (Martin Desruisseaux) Date: Mon, 20 Jan 2025 11:50:35 GMT Subject: RFR: JDK-8348030 : Extend Math.min and Math.max to support multiple parameters [v2] In-Reply-To: References: Message-ID: <_9KdxsIM0WCqZQaV3UGGyLJzwJ-0DEt37anHj2xxgZ0=.a0e7b51b-ffd3-4a15-bb57-a981e197d362@github.com> On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer wrote: >> This change extends the Math.min function to support multiple parameters, improving its usability and code readability. >> >> Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. >> >> Benefits: >> >> Simplifies code by eliminating the need for nested Math.min calls. >> Enhances readability, especially when comparing multiple values. >> Offers consistency with existing Math.min usage patterns. > > Aviad Zer has updated the pull request incrementally with one additional commit since the last revision: > > Update Math.java by adding extended max function Aren't `Math.min(values)` methods duplicating `Arrays.stream(values).min()`? Except for the `float` type, for which there is no stream. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2602212272 From duke at openjdk.org Mon Jan 20 12:02:37 2025 From: duke at openjdk.org (Aviad Zer) Date: Mon, 20 Jan 2025 12:02:37 GMT Subject: RFR: JDK-8348030 : Extend Math.min and Math.max to support multiple parameters [v2] In-Reply-To: <_9KdxsIM0WCqZQaV3UGGyLJzwJ-0DEt37anHj2xxgZ0=.a0e7b51b-ffd3-4a15-bb57-a981e197d362@github.com> References: <_9KdxsIM0WCqZQaV3UGGyLJzwJ-0DEt37anHj2xxgZ0=.a0e7b51b-ffd3-4a15-bb57-a981e197d362@github.com> Message-ID: On Mon, 20 Jan 2025 11:48:20 GMT, Martin Desruisseaux wrote: >> Aviad Zer has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Math.java by adding extended max function > > Aren't `Math.min(values)` methods duplicating `Arrays.stream(values).min()`? Except for the `float` type, for which there is no stream. Thank you for your feedback @desruisseaux ! While Arrays.stream(values).min() can indeed be used for int, long, and double, I believe that Math.min(values...) provides a more concise and intuitive alternative for these cases. Developers might prefer the simplicity of using a single method, especially when working with smaller sets of values where creating a stream might feel excessive. As you pointed out, the Streams API does not support float arrays directly. The Math.min(float...) method addresses this gap, offering a consistent API for all primitive types. Including varargs-based Math.min methods for all primitive types ensures consistency across the Math class and improves code readability. I hope this clarifies the motivation behind the proposal. Please let me know if you have further suggestions or feedback! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2602234412 From alanb at openjdk.org Mon Jan 20 12:12:20 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Jan 2025 12:12:20 GMT Subject: RFR: 8299504: Resolve `uses` and `provides` at run time if the service is optional and missing [v2] In-Reply-To: References: Message-ID: > Extend the support for optional dependences to allow for a service to be optional. The post-resolution consistency check specified by `Configuration.resolve` is relaxed to allow for the possibility that the service from a module in the module graph at compile-time but the module is not in the module graph at run-time. > > ConfigurationTest is ported from TestNG to JUnit and updated to add new tests testUsesOptionalService$N and testProvidesOptionalService$N. The port to JUnit is mostly trivial/mechanical changes but it does create a bit of noise - I can move this port to another issue if it makes the harder to see the additions to the test. Alan Bateman 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: - Add Optional Services section from Alex - Merge branch 'master' into JDK-8299504 - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23147/files - new: https://git.openjdk.org/jdk/pull/23147/files/76e93724..d2f7b090 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23147&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23147&range=00-01 Stats: 6099 lines in 360 files changed: 4008 ins; 378 del; 1713 mod Patch: https://git.openjdk.org/jdk/pull/23147.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23147/head:pull/23147 PR: https://git.openjdk.org/jdk/pull/23147 From alanb at openjdk.org Mon Jan 20 12:12:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Jan 2025 12:12:36 GMT Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fifth Preview) [v4] In-Reply-To: References: Message-ID: > Changes for [JEP draft: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically: > > - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. > - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. > - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. > - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. > - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. > > The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Fix link - Merge branch 'master' into JDK-8342486 - Sync up impl/tests form loom repo - Merge branch 'master' into JDK-8342486 - Pull latest API docs + impl from loom repo - Merge branch 'master' into JDK-8342486 - Sync up from loom repo - Initial commit ------------- Changes: https://git.openjdk.org/jdk/pull/21934/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=03 Stats: 4074 lines in 14 files changed: 1869 ins; 1458 del; 747 mod Patch: https://git.openjdk.org/jdk/pull/21934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934 PR: https://git.openjdk.org/jdk/pull/21934 From pminborg at openjdk.org Mon Jan 20 12:40:36 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 20 Jan 2025 12:40:36 GMT Subject: RFR: JDK-8348030 : Extend Math.min and Math.max to support multiple parameters [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer wrote: >> This change extends the Math.min function to support multiple parameters, improving its usability and code readability. >> >> Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. >> >> Benefits: >> >> Simplifies code by eliminating the need for nested Math.min calls. >> Enhances readability, especially when comparing multiple values. >> Offers consistency with existing Math.min usage patterns. > > Aviad Zer has updated the pull request incrementally with one additional commit since the last revision: > > Update Math.java by adding extended max function Before dealing with a CSR, I suggest you socialize your idea/PR in the core-libs-dev at openjdk.org mailing list. You could reference this PR in the initial mail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2602320478 From duke at openjdk.org Mon Jan 20 12:54:36 2025 From: duke at openjdk.org (Aviad Zer) Date: Mon, 20 Jan 2025 12:54:36 GMT Subject: RFR: JDK-8348030 : Extend Math.min and Math.max to support multiple parameters [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 11:43:13 GMT, Aviad Zer wrote: >> This change extends the Math.min function to support multiple parameters, improving its usability and code readability. >> >> Previously, finding the minimum value among multiple variables required using nested Math.min calls or converting the variables into an array and iterating through it. This enhancement provides a more intuitive and straightforward approach to achieve the same result. >> >> Benefits: >> >> Simplifies code by eliminating the need for nested Math.min calls. >> Enhances readability, especially when comparing multiple values. >> Offers consistency with existing Math.min usage patterns. > > Aviad Zer has updated the pull request incrementally with one additional commit since the last revision: > > Update Math.java by adding extended max function > Before dealing with a CSR, I suggest you socialize your idea/PR in the [core-libs-dev at openjdk.org](mailto:core-libs-dev at openjdk.org) mailing list. You could reference this PR in the initial mail. Thanks for help, I'll do that ------------- PR Comment: https://git.openjdk.org/jdk/pull/23138#issuecomment-2602350853 From shade at openjdk.org Mon Jan 20 12:59:09 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jan 2025 12:59:09 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner Message-ID: DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. We can migrate DBBs to use `java.lang.ref.Cleaner`. There are two pecularities during this rewrite. First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing are in DBB cleaning action, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 Additional testing: - [x] Linux x86_64 server fastdebug, `java/nio java/io` - [x] Linux AArch64 server fastdebug, `java/nio java/io` - [ ] Linux x86_64 server fastdebug, `all` - [ ] Linux AArch64 server fastdebug, `all` ------------- Commit messages: - Cleaner does not accept null cleanables - Fix Changes: https://git.openjdk.org/jdk/pull/22165/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344332 Stats: 270 lines in 8 files changed: 15 ins; 234 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From vklang at openjdk.org Mon Jan 20 13:27:37 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 20 Jan 2025 13:27:37 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner In-Reply-To: References: Message-ID: <9-qwIxCcUu35IeZ28A63BEAkOSbDkcuDX9RS-C_LVKQ=.1e6632a9-25b2-4cd1-a104-5deab2d1f120@github.com> On Fri, 15 Nov 2024 20:54:56 GMT, Aleksey Shipilev wrote: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing are in DBB cleaning action, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 88: > 86: // Old jdk.internal.ref.Cleaner behavior: when it fails, VM exits. > 87: if (System.err != null) { > 88: new Error("Cleaner terminated abnormally", x).printStackTrace(); @shipilev If this line throws, should the exit(1) be skipped? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1922401820 From vklang at openjdk.org Mon Jan 20 13:51:42 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 20 Jan 2025 13:51:42 GMT Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fifth Preview) [v4] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 12:12:36 GMT, Alan Bateman wrote: >> Changes for [JEP draft: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically: >> >> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor. Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close. >> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner. >> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions. >> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function. >> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method. >> >> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Fix link > - Merge branch 'master' into JDK-8342486 > - Sync up impl/tests form loom repo > - Merge branch 'master' into JDK-8342486 > - Pull latest API docs + impl from loom repo > - Merge branch 'master' into JDK-8342486 > - Sync up from loom repo > - Initial commit src/java.base/share/classes/java/util/concurrent/Joiners.java line 74: > 72: Subtask.State state = subtask.state(); > 73: if (state == Subtask.State.UNAVAILABLE) { > 74: throw new IllegalArgumentException(); Suggestion to add IAE exception message. src/java.base/share/classes/java/util/concurrent/Joiners.java line 121: > 119: Subtask.State state = subtask.state(); > 120: if (state == Subtask.State.UNAVAILABLE) { > 121: throw new IllegalArgumentException(); Suggestion to add IAE exception message ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r1922434029 PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r1922433639 From alanb at openjdk.org Mon Jan 20 13:53:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Jan 2025 13:53:40 GMT Subject: RFR: 8346230: [perf] scalability issue for the specjvm2008::xml.transform workload In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 23:08:20 GMT, Vladimir Ivanov wrote: > The synchronized scope was reduced from whole methods to sections that need hash map access control. The tier1 and jaxp tests are OK. The score of the specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported scores are: > original: 1vCPU - 148.4, 112vCPU - 12743.4, 224vCPU - 13481.31 ops/m > patched: 1vCPU - 149.77, 112vCPU - 13122.82, 224vCPU - 14751.57 ops/m > > According to the JFR the locking time for XMLReader object reduced from ~27sec to ~20sec for 224vCPU run. src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java line 53: > 51: * Cache of XMLReader objects > 52: */ > 53: private volatile ThreadLocal m_readers; It's not very common to see a ThreadLocal as an instance field but here it's more like a TL per XMLReaderManager instance. Is there any reason why this can't be eagerly created and use a final field here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23185#discussion_r1922437396 From swen at openjdk.org Mon Jan 20 13:55:20 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 20 Jan 2025 13:55:20 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v13] In-Reply-To: References: Message-ID: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22023/files - new: https://git.openjdk.org/jdk/pull/22023/files/7eb89c91..960e279e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=11-12 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023 PR: https://git.openjdk.org/jdk/pull/22023 From shade at openjdk.org Mon Jan 20 13:55:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jan 2025 13:55:43 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner In-Reply-To: <9-qwIxCcUu35IeZ28A63BEAkOSbDkcuDX9RS-C_LVKQ=.1e6632a9-25b2-4cd1-a104-5deab2d1f120@github.com> References: <9-qwIxCcUu35IeZ28A63BEAkOSbDkcuDX9RS-C_LVKQ=.1e6632a9-25b2-4cd1-a104-5deab2d1f120@github.com> Message-ID: On Mon, 20 Jan 2025 13:25:26 GMT, Viktor Klang wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 88: > >> 86: // Old jdk.internal.ref.Cleaner behavior: when it fails, VM exits. >> 87: if (System.err != null) { >> 88: new Error("Cleaner terminated abnormally", x).printStackTrace(); > > @shipilev If this line throws, should the exit(1) be skipped? ? This is verbatim from the old code in removed `Cleaner.java`. This line does not throw, it is there for printing the stack trace, I think :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1922439813 From jvernee at openjdk.org Mon Jan 20 14:12:37 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 20 Jan 2025 14:12:37 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 07:30:17 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> master at 764d70b7df18e288582e616c62b0d7078f1ff3aa >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op >> PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op >> PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op >> PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op >> PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op >> PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op >> PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > Implementation notes. Please also revert the unrelated formatting changes. src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 396: > 394: long address = fromCache != 0 ? fromCache : CallBufferCache.allocate(bufferSize); > 395: return new BoundedArena(MemorySegment.ofAddress(address).reinterpret(size)); > 396: } Looks like we're using `reinterpret` in the fallback case as well? I suggest structuring the code like this: Suggestion: final Arena arena = Arena.ofConfined(); MemorySegment segment = CallBufferCache.acquire(arena, size); if (segment == null) { segment = arena.allocate(size); } final SegmentAllocator slicingAllocator = SegmentAllocator.slicingAllocator(segment); return new Arena() { @Override public Scope scope() { return arena.scope(); } @Override public void close() { arena.close(); } @Override public MemorySegment allocate(long byteSize, long byteAlignment) { return slicingAllocator.allocate(byteSize, byteAlignment); } }; } i.e. encapsulate all the caching logic into the `CallBufferCache` class. Note that the 'release' action can be attached to `arena` as a cleanup action. test/micro/org/openjdk/bench/java/lang/foreign/points/PointsAlloc.java line 81: > 79: return Circle.byPtr(arena, NUM_CIRCLE_POINTS); > 80: } > 81: } I think it would be better to put the new benchmark in a separate benchmark class (e.g. a new variant of the `CallOverheadXXX` benchmark. There should already be some examples of benchmarks that pass structs), where the time unit is set to nanoseconds, so we can measure just the overhead of a single call. ------------- PR Review: https://git.openjdk.org/jdk/pull/23142#pullrequestreview-2562430579 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922426585 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922457699 From swen at openjdk.org Mon Jan 20 14:32:22 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 20 Jan 2025 14:32:22 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v14] In-Reply-To: References: Message-ID: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. Shaojin Wen 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 29 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 - fix comments - use putCharUnaligned - bug fix - from rgiulietti - Coding style consistency, from rgiulietti - fix benchmark, from rgiulietti - Coding style consistency, from rgiulietti - fix comment - fix comment, from @rgiulietti - ... and 19 more: https://git.openjdk.org/jdk/compare/4cf3f394...be1f88ab ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22023/files - new: https://git.openjdk.org/jdk/pull/22023/files/960e279e..be1f88ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=12-13 Stats: 70224 lines in 2661 files changed: 35172 ins; 22132 del; 12920 mod Patch: https://git.openjdk.org/jdk/pull/22023.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023 PR: https://git.openjdk.org/jdk/pull/22023 From mcimadamore at openjdk.org Mon Jan 20 15:06:38 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Jan 2025 15:06:38 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 07:30:17 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> master at 764d70b7df18e288582e616c62b0d7078f1ff3aa >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op >> PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op >> PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op >> PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op >> PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op >> PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op >> PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > Implementation notes. src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java line 75: > 73: > 74: @SuppressWarnings("restricted") > 75: public static long allocate(long size) { I don't think we should expose allocation/release methods (see related comment in `SharedUtils`) src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java line 97: > 95: public static long acquire() { > 96: // Protect against vthread unmount. > 97: Continuation.pin(); Other code that does this, first checks if we are in a virtual thread. Note that we have two options for dealing with problematic cases: * pin/unpin as soon as we see a virtual thread * if we have a virtual thread and we detect a race in accessing the cache (e.g. because of how the virtual threads have been scheduled to the same underlying carrier thread), we could avoid pinning, but just allocate a fresh new segment (thus avoiding recycling issues) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922533447 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922536958 From mcimadamore at openjdk.org Mon Jan 20 15:06:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Jan 2025 15:06:39 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 13:43:35 GMT, Jorn Vernee wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> Implementation notes. > > src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 396: > >> 394: long address = fromCache != 0 ? fromCache : CallBufferCache.allocate(bufferSize); >> 395: return new BoundedArena(MemorySegment.ofAddress(address).reinterpret(size)); >> 396: } > > Looks like we're using `reinterpret` in the fallback case as well? > > I suggest structuring the code like this: > > Suggestion: > > final Arena arena = Arena.ofConfined(); > MemorySegment segment = CallBufferCache.acquire(arena, size); > if (segment == null) { > segment = arena.allocate(size); > } > final SegmentAllocator slicingAllocator = SegmentAllocator.slicingAllocator(segment); > return new Arena() { > @Override > public Scope scope() { > return arena.scope(); > } > @Override > public void close() { > arena.close(); > } > @Override > public MemorySegment allocate(long byteSize, long byteAlignment) { > return slicingAllocator.allocate(byteSize, byteAlignment); > } > }; > } > > > i.e. encapsulate all the caching logic into the `CallBufferCache` class. Note that the 'release' action can be attached to `arena` as a cleanup action when calling `reinterpret`. Was about to suggest the same. The cache should work at a segment level - e.g. the client should call just `acquire` and get a valid segment back (no matter how that is obtained). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922532547 From stefank at openjdk.org Mon Jan 20 15:24:35 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 20 Jan 2025 15:24:35 GMT Subject: RFR: 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas wrote: > The proposed change here is the following: > 1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object > 2. Remove the Context object and its corresponding cleaner > > (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose. > > First what goes wrong without this patch. > > Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. > > For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. > > The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection. > > If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. > > For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ... Looks good to me. I think it would be good if someone more familiar with the MethodHandle code also reviewed this. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23194#pullrequestreview-2562657174 From rgiulietti at openjdk.org Mon Jan 20 16:04:36 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 20 Jan 2025 16:04:36 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v6] In-Reply-To: References: <0FIbRT8u5KnjNE8o4tsd44q5wC0wYrYbcRkEDps5EnY=.7bded3d2-1a7f-4879-b0f7-b06a90b587e7@github.com> <0s3sQ_sngeHasBQNMmGWjxNeFEugQFGKBVFdxTEuZ2I=.77553eb4-3f45-4bd3-87bb-829185368e2e@github.com> Message-ID: On Sat, 18 Jan 2025 00:58:36 GMT, Shaojin Wen wrote: >> Sorry, I was just reading the comment and not how DIGITS is initialized and used. >> >> The _correct_ comment should be something like >> >> * 97 -> '9' | ('7' << 8) -> 0x3739 >> >> so the `short` value was correct before, but not the expression to construct it. >> Again, sorry for the confusion. > > It was my mistake. I made the change without checking it carefully. It has been fixed. Thanks @wenshao. I ran the benchmarks on a Apple M1 CPU. I can observe a performance increase for the Latin1 cases but _not_ for the Utf16 cases, which is the same within the error bounds. before StringBuilders.appendWithIntLatin1 N/A avgt 15 181.071 ? 2.392 ns/op StringBuilders.appendWithIntUtf16 N/A avgt 15 160.507 ? 7.902 ns/op StringBuilders.appendWithLongLatin1 N/A avgt 15 232.727 ? 2.879 ns/op StringBuilders.appendWithLongUtf16 N/A avgt 15 222.765 ? 3.208 ns/op after StringBuilders.appendWithIntLatin1 N/A avgt 15 129.019 ? 0.097 ns/op StringBuilders.appendWithIntUtf16 N/A avgt 15 166.260 ? 2.144 ns/op StringBuilders.appendWithLongLatin1 N/A avgt 15 192.300 ? 1.520 ns/op StringBuilders.appendWithLongUtf16 N/A avgt 15 219.962 ? 0.850 ns/op Can you please rerun the benchmarks on your platforms and report here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22023#discussion_r1922611115 From swen at openjdk.org Mon Jan 20 16:11:43 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 20 Jan 2025 16:11:43 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v14] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen 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 29 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - fix comments > - use putCharUnaligned > - bug fix > - from rgiulietti > - Coding style consistency, from rgiulietti > - fix benchmark, from rgiulietti > - Coding style consistency, from rgiulietti > - fix comment > - fix comment, from @rgiulietti > - ... and 19 more: https://git.openjdk.org/jdk/compare/f24d889c...be1f88ab The performance numbers below show a significant improvement for appendWithIntLatin1 and appendWithLongLatin1. However, for appendWithIntUtf16 and appendWithLongUtf16, the performance is variable, sometimes faster and sometimes slower. This inconsistency might be due to measurement errors or other factors. ## 1. Script git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao # baseline d9e4383cca7 git checkout d9e4383cca77ed9667ea6916624f6416f976e3bf make test TEST="micro:java.lang.StringBuilders.appendWithIntUtf16" make test TEST="micro:java.lang.StringBuilders.appendWithLongUtf16" # current be1f88abfa5 git checkout be1f88abfa505b08bda761317961fef9b79986fe make test TEST="micro:java.lang.StringBuilders.appendWithInt" make test TEST="micro:java.lang.StringBuilders.appendWithLong" ## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa) -Benchmark Mode Cnt Score Error Units (d9e4383cca7) -StringBuilders.appendWithIntLatin1 avgt 15 171.264 ? 2.500 ns/op -StringBuilders.appendWithIntUtf16 avgt 15 162.430 ? 1.829 ns/op -StringBuilders.appendWithLongLatin1 avgt 15 227.369 ? 1.452 ns/op -StringBuilders.appendWithLongUtf16 avgt 15 214.854 ? 0.495 ns/op +Benchmark Mode Cnt Score Error Units (be1f88abfa5) +StringBuilders.appendWithIntLatin1 avgt 15 136.149 ? 0.213 ns/op +25.79% +StringBuilders.appendWithIntUtf16 avgt 15 165.650 ? 0.762 ns/op -1.94% +StringBuilders.appendWithLongLatin1 avgt 15 190.156 ? 2.260 ns/op +19.56% +StringBuilders.appendWithLongUtf16 avgt 15 224.880 ? 0.389 ns/op -4.45% ## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids) -Benchmark Mode Cnt Score Error Units (d9e4383cca7) -StringBuilders.appendWithIntLatin1 avgt 15 176.098 ? 3.122 ns/op -StringBuilders.appendWithIntUtf16 avgt 15 162.548 ? 0.403 ns/op -StringBuilders.appendWithLongLatin1 avgt 15 225.868 ? 1.912 ns/op -StringBuilders.appendWithLongUtf16 avgt 15 201.952 ? 6.429 ns/op +Benchmark Mode Cnt Score Error Units (be1f88abfa5) +StringBuilders.appendWithIntLatin1 avgt 15 145.052 ? 0.633 ns/op +21.40% +StringBuilders.appendWithIntUtf16 avgt 15 166.678 ? 0.392 ns/op -2.47% +StringBuilders.appendWithLongLatin1 avgt 15 187.617 ? 1.750 ns/op +20.38% +StringBuilders.appendWithLongUtf16 avgt 15 214.047 ? 1.687 ns/op -5.65% ## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710 ARM v9) -Benchmark Mode Cnt Score Error Units (d9e4383cca7) -StringBuilders.appendWithIntLatin1 avgt 15 267.675 ? 0.180 ns/op -StringBuilders.appendWithIntUtf16 avgt 15 246.470 ? 0.896 ns/op -StringBuilders.appendWithLongLatin1 avgt 15 342.262 ? 0.292 ns/op -StringBuilders.appendWithLongUtf16 avgt 15 327.840 ? 0.565 ns/op +Benchmark Mode Cnt Score Error Units (be1f88abfa5) +StringBuilders.appendWithIntLatin1 avgt 15 239.923 ? 1.331 ns/op +11.56% +StringBuilders.appendWithIntUtf16 avgt 15 252.083 ? 2.270 ns/op -2.22% +StringBuilders.appendWithLongLatin1 avgt 15 294.602 ? 2.770 ns/op +16.17% +StringBuilders.appendWithLongUtf16 avgt 15 324.465 ? 0.498 ns/op +1.04% ## 5. MacBook M1 Pro (aarch64) -Benchmark Mode Cnt Score Error Units (d9e4383cca7) -StringBuilders.appendWithIntLatin1 avgt 15 183.633 ? 5.675 ns/op -StringBuilders.appendWithIntUtf16 avgt 15 156.111 ? 1.045 ns/op -StringBuilders.appendWithLongLatin1 avgt 15 246.320 ? 0.934 ns/op -StringBuilders.appendWithLongUtf16 avgt 15 222.053 ? 1.177 ns/op +Benchmark Mode Cnt Score Error Units (be1f88abfa5) +StringBuilders.appendWithIntLatin1 avgt 15 139.442 ? 0.488 ns/op +31.69% +StringBuilders.appendWithIntUtf16 avgt 15 155.319 ? 1.039 ns/op +0.50% +StringBuilders.appendWithLongLatin1 avgt 15 202.335 ? 2.133 ns/op +21.73% +StringBuilders.appendWithLongUtf16 avgt 15 223.250 ? 0.774 ns/op -0.53% ## 6. orange_pi5_aarch64 (CPU RK3588S ARMv8.4) -Benchmark Mode Cnt Score Error Units (d9e4383cca7) -StringBuilders.appendWithIntLatin1 avgt 15 460.837 ? 6.925 ns/op -StringBuilders.appendWithIntUtf16 avgt 15 482.623 ? 16.269 ns/op -StringBuilders.appendWithLongLatin1 avgt 15 653.808 ? 15.051 ns/op -StringBuilders.appendWithLongUtf16 avgt 15 619.189 ? 15.581 ns/op +Benchmark Mode Cnt Score Error Units +StringBuilders.appendWithIntLatin1 avgt 15 385.403 ? 5.387 ns/op +19.57% +StringBuilders.appendWithIntUtf16 avgt 15 439.273 ? 3.404 ns/op +9.86% +StringBuilders.appendWithLongLatin1 avgt 15 573.817 ? 20.499 ns/op +13.94% +StringBuilders.appendWithLongUtf16 avgt 15 661.942 ? 0.282 ns/op -6.45% ------------- PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2602801895 From duke at openjdk.org Mon Jan 20 16:20:20 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 16:20:20 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v3] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > master at 764d70b7df18e288582e616c62b0d7078f1ff3aa > Benchmark Mode Cnt Score Error Units > PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op > PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### > PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op > PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op > PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op > > After: > Benchmark Mode Cnt Score Error Units > PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op > PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### > PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op > PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op > PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with three additional commits since the last revision: - shift api boundary - move bench - revert formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/35a3a156..4f8a9a97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=01-02 Stats: 343 lines in 8 files changed: 183 ins; 138 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From rgiulietti at openjdk.org Mon Jan 20 16:21:43 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 20 Jan 2025 16:21:43 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v14] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen 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 29 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - fix comments > - use putCharUnaligned > - bug fix > - from rgiulietti > - Coding style consistency, from rgiulietti > - fix benchmark, from rgiulietti > - Coding style consistency, from rgiulietti > - fix comment > - fix comment, from @rgiulietti > - ... and 19 more: https://git.openjdk.org/jdk/compare/07276096...be1f88ab Yes, that's what I observe as well. Your M1 results are consistent with the one I published just a few minutes earlier, so that's good. Do you think it is worth reconsidering the UTF16 case, which is mostly slightly slower? If not, I will approve the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2602823399 From duke at openjdk.org Mon Jan 20 16:23:38 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 16:23:38 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 15:00:14 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 396: >> >>> 394: long address = fromCache != 0 ? fromCache : CallBufferCache.allocate(bufferSize); >>> 395: return new BoundedArena(MemorySegment.ofAddress(address).reinterpret(size)); >>> 396: } >> >> Looks like we're using `reinterpret` in the fallback case as well? >> >> I suggest structuring the code like this: >> >> Suggestion: >> >> final Arena arena = Arena.ofConfined(); >> MemorySegment segment = CallBufferCache.acquire(arena, size); >> if (segment == null) { >> segment = arena.allocate(size); >> } >> final SegmentAllocator slicingAllocator = SegmentAllocator.slicingAllocator(segment); >> return new Arena() { >> @Override >> public Scope scope() { >> return arena.scope(); >> } >> @Override >> public void close() { >> arena.close(); >> } >> @Override >> public MemorySegment allocate(long byteSize, long byteAlignment) { >> return slicingAllocator.allocate(byteSize, byteAlignment); >> } >> }; >> } >> >> >> i.e. encapsulate all the caching logic into the `CallBufferCache` class. Note that the 'release' action can be attached to `arena` as a cleanup action when calling `reinterpret`. > > Was about to suggest the same. The cache should work at a segment level - e.g. the client should call just `acquire` and get a valid segment back (no matter how that is obtained). Moved logic to the cache to exchange MemorySegments. Attaching cleanup breaks scalar replacement though and we see ResourceList per call. I left a note in the code, it would be trivial to attach. > if (segment == null) { > segment = arena.allocate(size); > } No this wouldn't work, such a segment will be forcibly deallocated after the call, but we may want to put it into a cache slot afterwards. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922633799 From duke at openjdk.org Mon Jan 20 16:23:40 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 16:23:40 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 14:06:33 GMT, Jorn Vernee wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> Implementation notes. > > test/micro/org/openjdk/bench/java/lang/foreign/points/PointsAlloc.java line 81: > >> 79: return Circle.byPtr(arena, NUM_CIRCLE_POINTS); >> 80: } >> 81: } > > I think it would be better to put the new benchmark in a separate benchmark class (e.g. a new variant of the `CallOverheadXXX` benchmark. There should already be some examples of benchmarks that pass structs), where the time unit is set to nanoseconds, so we can measure just the overhead of a single call. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922633902 From ihse at openjdk.org Mon Jan 20 16:25:43 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 20 Jan 2025 16:25:43 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bj?rsn?s wrote: >> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. >> >> Links in `java.security` and `share/data/tzdata` are excluded from this PR. >> >> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. >> >> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). >> >> Changes beyond the obvious are as follows: >> >> `linux/native/libsimdsort/xss-common-qsort.h`: >> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170 >> >> `share/man/keytool.1`: >> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well? >> >> `unix/classes/sun/net/PortConfig.java` >> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. >> >> `unix/native/libjava/*`, >> Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs >> >> `unix/native/libjava/ProcessImpl_md.c` >> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to. > > Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into links-use-https > - Re-fix link to "Oracle Java Root Certificate program" in keytool.md > - Merge branch 'master' into links-use-https > > # Conflicts: > # src/java.base/share/man/keytool.1 > - Remove accidental "'" > - Use Wayback link > - Update copyright year > - Update links in java.base to use https:// @JoKern65 Can you have a look at the AIX link? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2602830677 From ihse at openjdk.org Mon Jan 20 16:28:44 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 20 Jan 2025 16:28:44 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bj?rsn?s wrote: >> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. >> >> Links in `java.security` and `share/data/tzdata` are excluded from this PR. >> >> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. >> >> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). >> >> Changes beyond the obvious are as follows: >> >> `linux/native/libsimdsort/xss-common-qsort.h`: >> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170 >> >> `share/man/keytool.1`: >> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well? >> >> `unix/classes/sun/net/PortConfig.java` >> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. >> >> `unix/native/libjava/*`, >> Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs >> >> `unix/native/libjava/ProcessImpl_md.c` >> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to. > > Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into links-use-https > - Re-fix link to "Oracle Java Root Certificate program" in keytool.md > - Merge branch 'master' into links-use-https > > # Conflicts: > # src/java.base/share/man/keytool.1 > - Remove accidental "'" > - Use Wayback link > - Update copyright year > - Update links in java.base to use https:// For the changes in `ProcessImpl_md.c`, I think we'll want to have the input of @RogerRiggs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2602836939 From duke at openjdk.org Mon Jan 20 16:34:15 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 16:34:15 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v4] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > master at 764d70b7df18e288582e616c62b0d7078f1ff3aa > Benchmark Mode Cnt Score Error Units > PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op > PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### > PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op > PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op > PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op > > After: > Benchmark Mode Cnt Score Error Units > PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op > PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### > PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op > PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op > PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: reduce visibility ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/4f8a9a97..0023eb45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=02-03 Stats: 36 lines in 2 files changed: 2 ins; 18 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From duke at openjdk.org Mon Jan 20 16:34:16 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 16:34:16 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 15:00:55 GMT, Maurizio Cimadamore wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> Implementation notes. > > src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java line 75: > >> 73: >> 74: @SuppressWarnings("restricted") >> 75: public static long allocate(long size) { > > I don't think we should expose allocation/release methods (see related comment in `SharedUtils`) Done. These were only visible for the unit test, changed that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922645500 From shade at openjdk.org Mon Jan 20 16:43:08 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jan 2025 16:43:08 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v2] In-Reply-To: References: Message-ID: <00hUbsbC0k4Q12lEVRbIbflJflQPlwH51VHIztwhdxc=.900a197b-3448-40b2-a25b-b124449b42ba@github.com> > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Lazy initialization to avoid bootstrap circularities ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/dc021ce4..0d32ea15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=00-01 Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From shade at openjdk.org Mon Jan 20 16:43:08 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jan 2025 16:43:08 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 20:54:56 GMT, Aleksey Shipilev wrote: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` FTR, wider testing shows two tests that install custom system classloader fail with the following circularity: TEST: runtime/cds/appcds/SpecifySysLoaderProp.java TEST: java/security/SignedJar/SignedJarWithCustomClassLoader.java Caused by: java.lang.IllegalStateException: getSystemClassLoader cannot be called during the system class loader instantiation at java.lang.ClassLoader.getSystemClassLoader(java.base at 25-internal/ClassLoader.java:1849) at jdk.internal.misc.InnocuousThread.newThread(java.base at 25-internal/InnocuousThread.java:68) at jdk.internal.ref.CleanerImpl$InnocuousThreadFactory.newThread(java.base at 25-internal/CleanerImpl.java:208) at jdk.internal.ref.CleanerImpl.start(java.base at 25-internal/CleanerImpl.java:110) at java.lang.ref.Cleaner.create(java.base at 25-internal/Cleaner.java:174) at java.nio.DirectByteBuffer.(java.base at 25-internal/DirectByteBuffer.java:95) at jdk.internal.perf.Perf.createLong(java.base at 25-internal/Native Method) at jdk.internal.perf.PerfCounter.(java.base at 25-internal/PerfCounter.java:63) at jdk.internal.perf.PerfCounter.newPerfCounter(java.base at 25-internal/PerfCounter.java:69) at jdk.internal.perf.PerfCounter$CoreCounters.(java.base at 25-internal/PerfCounter.java:126) at jdk.internal.perf.PerfCounter.getZipFileOpenTime(java.base at 25-internal/PerfCounter.java:176) at java.util.zip.ZipFile.(java.base at 25-internal/ZipFile.java:203) at java.util.zip.ZipFile.(java.base at 25-internal/ZipFile.java:148) at java.util.jar.JarFile.(java.base at 25-internal/JarFile.java:333) at jdk.internal.loader.URLClassPath$JarLoader.getJarFile(java.base at 25-internal/URLClassPath.java:682) at jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(java.base at 25-internal/URLClassPath.java:653) at jdk.internal.loader.URLClassPath$JarLoader.(java.base at 25-internal/URLClassPath.java:622) at jdk.internal.loader.URLClassPath.getLoader(java.base at 25-internal/URLClassPath.java:465) at jdk.internal.loader.URLClassPath.getLoader(java.base at 25-internal/URLClassPath.java:409) at jdk.internal.loader.URLClassPath.getResource(java.base at 25-internal/URLClassPath.java:331) at jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(java.base at 25-internal/BuiltinClassLoader.java:688) at jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(java.base at 25-internal/BuiltinClassLoader.java:620) at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 25-internal/BuiltinClassLoader.java:578) at java.lang.ClassLoader.loadClass(java.base at 25-internal/ClassLoader.java:490) at java.lang.Class.forName0(java.base at 25-internal/Native Method) at java.lang.Class.forName(java.base at 25-internal/Class.java:543) at java.lang.ClassLoader.initSystemClassLoader(java.base at 25-internal/ClassLoader.java:1887) at java.lang.System.initPhase3(java.base at 25-internal/System.java:1964) This can be avoided if we use the lazy holder pattern to delay `Cleaner` initialization until the actual use. Done in new commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2602865622 From duke at openjdk.org Mon Jan 20 16:48:38 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 16:48:38 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 15:03:37 GMT, Maurizio Cimadamore wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> Implementation notes. > > src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java line 97: > >> 95: public static long acquire() { >> 96: // Protect against vthread unmount. >> 97: Continuation.pin(); > > Other code that does this, first checks if we are in a virtual thread. > Note that we have two options for dealing with problematic cases: > * pin/unpin as soon as we see a virtual thread > * if we have a virtual thread and we detect a race in accessing the cache (e.g. because of how the virtual threads have been scheduled to the same underlying carrier thread), we could avoid pinning, but just allocate a fresh new segment (thus avoiding recycling issues) Would be worth understanding why we would _not_ want to pin here. IINM, the `pin` code itself [checks](https://github.com/mernst-github/jdk/blob/f5573f5cbdcae5d1303c8b58d2946c168b977326/src/hotspot/share/opto/library_call.cpp#L3754) whether there's continuation, what would we win by a redundant `if` ? Second, I'm not sure how you would want to detect a race, if you cannot trust any field you just read. I can't see how you would get around using atomics, which is a much more expensive alternative. I designed these to be as short sections as possible (if available, take/null out slot ; if free, put slot; ). If that isn't what pinning is good for, I'm not sure what is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922661817 From shade at openjdk.org Mon Jan 20 16:48:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jan 2025 16:48:49 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v3] In-Reply-To: References: Message-ID: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Visibility and whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/0d32ea15..b115ec46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From jkern at openjdk.org Mon Jan 20 16:53:40 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 20 Jan 2025 16:53:40 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bj?rsn?s wrote: >> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. >> >> Links in `java.security` and `share/data/tzdata` are excluded from this PR. >> >> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. >> >> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). >> >> Changes beyond the obvious are as follows: >> >> `linux/native/libsimdsort/xss-common-qsort.h`: >> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170 >> >> `share/man/keytool.1`: >> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well? >> >> `unix/classes/sun/net/PortConfig.java` >> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. >> >> `unix/native/libjava/*`, >> Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs >> >> `unix/native/libjava/ProcessImpl_md.c` >> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to. > > Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into links-use-https > - Re-fix link to "Oracle Java Root Certificate program" in keytool.md > - Merge branch 'master' into links-use-https > > # Conflicts: > # src/java.base/share/man/keytool.1 > - Remove accidental "'" > - Use Wayback link > - Update copyright year > - Update links in java.base to use https:// I cannot find a better page for ephemeral ports on AIX. For me the new link is OK. The problem is, that such IBM links do not work very long. In one or a view years this link again might point to nirvana. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2602886517 From ihse at openjdk.org Mon Jan 20 16:57:35 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 20 Jan 2025 16:57:35 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:50:29 GMT, Joachim Kern wrote: > The problem is, that such IBM links do not work very long. In one or a view years this link again might point to nirvana. Should we remove it instead then? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2602895229 From dfuchs at openjdk.org Mon Jan 20 17:03:35 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 20 Jan 2025 17:03:35 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: Message-ID: <4YqYCIOH9RQoWhMCkuVC2JbQhzRLBxaFWnv0e_VK8rg=.409cc0ad-2d9b-4078-bd2c-9d6428d3fb6d@github.com> On Mon, 20 Jan 2025 16:55:10 GMT, Magnus Ihse Bursie wrote: > > The problem is, that such IBM links do not work very long. In one or a view years this link again might point to nirvana. > > Should we remove it instead then? I would be OK with just dropping the link. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2602906326 From rriggs at openjdk.org Mon Jan 20 17:15:41 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 20 Jan 2025 17:15:41 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: Message-ID: <8tyc5YtyUIp3AiJc6lZ1FoqfPgYXeG8-8rgHbMOGv_Q=.77908a0d-04d9-4947-a051-95fb76123360@github.com> On Fri, 17 Jan 2025 18:38:25 GMT, Eirik Bj?rsn?s wrote: >> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. >> >> Links in `java.security` and `share/data/tzdata` are excluded from this PR. >> >> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. >> >> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). >> >> Changes beyond the obvious are as follows: >> >> `linux/native/libsimdsort/xss-common-qsort.h`: >> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170 >> >> `share/man/keytool.1`: >> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well? >> >> `unix/classes/sun/net/PortConfig.java` >> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. >> >> `unix/native/libjava/*`, >> Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs >> >> `unix/native/libjava/ProcessImpl_md.c` >> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to. > > Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into links-use-https > - Re-fix link to "Oracle Java Root Certificate program" in keytool.md > - Merge branch 'master' into links-use-https > > # Conflicts: > # src/java.base/share/man/keytool.1 > - Remove accidental "'" > - Use Wayback link > - Update copyright year > - Update links in java.base to use https:// In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process handling. I suggest removing the "unofficial" link, it does not include useful information at this point and is fragile. The current behavior always setting SIGCHLD to SIG_DFL is/has been reliable and does not depend on the behavior of the parent process. (Good) @tstuefe May also be interested in reviewing this change. The previous sentence mentions Solaris and that should be removed at some point but out of scope for this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2602929475 From swen at openjdk.org Mon Jan 20 17:24:41 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 20 Jan 2025 17:24:41 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v14] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen 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 29 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - fix comments > - use putCharUnaligned > - bug fix > - from rgiulietti > - Coding style consistency, from rgiulietti > - fix benchmark, from rgiulietti > - Coding style consistency, from rgiulietti > - fix comment > - fix comment, from @rgiulietti > - ... and 19 more: https://git.openjdk.org/jdk/compare/38a058da...be1f88ab The UTF16 case is slower on x64 machines, and I think it's worth analyzing why. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2602943909 From jvernee at openjdk.org Mon Jan 20 17:27:40 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 20 Jan 2025 17:27:40 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v3] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:20:20 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> master at 764d70b7df18e288582e616c62b0d7078f1ff3aa >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op >> PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op >> PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op >> PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op >> PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op >> PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op >> PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with three additional commits since the last revision: > > - shift api boundary > - move bench > - revert formatting src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 393: > 391: MemorySegment unscoped = CallBufferCache.acquireOrAllocate(size); > 392: Arena scope = Arena.ofConfined(); > 393: MemorySegment source = unscoped.reinterpret(scope, null); I suggest passing the `scope` to `acquireOrAllocate` as well, so we only need a single call to `reinterpret` (it has an overload that takes both a size and arena. (And I think you can then also remove the `@SuppressWarnings` from this method) src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 395: > 393: MemorySegment source = unscoped.reinterpret(scope, null); > 394: // Preferable we'd like to register this cleanup in the line above > 395: // but it breaks scalar replacement. I have a fix for this issue. Will create a PR. test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 54: > 52: @State(org.openjdk.jmh.annotations.Scope.Thread) > 53: @OutputTimeUnit(TimeUnit.NANOSECONDS) > 54: @Fork(value = 1, jvmArgs = {"-Xlog:gc", "--enable-native-access=ALL-UNNAMED", "-Djava.library.path=micro/native"}) FWIW, unfortunately there is no builtin support to run profilers through `make`. I personally have a separate script that runs the benchmarks.jar: ./build/$CONF/images/jdk/bin/java -jar ./build/$CONF/images/test/micro/benchmarks.jar -prof gc AllocTest.alloc_confined (where `$CONF` is your build configuration) test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 98: > 96: (SegmentAllocator) (_, _) -> dest, > 97: phi); > 98: } Would it be viable to measure just a single invocation? That way we can remove other things like the `asSlice` call, which might introduce noise. test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 99: > 97: phi); > 98: } > 99: return points; I don't think `points` needs to be returned here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922701981 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922701268 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922699935 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922700908 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922698930 From jvernee at openjdk.org Mon Jan 20 17:30:36 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 20 Jan 2025 17:30:36 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v3] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:20:20 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> master at 764d70b7df18e288582e616c62b0d7078f1ff3aa >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op >> PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op >> PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op >> PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op >> PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op >> PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op >> PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with three additional commits since the last revision: > > - shift api boundary > - move bench > - revert formatting src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java line 41: > 39: // Storing addresses, not MemorySegments turns out to be slightly faster (write barrier?). > 40: private long address1; > 41: private long address2; Can we store just `MemorySegment`s here? It would avoid having to call `ofAddress` in `acquireOrAllocate`, and would slightly reduce the footprint when using compressed oops. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922704992 From rgiulietti at openjdk.org Mon Jan 20 17:31:41 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 20 Jan 2025 17:31:41 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v14] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen 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 29 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - fix comments > - use putCharUnaligned > - bug fix > - from rgiulietti > - Coding style consistency, from rgiulietti > - fix benchmark, from rgiulietti > - Coding style consistency, from rgiulietti > - fix comment > - fix comment, from @rgiulietti > - ... and 19 more: https://git.openjdk.org/jdk/compare/66be45fb...be1f88ab Do you prefer to postpone that analysis to a followup PR, so that we can integrate this one and move on? Up to you ;-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2602954310 From mcimadamore at openjdk.org Mon Jan 20 17:37:40 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Jan 2025 17:37:40 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v4] In-Reply-To: References: Message-ID: <6Ls4U6AiL-otOkXLteEvGmwR-pC_7ZyBGDkvL1upLGY=.be9acef7-32e1-4d15-8ce7-6f838491fe71@github.com> On Mon, 20 Jan 2025 16:34:15 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> master at 764d70b7df18e288582e616c62b0d7078f1ff3aa >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op >> PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op >> PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op >> PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op >> PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### >> PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op >> PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op >> PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > reduce visibility src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java line 112: > 110: > 111: @SuppressWarnings("restricted") > 112: public static MemorySegment acquireOrAllocate(long requestedSize) { An even higher-level alternative here would be for this method to return a custom arena, whose `close` implementation does the `release`. This way, no cleanup action is needed. The arena could use a slicing allocator on a pre-allocated, per-thread segment. If the segment is not big enough for the allocation the linker wants to do, we can just return a plain confined arena. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922709682 From mcimadamore at openjdk.org Mon Jan 20 17:37:41 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 Jan 2025 17:37:41 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v4] In-Reply-To: <6Ls4U6AiL-otOkXLteEvGmwR-pC_7ZyBGDkvL1upLGY=.be9acef7-32e1-4d15-8ce7-6f838491fe71@github.com> References: <6Ls4U6AiL-otOkXLteEvGmwR-pC_7ZyBGDkvL1upLGY=.be9acef7-32e1-4d15-8ce7-6f838491fe71@github.com> Message-ID: On Mon, 20 Jan 2025 17:33:01 GMT, Maurizio Cimadamore wrote: > An even higher-level alternative here would be for this method to return a custom arena, whose `close` implementation does the `release`. This way, no cleanup action is needed. The arena could use a slicing allocator on a pre-allocated, per-thread segment. If the segment is not big enough for the allocation the linker wants to do, we can just return a plain confined arena. The observation here is that you have an acquire/release "lifetime". And then you have a client that wants to use the Arena API. So we could actually fold these two use cases, and create an Arena that has a better allocation strategy (because it recycles memory) and does the right thing when it is closed. This is kind of why custom arenas were allowed by the FFM API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922711068 From alanb at openjdk.org Mon Jan 20 17:39:37 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 20 Jan 2025 17:39:37 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v3] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:48:49 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Visibility and whitespace No objection to move this to use jl.ref.Cleaner. Note that the long standing recommendation has always been to cache/reuse direct buffers rather than discard like the reproducer does. Now that the FFM API is permanent then we should redirect developers looking for deterministic release to use the new API and they can get a BB view if needed. I assume you'll update the copyright header before this change is integrated. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 86: > 84: Bits.unreserveMemory(size, capacity); > 85: } catch (Throwable x) { > 86: // Old jdk.internal.ref.Cleaner behavior: when it fails, VM exits. I'd prefer not reference a class that no longer exists, instead just say that it preserves long standing behavior exit the VM. In the case of DBB, I can't think what exceptions/errors are possible here. src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 100: > 98: private static final Cleaner CLEANER = Cleaner.create(); > 99: > 100: public static Cleanable register(Object buffer, Runnable action) { Why is this public? ------------- PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2562893777 PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1922695881 PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1922696432 From duke at openjdk.org Mon Jan 20 17:59:14 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 17:59:14 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v5] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > master at 764d70b7df18e288582e616c62b0d7078f1ff3aa > Benchmark Mode Cnt Score Error Units > PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op > PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### > PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op > PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op > PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op > > After: > Benchmark Mode Cnt Score Error Units > PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op > PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### > PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op > PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op > PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: remove stray -Xlog:gc test single call overhead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/0023eb45..f68a930b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=03-04 Stats: 38 lines in 2 files changed: 0 ins; 17 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From duke at openjdk.org Mon Jan 20 17:59:15 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 17:59:15 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v3] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 17:22:09 GMT, Jorn Vernee wrote: >> Matthias Ernst has updated the pull request incrementally with three additional commits since the last revision: >> >> - shift api boundary >> - move bench >> - revert formatting > > test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 54: > >> 52: @State(org.openjdk.jmh.annotations.Scope.Thread) >> 53: @OutputTimeUnit(TimeUnit.NANOSECONDS) >> 54: @Fork(value = 1, jvmArgs = {"-Xlog:gc", "--enable-native-access=ALL-UNNAMED", "-Djava.library.path=micro/native"}) > > FWIW, unfortunately there is no builtin support to run profilers through `make`. I personally have a separate script that runs the benchmarks.jar: > > > ./build/$CONF/images/jdk/bin/java -jar ./build/$CONF/images/test/micro/benchmarks.jar -prof gc AllocTest.alloc_confined > > > (where `$CONF` is your build configuration) Removed. > test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 98: > >> 96: (SegmentAllocator) (_, _) -> dest, >> 97: phi); >> 98: } > > Would it be viable to measure just a single invocation? That way we can remove other things like the `asSlice` call, which might introduce noise. Done. Numbers are now: Benchmark Mode Cnt Score Error Units CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op > test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 99: > >> 97: phi); >> 98: } >> 99: return points; > > I don't think `points` needs to be returned here? Removed. I wanted to be conservative and give the "blackhole" something to work with, but I guess it can't optimize away an FFM call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922727695 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922728050 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922727507 From uschindler at openjdk.org Mon Jan 20 18:06:35 2025 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 20 Jan 2025 18:06:35 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v3] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 16:48:49 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Visibility and whitespace Marked as reviewed by uschindler (Author). This looks fine for me. Older Lucene versions won't break, as they use `sun.misc.Unsafe#invokeCleaner()` which behaves as before. Code that deep reflected and made `DirectByteBuffer#cleaner()` accessible was broken for long time anyways (since Java 9), so the new names and class types should not affect uptodate code. I'd remove the `catch (Throwable)` => exit VM code completely. The called methods have no checked exceptions. If the deallocation fails for some (internal) reason it its already broken and a crush will come sooner or later anyways. ------------- PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2562957601 PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2603003680 From duke at openjdk.org Mon Jan 20 18:13:54 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 18:13:54 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v4] In-Reply-To: References: <6Ls4U6AiL-otOkXLteEvGmwR-pC_7ZyBGDkvL1upLGY=.be9acef7-32e1-4d15-8ce7-6f838491fe71@github.com> Message-ID: On Mon, 20 Jan 2025 17:34:45 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java line 112: >> >>> 110: >>> 111: @SuppressWarnings("restricted") >>> 112: public static MemorySegment acquireOrAllocate(long requestedSize) { >> >> An even higher-level alternative here would be for this method to return a custom arena, whose `close` implementation does the `release`. This way, no cleanup action is needed. The arena could use a slicing allocator on a pre-allocated, per-thread segment. If the segment is not big enough for the allocation the linker wants to do, we can just return a plain confined arena. > >> An even higher-level alternative here would be for this method to return a custom arena, whose `close` implementation does the `release`. This way, no cleanup action is needed. The arena could use a slicing allocator on a pre-allocated, per-thread segment. If the segment is not big enough for the allocation the linker wants to do, we can just return a plain confined arena. > > The observation here is that you have an acquire/release "lifetime". And then you have a client (the Linker) that wants to use the Arena API. So we could actually fold these two use cases, and create an Arena that has a better allocation strategy (because it recycles memory) and does the right thing when it is closed. This is kind of why custom arenas were allowed by the FFM API. Maybe that's possible - I would at this point try to avoid making it too general. I really only want to satisfy the Linker here, I only moved this code out of the boundedArea method because of code size. I think this version sets a good bar here for the overhead of a call-with-buffer: 5.5ns (over 3.3 w/o buffer) and zero allocations; we can work against that with new designs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922732833 From duke at openjdk.org Mon Jan 20 18:13:53 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 18:13:53 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v6] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > master at 764d70b7df18e288582e616c62b0d7078f1ff3aa > Benchmark Mode Cnt Score Error Units > PointsAlloc.circle_by_ptr avgt 30 9.197 ? 0.037 ns/op > PointsAlloc.circle_by_value avgt 30 42.195 ? 0.088 ns/op <= ####### > PointsAlloc.jni_ByteBuffer_alloc avgt 30 226.127 ? 35.378 ns/op > PointsAlloc.jni_long_alloc avgt 30 25.297 ? 2.457 ns/op > PointsAlloc.panama_alloc avgt 30 27.053 ? 1.915 ns/op > > After: > Benchmark Mode Cnt Score Error Units > PointsAlloc.circle_by_ptr avgt 30 9.156 ? 0.021 ns/op > PointsAlloc.circle_by_value avgt 30 11.995 ? 0.051 ns/op <= ####### > PointsAlloc.jni_ByteBuffer_alloc avgt 30 211.161 ? 23.284 ns/op > PointsAlloc.jni_long_alloc avgt 30 24.885 ? 2.461 ns/op > PointsAlloc.panama_alloc avgt 30 26.905 ? 1.935 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: whitespace :scream: ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/f68a930b..a523278a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From duke at openjdk.org Mon Jan 20 18:13:54 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 18:13:54 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v3] In-Reply-To: References: Message-ID: <3ZnEuyCuFaNwr_y6_Q6MMw4iaMgcfsJKGBS7qjUe5Yo=.6d72ff3a-957e-47cc-a8b5-6ce5056cda3a@github.com> On Mon, 20 Jan 2025 17:27:40 GMT, Jorn Vernee wrote: >> Matthias Ernst has updated the pull request incrementally with three additional commits since the last revision: >> >> - shift api boundary >> - move bench >> - revert formatting > > src/java.base/share/classes/jdk/internal/foreign/abi/CallBufferCache.java line 41: > >> 39: // Storing addresses, not MemorySegments turns out to be slightly faster (write barrier?). >> 40: private long address1; >> 41: private long address2; > > Can we store just `MemorySegment`s here? It would avoid having to call `ofAddress` in `acquireOrAllocate`, and would slightly reduce the footprint when using compressed oops. That was my original version, but this proved to be faster (albeit very little, O(.5ns)). I can't really explain why, that's above my paygrade, but one thing that comes to mind when storing references is that there's might be a GC barrier involved? Footprint reduction would be 8 bytes * #carrier threads, and with scalar replacement, ofAddress should become a noop, right? Let me re-run the BM once more with pointers, whether I can reproduce. > src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 393: > >> 391: MemorySegment unscoped = CallBufferCache.acquireOrAllocate(size); >> 392: Arena scope = Arena.ofConfined(); >> 393: MemorySegment source = unscoped.reinterpret(scope, null); > > I suggest passing the `scope` to `acquireOrAllocate` as well, so we only need a single call to `reinterpret` (it has an overload that takes both a size and arena. (And I think you can then also remove the `@SuppressWarnings` from this method) I generally agree that would be the right thing to do. But again, this would require creating the scope before the CTL interaction and that breaks EA. Just swapping lines 391 and 392 leads to plenty of allocations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922738090 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922734006 From jvernee at openjdk.org Mon Jan 20 18:17:35 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 20 Jan 2025 18:17:35 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v3] In-Reply-To: <3ZnEuyCuFaNwr_y6_Q6MMw4iaMgcfsJKGBS7qjUe5Yo=.6d72ff3a-957e-47cc-a8b5-6ce5056cda3a@github.com> References: <3ZnEuyCuFaNwr_y6_Q6MMw4iaMgcfsJKGBS7qjUe5Yo=.6d72ff3a-957e-47cc-a8b5-6ce5056cda3a@github.com> Message-ID: On Mon, 20 Jan 2025 18:09:56 GMT, Matthias Ernst wrote: > Footprint reduction would be 8 bytes * #carrier threads, and with scalar replacement, ofAddress should become a noop, right? Yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922741985 From duke at openjdk.org Mon Jan 20 18:29:36 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 18:29:36 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v3] In-Reply-To: References: <3ZnEuyCuFaNwr_y6_Q6MMw4iaMgcfsJKGBS7qjUe5Yo=.6d72ff3a-957e-47cc-a8b5-6ce5056cda3a@github.com> Message-ID: On Mon, 20 Jan 2025 18:15:11 GMT, Jorn Vernee wrote: >> That was my original version, but this proved to be faster (albeit very little, O(.5ns)). I can't really explain why, that's above my paygrade, but one thing that comes to mind when storing references is that there's might be a GC barrier involved? >> >> Footprint reduction would be 8 bytes * #carrier threads, and with scalar replacement, ofAddress should become a noop, right? >> >> Let me re-run the BM once more with pointers, whether I can reproduce. > >> Footprint reduction would be 8 bytes * #carrier threads, and with scalar replacement, ofAddress should become a noop, right? > > Yes. When moving references in and out of the cache slots, I lose .8ns: Benchmark Mode Cnt Score Error Units CallOverheadByValue.byPtr avgt 10 3.283 ? 0.020 ns/op CallOverheadByValue.byValue avgt 10 6.309 ? 0.027 ns/op ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922749824 From jvernee at openjdk.org Mon Jan 20 18:36:37 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 20 Jan 2025 18:36:37 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v6] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 18:13:53 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > whitespace :scream: test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 54: > 52: @State(org.openjdk.jmh.annotations.Scope.Thread) > 53: @OutputTimeUnit(TimeUnit.NANOSECONDS) > 54: @Fork(value = 1, jvmArgs = {"--enable-native-access=ALL-UNNAMED", "-Djava.library.path=micro/native"}) Please set the fork value to at least 3, so we can spot bimodal results. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922753705 From jvernee at openjdk.org Mon Jan 20 18:36:37 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 20 Jan 2025 18:36:37 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v6] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 18:32:55 GMT, Jorn Vernee wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace :scream: > > test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 54: > >> 52: @State(org.openjdk.jmh.annotations.Scope.Thread) >> 53: @OutputTimeUnit(TimeUnit.NANOSECONDS) >> 54: @Fork(value = 1, jvmArgs = {"--enable-native-access=ALL-UNNAMED", "-Djava.library.path=micro/native"}) > > Please set the fork value to at least 3, so we can spot bimodal results. Actually, on my machine I'm already seeing some bimodal results, where sometimes the `byValue` case takes twice as long. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922754343 From egahlin at openjdk.org Mon Jan 20 18:41:39 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 20 Jan 2025 18:41:39 GMT Subject: RFR: 8310996: Add JFR event for connect operations [v5] In-Reply-To: References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com> <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com> <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com> <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com> Message-ID: On Thu, 19 Dec 2024 19:16:55 GMT, Erik Gahlin wrote: >> I'm not sure if one or two events are most suitable. If possible, I would like to discuss it with Markus to get some more input. He will back in January. > > Regarding one or two events. I'm fine with integrating as-is and then revisit it before FC, if needed. I talked to Markus, and we think two events would provide the greatest flexibility for future settings and events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1922757394 From duke at openjdk.org Mon Jan 20 18:43:54 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 18:43:54 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v7] In-Reply-To: References: Message-ID: <9BRvcyOSfKcjiPpulF8669ISy36DjH71DGudiOIwFtw=.6259a2c8-250f-4ae4-bbd4-2bc96d64177f@github.com> > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op > CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: restore 3 forks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/a523278a..5a8491f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From jvernee at openjdk.org Mon Jan 20 18:43:55 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 20 Jan 2025 18:43:55 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v6] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 18:13:53 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > whitespace :scream: test/jdk/java/foreign/CallBufferCacheTest.java line 95: > 93: assertTrue(CallBufferCache.release(address)); > 94: assertEquals(address, CallBufferCache.acquire()); > 95: Thread.ofPlatform().start(() -> { Should this have been `ofVirtual`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922757512 From duke at openjdk.org Mon Jan 20 18:43:55 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 18:43:55 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v6] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 18:33:55 GMT, Jorn Vernee wrote: >> test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 54: >> >>> 52: @State(org.openjdk.jmh.annotations.Scope.Thread) >>> 53: @OutputTimeUnit(TimeUnit.NANOSECONDS) >>> 54: @Fork(value = 1, jvmArgs = {"--enable-native-access=ALL-UNNAMED", "-Djava.library.path=micro/native"}) >> >> Please set the fork value to at least 3, so we can spot bimodal results. > > Actually, on my machine I'm already seeing some bimodal results, where sometimes the `byValue` case takes twice as long. Done. I've been seeing stable results. Benchmark Mode Cnt Score Error Units CallOverheadByValue.byPtr avgt 30 3.344 ? 0.074 ns/op CallOverheadByValue.byValue avgt 30 5.496 ? 0.054 ns/op ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922759333 From duke at openjdk.org Mon Jan 20 18:47:37 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 20 Jan 2025 18:47:37 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v6] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 18:39:06 GMT, Jorn Vernee wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace :scream: > > test/jdk/java/foreign/CallBufferCacheTest.java line 95: > >> 93: assertTrue(CallBufferCache.release(address)); >> 94: assertEquals(address, CallBufferCache.acquire()); >> 95: Thread.ofPlatform().start(() -> { > > Should this have been `ofVirtual`? No, the point is that a virtual thread might take a segment while on carrier #1 but return on carrier #2 (moved between native call stub return but before call recipe closes the arena). This test is trying to emulate that, i.e. afterwards carrier #2 owns and returns and carrier #1 doesn't know it anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1922761016 From shade at openjdk.org Mon Jan 20 19:12:22 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jan 2025 19:12:22 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v4] In-Reply-To: References: Message-ID: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Review feedback and benchmarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/b115ec46..f8ecbd60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=02-03 Stats: 116 lines in 7 files changed: 108 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From shade at openjdk.org Mon Jan 20 19:12:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jan 2025 19:12:23 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v3] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 17:37:19 GMT, Alan Bateman wrote: > Note that the long standing recommendation has always been to cache/reuse direct buffers rather than discard like the reproducer does The reproducer is likely overly simplistic. The performance problem we are solving is non-parallelism in GC when processing backing Cleaner lists. Actually, this reminds me that I need to add direct churn/GC tests like we did for [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704) to verify the DBB-like scenarios also improve. I pushed some benchmarks, going to see how they perform now. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 86: > >> 84: Bits.unreserveMemory(size, capacity); >> 85: } catch (Throwable x) { >> 86: // Old jdk.internal.ref.Cleaner behavior: when it fails, VM exits. > > I'd prefer not reference a class that no longer exists, instead just say that it preserves long standing behavior exit the VM. In the case of DBB, I can't think what exceptions/errors are possible here. Amended the comment. > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 100: > >> 98: private static final Cleaner CLEANER = Cleaner.create(); >> 99: >> 100: public static Cleanable register(Object buffer, Runnable action) { > > Why is this public? It is a public method in a private nested class. This method is used from the enclosing class, so private would be weird? I can drop public, though, let it be package-private. Done in new commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2603094715 PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1922775259 PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1922775141 From stuefe at openjdk.org Mon Jan 20 19:37:37 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 20 Jan 2025 19:37:37 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: <8tyc5YtyUIp3AiJc6lZ1FoqfPgYXeG8-8rgHbMOGv_Q=.77908a0d-04d9-4947-a051-95fb76123360@github.com> References: <8tyc5YtyUIp3AiJc6lZ1FoqfPgYXeG8-8rgHbMOGv_Q=.77908a0d-04d9-4947-a051-95fb76123360@github.com> Message-ID: On Mon, 20 Jan 2025 17:13:19 GMT, Roger Riggs wrote: > In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process handling. I suggest removing the "unofficial" link, it does not include useful information at this point and is fragile. > > The current behavior always setting SIGCHLD to SIG_DFL is/has been reliable and does not depend on the behavior of the parent process. (Good) @tstuefe May also be interested in reviewing this change. https://pubs.opengroup.org/onlinepubs/9799919799/ seems to indicate that the "default action is to ignore the signal", which is unclear to me. I think it means that the signal will not cause invocation of a user handler or abort the process, but does this also mean that wait and waited won't work? In any case, I agree with @RogerRiggs that keeping this behavior is fine. > > The previous sentence mentions Solaris and that should be removed at some point but out of scope for this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2603125595 From ihse at openjdk.org Mon Jan 20 21:32:38 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 20 Jan 2025 21:32:38 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: <8tyc5YtyUIp3AiJc6lZ1FoqfPgYXeG8-8rgHbMOGv_Q=.77908a0d-04d9-4947-a051-95fb76123360@github.com> Message-ID: On Mon, 20 Jan 2025 19:34:53 GMT, Thomas Stuefe wrote: >> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process handling. >> I suggest removing the "unofficial" link, it does not include useful information at this point and is fragile. >> >> The current behavior always setting SIGCHLD to SIG_DFL is/has been reliable and does not depend on the behavior of the parent process. (Good) >> @tstuefe May also be interested in reviewing this change. >> >> The previous sentence mentions Solaris and that should be removed at some point but out of scope for this PR. > >> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process handling. I suggest removing the "unofficial" link, it does not include useful information at this point and is fragile. >> >> The current behavior always setting SIGCHLD to SIG_DFL is/has been reliable and does not depend on the behavior of the parent process. (Good) @tstuefe May also be interested in reviewing this change. > > https://pubs.opengroup.org/onlinepubs/9799919799/ seems to indicate that the "default action is to ignore the signal", which is unclear to me. I think it means that the signal will not cause invocation of a user handler or abort the process, but does this also mean that wait and waited won't work? > > In any case, I agree with @RogerRiggs that keeping this behavior is fine. > >> >> The previous sentence mentions Solaris and that should be removed at some point but out of scope for this PR. @tstuefe And you also agree that the link should be removed? (Which is what this PR is about) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2603253756 From jkern at openjdk.org Mon Jan 20 22:20:35 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 20 Jan 2025 22:20:35 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: <4YqYCIOH9RQoWhMCkuVC2JbQhzRLBxaFWnv0e_VK8rg=.409cc0ad-2d9b-4078-bd2c-9d6428d3fb6d@github.com> References: <4YqYCIOH9RQoWhMCkuVC2JbQhzRLBxaFWnv0e_VK8rg=.409cc0ad-2d9b-4078-bd2c-9d6428d3fb6d@github.com> Message-ID: On Mon, 20 Jan 2025 17:01:10 GMT, Daniel Fuchs wrote: > > > The problem is, that such IBM links do not work very long. In one or a view years this link again might point to nirvana. > > > > > > Should we remove it instead then? > > I would be OK with just dropping the link. I would keep the link, because currently it is good, but be aware to fix it again in one of the next jdk versions. Maybe you can copy the essentials of the IBM page regarding ephemeral ports as comment to `PortConfig.java` with the link as citation mark. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2603299795 From duke at openjdk.org Mon Jan 20 23:12:40 2025 From: duke at openjdk.org (duke) Date: Mon, 20 Jan 2025 23:12:40 GMT Subject: Withdrawn: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler In-Reply-To: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> Message-ID: On Mon, 28 Oct 2024 18:45:59 GMT, Tom Rodriguez wrote: > Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309. In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure. Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21745 From never at openjdk.org Tue Jan 21 03:07:41 2025 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 21 Jan 2025 03:07:41 GMT Subject: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v2] In-Reply-To: References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> Message-ID: On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez wrote: >> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309. In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure. Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt. > > Tom Rodriguez 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: > > - adjust OOMEInStampedLock.java too > - Merge branch 'master' into tkr-oomeinaqs-ea > - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler @AlanBateman Could you take a look at this one? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2603529376 From swen at openjdk.org Tue Jan 21 03:08:47 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 21 Jan 2025 03:08:47 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v14] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 17:28:40 GMT, Raffaello Giulietti wrote: >> Shaojin Wen 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 29 additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 >> - fix comments >> - use putCharUnaligned >> - bug fix >> - from rgiulietti >> - Coding style consistency, from rgiulietti >> - fix benchmark, from rgiulietti >> - Coding style consistency, from rgiulietti >> - fix comment >> - fix comment, from @rgiulietti >> - ... and 19 more: https://git.openjdk.org/jdk/compare/e8af273a...be1f88ab > > Do you prefer to postpone that analysis to a followup PR, so that we can integrate this one and move on? > Up to you ;-) Thanks @rgiulietti I found out that the reason for the slowdown on x64 may not be related to the changes in this PR, because I reverted the code to (d22a28607edba719850af807934ac39a7c332d13) in the current PR branch, and the performance is the same. I suspect that the master version C2 has new optimizations. I think it can be integrated, and further optimization can be put in the next step. My next optimization plan is to change the length of DIGITS to 128 and use `DIGITS[v & 0x7f]` to eliminate array bounds checks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2603529847 From stuefe at openjdk.org Tue Jan 21 06:54:35 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jan 2025 06:54:35 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: <8tyc5YtyUIp3AiJc6lZ1FoqfPgYXeG8-8rgHbMOGv_Q=.77908a0d-04d9-4947-a051-95fb76123360@github.com> Message-ID: On Mon, 20 Jan 2025 19:34:53 GMT, Thomas Stuefe wrote: >> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process handling. >> I suggest removing the "unofficial" link, it does not include useful information at this point and is fragile. >> >> The current behavior always setting SIGCHLD to SIG_DFL is/has been reliable and does not depend on the behavior of the parent process. (Good) >> @tstuefe May also be interested in reviewing this change. >> >> The previous sentence mentions Solaris and that should be removed at some point but out of scope for this PR. > >> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process handling. I suggest removing the "unofficial" link, it does not include useful information at this point and is fragile. >> >> The current behavior always setting SIGCHLD to SIG_DFL is/has been reliable and does not depend on the behavior of the parent process. (Good) @tstuefe May also be interested in reviewing this change. > > https://pubs.opengroup.org/onlinepubs/9799919799/ seems to indicate that the "default action is to ignore the signal", which is unclear to me. I think it means that the signal will not cause invocation of a user handler or abort the process, but does this also mean that wait and waited won't work? > > In any case, I agree with @RogerRiggs that keeping this behavior is fine. > >> >> The previous sentence mentions Solaris and that should be removed at some point but out of scope for this PR. > @tstuefe And you also agree that the link should be removed? (Which is what this PR is about) The 20+ years old link to the PASC error report I would probably remove; it is likely outdated now. If one wanted to invest the time, one could test the current behavior on our supported Unices. As long as that is not done, we can live with setting SIG_DFL manually. I would replace it with a link to https://pubs.opengroup.org/onlinepubs/007904875/functions/wait.html and point to the section that says: [XSI] [Option Start] If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, and the process has no unwaited-for children that were transformed into zombie processes, the calling thread shall block until all of the children of the process containing the calling thread terminate, and wait() and waitpid() shall fail and set errno to [ECHILD]. [Option End] Again, that is XSI though; I am not sure which of our Unices comply to that. Linux does only partially, so one would have to test that behavior. Another question @RogerRiggs , I was surprised to see that we set the SIGCHLD default behavior only at Java_java_lang_ProcessImpl_init. Should we also set it in jspawnhelper before the exec? But I guess the assumption is that no java process will fork before Java_java_lang_ProcessImpl_init, so maybe its okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2603796226 From clanger at openjdk.org Tue Jan 21 07:52:34 2025 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 21 Jan 2025 07:52:34 GMT Subject: RFR: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote: > This PR reverts the fix from [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it increases the runtime of the test a lot. > Instead a full gc is requested via the whitebox api. This solves the issues (see bug description) and it is also clearer and more reliable then allocating objects and classes expecting a gc because of the small heap. > The heap setting is also removed since it is not needed anymore. > > #### Testing: Duration Running HiddenClassUnloading with fastdebug Builds > > I'm giving the minimum of a few runs because durations vary by +/- 10s. > > > Linux / x86_64: > After JDK-8339166: 3m15s > JDK-8339166 reverted: 50s > PR: 50s > > macOS / M1: > After JDK-8339166: 2m30s > JDK-8339166 reverted: 30s > PR: 30s > > Linux / ppc64le > After JDK-8339166: 12m30s > JDK-8339166 reverted: 2m30s (failure: no classes unloaded) > PR: 2m30s (success) Looks great, thanks for the fix. You should update the copyright years. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23137#pullrequestreview-2563712644 From mbaesken at openjdk.org Tue Jan 21 08:16:35 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 21 Jan 2025 08:16:35 GMT Subject: RFR: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote: > This PR reverts the fix from [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it increases the runtime of the test a lot. > Instead a full gc is requested via the whitebox api. This solves the issues (see bug description) and it is also clearer and more reliable then allocating objects and classes expecting a gc because of the small heap. > The heap setting is also removed since it is not needed anymore. > > #### Testing: Duration Running HiddenClassUnloading with fastdebug Builds > > I'm giving the minimum of a few runs because durations vary by +/- 10s. > > > Linux / x86_64: > After JDK-8339166: 3m15s > JDK-8339166 reverted: 50s > PR: 50s > > macOS / M1: > After JDK-8339166: 2m30s > JDK-8339166 reverted: 30s > PR: 30s > > Linux / ppc64le > After JDK-8339166: 12m30s > JDK-8339166 reverted: 2m30s (failure: no classes unloaded) > PR: 2m30s (success) LGTM; probably you do not need 2000 iterations now with the full GC, a smaller number would do as well, correct ? But it is okay for me as it is. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23137#pullrequestreview-2563767103 From rgiulietti at openjdk.org Tue Jan 21 08:29:45 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 21 Jan 2025 08:29:45 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v14] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen 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 29 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - fix comments > - use putCharUnaligned > - bug fix > - from rgiulietti > - Coding style consistency, from rgiulietti > - fix benchmark, from rgiulietti > - Coding style consistency, from rgiulietti > - fix comment > - fix comment, from @rgiulietti > - ... and 19 more: https://git.openjdk.org/jdk/compare/311fe402...be1f88ab Thanks @wenshao for your contribution. ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22023#pullrequestreview-2563806325 From rgiulietti at openjdk.org Tue Jan 21 08:34:39 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 21 Jan 2025 08:34:39 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v8] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 04:08:28 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix comment > > Always good to see some methods removed from `JavaLangAccess` - but it appears these are already unused? > > I think the performance gain from this is somewhat underwhelming. `Unsafe` is a big hammer to eek out ~10% performance in an isolated code path. > > And perhaps it would be better to just push the microbenchmark, any code cleanups (like the removal of unused methods from JavaLangAccess) and leave code unchanged and leave it as a challenge for JIT engineers to get the pre-existing code to parity with this `Unsafe` routine. > > That said I'm ok with this as is but will request a second opinion. Maybe @rgiulietti can weigh in? @cl4es I think you need to re-review for this PR to move to 100% approved ------------- PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2603964029 From rrich at openjdk.org Tue Jan 21 08:46:35 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Tue, 21 Jan 2025 08:46:35 GMT Subject: RFR: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 08:14:22 GMT, Matthias Baesken wrote: > LGTM; probably you do not need 2000 iterations now with the full GC, a smaller number would do as well, correct ? But it is okay for me as it is. Thanks for reviewing. I've tried 1000 iterations but the runtime hardly changed so I revert back to the original 2000 iterations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23137#issuecomment-2603992711 From rafael.wth at gmail.com Tue Jan 21 09:17:35 2025 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 21 Jan 2025 10:17:35 +0100 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: <1054038972.68527184.1737299922796.JavaMail.zimbra@univ-eiffel.fr> References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> <1054038972.68527184.1737299922796.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Wouldn't this already be possible with today's union types? static & SequencedSet> S of(E... elements) { ... } Then again, I do not think that the regular Set and Map implementations should be sequenced, mainly to avoid that tests suffer from this sequencing. Am So., 19. Jan. 2025 um 16:18 Uhr schrieb Remi Forax : > What can be done is to have Set.of()/Map.of() to delegate to > SequenceSet.of()/SequenceMap.of() so there is only one implementation at > runtime. > > Also, technically, there is a way to change the return type in a binary > compatible way ... if union types are supported in the language. > In that case, Set.of() can be declared like this > > static Set | SequenceSet of(E... ) { > ... > } > > because of erasure, the binary descriptor will use Set, but the Signature > will be Set | SequenceSet so the compiler will see the return type > as a SequencedSet . > > Obviously, union types is a far bigger features than adding > SequenceSet/SequenceMap so it's a big if, but it may happen in the future. > > R?mi > > ------------------------------ > > *From: *"joe darcy" > *To: *"core-libs-dev" > *Sent: *Friday, January 17, 2025 6:30:40 PM > *Subject: *Re: Factory methods for SequencedSet and SequencedMap > > On 1/16/2025 11:26 PM, Rafael Winterhalter wrote: > > > Would it even be possible to change the return types of Set.of(...) and > Map.of(...) without breaking binary compatibility? > > > In short, no. > > > [...] > > > -Joe > > > R?mi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdoerr at openjdk.org Tue Jan 21 09:37:34 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 21 Jan 2025 09:37:34 GMT Subject: RFR: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote: > This PR reverts the fix from [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it increases the runtime of the test a lot. > Instead a full gc is requested via the whitebox api. This solves the issues (see bug description) and it is also clearer and more reliable then allocating objects and classes expecting a gc because of the small heap. > The heap setting is also removed since it is not needed anymore. > > #### Testing: Duration Running HiddenClassUnloading with fastdebug Builds > > I'm giving the minimum of a few runs because durations vary by +/- 10s. > > > Linux / x86_64: > After JDK-8339166: 3m15s > JDK-8339166 reverted: 50s > PR: 50s > > macOS / M1: > After JDK-8339166: 2m30s > JDK-8339166 reverted: 30s > PR: 30s > > Linux / ppc64le > After JDK-8339166: 12m30s > JDK-8339166 reverted: 2m30s (failure: no classes unloaded) > PR: 2m30s (success) LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23137#pullrequestreview-2564004167 From shade at openjdk.org Tue Jan 21 09:46:58 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jan 2025 09:46:58 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v5] In-Reply-To: References: Message-ID: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Amend benchmarks - Fix tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/f8ecbd60..d33e9eb8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=03-04 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From shade at openjdk.org Tue Jan 21 09:46:58 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jan 2025 09:46:58 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v4] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 19:12:22 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback and benchmarks Benchmark data on new benchmarks: Benchmark (count) (recipFreq) Mode Cnt Score Error Units # Before DirectByteBufferChurn.test N/A 128 avgt 9 11.852 ? 0.505 ns/op DirectByteBufferChurn.test N/A 256 avgt 9 9.107 ? 0.695 ns/op DirectByteBufferChurn.test N/A 512 avgt 9 7.643 ? 0.480 ns/op DirectByteBufferChurn.test N/A 1024 avgt 9 7.091 ? 0.183 ns/op DirectByteBufferChurn.test N/A 2048 avgt 9 6.734 ? 0.184 ns/op DirectByteBufferGC.test 16384 N/A avgt 9 3.122 ? 0.028 ms/op DirectByteBufferGC.test 65536 N/A avgt 9 6.079 ? 0.111 ms/op DirectByteBufferGC.test 262144 N/A avgt 9 16.892 ? 0.705 ms/op DirectByteBufferGC.test 1048576 N/A avgt 9 156.980 ? 9.673 ms/op DirectByteBufferGC.test 4194304 N/A avgt 9 725.576 ? 49.363 ms/op # After DirectByteBufferChurn.test N/A 128 avgt 9 8.697 ? 0.742 ns/op ; <--- DirectByteBufferChurn.test N/A 256 avgt 9 7.557 ? 0.353 ns/op ; <--- DirectByteBufferChurn.test N/A 512 avgt 9 7.074 ? 0.268 ns/op ; <--- DirectByteBufferChurn.test N/A 1024 avgt 9 6.853 ? 0.272 ns/op DirectByteBufferChurn.test N/A 2048 avgt 9 6.688 ? 0.298 ns/op DirectByteBufferGC.test 16384 N/A avgt 9 3.197 ? 0.231 ms/op DirectByteBufferGC.test 65536 N/A avgt 9 5.442 ? 0.323 ms/op DirectByteBufferGC.test 262144 N/A avgt 9 16.967 ? 0.485 ms/op DirectByteBufferGC.test 1048576 N/A avgt 9 50.613 ? 2.107 ms/op ; <--- DirectByteBufferGC.test 4194304 N/A avgt 9 343.177 ? 20.655 ms/op ; <--- ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2604187764 From duke at openjdk.org Tue Jan 21 09:53:47 2025 From: duke at openjdk.org (duke) Date: Tue, 21 Jan 2025 09:53:47 GMT Subject: Withdrawn: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote: > c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) > > Summary > ------- > > Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. > > > Problem > ------- > > The JDK is lacking tooling to diagnose issues with virtual threads. > > > Solution > -------- > > Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. > > Here is sample output. The output is intended for experts and is not intended for automated parsing. > > > Virtual thread scheduler: > java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] > > Timeout schedulers: > [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] > [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > > Read I/O pollers: > [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] > > Write I/O pollers: > [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] > > Thread groupings: > [platform threads = 11, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] > ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] > ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] > java.util.concurrent.Scheduled... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22121 From vklang at openjdk.org Tue Jan 21 10:13:51 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 21 Jan 2025 10:13:51 GMT Subject: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v2] In-Reply-To: References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> Message-ID: On Tue, 21 Jan 2025 03:05:06 GMT, Tom Rodriguez wrote: >> Tom Rodriguez 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: >> >> - adjust OOMEInStampedLock.java too >> - Merge branch 'master' into tkr-oomeinaqs-ea >> - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler > > @AlanBateman Could you take a look at this one? @tkrodriguez I'm a bit hesitant about the proposed change?it sounds to me like it relies too much on implementation details. If EA is decides to treat NTHREADS as effectively final (at some point) then this test will start failing again under Xcomp. What are the alternatives here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2604253649 From viktor.klang at oracle.com Tue Jan 21 10:15:39 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Tue, 21 Jan 2025 10:15:39 +0000 Subject: [External] : Re: Minor optimizations / questions about stream implementation In-Reply-To: References: Message-ID: Hi Daniel, Making changes locally and use the tests to verify your assumptions is a great way to validate your understanding. Then you can use the benches to validate the performance impact of your modifications, then it becomes easier to discuss the pros/cons of potential changes here on the list. That's what I'd do if I were in your shoes. ? Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Daniel Avery Sent: Friday, 17 January 2025 18:06 To: Viktor Klang Cc: core-libs-dev at openjdk.org Subject: [External] : Re: Minor optimizations / questions about stream implementation Hi Viktor. I guess for 1-4 I'm just looking for a quick eyeball to check if my takeaways are valid, nothing too committal. I'm a little more interested in 5, because I'm currently building a document that is attempting to capture how the stream internals fit together, including visualizing stream performance characteristics. How op flags are set/cleared/propagated plays a big part in what I've prepared. I want to make sure I don't oversimplify how they work. I have not attempted to make/test changes to the source. I guess I didn't presume I could contribute in that way, but I can look into it if you think it's worth it :) Thanks, Daniel On Fri, Jan 17, 2025 at 3:32?AM Viktor Klang > wrote: Hi Daniel, Thanks for your patience. What kind of feedback/responses are you looking for primarily? Have you attempted to make changes and run any of the openjdk stream benches (after running the tests)? Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev > on behalf of Daniel Avery > Sent: Friday, 10 January 2025 04:01 To: core-libs-dev at openjdk.org > Subject: Minor optimizations / questions about stream implementation Hi, I recently finished a deep-dive through the code in java.util.stream, and came across a few corners that stuck out to me as being odd, in a "small missed opportunity" kind of way. I figured I'd raise them here just in case any are legitimate, or I could get some better insight. I am looking at JDK 24 [build 30] (https://github.com/openjdk/jdk/tree/jdk-24%2B30/src/java.base/share/classes/java). 1. AbstractPipeline.wrap() is passed isParallel(), which ultimately (only) plays into determining if StreamSpliterators.AbstractWrappingSpliterator is allowed to split. It looks like the code could be more lenient, and instead pass (isParallel() || !hasAnyStateful()), i.e. allow splitting the spliterator() from sequential streams that do not have stateful ops. 2. It looks like StreamSpliterators.UnorderedSliceSpliterator.trySplit() should disable splitting if (permitStatus == NO_MORE), instead of (permits.get() == 0). As is, it would appear to unnecessarily disable splitting after skipping, in the skip-only case. 3. It looks like SortedOps could override opEvaluateParallelLazy to no-op in the already-sorted case, similar to DistinctOps in the already-distinct case. 4. It looks like SliceOps.makeRef() could fuse adjacent skip()/limit() ops (though I could see that being an overly niche optimization, especially if it makes linked/consumed handling painful). 5. It looks like there is some dead code in StreamOpFlag? I don't see a path where isPreserved() would return true in practice (it appears to only be called in exactly 2 'minor optimization' places: SliceTask.doLeaf() and DropWhileTask.doLeaf()). With the way StreamOpFlag.combineOpFlags() works, it looks like in practice 0b00 is used to preserve, rather than 0b11. I also don't see Type.OP, Type.TERMINAL_OP, or Type.UPSTREAM_TERMINAL_OP being used anywhere. I assume some of the methods here are intended for tests only (isStreamFlag(), canSet())... But given how much of this class I'm not seeing being used, I'm wondering if I'm just missing something. Thank you, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Tue Jan 21 11:54:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Jan 2025 11:54:41 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 09:46:58 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Amend benchmarks > - Fix tests Good, I don't have any other comments. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2564379884 From shade at openjdk.org Tue Jan 21 12:55:31 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jan 2025 12:55:31 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v6] In-Reply-To: References: Message-ID: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Track Cleaner progress with canaries ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/d33e9eb8..25cb6453 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=04-05 Stats: 195 lines in 5 files changed: 84 ins; 99 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From shade at openjdk.org Tue Jan 21 12:55:32 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jan 2025 12:55:32 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 09:46:58 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Amend benchmarks > - Fix tests Unfortunately, I am seeing intermittent OOME failures in GHA on `DirectBufferAllocTest`. I managed to reproduce some of these locally. This likely hits us hard: > With the patched version, we now rely on normal Cleaner thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. So I think we need a feedback loop from a relevant Cleaner back to allocation code. I pushed a hopefully reliable version of it now. It survives the short `DirectBufferAllocTest` stress tests I throw at it, now running it for longer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2604647588 From duke at openjdk.org Tue Jan 21 13:09:48 2025 From: duke at openjdk.org (Johny Jose) Date: Tue, 21 Jan 2025 13:09:48 GMT Subject: RFR: 8347965: (tz) Update Timezone Data to 2025a Message-ID: Changes to Update Timezone Data to 2025a ------------- Commit messages: - 8347965: (tz) Update Timezone Data to 2025a Changes: https://git.openjdk.org/jdk/pull/23212/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23212&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347965 Stats: 249 lines in 12 files changed: 150 ins; 53 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/23212.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23212/head:pull/23212 PR: https://git.openjdk.org/jdk/pull/23212 From mbaesken at openjdk.org Tue Jan 21 13:30:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 21 Jan 2025 13:30:07 GMT Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address Message-ID: We were running into this error : sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25 stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30 at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192) ... 11 more In the discussion in the JBS bug it was found that a retry option in` launch `should be added. ------------- Commit messages: - JDK-8347779 Changes: https://git.openjdk.org/jdk/pull/23213/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23213&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347779 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23213/head:pull/23213 PR: https://git.openjdk.org/jdk/pull/23213 From eirbjo at openjdk.org Tue Jan 21 13:37:20 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 21 Jan 2025 13:37:20 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v4] In-Reply-To: References: Message-ID: <9l0tVCvZfYRuNcN0Rp5hKl9u-b2IMxI0wBN6EkD3J4E=.9cf919f5-4b67-491b-bff3-07bee41f693b@github.com> > Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. > > Links in `java.security` and `share/data/tzdata` are excluded from this PR. > > This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. > > There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). > > Changes beyond the obvious are as follows: > > `linux/native/libsimdsort/xss-common-qsort.h`: > The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170 > > `share/man/keytool.1`: > www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well? > > `unix/classes/sun/net/PortConfig.java` > The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. > > `unix/native/libjava/*`, > Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs > > `unix/native/libjava/ProcessImpl_md.c` > A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Remove broken, outdated "unofficial" PASC link ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21633/files - new: https://git.openjdk.org/jdk/pull/21633/files/0f5bf950..7174f839 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21633&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21633&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21633/head:pull/21633 PR: https://git.openjdk.org/jdk/pull/21633 From eirbjo at openjdk.org Tue Jan 21 13:37:20 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 21 Jan 2025 13:37:20 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: <8tyc5YtyUIp3AiJc6lZ1FoqfPgYXeG8-8rgHbMOGv_Q=.77908a0d-04d9-4947-a051-95fb76123360@github.com> Message-ID: On Tue, 21 Jan 2025 06:51:10 GMT, Thomas Stuefe wrote: > > @tstuefe And you also agree that the link should be removed? (Which is what this PR is about) > > The 20+ years old link to the PASC error report I would probably remove; it is likely outdated now. If one wanted to invest the time, one could test the current behavior on our supported Unices. As long as that is not done, we can live with setting SIG_DFL manually. Thanks for looking into this Thomas, much appreciated! I think the improvements you suggest here are perhaps streching the scope of this particular PR, which was mostly to update links to use HTTPS. I must also admit that I have a very limited understanding of these low-level Unix APIs, so I'm reluctant to include material changes in this PR. I have filed https://bugs.openjdk.org/browse/JDK-8348183 to track a review/update of the comment in ProcessImpl_md.c and suggest that we simply remove the "unofficial" link for this PR. Would this be ok with you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2604751323 From alanb at openjdk.org Tue Jan 21 13:48:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Jan 2025 13:48:36 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v6] In-Reply-To: References: Message-ID: <6I92Ypsg5cTFrNQnnsmXs5gXzpLmIWAE90lT6pW_ebk=.571f971f-bfbe-49d6-8647-21fa781420ed@github.com> On Tue, 21 Jan 2025 12:55:31 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Track Cleaner progress with canaries Okay, there is much more significant change now and will require time to review very closely. ------------- Changes requested by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2564681328 From eirbjo at openjdk.org Tue Jan 21 13:56:30 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 21 Jan 2025 13:56:30 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v5] In-Reply-To: References: Message-ID: > Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. > > Links in `java.security` and `share/data/tzdata` are excluded from this PR. > > This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. > > There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). > > Changes beyond the obvious are as follows: > > `linux/native/libsimdsort/xss-common-qsort.h`: > The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170 > > `share/man/keytool.1`: > www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well? > > `unix/classes/sun/net/PortConfig.java` > The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. > > `unix/native/libjava/*`, > Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs > > `unix/native/libjava/ProcessImpl_md.c` > A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Update copyright headers for 2025 for Oracle files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21633/files - new: https://git.openjdk.org/jdk/pull/21633/files/7174f839..d1ec70bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21633&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21633&range=03-04 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/21633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21633/head:pull/21633 PR: https://git.openjdk.org/jdk/pull/21633 From shade at openjdk.org Tue Jan 21 14:33:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jan 2025 14:33:43 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v6] In-Reply-To: <6I92Ypsg5cTFrNQnnsmXs5gXzpLmIWAE90lT6pW_ebk=.571f971f-bfbe-49d6-8647-21fa781420ed@github.com> References: <6I92Ypsg5cTFrNQnnsmXs5gXzpLmIWAE90lT6pW_ebk=.571f971f-bfbe-49d6-8647-21fa781420ed@github.com> Message-ID: <1deAxr-IkpzltLxEyXGRQ551UDQDsj59dMJCGdt_XKA=.3fe05042-e6db-49d3-9e6c-aa90f949c173@github.com> On Tue, 21 Jan 2025 13:45:50 GMT, Alan Bateman wrote: > Okay, there is much more significant change now and will require time to review very closely. Sure. I was hoping we could avoid changing the feedback path in allocation code, but testing disagreed :) I remember when we built that feedback path back in JDK 8 days; it is clumsy and hacky and arguably a tech debt, but it worked well on stress tests. Today, migrating DDB to standard Cleaner forces us to figure out that particular part of technical debt: the feedback path from Reference handler to DDB allocation code needs to be replaced with the feedback path from Cleaner. I think current version is less messy than what we had before. No stress test failures so far... ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2604896009 From rriggs at openjdk.org Tue Jan 21 16:28:38 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 21 Jan 2025 16:28:38 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v5] In-Reply-To: References: Message-ID: <1wf30qWLDemMhhOQbMmD_O7lUD1_Q-pdqJqHsEiYSq8=.dbf9961b-4f1e-4124-a07d-c96f71966fee@github.com> On Tue, 21 Jan 2025 13:56:30 GMT, Eirik Bj?rsn?s wrote: >> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. >> >> Links in `java.security` and `share/data/tzdata` are excluded from this PR. >> >> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. >> >> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). >> >> Changes beyond the obvious are as follows: >> >> `linux/native/libsimdsort/xss-common-qsort.h`: >> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170 >> >> `share/man/keytool.1`: >> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well? >> >> `unix/classes/sun/net/PortConfig.java` >> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. >> >> `unix/native/libjava/*`, >> Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs >> >> `unix/native/libjava/ProcessImpl_md.c` >> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright headers for 2025 for Oracle files The current implementation reaps exit status of subprocesses using wait() in a dedicated OS thread. >From time to time, we conjecture that using a signal handler to capture the exit status might be preferred. However, with Hotspot handling signals and other native code might also want to handle signals, there is less risk using the current mechanism to get the exit status. So for the purposes of reaping status, setting the handler to SIG_DFL to ignore the signals is fine as is. I agree doing (in this PR) anything more than fix the link is out of scope. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2605194543 From never at openjdk.org Tue Jan 21 16:39:43 2025 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 21 Jan 2025 16:39:43 GMT Subject: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v2] In-Reply-To: References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> Message-ID: <-AVkzOe3iewpemODfi0esiqxDWa-Q5rbtcljgFJbIt0=.3066ef66-7e38-49bf-b9e0-ec2a72da34de@github.com> On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez wrote: >> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309. In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure. Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt. > > Tom Rodriguez 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: > > - adjust OOMEInStampedLock.java too > - Merge branch 'master' into tkr-oomeinaqs-ea > - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler I'm not sure there are a lot of great alternatives. There's no easy global solution to the problem of EA being unable to materialize values during deopt so these kinds of problems crop up in tests, particularly with Xcomp. So the choices boil down to don't run it under Xcomp with Graal or work around it. Something about the structure of this test reliably causes a unreached deopt in this code path and that seems to caused of some relatively recent random JDK change as this had been passing previously. Modifying the test in this way seem like a pragmatic way of dealing with it. The main is effectively the harness, so the change has no effect on the validity of the test itself. We can always revisit this if it crop up again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2605220919 From rriggs at openjdk.org Tue Jan 21 16:36:38 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 21 Jan 2025 16:36:38 GMT Subject: RFR: 8338428: Add logging of final VM flags while setting properties [v6] In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> Message-ID: On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". >> >> Update: >> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated flags lgtm Got it, I've resolved my mis-understanding of the properties being changed to the narrow use of invoking the initial VMProps to determine the supported properties of the VM under test. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23054#pullrequestreview-2565158818 PR Comment: https://git.openjdk.org/jdk/pull/23054#issuecomment-2605213324 From jvernee at openjdk.org Tue Jan 21 17:07:45 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 21 Jan 2025 17:07:45 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v7] In-Reply-To: <9BRvcyOSfKcjiPpulF8669ISy36DjH71DGudiOIwFtw=.6259a2c8-250f-4ae4-bbd4-2bc96d64177f@github.com> References: <9BRvcyOSfKcjiPpulF8669ISy36DjH71DGudiOIwFtw=.6259a2c8-250f-4ae4-bbd4-2bc96d64177f@github.com> Message-ID: On Mon, 20 Jan 2025 18:43:54 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > restore 3 forks Talking to Maurizio offline, and we realized that if we just pin the continuation when we acquire the buffer, and unpin when releasing, we don't have to worry about buffers floating between threads between acquire & release, and we can also re-use the buffer in consecutive calls (like a bump allocator), meaning we just need a single buffer, instead of a two element cache, and we might be able to use it for more than 2 calls. Pinning the continuation wouldn't be a problem since we're about to do a native call any way, which will also pin it. We would need to wait until: https://bugs.openjdk.org/browse/JDK-8347997 is fixed, which seems like a good idea either way, so we have more options when implementing this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2605284762 From jlu at openjdk.org Tue Jan 21 18:05:35 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 21 Jan 2025 18:05:35 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 23:53:06 GMT, Naoto Sato wrote: > IANAL, but my understanding is that it reflects the year the last change was open to the public. It does not seem to matter from copyright point if the file is a translation of English one or not. While that has been my understanding as well, for L10n specifically we have always reflected the original English file year in the localized copyright. For example, I believe most (if not all) of the other files included in this PR have a 2024 copyright years, not just those .java XML files. I am fine if we make this switch, but it will be a departure from how we have normally done it for the L10n process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2605409150 From mcimadamore at openjdk.org Tue Jan 21 18:27:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 21 Jan 2025 18:27:39 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v7] In-Reply-To: References: <9BRvcyOSfKcjiPpulF8669ISy36DjH71DGudiOIwFtw=.6259a2c8-250f-4ae4-bbd4-2bc96d64177f@github.com> Message-ID: On Tue, 21 Jan 2025 17:04:01 GMT, Jorn Vernee wrote: > Talking to Maurizio offline, and we realized that if we just pin the continuation when we acquire the buffer, and unpin when releasing, we don't have to worry about buffers floating between threads between acquire & release, and we can also re-use the buffer in consecutive calls (like a bump allocator), meaning we just need a single buffer, instead of a two element cache, and we might be able to use it for more than 2 calls. Pinning the continuation wouldn't be a problem since we're about to do a native call any way, which will also pin it. > > We would need to wait until: https://bugs.openjdk.org/browse/JDK-8347997 is fixed, which seems like a good idea either way, so we have more options when implementing this. There's actually two strategies that are possible to avoid issues with virtual threads. The first would be the one described above - e.g. use pin/unpin. Alternatively we can use locking - e.g. acquire the allocator. Any other thread mounted on the same carrier thread will fail to acquire the allocator if already acquired -- in which case we can just return a plain confined arena (and take the performance hit). It is basically a choice as to whether we want a hit in terms of scalability _always_ (in the unlikely event of some scheduling issue), or if we want to pay for an extra CAS in the event we see the allocator acquire comes a virtual thread. >From a code maintenance perspective, I believe it would be better to address all these issues in a centralized manner. As already discussed, we have a number of efforts in this area - for instance https://git.openjdk.org/jdk/pull/22391 It is my understanding that that PR has been closed and will be rebased on top of a more general thread-local allocator scheme. When that happens, we can then also use the same allocator from the Linker (instead of having different mechanisms springing up in different places of the JDK). (We do appreciate the efforts in pushing this forward though, as that helped fleshing out more of the constraints!) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2605452325 From naoto at openjdk.org Tue Jan 21 18:31:37 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 21 Jan 2025 18:31:37 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. > While that has been my understanding as well, for L10n specifically we have always reflected the original English file year in the localized copyright Yes. I think it is probably time to assure it really is the case. Since we are following the procedure, I approve the changes. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2565411176 From naoto at openjdk.org Tue Jan 21 18:32:42 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 21 Jan 2025 18:32:42 GMT Subject: RFR: 8347841: Test fixes that use deprecated time zone IDs [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 00:45:54 GMT, Naoto Sato wrote: >> This fix is a follow on for [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes usages of those deprecated time zone ids in tests. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed extra spaces Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23166#issuecomment-2605460730 From naoto at openjdk.org Tue Jan 21 18:32:43 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 21 Jan 2025 18:32:43 GMT Subject: Integrated: 8347841: Test fixes that use deprecated time zone IDs In-Reply-To: References: Message-ID: <0xn9h5Wqw--SMsJNuyyy7yXYh5YhDVi9XgOqmXS0c0s=.62ddda70-36e7-492c-b135-e40ca7f479b5@github.com> On Thu, 16 Jan 2025 23:38:48 GMT, Naoto Sato wrote: > This fix is a follow on for [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes usages of those deprecated time zone ids in tests. This pull request has now been integrated. Changeset: 81912e95 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/81912e958ba77c1c9371305ecfedad13aaa3fa6a Stats: 213 lines in 27 files changed: 67 ins; 34 del; 112 mod 8347841: Test fixes that use deprecated time zone IDs Reviewed-by: jlu, joehw ------------- PR: https://git.openjdk.org/jdk/pull/23166 From djelinski at openjdk.org Tue Jan 21 18:37:37 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 21 Jan 2025 18:37:37 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v5] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 20:27:54 GMT, Brian Burkhalter wrote: >> Fix the means of determining whether an exception is to be expected in the Windows test. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8347740: Remove vestigial constant WINDOWS_11_MINIMUM_BUILD LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23117#pullrequestreview-2565422142 From jlu at openjdk.org Tue Jan 21 18:48:24 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 21 Jan 2025 18:48:24 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v6] In-Reply-To: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: > Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. > > The motivation can be found in the CSR. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23165/files - new: https://git.openjdk.org/jdk/pull/23165/files/46dcf78e..96e86c80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=04-05 Stats: 60 lines in 2 files changed: 17 ins; 3 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/23165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165 PR: https://git.openjdk.org/jdk/pull/23165 From jlu at openjdk.org Tue Jan 21 18:48:25 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 21 Jan 2025 18:48:25 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> Message-ID: <1Go2l9P0V7BbB3UHJDowtnhvQP--4V2bdjzLxKbSe90=.547698b4-a011-4ff6-a71f-5119f3c7dd93@github.com> On Mon, 20 Jan 2025 09:46:05 GMT, Viktor Klang wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> provide message for test assertion > > src/java.base/share/classes/java/util/Currency.java line 494: > >> 492: >> 493: if (scEntry.cutOverTime == Long.MAX_VALUE >> 494: || System.currentTimeMillis() < scEntry.cutOverTime) { > > It'd be better to obtain the current time once and compare against the same value for all entries rather than potentially using different current times for each comparison. That's a good point. I filed [JDK-8348205](https://bugs.openjdk.org/browse/JDK-8348205) because that change would have its own behavioral concerns, which I don't want to overlap with this issue/CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1924212238 From jlu at openjdk.org Tue Jan 21 18:48:25 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 21 Jan 2025 18:48:25 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> Message-ID: On Sat, 18 Jan 2025 01:29:01 GMT, Chen Liang wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> provide message for test assertion > > src/java.base/share/classes/java/util/Currency.java line 469: > >> 467: >> 468: // Initialize the set of available currencies if needed >> 469: private static synchronized void initAvailableCurrencies() { > > Should we make `available` volatile so we can avoid entering the monitor if the currencies are initialized? > > (Note: We may get Stable Values very soon, at that point SV is a much better solution) Thanks Chen, made `available` volatile and implemented DCL in https://github.com/openjdk/jdk/pull/23165/commits/96e86c800f1d1af1c20bfee944c298f17b7e8860. Also added a duplicate elements test as you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1924213435 From bpb at openjdk.org Tue Jan 21 19:10:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 21 Jan 2025 19:10:43 GMT Subject: RFR: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 18:34:52 GMT, Daniel Jeli?ski wrote: > LGTM. Thanks for the re-review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23117#issuecomment-2605526172 From bpb at openjdk.org Tue Jan 21 19:10:44 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 21 Jan 2025 19:10:44 GMT Subject: Integrated: 8347740: java/io/File/createTempFile/SpecialTempFile.java failing In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 21:47:06 GMT, Brian Burkhalter wrote: > Fix the means of determining whether an exception is to be expected in the Windows test. This pull request has now been integrated. Changeset: f2a9d26b Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/f2a9d26b2e409a7216d967ebb6b92726e8ed65c3 Stats: 28 lines in 1 file changed: 12 ins; 3 del; 13 mod 8347740: java/io/File/createTempFile/SpecialTempFile.java failing Reviewed-by: djelinski ------------- PR: https://git.openjdk.org/jdk/pull/23117 From cjplummer at openjdk.org Tue Jan 21 19:11:42 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 21 Jan 2025 19:11:42 GMT Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:24:41 GMT, Matthias Baesken wrote: > We were running into this error : > sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25 > > stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30 > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192) > ... 11 more > > In the discussion in the JBS bug it was found that a retry option in` launch `should be added. test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 84: > 82: output.shouldHaveExitValue(0); > 83: } catch (Exception ex) { > 84: if (allowRetry) return false; The exception should be printed if we are going to retry, and also maybe print a message that mentions retrying similar to what we do in printStackTraces()L 122 System.out.println("'JShellToolProvider' missing. Allow one retry."); test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 104: > 102: if (!res) { // try once more > 103: launch(expectedMessage, Arrays.asList(toolArgs), false); > 104: } `launch()` should take an allowRetry argument and only retry if true. This test is operated in two different modes. One is with an active target process and one is with a target process that should be stabilized and inactive. The latter is not allowed to retry since it should never fail. Also, it would help to add a comment as to why the retry is being done. See the comment in `printStackTrace()`. I think a better approach would be for launch() to just return if a retry should be done. testHeapDump() should check the result, and just immediately return true if launch() returns true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1924239855 PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1924237704 From joehw at openjdk.org Tue Jan 21 19:15:38 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 21 Jan 2025 19:15:38 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. java.xml changes look good. ------------- Marked as reviewed by joehw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2565493674 From prr at openjdk.org Tue Jan 21 19:44:42 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 21 Jan 2025 19:44:42 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Wed, 8 Jan 2025 20:13:50 GMT, Hannes Walln?fer wrote: > Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288: > 1286: > 1287: /** > 1288: * Serializes this {@code DataFlavor}. This most definitely changes the serialisation spec. So a CSR is needed. Also shouldn't readExternal be updated to correspond ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1924275958 From dholmes at openjdk.org Tue Jan 21 21:07:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Jan 2025 21:07:38 GMT Subject: RFR: 8338428: Add logging of final VM flags while setting properties [v6] In-Reply-To: <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> <_jqAB7z6VMwSFINV3WMFIY8EMOMxadB8xf7im801PDg=.58662194-e446-4ec5-82ad-11148d2ab8b5@github.com> Message-ID: On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote: >> Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. >> >> I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". >> >> Update: >> There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated flags Still good. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23054#pullrequestreview-2565690364 From lmesnik at openjdk.org Tue Jan 21 21:13:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 21 Jan 2025 21:13:41 GMT Subject: Integrated: 8338428: Add logging of final VM flags while setting properties In-Reply-To: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> References: <1zrpd7npbBYcWsSvoTdJXmT-s1ct4PLdHSwv78JwAy0=.c3befe7f-3c16-4add-9c81-64fc47d0d478@github.com> Message-ID: On Sun, 12 Jan 2025 06:08:02 GMT, Leonid Mesnik wrote: > Some VM flags might depend on the environment and it makes sense to log final flags so it is possible to get their value when investigating failures. > > I added them to VMProps, so it is always dump final flags before running tests using "-XX:+PrintFlagsFinal". > > Update: > There were intermittent compilation failures when I tried to use classes from testlibrary, so I rewrtite the code without them. This pull request has now been integrated. Changeset: bbd88077 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/bbd880775f73ac11dc2c86ec5b598bdb4305e699 Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod 8338428: Add logging of final VM flags while setting properties Reviewed-by: dholmes, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/23054 From coffeys at openjdk.org Tue Jan 21 21:57:35 2025 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 21 Jan 2025 21:57:35 GMT Subject: RFR: 8347965: (tz) Update Timezone Data to 2025a In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:03:45 GMT, Johny Jose wrote: > Changes to Update Timezone Data to 2025a Marked as reviewed by coffeys (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23212#pullrequestreview-2565771402 From vaivanov at openjdk.org Tue Jan 21 23:48:14 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 21 Jan 2025 23:48:14 GMT Subject: RFR: 8346230: [perf] scalability issue for the specjvm2008::xml.transform workload [v2] In-Reply-To: References: Message-ID: > The synchronized scope was reduced from whole methods to sections that need hash map access control. The tier1 and jaxp tests are OK. The score of the specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported scores are: > original: 1vCPU - 148.4, 112vCPU - 12743.4, 224vCPU - 13481.31 ops/m > patched: 1vCPU - 149.77, 112vCPU - 13122.82, 224vCPU - 14751.57 ops/m > > According to the JFR the locking time for XMLReader object reduced from ~27sec to ~20sec for 224vCPU run. Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: 8346230 [perf] scalability issue for the specjvm2008::xml.transform workload ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23185/files - new: https://git.openjdk.org/jdk/pull/23185/files/989ef34d..90c25906 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23185&range=00-01 Stats: 8 lines in 1 file changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23185/head:pull/23185 PR: https://git.openjdk.org/jdk/pull/23185 From vaivanov at openjdk.org Wed Jan 22 00:20:35 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 22 Jan 2025 00:20:35 GMT Subject: RFR: 8346230: [perf] scalability issue for the specjvm2008::xml.transform workload [v2] In-Reply-To: References: Message-ID: <6KEJiStLuoxwDo5sZjqIlntTDkM2NfdxKSSh6XvU2JI=.42158a28-dd85-4b3e-9820-cb4763c643f9@github.com> On Tue, 21 Jan 2025 23:48:14 GMT, Vladimir Ivanov wrote: >> The synchronized scope was reduced from whole methods to sections that need hash map access control. The tier1 and jaxp tests are OK. The score of the specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported scores are: >> original: 1vCPU - 148.4, 112vCPU - 12743.4, 224vCPU - 13481.31 ops/m >> patched: 1vCPU - 149.77, 112vCPU - 13122.82, 224vCPU - 14751.57 ops/m >> >> According to the JFR the locking time for XMLReader object reduced from ~27sec to ~20sec for 224vCPU run. > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > 8346230 [perf] scalability issue for the specjvm2008::xml.transform workload Thanks for your comment. You are correct. The 'volatile' modifier does not need here. Also it can't be 'final' while may be updated during runs. The thread local variable is OK here. Tier1 and jaxp tests are OK. Scores are same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23185#issuecomment-2606007098 From peter.firmstone at zeus.net.au Wed Jan 22 03:07:31 2025 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 22 Jan 2025 13:07:31 +1000 Subject: ScopedValue API Message-ID: <7faa6070-9e2f-4497-880a-d7c57ccb8d6a@zeus.net.au> Just wanted to say, I've been experimenting with replacing ThreadLocal with ScopedValue, this is a great new API, I love the way ScopedValue uses recursion, we can have multiple immutable instances representing a scoped value for a short period and we're not worried about managing state as it goes out of scope as soon as it's no longer in use. Cheers, Peter. From iklam at openjdk.org Wed Jan 22 03:32:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 22 Jan 2025 03:32:57 GMT Subject: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() Message-ID: I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there. The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java. ### How this works: For example, let's assume you have the following classfiles in foo.jar: interface MyInterface1 {} interface MyInterface2 {} class MyClass extends Object implements MyInterface1, MyInterface2 {} The CDS classlist file can look like this: java/lang/Object id: 1 MyInterface1: id: 2 super: 1 source: foo.jar MyInterface2: id: 3 super: 1 source: foo.jar MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters: - `name` = "MyClass" - `superClass` = java.lang.Object - `interfaces` = {MyInterface1, MyInterface2} `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`. ------------- Commit messages: - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() Changes: https://git.openjdk.org/jdk/pull/23226/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23226&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348240 Stats: 342 lines in 9 files changed: 193 ins; 113 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/23226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23226/head:pull/23226 PR: https://git.openjdk.org/jdk/pull/23226 From dholmes at openjdk.org Wed Jan 22 05:37:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Jan 2025 05:37:41 GMT Subject: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v2] In-Reply-To: References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> Message-ID: On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez wrote: >> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309. In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure. Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt. > > Tom Rodriguez 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: > > - adjust OOMEInStampedLock.java too > - Merge branch 'master' into tkr-oomeinaqs-ea > - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler Changing the test this way does not sit well with me either. This adjustment to the test is far too intricately entwined with the implementation details of a particular JIT. I'm much more inclined to exclude Xcomp mode for OOME tests; or perhaps just disable EA (if Graal supports that) so we get most Xcomp coverage whilst side-stepping the EA issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2606338305 From rrich at openjdk.org Wed Jan 22 07:05:39 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 22 Jan 2025 07:05:39 GMT Subject: Integrated: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds In-Reply-To: References: Message-ID: <2QqQQ_kMREL599Rl8JOHxGcakNMAMkGZo32cJjAOSnc=.9e4cf950-176c-44b9-880b-b94318f21368@github.com> On Wed, 15 Jan 2025 14:14:37 GMT, Richard Reingruber wrote: > This PR reverts the fix from [JDK-8339166](https://bugs.openjdk.org/browse/JDK-8339166) because it increases the runtime of the test a lot. > Instead a full gc is requested via the whitebox api. This solves the issues (see bug description) and it is also clearer and more reliable then allocating objects and classes expecting a gc because of the small heap. > The heap setting is also removed since it is not needed anymore. > > #### Testing: Duration Running HiddenClassUnloading with fastdebug Builds > > I'm giving the minimum of a few runs because durations vary by +/- 10s. > > > Linux / x86_64: > After JDK-8339166: 3m15s > JDK-8339166 reverted: 50s > PR: 50s > > macOS / M1: > After JDK-8339166: 2m30s > JDK-8339166 reverted: 30s > PR: 30s > > Linux / ppc64le > After JDK-8339166: 12m30s > JDK-8339166 reverted: 2m30s (failure: no classes unloaded) > PR: 2m30s (success) This pull request has now been integrated. Changeset: 15d6469e Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/15d6469e8da635364c0ba83e425fd149c2d69495 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds Reviewed-by: clanger, mbaesken, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/23137 From epeter at openjdk.org Wed Jan 22 08:17:43 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 22 Jan 2025 08:17:43 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com> References: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com> Message-ID: On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja wrote: >>> > Can you quickly summarize what tests you have, and what they test? >>> >>> Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps. >> >> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours. > >> > > Can you quickly summarize what tests you have, and what they test? >> > >> > >> > Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps. >> >> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours. > > > Validations details:- > > A) x86 backend changes > - new assembler instruction > - macro assembly routines. > Test point:- test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java > - This test is based on a testng framework and includes new DataProviders to generate test vectors. > - Test vectors cover the entire float16 value range and also special floating point values (NaN, +Int, -Inf, 0.0 and -0.0) > B) GVN transformations:- > - Value Transforms > Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Covers all the constant folding scenarios for add, sub, mul, div, sqrt, fma, min, and max operations addressed by this patch. > - It also tests special case scenarios for each operation as specified by Java language specification. > - identity Transforms > Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Covers identity transformation for ReinterpretS2HFNode, DivHFNode > - idealization Transforms > Test points:- test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java > :- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Contains test point for the following transform > MulHF idealization i.e. MulHF * 2 => AddHF > - Contains test point for the following transform > DivHF SRC , PoT(constant) => MulHF SRC * reciprocal (constant) > - Contains idealization test points for the following transform > ConvF2HF(FP32BinOp(ConvHF2F(x), ConvHF2F(y))) => > ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y))) @jatin-bhateja just ping me again whenever this is ready for a re-review :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2606558812 From rrich at openjdk.org Wed Jan 22 08:35:45 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 22 Jan 2025 08:35:45 GMT Subject: [jdk24] RFR: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds Message-ID: Hi all, I would like to backport the test-fix from commit [15d6469e](https://github.com/openjdk/jdk/commit/15d6469e8da635364c0ba83e425fd149c2d69495) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The backport will help prevent frequent tier1 test timeouts in our CI testing. The commit being backported was authored by Richard Reingruber on 22 Jan 2025 and was reviewed by Christoph Langer, Matthias Baesken and Martin Doerr. Thanks, Richard. ------------- Commit messages: - Backport 15d6469e8da635364c0ba83e425fd149c2d69495 Changes: https://git.openjdk.org/jdk/pull/23228/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347817 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23228/head:pull/23228 PR: https://git.openjdk.org/jdk/pull/23228 From shade at openjdk.org Wed Jan 22 08:50:38 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Jan 2025 08:50:38 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v6] In-Reply-To: <1deAxr-IkpzltLxEyXGRQ551UDQDsj59dMJCGdt_XKA=.3fe05042-e6db-49d3-9e6c-aa90f949c173@github.com> References: <6I92Ypsg5cTFrNQnnsmXs5gXzpLmIWAE90lT6pW_ebk=.571f971f-bfbe-49d6-8647-21fa781420ed@github.com> <1deAxr-IkpzltLxEyXGRQ551UDQDsj59dMJCGdt_XKA=.3fe05042-e6db-49d3-9e6c-aa90f949c173@github.com> Message-ID: <1lr5io7nX-jRr3wfr3XThOzB4qaVHFSZQN62v0R73pw=.33448629-a662-41ff-82f2-27920f4e7ee4@github.com> On Tue, 21 Jan 2025 14:31:33 GMT, Aleksey Shipilev wrote: > No stress test failures so far... I ran a large matrix of `DirectBufferAllocTest` configs on my 5950X overnight, and it did not fail once. Several GHA re-runs also came back clean. This gives me confidence current version works well. #!/bin/bash set -euxo pipefail J=~/trunks/jdk/build/linux-x86_64-server-release/images/jdk/bin/java JOPTS="-Xmx128m -Xlog:gc" for T in 1 4 16 64 256 1024; do for M in 1 2 4 8 16 32 64 128 256; do $J $JOPTS -XX:MaxDirectMemorySize=${M}m DirectBufferAllocTest.java -r 800 -t $T done done ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2606622780 From mbaesken at openjdk.org Wed Jan 22 08:52:37 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Jan 2025 08:52:37 GMT Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 19:06:40 GMT, Chris Plummer wrote: > launch() should take an allowRetry argument and only retry if true. Are you talking about `public static void launch(String expectedMessage, String... toolArgs)` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1924930551 From mbaesken at openjdk.org Wed Jan 22 09:15:10 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Jan 2025 09:15:10 GMT Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address [v2] In-Reply-To: References: Message-ID: <2RmUz6EFb4bFPahDd48JpIlonqxmje6PXB_dtWTRCcw=.d272af05-135d-4cfe-a76c-c2794ec4d416@github.com> > We were running into this error : > sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25 > > stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30 > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192) > ... 11 more > > In the discussion in the JBS bug it was found that a retry option in` launch `should be added. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: More output in case of retry in launch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23213/files - new: https://git.openjdk.org/jdk/pull/23213/files/9e638a3e..b54de9b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23213&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23213&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23213/head:pull/23213 PR: https://git.openjdk.org/jdk/pull/23213 From hannesw at openjdk.org Wed Jan 22 09:25:43 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 22 Jan 2025 09:25:43 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 19:41:39 GMT, Phil Race wrote: >> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. >> >> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 >> >> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. >> >> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. > > src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288: > >> 1286: >> 1287: /** >> 1288: * Serializes this {@code DataFlavor}. > > This most definitely changes the serialisation spec. So a CSR is needed. > Also shouldn't readExternal be updated to correspond ? Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that. @prrace do you have any suggestions for the spec change, or are you ok with the proposed wording? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1924979277 From duke at openjdk.org Wed Jan 22 09:57:15 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 09:57:15 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op > CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: Back buffer allocation with a single carrier-local segment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/5a8491f1..d408852d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=06-07 Stats: 332 lines in 4 files changed: 57 ins; 268 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From duke at openjdk.org Wed Jan 22 10:04:40 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 10:04:40 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 09:57:15 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > Back buffer allocation with a single carrier-local segment. > just need a single buffer > Alternatively we can use locking I think these are really really great suggestions, thank you! It simplifies things tremendously, I've pushed a version of it. As you say, the errno / state capture piece can probably just use it, too. The extra atomics for acquiring/releasing don't seem to cost that much, so this has still excellent performance (and is also alloc-free): Benchmark Mode Cnt Score Error Units CallOverheadByValue.byPtr avgt 30 3.375 ? 0.138 ns/op CallOverheadByValue.byValue avgt 30 6.625 ? 0.057 ns/op I'll leave this here for inspiration, I'll add a few unit tests for the stack, but feel free to just close it in favor of related work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2606794554 From duke at openjdk.org Wed Jan 22 10:08:39 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 10:08:39 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 09:57:15 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > Back buffer allocation with a single carrier-local segment. src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 389: > 387: @Override > 388: protected BufferStack initialValue() { > 389: return new BufferStack(Arena.ofAuto().allocate(256)); Could as well use keep using TerminatingThreadLocal+Unsafe here, I just like the fact to use as few non-public apis as possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925044684 From duke at openjdk.org Wed Jan 22 10:12:13 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 10:12:13 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op > CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: --unnecessary annotations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/d408852d..ad0b9282 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From rgiulietti at openjdk.org Wed Jan 22 10:36:38 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 22 Jan 2025 10:36:38 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v8] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 04:08:28 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> fix comment > > Always good to see some methods removed from `JavaLangAccess` - but it appears these are already unused? > > I think the performance gain from this is somewhat underwhelming. `Unsafe` is a big hammer to eek out ~10% performance in an isolated code path. > > And perhaps it would be better to just push the microbenchmark, any code cleanups (like the removal of unused methods from JavaLangAccess) and leave code unchanged and leave it as a challenge for JIT engineers to get the pre-existing code to parity with this `Unsafe` routine. > > That said I'm ok with this as is but will request a second opinion. Maybe @rgiulietti can weigh in? @cl4es FYI, the changes introduced since the commit you approved are just cosmetic and stylistic. The only notable modification is the use of `Unsafe::putCharUnaligned`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2606867180 From mcimadamore at openjdk.org Wed Jan 22 10:37:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 22 Jan 2025 10:37:39 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: <1DlMfiqq8VpSWEadim5X70QJBJt3GpfzU2-2-WH2lpU=.16e7b6b0-e939-4e98-b6e7-714c7594be83@github.com> On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > --unnecessary annotations src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 52: > 50: scope.close(); > 51: offset = parentOffset; > 52: lock.unlock(); I believe you could have mismatched lock/unlock in some cases ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925088068 From volkan at yazi.ci Wed Jan 22 10:39:29 2025 From: volkan at yazi.ci (=?UTF-8?B?Vm9sa2FuIFlhesSxY8Sx?=) Date: Wed, 22 Jan 2025 11:39:29 +0100 Subject: ScopedValue API In-Reply-To: <7faa6070-9e2f-4497-880a-d7c57ccb8d6a@zeus.net.au> References: <7faa6070-9e2f-4497-880a-d7c57ccb8d6a@zeus.net.au> Message-ID: Hello Peter, Thanks so much for the feedback. AFAIK, that work is delivered by the Loom crew and they use the `loom-dev` mailing list for discussions. I think they would really appreciate hearing your feedback: What is the real-world use case you used SVs for? How was that particular logic implemented before? What are the performance/code/semantic changes you observed during migration? Did you encounter any problems? Did you find the API intuitive? etc. Kind regards. On Wed, Jan 22, 2025 at 4:11?AM Peter Firmstone wrote: > Just wanted to say, I've been experimenting with replacing ThreadLocal > with ScopedValue, this is a great new API, I love the way ScopedValue > uses recursion, we can have multiple immutable instances representing a > scoped value for a short period and we're not worried about managing > state as it goes out of scope as soon as it's no longer in use. > > Cheers, > > Peter. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Wed Jan 22 10:42:40 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 22 Jan 2025 10:42:40 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > --unnecessary annotations src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 17: > 15: > 16: public Arena reserve(long size) { > 17: if (!lock.tryLock()) { I believe we only need to lock if `reserve` is called from a virtual thread. So there's more cases where the locking can be avoided :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925094903 From mcimadamore at openjdk.org Wed Jan 22 10:45:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 22 Jan 2025 10:45:39 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > --unnecessary annotations src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 38: > 36: @SuppressWarnings("restricted") > 37: public MemorySegment allocate(long byteSize, long byteAlignment) { > 38: MemorySegment slice = backingSegment.asSlice(offset, byteSize, byteAlignment); You have re-implemented a slicing allocator (`SegmentAllocator::slicingAllocator`). I think that's probably ok, but I'll point out that slicing allocator will try to deal with alignment, and will also throw exceptions when called with non-sensical arguments. A more robust way to do this would be to: 1. have `reserve` pass the reserved size to `Frame` 2. `Frame` will slice the segment according to offset/size 3. then create a slicing allocator based on that segment 4. use the slicing allocator to implement `allocate` In our tests, something like this did not add any extra overhead (the allocation of the slicing allocator is escape-analyzed away) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925099911 From mcimadamore at openjdk.org Wed Jan 22 10:52:44 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 22 Jan 2025 10:52:44 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > --unnecessary annotations src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 9: > 7: public class BufferStack { > 8: private final MemorySegment backingSegment; > 9: private final ReentrantLock lock = new ReentrantLock(); This could go lower level and do a CAS loop directly, but probably your solution achieves a good compromise between performance and maintainability - esp. coupled with the suggestion below of only lock when we're in a virtual thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925109072 From mcimadamore at openjdk.org Wed Jan 22 10:57:40 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 22 Jan 2025 10:57:40 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: <5XfsjQ3ileiG0-5kJjs_t3ODHoGGDZOsBtdUeC9GNkE=.bdabf940-5cb5-4718-8891-f48b2ebeab71@github.com> On Wed, 22 Jan 2025 10:12:13 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op >> CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > --unnecessary annotations General comment - thanks for persevering, I like the new changes a lot, and I think they move things in the right direction, which is that to provide a component that can be reused for more than just this use case. Once the issues I've outlined are addressed, I have no objection going ahead with this PR, given this looks pretty similar to what we had in mind anyway. ------------- PR Review: https://git.openjdk.org/jdk/pull/23142#pullrequestreview-2566870847 From mcimadamore at openjdk.org Wed Jan 22 10:57:42 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 22 Jan 2025 10:57:42 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 10:05:31 GMT, Matthias Ernst wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> Back buffer allocation with a single carrier-local segment. > > src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 389: > >> 387: @Override >> 388: protected BufferStack initialValue() { >> 389: return new BufferStack(Arena.ofAuto().allocate(256)); > > Could as well use keep using TerminatingThreadLocal+Unsafe here, I just like the fact to use as few non-public apis as possible. I'm told that TerminatingThreadLocal runs the "terminate" action for an object T from the same thread T refers to. So, in principle, using a TerminatingThreadLocal + confined arena should be ok. If that works, I'd suggest to consider maybe moving all this sharing logic inside BufferStack, so that users only need to do: static final BufferStack LINKER_BUFFER = new BufferStack(256); ... try (Arena arena = BufferStack.reserve(size)) { ... } Which seems a more re-usable API. After all, the fact that we decide to lock or not in certain cases is heavily influenced by the fact that we expect a BufferStack to be used with a carrier local, so we might just as well fold the caching in there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925113881 From mcimadamore at openjdk.org Wed Jan 22 11:07:39 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 22 Jan 2025 11:07:39 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 10:43:27 GMT, Maurizio Cimadamore wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> --unnecessary annotations > > src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 38: > >> 36: @SuppressWarnings("restricted") >> 37: public MemorySegment allocate(long byteSize, long byteAlignment) { >> 38: MemorySegment slice = backingSegment.asSlice(offset, byteSize, byteAlignment); > > You have re-implemented a slicing allocator (`SegmentAllocator::slicingAllocator`). I think that's probably ok, but I'll point out that slicing allocator will try to deal with alignment, and will also throw exceptions when called with non-sensical arguments. > > A more robust way to do this would be to: > 1. have `reserve` pass the reserved size to `Frame` > 2. `Frame` will slice the segment according to offset/size > 3. then create a slicing allocator based on that segment > 4. use the slicing allocator to implement `allocate` > > In our tests, something like this did not add any extra overhead (the allocation of the slicing allocator is escape-analyzed away) On another note: in principle if a Frame is not the latest returned in a given thread, it is not safe to allow its allocation method (and probably close too) to succeed. Consider this case: Arena arenaOuter = bufferStack.reserve(100); arenaOuter.allocate(16); // now offset is 16 ... Arena arenaInner = bufferStack.reserve(100); arenaInner.allocate(16); // now offset is 32 arenaOuter.allocate(16); // now offset is 48 // whooops ... arenaInner.close(); // now offset is 16 arenaOuter.allocate(16); // now offset is 32 arenaOuter.allocate(16); // now offset is 48 (overwriting!!) The last statement in this snippet effectively overwrites the memory that has been previously allocated _by the same frame_. This is because we allow `arenaOuter::allocate` to work even after `arenaInner` has been obtained (see statement with `whooops` comment). Now, I believe the linker implementation is "correct" and never attempts something like this - other clients might try something similar and get surprising result. So, in the general case, I believe we should think about this (although it's fine if you do not want to tackle that in this PR) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925132267 From jpai at openjdk.org Wed Jan 22 11:31:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 11:31:46 GMT Subject: [jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4 Message-ID: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> This brings in CPU25_01 changes into jdk24 branch. ------------- Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/23232/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23232/head:pull/23232 PR: https://git.openjdk.org/jdk/pull/23232 From jpai at openjdk.org Wed Jan 22 11:31:44 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 11:31:44 GMT Subject: Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 Message-ID: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> This brings in CPU25_01 changes into master branch. ------------- Commit messages: The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/23231/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23231.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23231/head:pull/23231 PR: https://git.openjdk.org/jdk/pull/23231 From dfuchs at openjdk.org Wed Jan 22 11:31:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Jan 2025 11:31:45 GMT Subject: Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 In-Reply-To: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> References: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> Message-ID: On Wed, 22 Jan 2025 11:22:49 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into master branch. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23231#pullrequestreview-2566935776 From dfuchs at openjdk.org Wed Jan 22 11:31:46 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Jan 2025 11:31:46 GMT Subject: [jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4 In-Reply-To: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> References: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> Message-ID: On Wed, 22 Jan 2025 11:22:53 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into jdk24 branch. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23232#pullrequestreview-2566937917 From jpai at openjdk.org Wed Jan 22 11:31:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 11:31:45 GMT Subject: Integrated: Merge 5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 In-Reply-To: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> References: <_VvOJUWsEzAhZT5PT8bbL5xxenPsJsJGdM5tYoZRHNE=.341b04c8-822c-43ea-9d4a-fcb17f7d103f@github.com> Message-ID: On Wed, 22 Jan 2025 11:22:49 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into master branch. This pull request has now been integrated. Changeset: 61873564 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/61873564a44d448feb2ae6e5dae93ab33a0aa719 Stats: 137 lines in 4 files changed: 82 ins; 10 del; 45 mod Merge Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/23231 From jpai at openjdk.org Wed Jan 22 11:31:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 11:31:46 GMT Subject: [jdk24] Integrated: Merge 93ea8e708d5fc3dfe01de8d5b6d1061fef91b5d4 In-Reply-To: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> References: <4AAjawQ_G6PYlfzhCL5WryoMZF8_-zYbZkHc07P00Jc=.7990afc0-b38f-435d-b29f-c928fd8fe7e2@github.com> Message-ID: On Wed, 22 Jan 2025 11:22:53 GMT, Jaikiran Pai wrote: > This brings in CPU25_01 changes into jdk24 branch. This pull request has now been integrated. Changeset: 4ce95c95 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/4ce95c95efd1587003e91c9d18d94d5b3134aeac Stats: 137 lines in 4 files changed: 82 ins; 10 del; 45 mod Merge Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/23232 From jvernee at openjdk.org Wed Jan 22 11:52:56 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 22 Jan 2025 11:52:56 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8] In-Reply-To: References: Message-ID: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> On Wed, 22 Jan 2025 10:52:57 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 389: >> >>> 387: @Override >>> 388: protected BufferStack initialValue() { >>> 389: return new BufferStack(Arena.ofAuto().allocate(256)); >> >> Could as well use keep using TerminatingThreadLocal+Unsafe here, I just like the fact to use as few non-public apis as possible. > > I'm told that TerminatingThreadLocal runs the "terminate" action for an object T from the same thread T refers to. So, in principle, using a TerminatingThreadLocal + confined arena should be ok. > > If that works, I'd suggest to consider maybe moving all this sharing logic inside BufferStack, so that users only need to do: > > > static final BufferStack LINKER_BUFFER = new BufferStack(256); > > ... > > try (Arena arena = BufferStack.reserve(size)) { > ... > } > > > Which seems a more re-usable API. After all, the fact that we decide to lock or not in certain cases is heavily influenced by the fact that we expect a BufferStack to be used with a carrier local, so we might just as well fold the caching in there. Isn't the problem access? E.g. a virtual thread `A` running on our carrier thread might create the confined arena, binding it to _virtual_ thread `A`, and then another virtual thread `B` comes along one the same carrier thread, and wants to use the same `BufferStack`, but can't because it is confined to thread `A`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925189099 From mdoerr at openjdk.org Wed Jan 22 12:04:36 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 22 Jan 2025 12:04:36 GMT Subject: [jdk24] RFR: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 08:30:16 GMT, Richard Reingruber wrote: > Hi all, > > I would like to backport the test-fix from commit [15d6469e](https://github.com/openjdk/jdk/commit/15d6469e8da635364c0ba83e425fd149c2d69495) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > The backport will help prevent frequent tier1 test timeouts in our CI testing. > > The commit being backported was authored by Richard Reingruber on 22 Jan 2025 and was reviewed by Christoph Langer, Matthias Baesken and Martin Doerr. > > Thanks, Richard. LGTM. Thanks for backporting! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23228#pullrequestreview-2567011671 From duke at openjdk.org Wed Jan 22 12:24:16 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 12:24:16 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v10] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op > CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: * use slicing allocator for alignment guarantees * also provide alignment for frame allocation * verify stack order * only lock if VT @ root ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/ad0b9282..d347a87b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=08-09 Stats: 119 lines in 3 files changed: 79 ins; 13 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From duke at openjdk.org Wed Jan 22 12:30:39 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 12:30:39 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 10:40:07 GMT, Maurizio Cimadamore wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> --unnecessary annotations > > src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 17: > >> 15: >> 16: public Arena reserve(long size) { >> 17: if (!lock.tryLock()) { > > I believe we only need to lock if `reserve` is called from a virtual thread. So there's more cases where the locking can be avoided :-) Done. Also can avoid the recursion (although that's probably cheap under RL, let me double-check). > src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 52: > >> 50: scope.close(); >> 51: offset = parentOffset; >> 52: lock.unlock(); > > I believe you could have mismatched lock/unlock in some cases Which scenario? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925238375 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925236864 From duke at openjdk.org Wed Jan 22 12:30:40 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 12:30:40 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v8] In-Reply-To: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> Message-ID: On Wed, 22 Jan 2025 11:50:10 GMT, Jorn Vernee wrote: >> I'm told that TerminatingThreadLocal runs the "terminate" action for an object T from the same thread T refers to. So, in principle, using a TerminatingThreadLocal + confined arena should be ok. >> >> If that works, I'd suggest to consider maybe moving all this sharing logic inside BufferStack, so that users only need to do: >> >> >> static final BufferStack LINKER_BUFFER = new BufferStack(256); >> >> ... >> >> try (Arena arena = BufferStack.reserve(size)) { >> ... >> } >> >> >> Which seems a more re-usable API. After all, the fact that we decide to lock or not in certain cases is heavily influenced by the fact that we expect a BufferStack to be used with a carrier local, so we might just as well fold the caching in there. > > Isn't the problem access? E.g. a virtual thread `A` running on our carrier thread might create the confined arena, binding it to _virtual_ thread `A`, and then another virtual thread `B` comes along one the same carrier thread, and wants to use the same `BufferStack`, but can't because it is confined to thread `A`. I think _using_ it might even be ok, since all it does to the stack is slicing and reinterpreting, but the final close() would be on the wrong thread (allocator = virtual, closer=terminator likely a platform thread). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925236362 From epeter at openjdk.org Wed Jan 22 12:37:42 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 22 Jan 2025 12:37:42 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com> References: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com> Message-ID: On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja wrote: >>> > Can you quickly summarize what tests you have, and what they test? >>> >>> Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps. >> >> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours. > >> > > Can you quickly summarize what tests you have, and what they test? >> > >> > >> > Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps. >> >> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours. > > > Validations details:- > > A) x86 backend changes > - new assembler instruction > - macro assembly routines. > Test point:- test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java > - This test is based on a testng framework and includes new DataProviders to generate test vectors. > - Test vectors cover the entire float16 value range and also special floating point values (NaN, +Int, -Inf, 0.0 and -0.0) > B) GVN transformations:- > - Value Transforms > Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Covers all the constant folding scenarios for add, sub, mul, div, sqrt, fma, min, and max operations addressed by this patch. > - It also tests special case scenarios for each operation as specified by Java language specification. > - identity Transforms > Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Covers identity transformation for ReinterpretS2HFNode, DivHFNode > - idealization Transforms > Test points:- test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java > :- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java > - Contains test point for the following transform > MulHF idealization i.e. MulHF * 2 => AddHF > - Contains test point for the following transform > DivHF SRC , PoT(constant) => MulHF SRC * reciprocal (constant) > - Contains idealization test points for the following transform > ConvF2HF(FP32BinOp(ConvHF2F(x), ConvHF2F(y))) => > ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y))) @jatin-bhateja can you also merge here, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2607132748 From duke at openjdk.org Wed Jan 22 12:40:53 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 12:40:53 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 11:05:14 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 38: >> >>> 36: @SuppressWarnings("restricted") >>> 37: public MemorySegment allocate(long byteSize, long byteAlignment) { >>> 38: MemorySegment slice = backingSegment.asSlice(offset, byteSize, byteAlignment); >> >> You have re-implemented a slicing allocator (`SegmentAllocator::slicingAllocator`). I think that's probably ok, but I'll point out that slicing allocator will try to deal with alignment, and will also throw exceptions when called with non-sensical arguments. >> >> A more robust way to do this would be to: >> 1. have `reserve` pass the reserved size to `Frame` >> 2. `Frame` will slice the segment according to offset/size >> 3. then create a slicing allocator based on that segment >> 4. use the slicing allocator to implement `allocate` >> >> In our tests, something like this did not add any extra overhead (the allocation of the slicing allocator is escape-analyzed away) > > On another note: in principle if a Frame is not the latest returned in a given thread, it is not safe to allow its allocation method (and probably close too) to succeed. Consider this case: > > > Arena arenaOuter = bufferStack.reserve(100); > arenaOuter.allocate(16); // now offset is 16 > ... > Arena arenaInner = bufferStack.reserve(100); > arenaInner.allocate(16); // now offset is 32 > arenaOuter.allocate(16); // now offset is 48 // whooops > ... > arenaInner.close(); // now offset is 16 > arenaOuter.allocate(16); // now offset is 32 > arenaOuter.allocate(16); // now offset is 48 (overwriting!!) > > > The last statement in this snippet effectively overwrites the memory that has been previously allocated _by the same frame_. This is because we allow `arenaOuter::allocate` to work even after `arenaInner` has been obtained (see statement with `whooops` comment). > > Now, I believe the linker implementation is "correct" and never attempts something like this - other clients might try something similar and get surprising result. So, in the general case, I believe we should think about this (although it's fine if you do not want to tackle that in this PR) Right. Using SlicingAllocator now. Which brings up one question about alignment of the stack frames. When the linker asks for a buffer, it also has an alignment requirement. Do we guarantee anything about the alignment of Arena.ofConfined().allocate() ? Does the linker overallocate already? To accomodate for this, I added a frame alignment parameter as well => the stack itself is well-served by using a SlicingAllocator. For this, I added methods to query and reset the position, as well as whether it could satisfy a certain allocation request. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925248570 From duke at openjdk.org Wed Jan 22 12:40:53 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 12:40:53 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 12:36:17 GMT, Matthias Ernst wrote: >> On another note: in principle if a Frame is not the latest returned in a given thread, it is not safe to allow its allocation method (and probably close too) to succeed. Consider this case: >> >> >> Arena arenaOuter = bufferStack.reserve(100); >> arenaOuter.allocate(16); // now offset is 16 >> ... >> Arena arenaInner = bufferStack.reserve(100); >> arenaInner.allocate(16); // now offset is 32 >> arenaOuter.allocate(16); // now offset is 48 // whooops >> ... >> arenaInner.close(); // now offset is 16 >> arenaOuter.allocate(16); // now offset is 32 >> arenaOuter.allocate(16); // now offset is 48 (overwriting!!) >> >> >> The last statement in this snippet effectively overwrites the memory that has been previously allocated _by the same frame_. This is because we allow `arenaOuter::allocate` to work even after `arenaInner` has been obtained (see statement with `whooops` comment). >> >> Now, I believe the linker implementation is "correct" and never attempts something like this - other clients might try something similar and get surprising result. So, in the general case, I believe we should think about this (although it's fine if you do not want to tackle that in this PR) > > Right. Using SlicingAllocator now. > > Which brings up one question about alignment of the stack frames. When the linker asks for a buffer, it also has an alignment requirement. Do we guarantee anything about the alignment of Arena.ofConfined().allocate() ? Does the linker overallocate already? > > To accomodate for this, I added a frame alignment parameter as well => the stack itself is well-served by using a SlicingAllocator. For this, I added methods to query and reset the position, as well as whether it could satisfy a certain allocation request. And yes, this requires that a client operate in stack order. I added checks for this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925251331 From duke at openjdk.org Wed Jan 22 13:25:25 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 13:25:25 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v11] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op > CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: (c) start a test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/d347a87b..b0c2af1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=09-10 Stats: 126 lines in 2 files changed: 112 ins; 11 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From duke at openjdk.org Wed Jan 22 13:48:56 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 13:48:56 GMT Subject: RFR: 8287788: reuse intermediate segments allocated during FFM stub invocations [v12] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR remembers and reuses up to two small intermediate buffers per carrier-thread in subsequent calls. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.291 ? 0.031 ns/op > CallOverheadByValue.byValue avgt 10 5.464 ? 0.007 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: more test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/b0c2af1b..954a6859 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=10-11 Stats: 39 lines in 1 file changed: 16 ins; 6 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From jpai at openjdk.org Wed Jan 22 14:15:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Jan 2025 14:15:18 GMT Subject: RFR: 8341184: Clean up the interaction between the launcher native code and the LauncherHelper [v14] In-Reply-To: References: Message-ID: <9nDk9QHV1zrjx0-0bttSAYKgfCC4HmQQbYRHVc-GrCY=.cc2a6288-de16-445c-a718-a54f91b6cba7@github.com> > Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? > > As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. > > Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code. > > No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - ... and 4 more: https://git.openjdk.org/jdk/compare/16dcf15a...53a48775 ------------- Changes: https://git.openjdk.org/jdk/pull/21256/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=13 Stats: 367 lines in 2 files changed: 105 ins; 172 del; 90 mod Patch: https://git.openjdk.org/jdk/pull/21256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21256/head:pull/21256 PR: https://git.openjdk.org/jdk/pull/21256 From mark.reinhold at oracle.com Wed Jan 22 15:10:06 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 22 Jan 2025 15:10:06 +0000 Subject: New candidate JEP: 502: Stable Values (Preview) Message-ID: <20250122151005.3CB71787B60@eggemoggin.niobe.net> https://openjdk.org/jeps/502 Summary: Introduce an API for stable values, which are objects that hold immutable data. Stable values are treated as constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, stable values offer greater flexibility as to the timing of their initialization. This is a preview API. - Mark From shade at openjdk.org Wed Jan 22 15:58:14 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Jan 2025 15:58:14 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v7] In-Reply-To: References: Message-ID: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Remove vestigial reference to waitForReferenceProcessing in tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/25cb6453..2c2c4df2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=05-06 Stats: 26 lines in 1 file changed: 0 ins; 26 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From qamai at openjdk.org Wed Jan 22 16:51:19 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 22 Jan 2025 16:51:19 GMT Subject: RFR: 8345687: Improve the implementation of SegmentFactories::allocateSegment [v4] In-Reply-To: References: Message-ID: > Hi, > > This patch improves the performance of a typical `Arena::allocate` in several ways: > > - Delay the creation of the NativeMemorySegmentImpl. This avoids the merge of the instance with the one obtained from the call in the uncommon path, increasing the chance the object being scalar replaced. > - Split the allocation of over-aligned memory to a slow-path method. > - Align the memory to 8 bytes, allowing faster zeroing. > - Use a dedicated method to zero the just-allocated native memory, reduce code size and make it more straightforward. > - Make `VM.pageAlignDirectMemory` a `Boolean` instead of a `boolean` so that `false` value can be constant folded. > > Please take a look and leave your reviews, thanks a lot. Quan Anh Mai 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 six additional commits since the last revision: - copyright - Merge branch 'master' into segmentallocate - wrong init - move segment instance creation to SegmentFactories - address review - improve the implementation of SegmentFactories::allocateSegment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22610/files - new: https://git.openjdk.org/jdk/pull/22610/files/9654c322..d3cba466 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22610&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22610&range=02-03 Stats: 189769 lines in 5984 files changed: 93880 ins; 78500 del; 17389 mod Patch: https://git.openjdk.org/jdk/pull/22610.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22610/head:pull/22610 PR: https://git.openjdk.org/jdk/pull/22610 From qamai at openjdk.org Wed Jan 22 16:51:19 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 22 Jan 2025 16:51:19 GMT Subject: RFR: 8345687: Improve the implementation of SegmentFactories::allocateSegment [v3] In-Reply-To: References: <5bAs8hhqvy-c776n0_9Xqw6n8quA-c_a59ii-nWFhuE=.2eae9a1b-b46a-4626-9ac5-3ee35a34b82c@github.com> Message-ID: <4T4xAZGj1lmd8-KBdRCsBF5oltxC0mQzseUIJGTKaCE=.f71ab6fc-a247-45af-9000-9d1288bdf5d4@github.com> On Mon, 16 Dec 2024 11:01:11 GMT, Maurizio Cimadamore wrote: >> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision: >> >> - wrong init >> - move segment instance creation to SegmentFactories > > test/micro/org/openjdk/bench/java/lang/foreign/AllocTest.java line 77: > >> 75: var freeAddr = lookup.findOrThrow("free"); >> 76: CALLOC = linker.downcallHandle(callocAddr, FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG)); >> 77: FREE = linker.downcallHandle(freeAddr, FunctionDescriptor.ofVoid(ValueLayout.JAVA_LONG)); > > I'm not sure these changes are needed. It seems the main goal here is to avoid the cost of the capture associated with `CLayouts::freeMemory` ? If so, can't we just store that consumer into a static final and call it a day? I think then we could avoid the `static` init, and leave most of the code unchanged, except for the additional static field? The main goal here is that passing/receiving raw addresses as longs is cheaper than as `MemorySegment`s. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22610#discussion_r1925646301 From jvernee at openjdk.org Wed Jan 22 16:55:51 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 22 Jan 2025 16:55:51 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls. [v13] In-Reply-To: <3ftmhEPFJCuCYM9SH0F7atZBj9mqovX5dXekB9laCIE=.bdf7ba31-aede-43b2-9245-6e285e082f46@github.com> References: <3ftmhEPFJCuCYM9SH0F7atZBj9mqovX5dXekB9laCIE=.bdf7ba31-aede-43b2-9245-6e285e082f46@github.com> Message-ID: On Wed, 22 Jan 2025 15:01:03 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > an attempt at a stress test I've removed the trailing `.` from the issue title, so you should be able to fix the warning now. I don't mind changing the title/description to something else as well ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2607765961 From naoto at openjdk.org Wed Jan 22 16:58:47 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 22 Jan 2025 16:58:47 GMT Subject: RFR: 8347965: (tz) Update Timezone Data to 2025a In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:03:45 GMT, Johny Jose wrote: > Changes to Update Timezone Data to 2025a LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23212#pullrequestreview-2567779568 From rriggs at openjdk.org Wed Jan 22 17:12:55 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 22 Jan 2025 17:12:55 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> Message-ID: On Tue, 21 Jan 2025 18:44:39 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/util/Currency.java line 469: >> >>> 467: >>> 468: // Initialize the set of available currencies if needed >>> 469: private static synchronized void initAvailableCurrencies() { >> >> Should we make `available` volatile so we can avoid entering the monitor if the currencies are initialized? >> >> (Note: We may get Stable Values very soon, at that point SV is a much better solution) > > Thanks Chen, made `available` volatile and implemented DCL in https://github.com/openjdk/jdk/pull/23165/commits/96e86c800f1d1af1c20bfee944c298f17b7e8860. > Also added a duplicate elements test as you suggested. I'm not sure how useful it is to optimize the performance of `availableCurrencies` access to "available", but adding volatile will slow every access down. The computation of the available currencies is stable, so a race computing it is benign. Except for the available hashSet being partially filled when read by the thread calling `getAvailableCurrencies()`. That could be remedied by using a new local for the new HashSet in initAvailableCurrencies and assigning to available only when the set is completely initialized. (And yes, this looks like a good fit for stable values.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1925680680 From sgehwolf at openjdk.org Wed Jan 22 17:15:55 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 22 Jan 2025 17:15:55 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. I only looked at the jlink changes which look fine to me. Fine to keep with/without the suggestion. src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 78: > 76: err.runtime.link.modified.file={0} wurde ge?ndert > 77: err.runtime.link.patched.module=jlink unterst?tzt keine Verkn?pfung vom Laufzeitimage unter einer gepatchten Laufzeit mit --patch-module > 78: err.no.module.path=--module-path-Option muss mit --add-modules ALL-MODULE-PATH angegeben werden Suggestion: err.no.module.path=--module-path Option muss mit --add-modules ALL-MODULE-PATH angegeben werden ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2567811411 PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1925680330 From shade at openjdk.org Wed Jan 22 17:16:48 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Jan 2025 17:16:48 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v7] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 15:58:14 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove vestigial reference to waitForReferenceProcessing in tests Some test code removals should disappear once we merge https://github.com/openjdk/jdk/pull/23239. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2607813845 From alanb at openjdk.org Wed Jan 22 17:28:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 22 Jan 2025 17:28:52 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v7] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 15:58:14 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove vestigial reference to waitForReferenceProcessing in tests I've done a pass over the latest version and I think it's okay but want to do another pass on tomorrow, only because this is change code in a very critical area. src/java.base/share/classes/java/nio/Bits.java line 160: > 158: } catch (InterruptedException e) { > 159: interrupted = true; > 160: break; I'm not sure that bailing out to throw OOME when interrupted is the right thing to do here. If ByteBuffer.allocateDIrect is called with the interrupt status set, or someone interrupts a thread while allocating on this slow path, then it would be surprising to have it throw OOME when it might have succeeded (with the interrupt status set). src/java.base/share/classes/java/nio/BufferCleaner.java line 48: > 46: } > 47: > 48: public static class Canary implements Runnable { Confusing for Canary to be public, it's not accessible outside of this package. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2607840604 PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1925699621 PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1925700380 From shade at openjdk.org Wed Jan 22 17:50:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Jan 2025 17:50:52 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v8] In-Reply-To: References: Message-ID: <45N5sfuYxIBGbY8f0IUwR_L84ABni1q3dXobFdiH2dI=.838e8a67-9d2f-4a8f-9eec-e143f4a97fe2@github.com> > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Alan's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/2c2c4df2..1b8b3ff1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From shade at openjdk.org Wed Jan 22 17:50:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Jan 2025 17:50:54 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v7] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:23:53 GMT, Alan Bateman wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove vestigial reference to waitForReferenceProcessing in tests > > src/java.base/share/classes/java/nio/Bits.java line 160: > >> 158: } catch (InterruptedException e) { >> 159: interrupted = true; >> 160: break; > > I'm not sure that bailing out to throw OOME when interrupted is the right thing to do here. If ByteBuffer.allocateDIrect is called with the interrupt status set, or someone interrupts a thread while allocating on this slow path, then it would be surprising to have it throw OOME when it might have succeeded (with the interrupt status set). Agreed. I thought I maintained the same interrupt behavior like before, but now I see old code does not bail on interrupt, it just restores the interrupt status on both failing and passing paths. Dropped this `break` in new commit. > src/java.base/share/classes/java/nio/BufferCleaner.java line 48: > >> 46: } >> 47: >> 48: public static class Canary implements Runnable { > > Confusing for Canary to be public, it's not accessible outside of this package. Right. Can be package-private. Done in new commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1925728413 PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1925728718 From duke at openjdk.org Wed Jan 22 18:18:47 2025 From: duke at openjdk.org (Matthias Ernst) Date: Wed, 22 Jan 2025 18:18:47 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v14] In-Reply-To: References: Message-ID: <48NT2sVZT1fzZwS42MZeQ671SqgLincHR6K5JOgNdD4=.ec7645db-c002-4b89-92ac-b7256357359e@github.com> > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR implements a per carrier-thread stacked allocator. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op > CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: (c) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/686132b1..13dfec94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From jlu at openjdk.org Wed Jan 22 18:39:47 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 22 Jan 2025 18:39:47 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2] In-Reply-To: References: Message-ID: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect jlink review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23184/files - new: https://git.openjdk.org/jdk/pull/23184/files/5ea5ddc9..cc8b23fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23184&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23184&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23184/head:pull/23184 PR: https://git.openjdk.org/jdk/pull/23184 From jlu at openjdk.org Wed Jan 22 18:39:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 22 Jan 2025 18:39:51 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> Message-ID: <4T4Fbje9gPyQuVXSduhYftns423fniOH-PjIqKi3VQw=.9b302512-fd62-4882-8d60-41a1e043ea9c@github.com> On Wed, 22 Jan 2025 17:09:54 GMT, Roger Riggs wrote: >> Thanks Chen, made `available` volatile and implemented DCL in https://github.com/openjdk/jdk/pull/23165/commits/96e86c800f1d1af1c20bfee944c298f17b7e8860. >> Also added a duplicate elements test as you suggested. > > I'm not sure how useful it is to optimize the performance of `availableCurrencies` access to "available", but adding volatile will slow every access down. > The computation of the available currencies is stable, so a race computing it is benign. > Except for the available hashSet being partially filled when read by the thread calling `getAvailableCurrencies()`. > That could be remedied by using a new local for the new HashSet in initAvailableCurrencies and assigning to available only when the set is completely initialized. > (And yes, this looks like a good fit for stable values.) How about I revert the most recent commit and have this PR simply deliver the change to provide the stream of currencies. I'll file another issue to improve `available` to use stable values when that is available. Does that sound fine? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1925795274 From asemenyuk at openjdk.org Wed Jan 22 18:39:48 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 22 Jan 2025 18:39:48 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 18:34:46 GMT, Justin Lu wrote: >> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. >> >> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. >> >> Once this pull request is integrated, it will be back-ported to the jdk24 branch. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect jlink review jpackage changes look good. ------------- Marked as reviewed by asemenyuk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2567985117 From jlu at openjdk.org Wed Jan 22 18:39:49 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 22 Jan 2025 18:39:49 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 17:09:40 GMT, Severin Gehwolf wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect jlink review > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties line 78: > >> 76: err.runtime.link.modified.file={0} wurde ge?ndert >> 77: err.runtime.link.patched.module=jlink unterst?tzt keine Verkn?pfung vom Laufzeitimage unter einer gepatchten Laufzeit mit --patch-module >> 78: err.no.module.path=--module-path-Option muss mit --add-modules ALL-MODULE-PATH angegeben werden > > Suggestion: > > err.no.module.path=--module-path Option muss mit --add-modules ALL-MODULE-PATH angegeben werden Fixed it in https://github.com/openjdk/jdk/pull/23184/commits/cc8b23fb9d65a9ea603c6f7576d651f447ac2d5e. The option reads incorrect with "-Option" appended, regardless of language rules. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23184#discussion_r1925792014 From joehw at openjdk.org Wed Jan 22 19:01:28 2025 From: joehw at openjdk.org (Joe Wang) Date: Wed, 22 Jan 2025 19:01:28 GMT Subject: RFR: 8343609: Broken links in java.xml Message-ID: Fix broken links in java.xml: Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. QName: rewrote the javadocs. ------------- Commit messages: - 8343609: Broken links in java.xml Changes: https://git.openjdk.org/jdk/pull/23242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343609 Stats: 78 lines in 7 files changed: 2 ins; 38 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/23242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23242/head:pull/23242 PR: https://git.openjdk.org/jdk/pull/23242 From jvernee at openjdk.org Wed Jan 22 20:08:54 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 22 Jan 2025 20:08:54 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v13] In-Reply-To: <3ftmhEPFJCuCYM9SH0F7atZBj9mqovX5dXekB9laCIE=.bdf7ba31-aede-43b2-9245-6e285e082f46@github.com> References: <3ftmhEPFJCuCYM9SH0F7atZBj9mqovX5dXekB9laCIE=.bdf7ba31-aede-43b2-9245-6e285e082f46@github.com> Message-ID: On Wed, 22 Jan 2025 15:01:03 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > an attempt at a stress test src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 97: > 95: private void assertOrder() { > 96: if (tos != stack.currentOffset()) > 97: throw new IllegalStateException("Out of order access: frame not TOS"); I'd prefer not using an abbreviation here. (probably for the variable name as well) Suggestion: throw new IllegalStateException("Out of order access: frame not top-of-stack"); src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 43: > 41: import jdk.internal.foreign.abi.x64.sysv.SysVx64Linker; > 42: import jdk.internal.foreign.abi.x64.windows.Windowsx64Linker; > 43: import jdk.internal.misc.CarrierThreadLocal; Spurious import? Suggestion: src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 386: > 384: } > 385: > 386: private static final BufferStack LINKER_STACK = new BufferStack(256); I think we want to make the size configurable. That would also make it easier to test with different values Suggestion: private static final int LINKER_STACK_SIZE = Integer.getInteger("jdk.internal.foreign.LINKER_STACK_SIZE", 256); private static final BufferStack LINKER_STACK = new BufferStack(LINKER_STACK_SIZE); test/jdk/java/foreign/TestBufferStack.java line 9: > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided > 9: * by Oracle in the LICENSE file that accompanied this code. This is the wrong copyright header. Note that tests have a different header which does not include the class path exception. test/micro/org/openjdk/bench/java/lang/foreign/CallOverheadByValue.java line 2: > 1: /* > 2: * Copyright (c) 2021, 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925670249 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925665999 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925668240 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925676168 PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925669213 From jvernee at openjdk.org Wed Jan 22 20:08:55 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 22 Jan 2025 20:08:55 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v14] In-Reply-To: <48NT2sVZT1fzZwS42MZeQ671SqgLincHR6K5JOgNdD4=.ec7645db-c002-4b89-92ac-b7256357359e@github.com> References: <48NT2sVZT1fzZwS42MZeQ671SqgLincHR6K5JOgNdD4=.ec7645db-c002-4b89-92ac-b7256357359e@github.com> Message-ID: On Wed, 22 Jan 2025 18:18:47 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > (c) test/jdk/java/foreign/TestBufferStack.java line 122: > 120: thread -> Assert.assertTrue(thread.isAlive())); > 121: } > 122: } I think we should also have a test that exercises the new code in the context of the linker. We have some tests that test downcall -> upcall with by-value structs, but I think we should also have a test that keeps going until it exhausts the buffer. Something like `test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java` (but without the `Whitebox` stuff). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925896935 From prr at openjdk.org Wed Jan 22 20:37:51 2025 From: prr at openjdk.org (Phil Race) Date: Wed, 22 Jan 2025 20:37:51 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 09:23:10 GMT, Hannes Walln?fer wrote: >> src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288: >> >>> 1286: >>> 1287: /** >>> 1288: * Serializes this {@code DataFlavor}. >> >> This most definitely changes the serialisation spec. So a CSR is needed. >> Also shouldn't readExternal be updated to correspond ? > > Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that. > > @prrace do you have any suggestions for the spec change, or are you ok with the proposed wording? There's not a great number of "good" examples of this in the JDK, so probably OK except it seems like most cases will do it like a normal javadoc method so you'd want an @param tag too. note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1925928563 From bchristi at openjdk.org Wed Jan 22 20:38:49 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 22 Jan 2025 20:38:49 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v8] In-Reply-To: <45N5sfuYxIBGbY8f0IUwR_L84ABni1q3dXobFdiH2dI=.838e8a67-9d2f-4a8f-9eec-e143f4a97fe2@github.com> References: <45N5sfuYxIBGbY8f0IUwR_L84ABni1q3dXobFdiH2dI=.838e8a67-9d2f-4a8f-9eec-e143f4a97fe2@github.com> Message-ID: On Wed, 22 Jan 2025 17:50:52 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Alan's review src/java.base/share/classes/java/lang/ref/Reference.java line 286: > 284: { > 285: synchronized (processPendingLock) { > 286: if (processPendingActive || hasReferencePendingList()) { It looks like `hasReferencePendingList()` is no longer used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1925928978 From cjplummer at openjdk.org Wed Jan 22 21:19:49 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 22 Jan 2025 21:19:49 GMT Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 08:49:52 GMT, Matthias Baesken wrote: >> test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 104: >> >>> 102: if (!res) { // try once more >>> 103: launch(expectedMessage, Arrays.asList(toolArgs), false); >>> 104: } >> >> `launch()` should take an allowRetry argument and only retry if true. This test is operated in two different modes. One is with an active target process and one is with a target process that should be stabilized and inactive. The latter is not allowed to retry since it should never fail. Also, it would help to add a comment as to why the retry is being done. See the comment in `printStackTrace()`. >> >> I think a better approach would be for launch() to just return if a retry should be done. testHeapDump() should check the result, and just immediately return true if launch() returns true. > >> launch() should take an allowRetry argument and only retry if true. > > Are you talking about `public static void launch(String expectedMessage, String... toolArgs)` ? Yes, but my suggestion on how to fix this might not be the best one. It's a bit hard to get the naming and usage of flags and logic right here. allowRetry, vs retry, vs doSleep. They all relate. Bottom line is that we should only ever attempt a retry if doSleep is false. Right now that flag is checked in printStackTraces(), and determines if true should be returned to allow a retry, but only if we aren't already doing a retry. Something similar needs to be done with launch() when it is deciding to return true or false after a failure. Right now it is only checking the allowRetry flag, but it should also check the doSleep flag. I think in testHeapDump(), the calling of `launch(String expectedMessage, String... toolArgs)` should be done in a way similar to calling `printStackTraces()`. Pass in allowRetry and assign the result to the retry boolean. If retry is true, then return it right away (back to main() so it can retry). In `launch(String expectedMessage, String... toolArgs)`, only call `launch(String expectedMessage, List toolArgs, boolean allowRetry)` once, passing in allowRetry flag. In `launch(String expectedMessage, List toolArgs, boolean allowRetry)`, only return true to allow a retry if allowRetry is true and doSleep is false. Anyway, it's kind of messy and there may be another way. The key issue with your current version is that it always allows for a retry, but it should only allow a retry if doSleep is false. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1925979789 From javalists at cbfiddle.com Wed Jan 22 21:53:53 2025 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 22 Jan 2025 13:53:53 -0800 Subject: New candidate JEP: 502: Stable Values (Preview) In-Reply-To: <20250122151005.3CB71787B60@eggemoggin.niobe.net> References: <20250122151005.3CB71787B60@eggemoggin.niobe.net> Message-ID: The JEP describes StableValue as a step towards deferred immutability, defined as: "What we are missing is a way to promise that a field will be initialized by the time it is used, with a value that is computed at most once and, furthermore, safely with respect to concurrency. In other words, we need a way to defer immutability.? What is the roadmap for getting the rest of the way? StableValue looks to me like an implementation mechanism, something that someday the compiler and JVM might use. It does not look like something I would want to use in my source code. If introduced as a public API, will StableValue be obsolete soon thereafter? > On Jan 22, 2025, at 7:10?AM, Mark Reinhold wrote: > > https://openjdk.org/jeps/502 > > Summary: Introduce an API for stable values, which are objects that > hold immutable data. Stable values are treated as constants by the > JVM, enabling the same performance optimizations that are enabled > by declaring a field final. Compared to final fields, however, > stable values offer greater flexibility as to the timing of their > initialization. This is a preview API. > > - Mark From ihse at openjdk.org Wed Jan 22 22:04:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 22 Jan 2025 22:04:57 GMT Subject: RFR: 8348324: The failure handler cannot be build by JDK 24 due to restricted warning Message-ID: GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger a `restricted` warning when building with JDK 24 or newer, and failing the build. This should be fixed by adding a @SuppressWarnings("restricted"). ------------- Commit messages: - 8348324: The failure handler cannot be build by JDK 24 due to restricted warning Changes: https://git.openjdk.org/jdk/pull/23244/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23244&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348324 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23244.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23244/head:pull/23244 PR: https://git.openjdk.org/jdk/pull/23244 From nbenalla at openjdk.org Wed Jan 22 23:35:50 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 22 Jan 2025 23:35:50 GMT Subject: RFR: 8343609: Broken links in java.xml In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 18:55:10 GMT, Joe Wang wrote: > Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. > > QName: rewrote the javadocs. Not a 'R'eviewer but I left a comment. src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java line 43: > 41: * external references using catalogs. > 42: *

> 43: * The I think this file's copyright header needs to be updated. ------------- PR Review: https://git.openjdk.org/jdk/pull/23242#pullrequestreview-2568506160 PR Review Comment: https://git.openjdk.org/jdk/pull/23242#discussion_r1926116089 From naoto at openjdk.org Wed Jan 22 23:35:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 22 Jan 2025 23:35:52 GMT Subject: RFR: 8343609: Broken links in java.xml In-Reply-To: References: Message-ID: <7AqKocen1VzQl6YdQyo-2ZvSXfwndIIkv1cl7fFeC44=.08af0896-781d-46f7-9d04-d3ad421b9f42@github.com> On Wed, 22 Jan 2025 18:55:10 GMT, Joe Wang wrote: > Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. > > QName: rewrote the javadocs. Looks good. Some minor nits src/java.xml/share/classes/javax/xml/namespace/QName.java line 332: > 330: > 331: /** > 332: * Returns the string representation of this {@code QName}. Could use {@return ...} construct (same for `valueOf`) src/java.xml/share/classes/javax/xml/namespace/QName.java line 358: > 356: * } > 357: * Since the {@code Prefix} is not represented in the string form, it will be > 358: * set to {@link javax.xml.XMLConstants#DEFAULT_NS_PREFIX XMLConstants.DEFAULT_NS_PREFIX}. Since this is in the import statement, `javax.xml.` does not seem to be needed. src/java.xml/share/classes/javax/xml/namespace/QName.java line 362: > 360: * @apiNote This method does not perform full validation of the resulting > 361: * {@code QName}. The {@code NamespaceURI} is not validated as a > 362: * URI reference. `https` would be preferred. (same for the following locations) ------------- PR Review: https://git.openjdk.org/jdk/pull/23242#pullrequestreview-2568493694 PR Review Comment: https://git.openjdk.org/jdk/pull/23242#discussion_r1926106540 PR Review Comment: https://git.openjdk.org/jdk/pull/23242#discussion_r1926115569 PR Review Comment: https://git.openjdk.org/jdk/pull/23242#discussion_r1926115385 From coleenp at openjdk.org Wed Jan 22 23:43:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 22 Jan 2025 23:43:45 GMT Subject: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam wrote: > I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there. > > The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java. > > ### How this works: > > For example, let's assume you have the following classfiles in foo.jar: > > > interface MyInterface1 {} > interface MyInterface2 {} > class MyClass extends Object implements MyInterface1, MyInterface2 {} > > > The CDS classlist file can look like this: > > > java/lang/Object id: 1 > MyInterface1: id: 2 super: 1 source: foo.jar > MyInterface2: id: 3 super: 1 source: foo.jar > MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar > > > When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters: > > - `name` = "MyClass" > - `superClass` = java.lang.Object > - `interfaces` = {MyInterface1, MyInterface2} > > `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`. I like this change a lot, except for the name "unregistered" but that can be taken up in some other way. If I understand correctly, this just creates a dummy class loader to load the classes you want to share from the non-boot, app or system class loader. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23226#pullrequestreview-2568515552 From bchristi at openjdk.org Wed Jan 22 23:46:49 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 22 Jan 2025 23:46:49 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v8] In-Reply-To: <45N5sfuYxIBGbY8f0IUwR_L84ABni1q3dXobFdiH2dI=.838e8a67-9d2f-4a8f-9eec-e143f4a97fe2@github.com> References: <45N5sfuYxIBGbY8f0IUwR_L84ABni1q3dXobFdiH2dI=.838e8a67-9d2f-4a8f-9eec-e143f4a97fe2@github.com> Message-ID: <9-yWCMfc8D4YFZFryYjeYJTV97f-wz9mon-7ZjRct_0=.1bfe4f67-28b1-48f7-8454-4d95a358750d@github.com> On Wed, 22 Jan 2025 17:50:52 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Alan's review src/java.base/share/classes/java/nio/BufferCleaner.java line 31: > 29: import java.lang.ref.Cleaner.Cleanable; > 30: > 31: class BufferCleaner { It looks like `BufferCleaner` is not meant to be instantiated. A private constructor (that throws?) would make that clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1926125201 From joehw at openjdk.org Thu Jan 23 00:35:25 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 23 Jan 2025 00:35:25 GMT Subject: RFR: 8343609: Broken links in java.xml [v2] In-Reply-To: References: Message-ID: > Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. > > QName: rewrote the javadocs. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: use return construct; s/http/https ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23242/files - new: https://git.openjdk.org/jdk/pull/23242/files/7a943956..58e89149 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23242&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23242&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/23242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23242/head:pull/23242 PR: https://git.openjdk.org/jdk/pull/23242 From joehw at openjdk.org Thu Jan 23 00:46:07 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 23 Jan 2025 00:46:07 GMT Subject: RFR: 8343609: Broken links in java.xml [v3] In-Reply-To: References: Message-ID: > Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. > > QName: rewrote the javadocs. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: s/javax.xml.XMLConstants/XMLConstants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23242/files - new: https://git.openjdk.org/jdk/pull/23242/files/58e89149..1dbf1ecb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23242&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23242&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/23242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23242/head:pull/23242 PR: https://git.openjdk.org/jdk/pull/23242 From joehw at openjdk.org Thu Jan 23 00:46:07 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 23 Jan 2025 00:46:07 GMT Subject: RFR: 8343609: Broken links in java.xml [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 00:35:25 GMT, Joe Wang wrote: >> Fix broken links in java.xml: >> >> Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. >> >> QName: rewrote the javadocs. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > use return construct; s/http/https Thanks Nizar, Naoto. Updated accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23242#issuecomment-2608593903 From ccheung at openjdk.org Thu Jan 23 01:10:54 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 23 Jan 2025 01:10:54 GMT Subject: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam wrote: > I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there. > > The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java. > > ### How this works: > > For example, let's assume you have the following classfiles in foo.jar: > > > interface MyInterface1 {} > interface MyInterface2 {} > class MyClass extends Object implements MyInterface1, MyInterface2 {} > > > The CDS classlist file can look like this: > > > java/lang/Object id: 1 > MyInterface1: id: 2 super: 1 source: foo.jar > MyInterface2: id: 3 super: 1 source: foo.jar > MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar > > > When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters: > > - `name` = "MyClass" > - `superClass` = java.lang.Object > - `interfaces` = {MyInterface1, MyInterface2} > > `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`. Looks like a good cleanup. I have couple of comments. src/hotspot/share/cds/unregisteredClasses.cpp line 72: > 70: > 71: JavaValue result(T_OBJECT); > 72: JavaCallArguments args(2); Should the 2 be increased to 3? src/hotspot/share/classfile/vmSymbols.hpp line 742: > 740: template(toFileURL_name, "toFileURL") \ > 741: template(toFileURL_signature, "(Ljava/lang/String;)Ljava/net/URL;") \ > 742: template(url_array_classloader_void_signature, "([Ljava/net/URL;Ljava/lang/ClassLoader;)V") \ I think you can also remove the following since `URLClassLoader` is not used directly anymore: `do_klass(URLClassLoader_klass, java_net_URLClassLoader ) ` ------------- PR Review: https://git.openjdk.org/jdk/pull/23226#pullrequestreview-2568629771 PR Review Comment: https://git.openjdk.org/jdk/pull/23226#discussion_r1926215557 PR Review Comment: https://git.openjdk.org/jdk/pull/23226#discussion_r1926205535 From iklam at openjdk.org Thu Jan 23 02:04:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 23 Jan 2025 02:04:33 GMT Subject: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() [v2] In-Reply-To: References: Message-ID: > I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there. > > The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java. > > ### How this works: > > For example, let's assume you have the following classfiles in foo.jar: > > > interface MyInterface1 {} > interface MyInterface2 {} > class MyClass extends Object implements MyInterface1, MyInterface2 {} > > > The CDS classlist file can look like this: > > > java/lang/Object id: 1 > MyInterface1: id: 2 super: 1 source: foo.jar > MyInterface2: id: 3 super: 1 source: foo.jar > MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar > > > When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters: > > - `name` = "MyClass" > - `superClass` = java.lang.Object > - `interfaces` = {MyInterface1, MyInterface2} > > `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`. Ioi Lam 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: - Merge branch 'master' into 8348240-remove-lookup_super_for_unregistered_class - @calvinccheung comments - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23226/files - new: https://git.openjdk.org/jdk/pull/23226/files/ca801052..e03dfc50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23226&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23226&range=00-01 Stats: 1256 lines in 46 files changed: 574 ins; 462 del; 220 mod Patch: https://git.openjdk.org/jdk/pull/23226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23226/head:pull/23226 PR: https://git.openjdk.org/jdk/pull/23226 From jiangli at openjdk.org Thu Jan 23 02:17:38 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 23 Jan 2025 02:17:38 GMT Subject: RFR: 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c Message-ID: Please review this trivial cleanup that removes the #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks. ------------- Commit messages: - 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c Changes: https://git.openjdk.org/jdk/pull/23247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348348 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23247/head:pull/23247 PR: https://git.openjdk.org/jdk/pull/23247 From iklam at openjdk.org Thu Jan 23 02:28:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 23 Jan 2025 02:28:48 GMT Subject: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() [v2] In-Reply-To: References: Message-ID: <3eKO2PFbnDRP4UFSSMDPeNJYNj_HL8y4E3GpVpHRTIk=.613bef4f-e927-4d68-8a2f-575d1c851868@github.com> On Thu, 23 Jan 2025 01:04:05 GMT, Calvin Cheung wrote: >> Ioi Lam 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: >> >> - Merge branch 'master' into 8348240-remove-lookup_super_for_unregistered_class >> - @calvinccheung comments >> - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() > > src/hotspot/share/cds/unregisteredClasses.cpp line 72: > >> 70: >> 71: JavaValue result(T_OBJECT); >> 72: JavaCallArguments args(2); > > Should the 2 be increased to 3? I changed it to 3. I wonder why the 2 didn't fail. It turns out that `JavaCallArguments` reserves at least 8 slots. > src/hotspot/share/classfile/vmSymbols.hpp line 742: > >> 740: template(toFileURL_name, "toFileURL") \ >> 741: template(toFileURL_signature, "(Ljava/lang/String;)Ljava/net/URL;") \ >> 742: template(url_array_classloader_void_signature, "([Ljava/net/URL;Ljava/lang/ClassLoader;)V") \ > > I think you can also remove the following since `URLClassLoader` is not used directly anymore: > `do_klass(URLClassLoader_klass, java_net_URLClassLoader ) ` Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23226#discussion_r1926270349 PR Review Comment: https://git.openjdk.org/jdk/pull/23226#discussion_r1926270410 From jlu at openjdk.org Thu Jan 23 02:50:46 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 02:50:46 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v7] In-Reply-To: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: > Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. > > The motivation can be found in the CSR. Justin Lu 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 eight additional commits since the last revision: - make 'available' un-volatile - Merge branch 'master' into 8347949-Currency-Stream - reflect feedback - provide message for test assertion - reflect Roger's review - init hashset w/ accurate size via HashSet.newHashSet(int) - synchronize init method over block - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23165/files - new: https://git.openjdk.org/jdk/pull/23165/files/96e86c80..ade21c92 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=05-06 Stats: 21807 lines in 2152 files changed: 10604 ins; 5415 del; 5788 mod Patch: https://git.openjdk.org/jdk/pull/23165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165 PR: https://git.openjdk.org/jdk/pull/23165 From jlu at openjdk.org Thu Jan 23 02:50:46 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 02:50:46 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: <4T4Fbje9gPyQuVXSduhYftns423fniOH-PjIqKi3VQw=.9b302512-fd62-4882-8d60-41a1e043ea9c@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> <4T4Fbje9gPyQuVXSduhYftns423fniOH-PjIqKi3VQw=.9b302512-fd62-4882-8d60-41a1e043ea9c@github.com> Message-ID: On Wed, 22 Jan 2025 18:37:32 GMT, Justin Lu wrote: >> I'm not sure how useful it is to optimize the performance of `availableCurrencies` access to "available", but adding volatile will slow every access down. >> The computation of the available currencies is stable, so a race computing it is benign. >> Except for the available hashSet being partially filled when read by the thread calling `getAvailableCurrencies()`. >> That could be remedied by using a new local for the new HashSet in initAvailableCurrencies and assigning to available only when the set is completely initialized. >> (And yes, this looks like a good fit for stable values.) > > How about I revert the most recent commit and have this PR simply deliver the change to provide the stream of currencies. I'll file another issue to improve `available` to use stable values when that is available. Does that sound fine? Reverted in https://github.com/openjdk/jdk/pull/23165/commits/ade21c923369d0f0423335c3073e2c615adf050c. Filed [JDK-8348351](https://bugs.openjdk.org/browse/JDK-8348351) to implement `available` as a stable value when applicable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1926283835 From jlu at openjdk.org Thu Jan 23 02:55:47 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 02:55:47 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs Message-ID: Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. ------------- Commit messages: - space at EOF - test - src Changes: https://git.openjdk.org/jdk/pull/23251/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347955 Stats: 177 lines in 15 files changed: 146 ins; 3 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/23251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23251/head:pull/23251 PR: https://git.openjdk.org/jdk/pull/23251 From duke at openjdk.org Thu Jan 23 05:05:48 2025 From: duke at openjdk.org (duke) Date: Thu, 23 Jan 2025 05:05:48 GMT Subject: RFR: 8347965: (tz) Update Timezone Data to 2025a In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:03:45 GMT, Johny Jose wrote: > Changes to Update Timezone Data to 2025a @johnyjose30 Your change (at version 20715329faf466ba6f7fb748f35fb2a4ff22c53e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23212#issuecomment-2608862907 From jwaters at openjdk.org Thu Jan 23 05:26:46 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 23 Jan 2025 05:26:46 GMT Subject: RFR: 8348324: The failure handler cannot be build by JDK 24 due to restricted warning In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 21:59:40 GMT, Magnus Ihse Bursie wrote: > GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger a `restricted` warning when building with JDK 24 or newer, and failing the build. > > This should be fixed by adding a @SuppressWarnings("restricted"). Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23244#pullrequestreview-2568889138 From aviad1486 at gmail.com Thu Jan 23 05:45:23 2025 From: aviad1486 at gmail.com (Aviad Zer) Date: Thu, 23 Jan 2025 07:45:23 +0200 Subject: Proposal to extend Math.min and Math.max to support multiple parameters Message-ID: Dear Core-Libs Dev Team, I hope this message finds you well. I would like to propose an enhancement to the Math class to extend the Math.min and Math.max methods to support multiple parameters using varargs. This enhancement aims to improve code readability and provide a more intuitive way to find the minimum or maximum value among multiple numbers without requiring nested calls or external logic. Motivation: Currently, developers must either nest multiple calls to Math.min or use the Streams API (Arrays.stream(values).min()), which can feel cumbersome for simple cases. By introducing varargs-based Math.min and Math.max methods for int, long, float, and double, this proposal simplifies the process and aligns with the expected functionality of these utility methods. Current Progress: I have submitted a pull request for this enhancement: PR #23138 . The PR includes: - Implementation of Math.min and Math.max with varargs for int, long, float, and double. Feedback and Next Steps: I am reaching out to gather your feedback on this proposal and determine whether this enhancement aligns with the goals of the core-libs. I understand that significant changes like this may require a CSR, and I am fully prepared to follow the process once I have a response from the community. Thank you for your time and consideration. I look forward to hearing your thoughts and engaging with the community on this proposal. Best regards, Aviad Zer -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.org Thu Jan 23 05:47:21 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 23 Jan 2025 05:47:21 GMT Subject: RFR: 8348365: Bad format string in CLDRDisplayNamesTest Message-ID: This change fixes an incorrect call to `printf` for a failure message in `CLDRDisplayNamesTest`. ------------- Commit messages: - 8348365: Bad format string in CLDRDisplayNamesTest Changes: https://git.openjdk.org/jdk/pull/23252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23252&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348365 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23252/head:pull/23252 PR: https://git.openjdk.org/jdk/pull/23252 From asotona at openjdk.org Thu Jan 23 07:19:56 2025 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 23 Jan 2025 07:19:56 GMT Subject: RFR: 8348283: java.lang.classfile.components.snippets.PackageSnippets shipped in java.base.jmod Message-ID: JDK-8345486 moved java.lang.classfile.components.snippet-files.PackageSnippets to jdk.internal.classfile.components.snippet-files folder. However change of the package name declared in the snippet file was omitted. Please review. Thank you, Adam ------------- Commit messages: - 8348283: java.lang.classfile.components.snippets.PackageSnippets shipped in java.base.jmod Changes: https://git.openjdk.org/jdk/pull/23254/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23254&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348283 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23254/head:pull/23254 PR: https://git.openjdk.org/jdk/pull/23254 From duke at openjdk.org Thu Jan 23 07:36:09 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 07:36:09 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v15] In-Reply-To: References: Message-ID: <7eHrWKWqStfawuJyWWhkA8K9vS14Mot1W4YvRODlmfc=.33b171ea-40d5-44ee-87ff-c4241ad4c325@github.com> > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR implements a per carrier-thread stacked allocator. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op > CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/13dfec94..f09a29de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=13-14 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From jpai at openjdk.org Thu Jan 23 07:53:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 23 Jan 2025 07:53:56 GMT Subject: RFR: 8348324: The failure handler cannot be build by JDK 24 due to restricted warning In-Reply-To: References: Message-ID: <88_JKxwOlBQQCyAQG2IQw4KQCw4j4DlnkYFaOIxnIvU=.45e1abee-f596-4d05-8708-c93c0e08358f@github.com> On Wed, 22 Jan 2025 21:59:40 GMT, Magnus Ihse Bursie wrote: > GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger a `restricted` warning when building with JDK 24 or newer, and failing the build. > > This should be fixed by adding a @SuppressWarnings("restricted"). This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23244#pullrequestreview-2569096689 From ihse at openjdk.org Thu Jan 23 07:53:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 23 Jan 2025 07:53:56 GMT Subject: Integrated: 8348324: The failure handler cannot be build by JDK 24 due to restricted warning In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 21:59:40 GMT, Magnus Ihse Bursie wrote: > GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger a `restricted` warning when building with JDK 24 or newer, and failing the build. > > This should be fixed by adding a @SuppressWarnings("restricted"). This pull request has now been integrated. Changeset: e69e5b79 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/e69e5b7960002b35af8c7579e5be043e8c7d63fa Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8348324: The failure handler cannot be build by JDK 24 due to restricted warning Reviewed-by: jwaters, jpai ------------- PR: https://git.openjdk.org/jdk/pull/23244 From mli at openjdk.org Thu Jan 23 08:16:52 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 23 Jan 2025 08:16:52 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 16:02:55 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review suggestions incorporated. src/hotspot/share/opto/library_call.cpp line 8670: > 8668: > 8669: const TypeInstPtr* box_type = _gvn.type(argument(0))->isa_instptr(); > 8670: if (box_type == nullptr || box_type->const_oop() == nullptr) { Hi, this is not a review comment. Just curious, to continue the following code path why does `box_type` must have a valid `const_oop`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926540874 From duke at openjdk.org Thu Jan 23 08:29:55 2025 From: duke at openjdk.org (Johny Jose) Date: Thu, 23 Jan 2025 08:29:55 GMT Subject: Integrated: 8347965: (tz) Update Timezone Data to 2025a In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:03:45 GMT, Johny Jose wrote: > Changes to Update Timezone Data to 2025a This pull request has now been integrated. Changeset: caa3c78f Author: Johny Jose Committer: Sean Coffey URL: https://git.openjdk.org/jdk/commit/caa3c78f7837b1f561740184bd8f9cb671c467eb Stats: 249 lines in 12 files changed: 150 ins; 53 del; 46 mod 8347965: (tz) Update Timezone Data to 2025a Reviewed-by: coffeys, naoto ------------- PR: https://git.openjdk.org/jdk/pull/23212 From shade at openjdk.org Thu Jan 23 08:30:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Jan 2025 08:30:49 GMT Subject: RFR: 8348365: Bad format string in CLDRDisplayNamesTest In-Reply-To: References: Message-ID: <35RTq72j03w67gYREfxIPj1OMC2Fu7zlHpuIlfUO6c0=.35161bc5-0152-45ca-9872-268e5b9cfabd@github.com> On Thu, 23 Jan 2025 05:42:33 GMT, Liam Miller-Cushon wrote: > This change fixes an incorrect call to `printf` for a failure message in `CLDRDisplayNamesTest`. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23252#pullrequestreview-2569169006 From rrich at openjdk.org Thu Jan 23 08:31:56 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 23 Jan 2025 08:31:56 GMT Subject: [jdk24] Integrated: 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds In-Reply-To: References: Message-ID: <8ySIMyDp2Ny3mF6ManIiqJN_LcE5q9Ol5M6nJRDcYVs=.02df0c86-f1e3-4698-8047-41c98aa9a0df@github.com> On Wed, 22 Jan 2025 08:30:16 GMT, Richard Reingruber wrote: > Hi all, > > I would like to backport the test-fix from commit [15d6469e](https://github.com/openjdk/jdk/commit/15d6469e8da635364c0ba83e425fd149c2d69495) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > The backport will help prevent frequent tier1 test timeouts in our CI testing. > > The commit being backported was authored by Richard Reingruber on 22 Jan 2025 and was reviewed by Christoph Langer, Matthias Baesken and Martin Doerr. > > Thanks, Richard. This pull request has now been integrated. Changeset: 53aa9f25 Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/53aa9f2596d5d839f0f53c34e947d2ce0182421f Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod 8347817: Timeouts running test/jdk/java/lang/String/concat/HiddenClassUnloading.java with fastdebug builds Reviewed-by: mdoerr Backport-of: 15d6469e8da635364c0ba83e425fd149c2d69495 ------------- PR: https://git.openjdk.org/jdk/pull/23228 From duke at openjdk.org Thu Jan 23 08:33:23 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 08:33:23 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v16] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR implements a per carrier-thread stacked allocator. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op > CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with four additional commits since the last revision: - test deep linker stack - Merge remote-tracking branch 'origin/mernst/cache-segments' into mernst/cache-segments - topOfStack - (c) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/f09a29de..0e6d5320 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=14-15 Stats: 80 lines in 3 files changed: 70 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From jbhateja at openjdk.org Thu Jan 23 08:36:01 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 23 Jan 2025 08:36:01 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: References: Message-ID: <9kjqXKPElm3xOqpAi2u7FNf9G4ATlLNMc6Tf0genUwA=.6de34b54-b56d-4f15-91f6-90ef2d358476@github.com> On Thu, 23 Jan 2025 08:14:13 GMT, Hamlin Li wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review suggestions incorporated. > > src/hotspot/share/opto/library_call.cpp line 8670: > >> 8668: >> 8669: const TypeInstPtr* box_type = _gvn.type(argument(0))->isa_instptr(); >> 8670: if (box_type == nullptr || box_type->const_oop() == nullptr) { > > Hi, this is not a review comment. > Just curious, to continue the following code path why does `box_type` must have a valid `const_oop`? @Hamlin-Li , Class types are passed as constant oop, this check is added for argument validation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926564701 From duke at openjdk.org Thu Jan 23 08:38:59 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 08:38:59 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v13] In-Reply-To: References: <3ftmhEPFJCuCYM9SH0F7atZBj9mqovX5dXekB9laCIE=.bdf7ba31-aede-43b2-9245-6e285e082f46@github.com> Message-ID: On Wed, 22 Jan 2025 17:06:22 GMT, Jorn Vernee wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> an attempt at a stress test > > test/jdk/java/foreign/TestBufferStack.java line 9: > >> 7: * published by the Free Software Foundation. Oracle designates this >> 8: * particular file as subject to the "Classpath" exception as provided >> 9: * by Oracle in the LICENSE file that accompanied this code. > > This is the wrong copyright header. Note that tests have a different header which does not include the class path exception. Oops, don't know where that one got copied from. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926567541 From duke at openjdk.org Thu Jan 23 08:39:00 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 08:39:00 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v14] In-Reply-To: References: <48NT2sVZT1fzZwS42MZeQ671SqgLincHR6K5JOgNdD4=.ec7645db-c002-4b89-92ac-b7256357359e@github.com> Message-ID: On Wed, 22 Jan 2025 20:05:25 GMT, Jorn Vernee wrote: >> Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> (c) > > test/jdk/java/foreign/TestBufferStack.java line 122: > >> 120: thread -> Assert.assertTrue(thread.isAlive())); >> 121: } >> 122: } > > I think we should also have a test that exercises the new code in the context of the linker. We have some tests that test downcall -> upcall with by-value structs, but I think we should also have a test that keeps going until it exhausts the buffer. Something like `test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java` (but without the `Whitebox` stuff). Done. Verified manually during test that we satisfy the first 5 frames from the stack and fall back afterwards. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926567636 From sundar at openjdk.org Thu Jan 23 08:50:47 2025 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Thu, 23 Jan 2025 08:50:47 GMT Subject: RFR: 8299504: Resolve `uses` and `provides` at run time if the service is optional and missing [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 12:12:20 GMT, Alan Bateman wrote: >> Extend the support for optional dependences to allow for a service to be optional. The post-resolution consistency check specified by `Configuration.resolve` is relaxed to allow for the possibility that the service from a module in the module graph at compile-time but the module is not in the module graph at run-time. >> >> ConfigurationTest is ported from TestNG to JUnit and updated to add new tests testUsesOptionalService$N and testProvidesOptionalService$N. The port to JUnit is mostly trivial/mechanical changes but it does create a bit of noise - I can move this port to another issue if it makes the harder to see the additions to the test. > > Alan Bateman 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: > > - Add Optional Services section from Alex > - Merge branch 'master' into JDK-8299504 > - Initial commit LGTM ------------- Marked as reviewed by sundar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23147#pullrequestreview-2569211213 From shade at openjdk.org Thu Jan 23 08:51:38 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Jan 2025 08:51:38 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: Message-ID: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [ ] Linux x86_64 server fastdebug, `all` > - [ ] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: - No instantiation for BufferCleaner, javadocs - Remove hasReferencePendingList - Revert test exclusion, moved to JDK-8348301 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/1b8b3ff1..2831bc84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=07-08 Stats: 71 lines in 6 files changed: 49 ins; 19 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From shade at openjdk.org Thu Jan 23 08:51:38 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Jan 2025 08:51:38 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: <45N5sfuYxIBGbY8f0IUwR_L84ABni1q3dXobFdiH2dI=.838e8a67-9d2f-4a8f-9eec-e143f4a97fe2@github.com> Message-ID: On Wed, 22 Jan 2025 20:35:49 GMT, Brent Christian wrote: >> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: >> >> - No instantiation for BufferCleaner, javadocs >> - Remove hasReferencePendingList >> - Revert test exclusion, moved to JDK-8348301 > > src/java.base/share/classes/java/lang/ref/Reference.java line 286: > >> 284: { >> 285: synchronized (processPendingLock) { >> 286: if (processPendingActive || hasReferencePendingList()) { > > It looks like `hasReferencePendingList()` is no longer used. Right, we can clean this up right here too. Done in new commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1926586148 From shade at openjdk.org Thu Jan 23 08:51:40 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Jan 2025 08:51:40 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v8] In-Reply-To: <9-yWCMfc8D4YFZFryYjeYJTV97f-wz9mon-7ZjRct_0=.1bfe4f67-28b1-48f7-8454-4d95a358750d@github.com> References: <45N5sfuYxIBGbY8f0IUwR_L84ABni1q3dXobFdiH2dI=.838e8a67-9d2f-4a8f-9eec-e143f4a97fe2@github.com> <9-yWCMfc8D4YFZFryYjeYJTV97f-wz9mon-7ZjRct_0=.1bfe4f67-28b1-48f7-8454-4d95a358750d@github.com> Message-ID: On Wed, 22 Jan 2025 23:44:02 GMT, Brent Christian wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan's review > > src/java.base/share/classes/java/nio/BufferCleaner.java line 31: > >> 29: import java.lang.ref.Cleaner.Cleanable; >> 30: >> 31: class BufferCleaner { > > It looks like `BufferCleaner` is not meant to be instantiated. A private constructor (that throws?) would make that clear. Correct, added some comments too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1926586462 From mbaesken at openjdk.org Thu Jan 23 09:07:23 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 23 Jan 2025 09:07:23 GMT Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address [v3] In-Reply-To: References: Message-ID: > We were running into this error : > sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25 > > stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30 > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192) > ... 11 more > > In the discussion in the JBS bug it was found that a retry option in` launch `should be added. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: check doSleep in launch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23213/files - new: https://git.openjdk.org/jdk/pull/23213/files/b54de9b1..168f6561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23213&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23213&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23213/head:pull/23213 PR: https://git.openjdk.org/jdk/pull/23213 From duke at openjdk.org Thu Jan 23 10:47:17 2025 From: duke at openjdk.org (serhiysachkov) Date: Thu, 23 Jan 2025 10:47:17 GMT Subject: RFR: 8347994: Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures Message-ID: Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures ------------- Commit messages: - 8347994: fixing trailing whitespace - 8347994: Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures Changes: https://git.openjdk.org/jdk/pull/23260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23260&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347994 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23260/head:pull/23260 PR: https://git.openjdk.org/jdk/pull/23260 From mli at openjdk.org Thu Jan 23 10:53:53 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 23 Jan 2025 10:53:53 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 16:02:55 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review suggestions incorporated. One minor comment about the test. test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 48: > 46: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "f16c", "true"}, > 47: counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"}) > 48: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "zvfh", "true"}, Is `"avx512_fp16", "false"` necessary at this line? ------------- PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2569517611 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926770427 From alanb at openjdk.org Thu Jan 23 10:56:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 23 Jan 2025 10:56:46 GMT Subject: RFR: 8348301: Remove unused Reference.waitForReferenceProcessing break-ins in tests In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:59:04 GMT, Aleksey Shipilev wrote: > `Reference.waitForReferenceProcessing` is in internal API, which should go away with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332). There is single use of that internal API in the tests, the last use of which was removed by [JDK-8080225](https://bugs.openjdk.org/browse/JDK-8080225). We can remove the `Reference.waitForReferenceProcessing` break-ins in the tests now. > > Additional testing: > - [x] Affected test still passes So the test wasn't actually calling Reference::waitForReferenceProcessing, do I have this right? In that case, this PR looks fine. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23239#pullrequestreview-2569532000 From mli at openjdk.org Thu Jan 23 10:57:49 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 23 Jan 2025 10:57:49 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: <9kjqXKPElm3xOqpAi2u7FNf9G4ATlLNMc6Tf0genUwA=.6de34b54-b56d-4f15-91f6-90ef2d358476@github.com> References: <9kjqXKPElm3xOqpAi2u7FNf9G4ATlLNMc6Tf0genUwA=.6de34b54-b56d-4f15-91f6-90ef2d358476@github.com> Message-ID: On Thu, 23 Jan 2025 08:32:47 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/library_call.cpp line 8670: >> >>> 8668: >>> 8669: const TypeInstPtr* box_type = _gvn.type(argument(0))->isa_instptr(); >>> 8670: if (box_type == nullptr || box_type->const_oop() == nullptr) { >> >> Hi, this is not a review comment. >> Just curious, to continue the following code path why does `box_type` must have a valid `const_oop`? > > @Hamlin-Li , Class types are passed as constant oop, this check is added for argument validation. Thanks! Seems it could be an assert instead? Or maybe I could have misunderstood your above explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926780216 From jbhateja at openjdk.org Thu Jan 23 11:01:49 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 23 Jan 2025 11:01:49 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: References: <9kjqXKPElm3xOqpAi2u7FNf9G4ATlLNMc6Tf0genUwA=.6de34b54-b56d-4f15-91f6-90ef2d358476@github.com> Message-ID: On Thu, 23 Jan 2025 10:54:54 GMT, Hamlin Li wrote: >> @Hamlin-Li , Class types are passed as constant oop, this check is added for argument validation. > > Thanks! > Seems it could be an assert instead? Or maybe I could have misunderstood your above explanation. Hi @Hamlin-Li, We intend to disable intrinsification if constraints are not met. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1926786421 From shade at openjdk.org Thu Jan 23 11:05:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Jan 2025 11:05:50 GMT Subject: RFR: 8348301: Remove unused Reference.waitForReferenceProcessing break-ins in tests In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 10:54:23 GMT, Alan Bateman wrote: > So the test wasn't actually calling Reference::waitForReferenceProcessing, do I have this right? In that case, this PR looks fine. Yup. The last use of `Reference::waitForReferenceProcessing` was removed by [JDK-8080225](https://bugs.openjdk.org/browse/JDK-8080225) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23239#issuecomment-2609512846 From lancea at openjdk.org Thu Jan 23 11:34:47 2025 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 23 Jan 2025 11:34:47 GMT Subject: RFR: 8343609: Broken links in java.xml [v3] In-Reply-To: References: Message-ID: <4EIYbZCMOLulO7R802SCIuLoL6pJdcy1xC0LenJFY2w=.68380b1a-21b7-4d68-a5b4-d99bd2fafbc0@github.com> On Thu, 23 Jan 2025 00:46:07 GMT, Joe Wang wrote: >> Fix broken links in java.xml: >> >> Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. >> >> QName: rewrote the javadocs. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > s/javax.xml.XMLConstants/XMLConstants Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23242#pullrequestreview-2569617467 From dfuchs at openjdk.org Thu Jan 23 11:46:46 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 23 Jan 2025 11:46:46 GMT Subject: RFR: 8347994: Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 10:38:50 GMT, serhiysachkov wrote: > Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures Marked as reviewed by dfuchs (Reviewer). Looks good to me. Good to have these additional diagnostics. ------------- PR Review: https://git.openjdk.org/jdk/pull/23260#pullrequestreview-2569643851 PR Comment: https://git.openjdk.org/jdk/pull/23260#issuecomment-2609597503 From peter.firmstone at zeus.net.au Thu Jan 23 12:14:19 2025 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 23 Jan 2025 22:14:19 +1000 Subject: ScopedValue API In-Reply-To: References: <7faa6070-9e2f-4497-880a-d7c57ccb8d6a@zeus.net.au> Message-ID: <0f79042f-f5da-490a-8d40-b4e56d47345d@zeus.net.au> Having had the opportunity to use ScopedValue to replace ThreadLocal, it was suggested I might provide some feedback here. Background: I'm maintaining an OpenJDK fork that retains SM, I merge weekly from upstream, this isn't for untrusted code, it's just ensuring permissions are only granted to authenticated users using trusted code (checked using a SHA256 message digest, or CodeSigner).? I have good fortune; I'm not constrained by strict backward compatibility, nor am I attempting to create a Sandbox (Graal would be a better place to quarantine untrusted code). Permission is no longer Serializable, allowing obsolete serial form to be dropped and fields made final. AccessControlContext is immutable now too, this was necessary, as I'm replacing AccessController functionality using ScopedValue to decorate doPrivileged calls, with AccessControlContext and the caller Class, and StackWalker is used to determine the stack context. AccessController is initialized very early during the vm initialization phase, so initially it just runs privileged calls and returns privileged context, until init phase 3 is reached. ScopedValue, Stackwalker and other classes depend on by them are initialized prior to init phase 3 from a static method in threads.cpp. The second use of ScopedValue is to prevent StackOverflowError occuring in a SecurityManager implementation, called CombinerSecurityManager, so called because it uses a DomainCombiner to execute permission checks on all ProtectionDomain's in a stack concurrently, but more importantly it contains a non-blocking timed and weakly reference cache, that uses Doug Lee's ConcurrentSkipListSet to cache the results of permission checks for AccessControlContext, in a ConcurrentMap. In a system running many tasks with the same context, this makes a big performance improvement, by avoiding repeat permission checks. ? Previously StackOverflowError was prevented using a ThreadLocal variable, with a counter that was incremented each time recursion occurs, in try - finally blocks, to ensure that it was decremented each time any recursion completed, once the counter reached a limit, an exception was thrown.?? However ScopedValue is a much better fit since it uses recursion, it doesn't require any try - finally blocks. CombinerSecurityManager is also using virtual threads to perform permission checks on each ProtectionDomain, to avoid blocking on platform threads when SocketPermission, FilePermission, are inevitably checked.?? There are also a non-caching Policy provider and policy parser implementations, that parse and stores policy grants in an immutable form following safe publication, it uses thread isolation to prevent contention on PermissionCollection instances.? There is a policy writing tool, that generates polp policy files. ProtectionDomain now implements equals and hashcode methods, the hashcode is final and calculated during construction.? The reason for this is many ProtectionDomain instances are created for a Subject's Principal[]'s and caching their result improves performance.? Similarly AccessControlContext also now has a final hashcode calculated during construction. I've also added support for privileged context to virtual threads, to allow virtual threads to be used with privileges, just like platform threads. There are two test failures which occur due to the new AccessController functionality, with both platform threads and virtual threads. I looked into the values of the Thread's inherited and Snapshot's Carrier, neither contain the ScopedValue used by AccessController.?? It may have something to do with earlier class initialization, I'm still trying to determine the cause. |ThreadFlockTest::testThreadExitWithOpenFlock '[1] java.lang.ThreadBuilders$VirtualThreadFactory at 21edf8f8' java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:2155) at ThreadFlockTest.lambda$testThreadExitWithOpenFlock$0(ThreadFlockTest.java:1018) at java.base/java.lang.VirtualThread.run(VirtualThread.java:470) Exception in thread "" java.util.concurrent.StructureViolationException: Scoped value bindings have changed at java.base/java.lang.Thread.inheritScopedValueBindings(Thread.java:324)| -- Regards, Peter On 22/01/2025 8:39 pm, Volkan Yaz?c? wrote: > Hello Peter, > > Thanks so much for the feedback. AFAIK, that work is delivered by the > Loom crew and they use the `loom-dev` mailing list > for discussions. > I think they would really appreciate hearing your feedback: What is > the real-world use case you used SVs for? How was that particular > logic implemented before? What are the performance/code/semantic > changes you observed during migration? Did you encounter any problems? > Did you find the API intuitive? etc. > > Kind regards. > > On Wed, Jan 22, 2025 at 4:11?AM Peter Firmstone > wrote: > > Just wanted to say, I've been experimenting with replacing > ThreadLocal > with ScopedValue, this is a great new API, I love the way ScopedValue > uses recursion, we can have multiple immutable instances > representing a > scoped value for a short period and we're not worried about managing > state as it goes out of scope as soon as it's no longer in use. > > Cheers, > > Peter. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Thu Jan 23 12:32:49 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 12:32:49 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 12:27:10 GMT, Matthias Ernst wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 52: >> >>> 50: scope.close(); >>> 51: offset = parentOffset; >>> 52: lock.unlock(); >> >> I believe you could have mismatched lock/unlock in some cases > > Which scenario? Apologies - that looks correct because: * we always lock on reserve, then * if there's no space, we unlock and return * if there's space we return a new Frame (which then unlock on close) * if we fail to lock, then we return a normal arena (and there's nothing to unlock) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926902590 From mcimadamore at openjdk.org Thu Jan 23 12:32:50 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 12:32:50 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> Message-ID: On Wed, 22 Jan 2025 12:26:45 GMT, Matthias Ernst wrote: >> Isn't the problem access? E.g. a virtual thread `A` running on our carrier thread might create the confined arena, binding it to _virtual_ thread `A`, and then another virtual thread `B` comes along one the same carrier thread, and wants to use the same `BufferStack`, but can't because it is confined to thread `A`. > > I think _using_ it might even be ok, since all it does to the stack is slicing and reinterpreting, but the final close() would be on the wrong thread (allocator = virtual, closer=terminator likely a platform thread). So: * the shared memory segment is confined on the carrier thread * allocation requests need to reinterpret segment slices to the arena (which is associated with the requesting thread, not the carrier) * my understanding is that the terminating action will be executed on the same carrier thread (so closing the confined arena should be ok) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926899199 From mcimadamore at openjdk.org Thu Jan 23 12:35:55 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 12:35:55 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v16] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 08:33:23 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with four additional commits since the last revision: > > - test deep linker stack > - Merge remote-tracking branch 'origin/mernst/cache-segments' into mernst/cache-segments > - topOfStack > - (c) src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 65: > 63: @ForceInline > 64: public Arena pushFrame(long size, long byteAlignment) { > 65: boolean needsLock = Thread.currentThread().isVirtual() && !lock.isHeldByCurrentThread(); @minborg please check this -- you have discovered some cases where `isVirtual` is not enough (e.g. because virtual threads use carrier in the common pool, which can also be used for non-virtual thread stuff) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926906087 From mcimadamore at openjdk.org Thu Jan 23 12:39:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 12:39:54 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v16] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 08:33:23 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with four additional commits since the last revision: > > - test deep linker stack > - Merge remote-tracking branch 'origin/mernst/cache-segments' into mernst/cache-segments > - topOfStack > - (c) src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 103: > 101: @SuppressWarnings("restricted") > 102: public MemorySegment allocate(long byteSize, long byteAlignment) { > 103: return frame.allocate(byteSize, byteAlignment); Should this also check order? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926910879 From mcimadamore at openjdk.org Thu Jan 23 12:43:58 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 12:43:58 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v9] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 12:38:25 GMT, Matthias Ernst wrote: >> Right. Using SlicingAllocator now. >> >> Which brings up one question about alignment of the stack frames. When the linker asks for a buffer, it also has an alignment requirement. Do we guarantee anything about the alignment of Arena.ofConfined().allocate() ? Does the linker overallocate already? >> >> To accomodate for this, I added a frame alignment parameter as well => the stack itself is well-served by using a SlicingAllocator. For this, I added methods to query and reset the position, as well as whether it could satisfy a certain allocation request. > > And yes, this requires that a client operate in stack order. I added checks for this. > To accomodate for this, I added a frame alignment parameter as well => the stack itself is well-served by using a SlicingAllocator. For this, I added methods to query and reset the position, as well as whether it could satisfy a certain allocation request. I like what you did w.r.t. alignment - I think the current revision seems to now handle that correctly ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926916051 From duke at openjdk.org Thu Jan 23 12:55:50 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 12:55:50 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v16] In-Reply-To: References: Message-ID: <0AqM2TdigJqEB3vUTTxR94gD6kC2pymQb1xrBPWB5l8=.eedd1bdd-d002-4908-8251-4a3788e729af@github.com> On Thu, 23 Jan 2025 12:37:16 GMT, Maurizio Cimadamore wrote: >> Matthias Ernst has updated the pull request incrementally with four additional commits since the last revision: >> >> - test deep linker stack >> - Merge remote-tracking branch 'origin/mernst/cache-segments' into mernst/cache-segments >> - topOfStack >> - (c) > > src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line 103: > >> 101: @SuppressWarnings("restricted") >> 102: public MemorySegment allocate(long byteSize, long byteAlignment) { >> 103: return frame.allocate(byteSize, byteAlignment); > > Should this also check order? We could, in the sense that an allocation in a lower stack frame seems suspicious, but technically it is completely legal. The frame has been allocated and is sliced to the requested size, and is guaranteed as long as the Frame's arena hasn't been closed, no matter whether other frames are on top: frame1 = pushFrame(256); frame2 = pushFrame(256); <> ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926931511 From duke at openjdk.org Thu Jan 23 12:55:51 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 12:55:51 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> Message-ID: On Thu, 23 Jan 2025 12:27:53 GMT, Maurizio Cimadamore wrote: > the shared memory segment is confined on the carrier thread But is it? When the CarrierThreadLocal is initialized, we may be executing in a VT and Arena.ofConfined will confine to it. We'd need something like an Arena.ofCarrierConfined() to make that work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926928205 From duke at openjdk.org Thu Jan 23 13:02:52 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 13:02:52 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> Message-ID: On Thu, 23 Jan 2025 12:50:41 GMT, Matthias Ernst wrote: >> So: >> * the shared memory segment is confined on the carrier thread >> * allocation requests need to reinterpret segment slices to the arena (which is associated with the requesting thread, not the carrier) >> * my understanding is that the terminating action will be executed on the same carrier thread (so closing the confined arena should be ok) > >> the shared memory segment is confined on the carrier thread > > But is it? When the CarrierThreadLocal is initialized, we may be executing in a VT and Arena.ofConfined will confine to it. We'd need something like an Arena.ofCarrierConfined() to make that work. I mean, it is totally possible: public PerThread(long size) { this.arena = MemorySessionImpl.createConfined(JLA.currentCarrierThread()).asArena(); this.stack = new SlicingAllocator(arena.allocate(size)); } public void close() { arena.close(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926940819 From duke at openjdk.org Thu Jan 23 13:09:51 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 13:09:51 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> Message-ID: <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> On Thu, 23 Jan 2025 12:59:53 GMT, Matthias Ernst wrote: >>> the shared memory segment is confined on the carrier thread >> >> But is it? When the CarrierThreadLocal is initialized, we may be executing in a VT and Arena.ofConfined will confine to it. We'd need something like an Arena.ofCarrierConfined() to make that work. > > I mean, it is totally possible: > > public PerThread(long size) { > this.arena = MemorySessionImpl.createConfined(JLA.currentCarrierThread()).asArena(); > this.stack = new SlicingAllocator(arena.allocate(size)); > } > > public void close() { > arena.close(); > } Ah no, the allocate fails of course: java.lang.WrongThreadException: Attempted access outside owning thread at java.base/jdk.internal.foreign.MemorySessionImpl.wrongThread(MemorySessionImpl.java:322) at java.base/jdk.internal.misc.ScopedMemoryAccess$ScopedAccessError.newRuntimeException(ScopedMemoryAccess.java:114) at java.base/jdk.internal.foreign.MemorySessionImpl.checkValidState(MemorySessionImpl.java:217) at java.base/jdk.internal.foreign.SegmentFactories.allocateSegment(SegmentFactories.java:181) at java.base/jdk.internal.foreign.ArenaImpl.allocateNoInit(ArenaImpl.java:52) at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:57) at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:31) at java.base/java.lang.foreign.SegmentAllocator.allocate(SegmentAllocator.java:644) at java.base/jdk.internal.foreign.abi.BufferStack$PerThread.(BufferStack.java:73) at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:50) at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:47) at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:224) at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:193) at java.base/java.lang.ThreadLocal.getCarrierThreadLocal(ThreadLocal.java:180) at java.base/java.lang.System$1.getCarrierThreadLocal(System.java:2237) at java.base/jdk.internal.misc.CarrierThreadLocal.get(CarrierThreadLocal.java:39) at java.base/jdk.internal.foreign.abi.BufferStack.pushFrame(BufferStack.java:61) at TestBufferStack.lambda$stress$1(TestBufferStack.java:113) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1926950494 From duke at openjdk.org Thu Jan 23 13:18:45 2025 From: duke at openjdk.org (duke) Date: Thu, 23 Jan 2025 13:18:45 GMT Subject: RFR: 8347994: Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 10:38:50 GMT, serhiysachkov wrote: > Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures @serhiysachkov Your change (at version 3a7f43ef409e09bbf818a9f43dee1f544538b104) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23260#issuecomment-2609783733 From sgehwolf at openjdk.org Thu Jan 23 13:21:47 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 23 Jan 2025 13:21:47 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2] In-Reply-To: References: Message-ID: <7F5pVmYefDZ12cPCDSFhBuyMJYt8x-xGaqbYruqvfTg=.e06337f6-e22e-4fb7-aec2-faaad2264365@github.com> On Wed, 22 Jan 2025 18:39:47 GMT, Justin Lu wrote: >> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. >> >> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. >> >> Once this pull request is integrated, it will be back-ported to the jdk24 branch. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect jlink review jdk.jlink changes still good. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23184#pullrequestreview-2569845897 From vklang at openjdk.org Thu Jan 23 13:40:47 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 23 Jan 2025 13:40:47 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v5] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <1cteD4vrIfoLpl5NZ2otl8wwI6nX4RqrOh8y0oIUZ9w=.dd039bc2-ec25-4552-835b-b1422f4536c9@github.com> <4T4Fbje9gPyQuVXSduhYftns423fniOH-PjIqKi3VQw=.9b302512-fd62-4882-8d60-41a1e043ea9c@github.com> Message-ID: On Thu, 23 Jan 2025 02:47:00 GMT, Justin Lu wrote: >> How about I revert the most recent commit and have this PR simply deliver the change to provide the stream of currencies. I'll file another issue to improve `available` to use stable values when that is available. Does that sound fine? > > Reverted in https://github.com/openjdk/jdk/pull/23165/commits/ade21c923369d0f0423335c3073e2c615adf050c. Filed [JDK-8348351](https://bugs.openjdk.org/browse/JDK-8348351) to implement `available` as a stable value when applicable. I suspect that [Stable Values](https://openjdk.org/jeps/502) would fit well here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23165#discussion_r1926993556 From duke at openjdk.org Thu Jan 23 13:42:51 2025 From: duke at openjdk.org (serhiysachkov) Date: Thu, 23 Jan 2025 13:42:51 GMT Subject: Integrated: 8347994: Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 10:38:50 GMT, serhiysachkov wrote: > Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures This pull request has now been integrated. Changeset: 5cc690d3 Author: Serhiy Sachkov Committer: Mark Sheppard URL: https://git.openjdk.org/jdk/commit/5cc690d31ee43f2ea0171cc091ce448144c57766 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8347994: Add additional diagnostics to macOS failure handler to assist with diagnosing MCast test failures Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/23260 From mcimadamore at openjdk.org Thu Jan 23 14:26:04 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 14:26:04 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v16] In-Reply-To: <0AqM2TdigJqEB3vUTTxR94gD6kC2pymQb1xrBPWB5l8=.eedd1bdd-d002-4908-8251-4a3788e729af@github.com> References: <0AqM2TdigJqEB3vUTTxR94gD6kC2pymQb1xrBPWB5l8=.eedd1bdd-d002-4908-8251-4a3788e729af@github.com> Message-ID: On Thu, 23 Jan 2025 12:53:08 GMT, Matthias Ernst wrote: > We could, in the sense that an allocation in a lower stack frame seems suspicious, but technically it is completely legal. The frame has been allocated and is sliced to the requested size, and is guaranteed as long as the Frame's arena hasn't been closed, no matter whether other frames are on top: > > ``` > frame1 = pushFrame(256); > frame2 = pushFrame(256); > <> > ``` Ok, in this particular design it's ok because you allocate up front. So each frame allocate in its own space. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927062606 From mcimadamore at openjdk.org Thu Jan 23 14:31:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 14:31:54 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> Message-ID: On Thu, 23 Jan 2025 13:07:03 GMT, Matthias Ernst wrote: > Ah no, the allocate fails of course: > > ``` > java.lang.WrongThreadException: Attempted access outside owning thread > at java.base/jdk.internal.foreign.MemorySessionImpl.wrongThread(MemorySessionImpl.java:322) > at java.base/jdk.internal.misc.ScopedMemoryAccess$ScopedAccessError.newRuntimeException(ScopedMemoryAccess.java:114) > at java.base/jdk.internal.foreign.MemorySessionImpl.checkValidState(MemorySessionImpl.java:217) > at java.base/jdk.internal.foreign.SegmentFactories.allocateSegment(SegmentFactories.java:181) > at java.base/jdk.internal.foreign.ArenaImpl.allocateNoInit(ArenaImpl.java:52) > at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:57) > at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:31) > at java.base/java.lang.foreign.SegmentAllocator.allocate(SegmentAllocator.java:644) > at java.base/jdk.internal.foreign.abi.BufferStack$PerThread.(BufferStack.java:73) > at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:50) > at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:47) > at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:224) > at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:193) > at java.base/java.lang.ThreadLocal.getCarrierThreadLocal(ThreadLocal.java:180) > at java.base/java.lang.System$1.getCarrierThreadLocal(System.java:2237) > at java.base/jdk.internal.misc.CarrierThreadLocal.get(CarrierThreadLocal.java:39) > at java.base/jdk.internal.foreign.abi.BufferStack.pushFrame(BufferStack.java:61) > at TestBufferStack.lambda$stress$1(TestBufferStack.java:113) > ``` I was under the impression (which appears incorrect) that `initialValue` would be called by the carrier thread as well. So, we basically have a mismatch where `initialValue` is called with thread A, but `terminate` is called on thread B ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927067860 From duke at openjdk.org Thu Jan 23 14:31:55 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 14:31:55 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> Message-ID: On Thu, 23 Jan 2025 14:26:23 GMT, Maurizio Cimadamore wrote: >> Ah no, the allocate fails of course: >> >> java.lang.WrongThreadException: Attempted access outside owning thread >> at java.base/jdk.internal.foreign.MemorySessionImpl.wrongThread(MemorySessionImpl.java:322) >> at java.base/jdk.internal.misc.ScopedMemoryAccess$ScopedAccessError.newRuntimeException(ScopedMemoryAccess.java:114) >> at java.base/jdk.internal.foreign.MemorySessionImpl.checkValidState(MemorySessionImpl.java:217) >> at java.base/jdk.internal.foreign.SegmentFactories.allocateSegment(SegmentFactories.java:181) >> at java.base/jdk.internal.foreign.ArenaImpl.allocateNoInit(ArenaImpl.java:52) >> at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:57) >> at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:31) >> at java.base/java.lang.foreign.SegmentAllocator.allocate(SegmentAllocator.java:644) >> at java.base/jdk.internal.foreign.abi.BufferStack$PerThread.(BufferStack.java:73) >> at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:50) >> at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:47) >> at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:224) >> at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:193) >> at java.base/java.lang.ThreadLocal.getCarrierThreadLocal(ThreadLocal.java:180) >> at java.base/java.lang.System$1.getCarrierThreadLocal(System.java:2237) >> at java.base/jdk.internal.misc.CarrierThreadLocal.get(CarrierThreadLocal.java:39) >> at java.base/jdk.internal.foreign.abi.BufferStack.pushFrame(BufferStack.java:61) >> at TestBufferStack.lambda$stress$1(TestBufferStack.java:113) > >> Ah no, the allocate fails of course: >> >> ``` >> java.lang.WrongThreadException: Attempted access outside owning thread >> at java.base/jdk.internal.foreign.MemorySessionImpl.wrongThread(MemorySessionImpl.java:322) >> at java.base/jdk.internal.misc.ScopedMemoryAccess$ScopedAccessError.newRuntimeException(ScopedMemoryAccess.java:114) >> at java.base/jdk.internal.foreign.MemorySessionImpl.checkValidState(MemorySessionImpl.java:217) >> at java.base/jdk.internal.foreign.SegmentFactories.allocateSegment(SegmentFactories.java:181) >> at java.base/jdk.internal.foreign.ArenaImpl.allocateNoInit(ArenaImpl.java:52) >> at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:57) >> at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:31) >> at java.base/java.lang.foreign.SegmentAllocator.allocate(SegmentAllocator.java:644) >> at java.base/jdk.internal.foreign.abi.BufferStack$PerThread.(BufferStack.java:73) >> at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:50) >> at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:47) >> at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:224) >> at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:193) >> at java.base/java.lang.ThreadLocal.getCarrierThreadLocal(ThreadLocal.java:180) >> at java.base/java.lang.System$1.getCarrierThreadLocal(System.java:2237) >> at java.base/jdk.internal.misc.CarrierThreadLocal.get(CarrierThreadLocal.java:39) >> at java.base/jdk.internal.foreign.abi.BufferStack.pushFrame(BufferStack.java:61) >> at TestBufferStack.lambda$stress$1(TestBufferStack.java:113) >> ``` > > I was under the impression (which appears incorrect) that `initialValue` would be called by the carrier thread as well. So, we basically have a mismatch where `initialValue` is called with thread A, but `terminate` is called on thread B ? Exactly. initialValue happens on-demand, not upfront, i.e. in the very moment the VT calls get(). Whereas terminate happens as the last action of the CT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927071961 From mcimadamore at openjdk.org Thu Jan 23 14:34:51 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 14:34:51 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> Message-ID: <33F87NmT6M4w5PsG3pJ73NY32VeqyHAkjIKK1jZyJbo=.eb99b2ad-6e7d-4e07-8616-8c2a720a755b@github.com> On Thu, 23 Jan 2025 14:28:57 GMT, Matthias Ernst wrote: >>> Ah no, the allocate fails of course: >>> >>> ``` >>> java.lang.WrongThreadException: Attempted access outside owning thread >>> at java.base/jdk.internal.foreign.MemorySessionImpl.wrongThread(MemorySessionImpl.java:322) >>> at java.base/jdk.internal.misc.ScopedMemoryAccess$ScopedAccessError.newRuntimeException(ScopedMemoryAccess.java:114) >>> at java.base/jdk.internal.foreign.MemorySessionImpl.checkValidState(MemorySessionImpl.java:217) >>> at java.base/jdk.internal.foreign.SegmentFactories.allocateSegment(SegmentFactories.java:181) >>> at java.base/jdk.internal.foreign.ArenaImpl.allocateNoInit(ArenaImpl.java:52) >>> at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:57) >>> at java.base/jdk.internal.foreign.ArenaImpl.allocate(ArenaImpl.java:31) >>> at java.base/java.lang.foreign.SegmentAllocator.allocate(SegmentAllocator.java:644) >>> at java.base/jdk.internal.foreign.abi.BufferStack$PerThread.(BufferStack.java:73) >>> at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:50) >>> at java.base/jdk.internal.foreign.abi.BufferStack$1.initialValue(BufferStack.java:47) >>> at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:224) >>> at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:193) >>> at java.base/java.lang.ThreadLocal.getCarrierThreadLocal(ThreadLocal.java:180) >>> at java.base/java.lang.System$1.getCarrierThreadLocal(System.java:2237) >>> at java.base/jdk.internal.misc.CarrierThreadLocal.get(CarrierThreadLocal.java:39) >>> at java.base/jdk.internal.foreign.abi.BufferStack.pushFrame(BufferStack.java:61) >>> at TestBufferStack.lambda$stress$1(TestBufferStack.java:113) >>> ``` >> >> I was under the impression (which appears incorrect) that `initialValue` would be called by the carrier thread as well. So, we basically have a mismatch where `initialValue` is called with thread A, but `terminate` is called on thread B ? > > Exactly. initialValue happens on-demand, not upfront, i.e. in the very moment the VT calls get(). > Whereas terminate happens as the last action of the CT. If this is really the case, I agree that there doesn't seem to be an alternative to use `ofAuto`. In which case you don't really need a TerminatingThreadLocal -- a CarrierThreadLocal is just fine (given we don't really have anything to do on close). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927077515 From mcimadamore at openjdk.org Thu Jan 23 14:37:56 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 14:37:56 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: <33F87NmT6M4w5PsG3pJ73NY32VeqyHAkjIKK1jZyJbo=.eb99b2ad-6e7d-4e07-8616-8c2a720a755b@github.com> References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> <33F87NmT6M4w5PsG3pJ73NY32VeqyHAkjIKK1jZyJbo=.eb99b2ad-6e7d-4e07-8616-8c2a720a755b@github.com> Message-ID: On Thu, 23 Jan 2025 14:32:22 GMT, Maurizio Cimadamore wrote: >> Exactly. initialValue happens on-demand, not upfront, i.e. in the very moment the VT calls get(). >> Whereas terminate happens as the last action of the CT. > > If this is really the case, I agree that there doesn't seem to be an alternative to use `ofAuto`. In which case you don't really need a TerminatingThreadLocal -- a CarrierThreadLocal is just fine (given we don't really have anything to do on close). alternatively - we could have some kind of internal "forceClose" API which doesn't check the owner thread. Some care is probably needed as the access is now on a different thread, so we'll need to make sure that some volatile accesses are used by this method, otherwise it might "miss" cleanup actions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927082367 From shade at openjdk.org Thu Jan 23 14:51:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Jan 2025 14:51:51 GMT Subject: RFR: 8348301: Remove unused Reference.waitForReferenceProcessing break-ins in tests In-Reply-To: References: Message-ID: <5feFk3WXj5oOfPPC-wYnRkULSZB7oON2L_96lDl87oQ=.f70f3e02-71ed-4d1d-be9e-bac63477879c@github.com> On Wed, 22 Jan 2025 16:59:04 GMT, Aleksey Shipilev wrote: > `Reference.waitForReferenceProcessing` is in internal API, which should go away with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332). There is single use of that internal API in the tests, the last use of which was removed by [JDK-8080225](https://bugs.openjdk.org/browse/JDK-8080225). We can remove the `Reference.waitForReferenceProcessing` break-ins in the tests now. > > Additional testing: > - [x] Affected test still passes I think I need another review for integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23239#issuecomment-2610011813 From mcimadamore at openjdk.org Thu Jan 23 14:57:50 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 14:57:50 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> <33F87NmT6M4w5PsG3pJ73NY32VeqyHAkjIKK1jZyJbo=.eb99b2ad-6e7d-4e07-8616-8c2a720a755b@github.com> Message-ID: <5LLNS59Ko2HRTTGTEPq1LKdPH0CeqbX-PKxdC8coMwU=.94ccae3a-7cd4-42e5-81d2-5ec72984d5c3@github.com> On Thu, 23 Jan 2025 14:35:29 GMT, Maurizio Cimadamore wrote: >> If this is really the case, I agree that there doesn't seem to be an alternative to use `ofAuto`. In which case you don't really need a TerminatingThreadLocal -- a CarrierThreadLocal is just fine (given we don't really have anything to do on close). > > alternatively - we could have some kind of internal "forceClose" API which doesn't check the owner thread. Some care is probably needed as the access is now on a different thread, so we'll need to make sure that some volatile accesses are used by this method, otherwise it might "miss" cleanup actions. A simpler (maybe interim) solution: if the requesting thread is not virtual, use the cache (and use a confined arena). Otherwise use a brand new confined arena. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927115941 From mcimadamore at openjdk.org Thu Jan 23 15:16:54 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 15:16:54 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: <5LLNS59Ko2HRTTGTEPq1LKdPH0CeqbX-PKxdC8coMwU=.94ccae3a-7cd4-42e5-81d2-5ec72984d5c3@github.com> References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> <33F87NmT6M4w5PsG3pJ73NY32VeqyHAkjIKK1jZyJbo=.eb99b2ad-6e7d-4e07-8616-8c2a720a755b@github.com> <5LLNS59Ko2HRTTGTEPq1LKdPH0CeqbX-PKxdC8coMwU=.94ccae3a-7cd4-42e5-81d2-5ec72984d5c3@github.com> Message-ID: On Thu, 23 Jan 2025 14:54:55 GMT, Maurizio Cimadamore wrote: >> alternatively - we could have some kind of internal "forceClose" API which doesn't check the owner thread. ~Some care is probably needed as the access is now on a different thread, so we'll need to make sure that some volatile accesses are used by this method, otherwise it might "miss" cleanup actions.~ (no need for volatile as the "carrier" thread is still the same) > > A simpler (maybe interim) solution: if the requesting thread is not virtual, use the cache (and use a confined arena). Otherwise use a brand new confined arena. Yet another option would be to use a confined or shared arena depending on the requesting thread. Which means the terminating thread local would _sometimes_ close the arena, sometimes it will leave it to the GC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927150864 From duke at openjdk.org Thu Jan 23 15:23:50 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 15:23:50 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> <33F87NmT6M4w5PsG3pJ73NY32VeqyHAkjIKK1jZyJbo=.eb99b2ad-6e7d-4e07-8616-8c2a720a755b@github.com> <5LLNS59Ko2HRTTGTEPq1LKdPH0CeqbX-PKxdC8coMwU=.94ccae3a-7cd4-42e5-81d2-5ec72984d5c3@github.com> Message-ID: On Thu, 23 Jan 2025 15:14:30 GMT, Maurizio Cimadamore wrote: >> A simpler (maybe interim) solution: if the requesting thread is not virtual, use the cache (and use a confined arena). Otherwise use a brand new confined arena. > > Yet another option would be to use a confined or shared arena depending on the requesting thread. Which means the terminating thread local would _sometimes_ close the arena, sometimes it will leave it to the GC. I'm losing track of what the issue is. I think ofAuto should work just fine, you're unlikely to cycle so hard through Carrier threads that GC pressure through 256byte allocs will become an issue. If we absolutely want to stay out of `auto` territory then a pair of Unsafe.alloc/free to allocate the stack seems the easier choice than distinguishing by thread-type. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927162259 From kevinw at openjdk.org Thu Jan 23 15:39:59 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 23 Jan 2025 15:39:59 GMT Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean, its implementation, and accessor method for removal Message-ID: java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9. These deprecations should be uprated to state they are for future removal. java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal. ------------- Commit messages: - 8336017: Deprecate java.util.logging.LoggingMXBean, its implementation, and accessor method for removal Changes: https://git.openjdk.org/jdk/pull/23271/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23271&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336017 Stats: 12 lines in 3 files changed: 2 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/23271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23271/head:pull/23271 PR: https://git.openjdk.org/jdk/pull/23271 From kevinw at openjdk.org Thu Jan 23 15:39:59 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 23 Jan 2025 15:39:59 GMT Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean, its implementation, and accessor method for removal In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote: > java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9. > > These deprecations should be uprated to state they are for future removal. > > java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal. This area is very confusing with the old redundant implementation hanging around. The interface `java.lang.management.PlatformLoggingMXBean` is the correct management interface for logging. As per the java.util.LogManager documentation, can be accessed using: ManagementFactory.getPlatformMXBean(PlatformLoggingMXBean.class) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23271#issuecomment-2610129200 From liach at openjdk.org Thu Jan 23 15:51:51 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 23 Jan 2025 15:51:51 GMT Subject: RFR: 8348283: java.lang.classfile.components.snippets.PackageSnippets shipped in java.base.jmod In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 07:14:42 GMT, Adam Sotona wrote: > JDK-8345486 moved java.lang.classfile.components.snippet-files.PackageSnippets to jdk.internal.classfile.components.snippet-files folder. However change of the package name declared in the snippet file was omitted. > > Please review. > > Thank you, > Adam Thanks for this fix. It's weird that we ship snippet files by its package declaration... ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23254#pullrequestreview-2570269159 From hannesw at openjdk.org Thu Jan 23 16:18:46 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Thu, 23 Jan 2025 16:18:46 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 20:35:22 GMT, Phil Race wrote: >> Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that. >> >> @prrace do you have any suggestions for the spec change, or are you ok with the proposed wording? > > There's not a great number of "good" examples of this in the JDK, so probably OK except it > seems like most cases will do it like a normal javadoc method so you'd want an @param tag too. > > note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others I've created a CSR with a slightly modified version of the text proposed in this PR: https://bugs.openjdk.org/browse/JDK-8348408 Other doc tags such as `@param` and `@throws` are inherited from the overridden method. Also, this is the only change in this PR that modifies the serialization spec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1927261011 From mullan at openjdk.org Thu Jan 23 16:38:46 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 23 Jan 2025 16:38:46 GMT Subject: RFR: 8348301: Remove unused Reference.waitForReferenceProcessing break-ins in tests In-Reply-To: <5feFk3WXj5oOfPPC-wYnRkULSZB7oON2L_96lDl87oQ=.f70f3e02-71ed-4d1d-be9e-bac63477879c@github.com> References: <5feFk3WXj5oOfPPC-wYnRkULSZB7oON2L_96lDl87oQ=.f70f3e02-71ed-4d1d-be9e-bac63477879c@github.com> Message-ID: On Thu, 23 Jan 2025 14:49:28 GMT, Aleksey Shipilev wrote: > I think I need another review for integration? Alan's review should be sufficient I think. The bug should have a `noreg-self` label. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23239#issuecomment-2610341728 From ccheung at openjdk.org Thu Jan 23 16:39:48 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 23 Jan 2025 16:39:48 GMT Subject: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() [v2] In-Reply-To: References: Message-ID: <2DJ4nTPwrRAk_oqyWf8z37DBZJLrfGFnkZS2xhPOuyE=.199caeaa-8582-49ba-ac00-74caf43414b5@github.com> On Thu, 23 Jan 2025 02:04:33 GMT, Ioi Lam wrote: >> I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there. >> >> The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java. >> >> ### How this works: >> >> For example, let's assume you have the following classfiles in foo.jar: >> >> >> interface MyInterface1 {} >> interface MyInterface2 {} >> class MyClass extends Object implements MyInterface1, MyInterface2 {} >> >> >> The CDS classlist file can look like this: >> >> >> java/lang/Object id: 1 >> MyInterface1: id: 2 super: 1 source: foo.jar >> MyInterface2: id: 3 super: 1 source: foo.jar >> MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar >> >> >> When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters: >> >> - `name` = "MyClass" >> - `superClass` = java.lang.Object >> - `interfaces` = {MyInterface1, MyInterface2} >> >> `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`. > > Ioi Lam 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: > > - Merge branch 'master' into 8348240-remove-lookup_super_for_unregistered_class > - @calvinccheung comments > - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() Thanks for the update. ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23226#pullrequestreview-2570418706 From shade at openjdk.org Thu Jan 23 16:51:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Jan 2025 16:51:51 GMT Subject: RFR: 8348301: Remove unused Reference.waitForReferenceProcessing break-ins in tests In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:59:04 GMT, Aleksey Shipilev wrote: > `Reference.waitForReferenceProcessing` is in internal API, which should go away with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332). There is single use of that internal API in the tests, the last use of which was removed by [JDK-8080225](https://bugs.openjdk.org/browse/JDK-8080225). We can remove the `Reference.waitForReferenceProcessing` break-ins in the tests now. > > Additional testing: > - [x] Affected test still passes All right, thanks. Added `noreg-self` to the bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23239#issuecomment-2610399398 From shade at openjdk.org Thu Jan 23 16:51:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 23 Jan 2025 16:51:51 GMT Subject: Integrated: 8348301: Remove unused Reference.waitForReferenceProcessing break-ins in tests In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 16:59:04 GMT, Aleksey Shipilev wrote: > `Reference.waitForReferenceProcessing` is in internal API, which should go away with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332). There is single use of that internal API in the tests, the last use of which was removed by [JDK-8080225](https://bugs.openjdk.org/browse/JDK-8080225). We can remove the `Reference.waitForReferenceProcessing` break-ins in the tests now. > > Additional testing: > - [x] Affected test still passes This pull request has now been integrated. Changeset: 59e75093 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/59e750931c43fa035650bb295c8c9f16fbe82df0 Stats: 26 lines in 1 file changed: 0 ins; 26 del; 0 mod 8348301: Remove unused Reference.waitForReferenceProcessing break-ins in tests Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/23239 From jvernee at openjdk.org Thu Jan 23 17:02:07 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 23 Jan 2025 17:02:07 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v16] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 08:33:23 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with four additional commits since the last revision: > > - test deep linker stack > - Merge remote-tracking branch 'origin/mernst/cache-segments' into mernst/cache-segments > - topOfStack > - (c) test/jdk/java/foreign/TestBufferStack.java line 28: > 26: * @modules java.base/jdk.internal.foreign.abi > 27: * @build NativeTestHelper TestBufferStack > 28: * @run testng TestBufferStack This needs to enable native access now. Suggestion: * @run testng/othervm --enable-native-access=ALL-UNNAMED TestBufferStack ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927340517 From duke at openjdk.org Thu Jan 23 17:13:37 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 17:13:37 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v17] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR implements a per carrier-thread stacked allocator. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op > CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: /othervm --enable-native-access=ALL-UNNAMED Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/0e6d5320..89479648 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From alanb at openjdk.org Thu Jan 23 17:25:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 23 Jan 2025 17:25:54 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: On Thu, 23 Jan 2025 08:51:38 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: > > - No instantiation for BufferCleaner, javadocs > - Remove hasReferencePendingList > - Revert test exclusion, moved to JDK-8348301 I did another pass over the changes today, including the update that removes JVM_HasReferencePendingList. I'm happy with the changes. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2570534886 From naoto at openjdk.org Thu Jan 23 17:25:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 23 Jan 2025 17:25:54 GMT Subject: RFR: 8343609: Broken links in java.xml [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 00:46:07 GMT, Joe Wang wrote: >> Fix broken links in java.xml: >> >> Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. >> >> QName: rewrote the javadocs. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > s/javax.xml.XMLConstants/XMLConstants Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23242#pullrequestreview-2570535891 From naoto at openjdk.org Thu Jan 23 17:26:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 23 Jan 2025 17:26:53 GMT Subject: RFR: 8348365: Bad format string in CLDRDisplayNamesTest In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 05:42:33 GMT, Liam Miller-Cushon wrote: > This change fixes an incorrect call to `printf` for a failure message in `CLDRDisplayNamesTest`. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23252#pullrequestreview-2570533968 From duke at openjdk.org Thu Jan 23 17:26:51 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 17:26:51 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v17] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:14:56 GMT, Jorn Vernee wrote: > test is timing out I think it's the stress test, the starting Thread sleeps and never gets rescheduled because it's starved out by the others. I can repro. Need to strategically place yields or interrupt the competitors. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2610482776 From cushon at openjdk.org Thu Jan 23 17:26:53 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 23 Jan 2025 17:26:53 GMT Subject: Integrated: 8348365: Bad format string in CLDRDisplayNamesTest In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 05:42:33 GMT, Liam Miller-Cushon wrote: > This change fixes an incorrect call to `printf` for a failure message in `CLDRDisplayNamesTest`. This pull request has now been integrated. Changeset: d9d2e19f Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/d9d2e19f923217a6831a8697c62ebeef0cc5d3b8 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8348365: Bad format string in CLDRDisplayNamesTest Reviewed-by: shade, naoto ------------- PR: https://git.openjdk.org/jdk/pull/23252 From jvernee at openjdk.org Thu Jan 23 17:18:01 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 23 Jan 2025 17:18:01 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v17] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:13:37 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > /othervm --enable-native-access=ALL-UNNAMED > > Co-authored-by: Jorn Vernee The `TestBufferStack` test is timing out in our CI on fastdebug builds when running with `-Duse.JTREG_TEST_THREAD_FACTORY=Virtual -XX:-VerifyContinuations`, I'm not sure what the issue is, as there's basically no output from the test, except the timeout message, and the warning about illegal native access. We need to fix that before integrating though. I'll see if I can uncover some more info. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2610460741 From jvernee at openjdk.org Thu Jan 23 17:31:55 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 23 Jan 2025 17:31:55 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v17] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:23:48 GMT, Matthias Ernst wrote: > Need to strategically place yields or interrupt the competitors. Maybe the number of iterations could be capped? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2610515954 From duke at openjdk.org Thu Jan 23 17:36:11 2025 From: duke at openjdk.org (Matthias Ernst) Date: Thu, 23 Jan 2025 17:36:11 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v18] In-Reply-To: References: Message-ID: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR implements a per carrier-thread stacked allocator. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op > CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: fix test under VThread factory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23142/files - new: https://git.openjdk.org/jdk/pull/23142/files/89479648..c314d6a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23142&range=16-17 Stats: 13 lines in 1 file changed: 6 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23142/head:pull/23142 PR: https://git.openjdk.org/jdk/pull/23142 From jvernee at openjdk.org Thu Jan 23 17:38:55 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 23 Jan 2025 17:38:55 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v17] In-Reply-To: References: Message-ID: <6pFPzb3iGYdl4yMqC62Sg3ti51c2scafY_F4gKO-cVU=.f0c1f709-c03d-4792-b13d-5adcb74148ca@github.com> On Thu, 23 Jan 2025 17:13:37 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > /othervm --enable-native-access=ALL-UNNAMED > > Co-authored-by: Jorn Vernee Thanks for the fix, I'll submit another CI job ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2610533297 From vpaprotski at openjdk.org Thu Jan 23 18:11:02 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 23 Jan 2025 18:11:02 GMT Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni [v2] In-Reply-To: References: Message-ID: > @TobiHartmann There are still some unanswered questions I have, but committing this since we need to work around vacation schedules. > > **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This fix fixes the crash but I don't understand entirely why the crash happens in the first place. > > The issue fixed here are all the CheckJNI warnings: > > OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall > > > Crash has nothing to do with String.indexOf work, but was introduced by my `8319429: Resetting MXCSR flags degrades ecore` change. I was able to get HelloWorld to crash on Windows (`-Xcheck:jni -XX:+EnableX86ECoreOpts`). Same command on linux produces hundreds of CheckJNI warnings. Is it odd that its only being found now, no other CheckJNI tests? > > I would appreciate some help/reviews from somebody more aware of the Java-to-C linkage. I think I got the masks fixed, but there is one specific place (see the 'FIXME' question in the diff) for Windows I am not certain about. (@sviswa7 is on vacation for few more weeks) > > Note: Crash on windows (if I have the Windows debugger actually correct), happens on: > > 0x000001f2525f13c1: fxrstor64 (%rsp) > Stack: > 0x00000088f1bfe060: 00007ff8b4384310 0000025bfaeb2200 > > > `00007ff8` _seems_ like a valid mxcsr value, only way it should crash is if top 2 bytes weren't zeroes, which they are. Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22673/files - new: https://git.openjdk.org/jdk/pull/22673/files/c106e350..6768b9df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=00-01 Stats: 86 lines in 7 files changed: 42 ins; 35 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22673.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22673/head:pull/22673 PR: https://git.openjdk.org/jdk/pull/22673 From vpaprotski at openjdk.org Thu Jan 23 18:26:06 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 23 Jan 2025 18:26:06 GMT Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni [v3] In-Reply-To: References: Message-ID: > (Also see `8319429: Resetting MXCSR flags degrades ecore`) > > For performance, signaling flags (bottom 6 bits) are set by default in MXCSR. This PR fixes the Xcheck:jni comparison that is producing these copious warnings: > > OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall > > > **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This PR fixes the crash but I have not been able to track down the source of the crash (i.e. crash in the warn handler). Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22673/files - new: https://git.openjdk.org/jdk/pull/22673/files/6768b9df..2b15f99a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22673.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22673/head:pull/22673 PR: https://git.openjdk.org/jdk/pull/22673 From mcimadamore at openjdk.org Thu Jan 23 18:35:57 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 Jan 2025 18:35:57 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v8] In-Reply-To: References: <2prZf-Gvl5R7y36kZavsP_pzWGVIjklRSpVe99bBdF4=.282c0156-3fff-4a07-b53a-175efd69fe74@github.com> <0Qv9xavVJEkYju_aV3Tnw-miGIBmmBt5fHp34g7vV2k=.b179219a-44d8-4a3f-a8c8-c227256209af@github.com> <33F87NmT6M4w5PsG3pJ73NY32VeqyHAkjIKK1jZyJbo=.eb99b2ad-6e7d-4e07-8616-8c2a720a755b@github.com> <5LLNS59Ko2HRTTGTEPq1LKdPH0CeqbX-PKxdC8coMwU=.94ccae3a-7cd4-42e5-81d2-5ec72984d5c3@github.com> Message-ID: On Thu, 23 Jan 2025 15:21:24 GMT, Matthias Ernst wrote: > losing `ofAuto` works fine, at least for now. I was mostly brainstorming aloud on how to get back to deterministic deallocation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927475963 From naoto at openjdk.org Thu Jan 23 18:38:48 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 23 Jan 2025 18:38:48 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 02:49:49 GMT, Justin Lu wrote: > Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. > > A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. Looks good. Some files need copyright year bump src/java.base/share/classes/java/util/TimeZone.java line 652: > 650: * > 651: * @param rawOffset the given time zone GMT offset in milliseconds. > 652: * @return an array of IDs, where the time zone for that ID has array -> stream src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 96: > 94: // specify it. Keep the same behavior for better > 95: // compatibility. > 96: String[] list = ids.toArray(new String[0]); Why is this change? Since the array has correct size, no extra array allocation is needed? src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 122: > 120: return zoneIds() > 121: .filter(id -> getZoneInfo(id).getRawOffset() == rawOffset) > 122: .sorted(); // Sort the IDs, see getZoneIds(int) This is interesting. one with `rawOffset` is soreted, but the other is not. It is inconsistent but probably we should align as you did here. ------------- PR Review: https://git.openjdk.org/jdk/pull/23251#pullrequestreview-2570586882 PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927410357 PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927429593 PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927452374 From vpaprotski at openjdk.org Thu Jan 23 18:26:06 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 23 Jan 2025 18:26:06 GMT Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 18:23:01 GMT, Volodymyr Paprotski wrote: >> (Also see `8319429: Resetting MXCSR flags degrades ecore`) >> >> For performance, signaling flags (bottom 6 bits) are set by default in MXCSR. This PR fixes the Xcheck:jni comparison that is producing these copious warnings: >> >> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall >> >> >> **This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This PR fixes the crash but I have not been able to track down the source of the crash (i.e. crash in the warn handler). > > Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: > > whitespace src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 185: > 183: // On ECore, restore with signaling flags enabled > 184: MxCsr |= 0x3F; > 185: } @JornVernee I came across your comment https://github.com/openjdk/jdk/pull/14523/files#r1236920072 I believe I am following the 'spirit' of that comment here, but would appreciate you having a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1927463691 From iris at openjdk.org Thu Jan 23 18:58:49 2025 From: iris at openjdk.org (Iris Clark) Date: Thu, 23 Jan 2025 18:58:49 GMT Subject: RFR: 8343609: Broken links in java.xml [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 00:46:07 GMT, Joe Wang wrote: >> Fix broken links in java.xml: >> >> Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. >> >> QName: rewrote the javadocs. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > s/javax.xml.XMLConstants/XMLConstants Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23242#pullrequestreview-2570769949 From jlu at openjdk.org Thu Jan 23 19:02:44 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 19:02:44 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v2] In-Reply-To: References: Message-ID: > Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. > > A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect Naoto's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23251/files - new: https://git.openjdk.org/jdk/pull/23251/files/4df90163..48956fdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23251&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23251&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23251/head:pull/23251 PR: https://git.openjdk.org/jdk/pull/23251 From jlu at openjdk.org Thu Jan 23 19:02:46 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 19:02:46 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:41:35 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect Naoto's review > > src/java.base/share/classes/java/util/TimeZone.java line 652: > >> 650: * >> 651: * @param rawOffset the given time zone GMT offset in milliseconds. >> 652: * @return an array of IDs, where the time zone for that ID has > > array -> stream Thanks for the catch. Fixed this and bumped those Zone* file copyright years in https://github.com/openjdk/jdk/pull/23251/commits/48956fdd92aba3a3802e81cfbc8468296dbab777. I double checked that all the test files have 2025 copyright years. > src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 96: > >> 94: // specify it. Keep the same behavior for better >> 95: // compatibility. >> 96: String[] list = ids.toArray(new String[0]); > > Why is this change? Since the array has correct size, no extra array allocation is needed? Regarding the switch from `toArray(new T[size])` to `toArray(new T[0])`, based off https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_conclusion, the JVM performs the latter faster. I believe the article data/results still hold true now. > src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 122: > >> 120: return zoneIds() >> 121: .filter(id -> getZoneInfo(id).getRawOffset() == rawOffset) >> 122: .sorted(); // Sort the IDs, see getZoneIds(int) > > This is interesting. one with `rawOffset` is soreted, but the other is not. It is inconsistent but probably we should align as you did here. Noticed that too. There is also the argument that since these stream methods are new, we can leave it un-sorted but we would have to specify the deviation. Although I agree it is best to align for consistency. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927539888 PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927539958 PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927540008 From jlu at openjdk.org Thu Jan 23 19:04:49 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 19:04:49 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 18:58:46 GMT, Justin Lu wrote: >> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 122: >> >>> 120: return zoneIds() >>> 121: .filter(id -> getZoneInfo(id).getRawOffset() == rawOffset) >>> 122: .sorted(); // Sort the IDs, see getZoneIds(int) >> >> This is interesting. one with `rawOffset` is soreted, but the other is not. It is inconsistent but probably we should align as you did here. > > Noticed that too. There is also the argument that since these stream methods are new, we can leave it un-sorted but we would have to specify the deviation. Although I agree it is best to align for consistency. Actually I'm wondering if we should specify these `rawOffset` methods with an `@implNote` that states they are sorted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927544428 From naoto at openjdk.org Thu Jan 23 19:15:50 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 23 Jan 2025 19:15:50 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 19:02:32 GMT, Justin Lu wrote: >> Noticed that too. There is also the argument that since these stream methods are new, we can leave it un-sorted but we would have to specify the deviation. Although I agree it is best to align for consistency. > > Actually I'm wondering if we should specify these `rawOffset` methods with an `@implNote` that states they are sorted. I'd rather not. If we did, users would wonder why no-arg return is not sorted, which might be a mere overlook (and if we sort it, it would be costly (num of tzids are not small)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927556567 From liach at openjdk.org Thu Jan 23 19:32:03 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 23 Jan 2025 19:32:03 GMT Subject: [jdk24] RFR: 8342466: Improve API documentation for java.lang.classfile.attribute Message-ID: <59Vo0cAaCMCzjMNZMNlZWTtmz3WxtEEPHOcIVAhS66Q=.9cc8e72c-09f2-4138-aa1e-6c9a399f2ef1@github.com> This is a non-clean backport the java.lang.classfile.attribute documentation improvements 973c630777d4075bc85c7ddc1eb02cc65904344d to JDK 24 , the release where the API is finalized. Also backported a tier1 docs build hotfix 28e01e6559a79720d03355444a4e1c1fbf0b0373 for the broken links. No related failure in tier 1-3 on all platforms. ------------- Commit messages: - 8347762: ClassFile attribute specification refers to non-SE modules - 8342466: Improve API documentation for java.lang.classfile.attribute Changes: https://git.openjdk.org/jdk/pull/23273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342466 Stats: 2561 lines in 70 files changed: 1594 ins; 125 del; 842 mod Patch: https://git.openjdk.org/jdk/pull/23273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23273/head:pull/23273 PR: https://git.openjdk.org/jdk/pull/23273 From jlu at openjdk.org Thu Jan 23 19:50:04 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 19:50:04 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v3] In-Reply-To: References: Message-ID: > Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. > > A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: include copyright bump for missed file in JDK-834836501 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23251/files - new: https://git.openjdk.org/jdk/pull/23251/files/48956fdd..db907223 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23251&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23251&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23251/head:pull/23251 PR: https://git.openjdk.org/jdk/pull/23251 From jlu at openjdk.org Thu Jan 23 19:50:04 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 19:50:04 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v3] In-Reply-To: References: Message-ID: <2ZvzymLN5E2C9zBqrQBBpxyZ5t92vLz9NtMfEkapoL4=.e2dd5df6-29da-48d6-8a2d-dd5bb1cd915a@github.com> On Thu, 23 Jan 2025 19:13:22 GMT, Naoto Sato wrote: >> Actually I'm wondering if we should specify these `rawOffset` methods with an `@implNote` that states they are sorted. > > I'd rather not. If we did, users would wonder why no-arg return is not sorted, which might be a mere overlook (and if we sort it, it would be costly (num of tzids are not small)) Fair enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927596306 From liach at openjdk.org Thu Jan 23 20:02:23 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 23 Jan 2025 20:02:23 GMT Subject: RFR: 8342465: Improve API documentation for java.lang.classfile Message-ID: This is the last piece in the API documentation improvement of the Class-File API. This includes general documentation about transforms, models (and traversals), options, constants, and CodeBuilder factories. In particular, this preserves the package summary to avoid extra disruptions. See the APIDiff for more details. Please forgive this messy commit history; the work began before attribute changes were integrated and based off that, and in the process there were a few merges back and forth. The files changed/webrev should be reliable. Please review the associated CSR as well. Note that this intends to be backported to 24; this won't be clean, as the `JAVA_25_VERSION` constant is a new addition that does not exist on 24. Testing: Running tier 1-3. APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-overall/java.base/java/lang/classfile/package-summary.html Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-overall/java.base/java/lang/classfile/package-summary.html ------------- Commit messages: - Trailing whitespaces - Broken anchor, add critical option informaton - Use imports for classfile api intro - Years - Fixes, roll back package info - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-overall - Merge remote-tracking branch 'openjdk/master' into docs/cf-overall - 8347762: ClassFile attribute specification refers to non-SE modules - CSR review remarks - Stage - ... and 2 more: https://git.openjdk.org/jdk/compare/605b53e4...d4b1c1ed Changes: https://git.openjdk.org/jdk/pull/23277/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342465 Stats: 2945 lines in 37 files changed: 1936 ins; 30 del; 979 mod Patch: https://git.openjdk.org/jdk/pull/23277.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23277/head:pull/23277 PR: https://git.openjdk.org/jdk/pull/23277 From liach at openjdk.org Thu Jan 23 20:06:49 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 23 Jan 2025 20:06:49 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v3] In-Reply-To: References: Message-ID: <-8D25Trp1PhvgxTPRGw1l-6euL3ZpX6pOJCAMx6OU94=.00faa9e8-8639-465e-807f-a788703bd602@github.com> On Thu, 23 Jan 2025 19:50:04 GMT, Justin Lu wrote: >> Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. >> >> A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > include copyright bump for missed file in JDK-834836501 src/java.base/share/classes/java/util/TimeZone.java line 659: > 657: * @since 25 > 658: */ > 659: public static synchronized Stream availableIDs(int rawOffset) { Why are these new methods synchronized? I think the streams and the spliterators are late-binding, so the synchronization does not synchronize the access to the underlying arrays. synchronized modifier also does not appear in Javadoc and is not part of the API surface, so it can be safely removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927614576 From jan7493 at gmail.com Thu Jan 23 21:20:00 2025 From: jan7493 at gmail.com (Jan Kowalski) Date: Thu, 23 Jan 2025 22:20:00 +0100 Subject: Adding BigDecimal.valueOf(float val) constructor Message-ID: Hi! I?m currently working on a project that heavily relies on float values, and we occasionally use BigDecimal for more precise mathematical operations. However, I?ve noticed that the current BigDecimal constructor implementation only supports double, which can lead to unintentional type conversion and precision loss when creating a BigDecimal from a float. The documentation suggests using BigDecimal.valueOf(double val) as the preferred method for converting double or float values to BigDecimal, but since method takes double as an argument, it leads much more often to precision loss when float is passed. For example: - BigDecimal.valueOf(0.1d) correctly produces 0.1. - However, BigDecimal.valueOf(0.1f) produces 0.10000000149011612, which introduces unwanted precision artifacts. What would you think about introducing a static factory method specifically for float values, such as: public static BigDecimal valueOf(float val) { return new BigDecimal(Float.toString(val)); } This addition should improve usability and ensure that float values are handled more precisely within the BigDecimal API -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bourrillion at oracle.com Thu Jan 23 21:46:51 2025 From: kevin.bourrillion at oracle.com (Kevin Bourrillion) Date: Thu, 23 Jan 2025 21:46:51 +0000 Subject: Adding BigDecimal.valueOf(float val) constructor In-Reply-To: References: Message-ID: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> Hi, Before addressing your request I want to try to just add a little context as to what?s really going on (after which Joe will probably correct me). You might know some or all of this, but it?s a refresher for everyone (including myself). First, the value 0.1d is a ?human-friendly? representation of the actual binary value, which is more accurately expressed as the hex literal 0x1.999999999999Ap-4 Notice it?s a repeating expansion, and it has to be rounded up at the end to make it fit into 13 hex digits. The true decimal representation of this value is 0.1000000000000000055511151231257827021181583404541015625 If we?d rounded that last digit (A) down (to 9) we would get this instead: 0.09999999999999999167332731531132594682276248931884765625 Now, the only reason we even call this value ?0.1? at all (which it is not!), and that Java even calls it ?0.1? when it is talking to us, is simply this: It happens to be the nearest representable value to 0.1 (which you can observe for yourself if you look very closely at the full decimal expansions I just gave). All that this means is that the short string ?0.1? becomes a suitably unambiguous way to refer to that number. A ?shorthand? for it. Now, the fact that BigDecimal.valueOf(0.1d) decides to produce a value with scale set to 1 is ? interesting: jshell> double a = 0.1 a ==> 0.1 jshell> double b = 0.2 b ==> 0.2 jshell> BigDecimal.valueOf(a).scale() $14 ==> 1 jshell> BigDecimal.valueOf(b).scale() $15 ==> 1 jshell> BigDecimal.valueOf(a + b).scale() $16 ==> 17 You?ve described its behavior as ?correct?, but I would question whether that?s really the right term for it. It feels uncomfortably arbitrary to me. When your goal is to get the BigDecimal value ?0.1? (with scale 1), the safe and recommended way to do that is with `new BigDecimal(?0.1?)`. Maybe some variation on this idea will help you in your case; I?m not sure. Again, I?m not directly commenting on your suggestion, just providing context. On Jan 23, 2025, at 1:20?PM, Jan Kowalski wrote: Hi! I?m currently working on a project that heavily relies on float values, and we occasionally use BigDecimal for more precise mathematical operations. However, I?ve noticed that the current BigDecimal constructor implementation only supports double, which can lead to unintentional type conversion and precision loss when creating a BigDecimal from a float. The documentation suggests using BigDecimal.valueOf(double val) as the preferred method for converting double or float values to BigDecimal, but since method takes double as an argument, it leads much more often to precision loss when float is passed. For example: - BigDecimal.valueOf(0.1d) correctly produces 0.1. - However, BigDecimal.valueOf(0.1f) produces 0.10000000149011612, which introduces unwanted precision artifacts. What would you think about introducing a static factory method specifically for float values, such as: public static BigDecimal valueOf(float val) { return new BigDecimal(Float.toString(val)); } This addition should improve usability and ensure that float values are handled more precisely within the BigDecimal API -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jan 23 21:55:18 2025 From: duke at openjdk.org (Zheng Feng) Date: Thu, 23 Jan 2025 21:55:18 GMT Subject: RFR: 8344925: translet-name ignored, when package-name is also set via TransformerFactory.setAttribute Message-ID: ?String) This bug seems from the improper handling of package and class name initialization in `XSLTC` since there is a default value of `_packageName` with `die.verwandlung`. This fix is just adjusting to call `setPackageName` before `setClassName`. I've done the tire1 and tire2 tests. The tire1 tests passed and tire2 reports ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier2 745 744 1 0 << >> jtreg:test/jdk:tier2 4142 4137 2 3 << jtreg:test/langtools:tier2 12 12 0 0 jtreg:test/jaxp:tier2 514 514 0 0 jtreg:test/docs:tier2 1 1 0 0 ============================== TEST FAILURE The failed tests are JT Harness : Tests that failed runtime/Thread/ThreadCountLimit.java#id0: Stress test that reaches the process limit for thread count, or time limit. JT Harness : Tests that failed java/net/InetAddress/CheckJNI.java: java -Xcheck:jni failing in net code on Solaris / [Datagram]Socket.getLocalAddress() failure java/net/Socket/LinkLocal.java: Connecting to a link-local IPv6 address should not causes a SocketException to be thrown. JT Harness : Tests that had errors java/net/URL/EarlyOrDelayedParsing.java: URL built-in protocol handlers should parse the URL early to avoid constructing URLs for which openConnection would later throw an exception, when possible. java/net/ipv6tests/UdpTest.java: IPv6 support for Windows XP and 2003 server. java/nio/channels/DatagramChannel/SendReceiveMaxSize.java: Check that it is possible to send and receive datagrams of maximum size on macOS. ------------- Commit messages: - 8344925: Call XSLTC.setPackageName(String) before XSLTC.setClassName(String) Changes: https://git.openjdk.org/jdk/pull/22425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344925 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22425/head:pull/22425 PR: https://git.openjdk.org/jdk/pull/22425 From sgehwolf at openjdk.org Thu Jan 23 21:55:19 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 23 Jan 2025 21:55:19 GMT Subject: RFR: 8344925: translet-name ignored, when package-name is also set via TransformerFactory.setAttribute In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng wrote: > ?String) > > This bug seems from the improper handling of package and class name initialization in `XSLTC` since there is a default value of `_packageName` with `die.verwandlung`. This fix is just adjusting to call `setPackageName` before `setClassName`. > > I've done the tire1 and tire2 tests. The tire1 tests passed and tire2 reports > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier2 745 744 1 0 << >>> jtreg:test/jdk:tier2 4142 4137 2 3 << > jtreg:test/langtools:tier2 12 12 0 0 > jtreg:test/jaxp:tier2 514 514 0 0 > jtreg:test/docs:tier2 1 1 0 0 > ============================== > TEST FAILURE > > > The failed tests are > > JT Harness : Tests that failed > runtime/Thread/ThreadCountLimit.java#id0: Stress test that reaches the process limit for thread count, or time limit. > > JT Harness : Tests that failed > java/net/InetAddress/CheckJNI.java: java -Xcheck:jni failing in net code on Solaris / [Datagram]Socket.getLocalAddress() failure > java/net/Socket/LinkLocal.java: Connecting to a link-local IPv6 address should not causes a SocketException to be thrown. > > JT Harness : Tests that had errors > java/net/URL/EarlyOrDelayedParsing.java: URL built-in protocol handlers should parse the URL early to avoid constructing URLs for which openConnection would later throw an exception, when possible. > java/net/ipv6tests/UdpTest.java: IPv6 support for Windows XP and 2003 server. > java/nio/channels/DatagramChannel/SendReceiveMaxSize.java: Check that it is possible to send and receive datagrams of maximum size on macOS. > /covered Zheng Feng works for Red Hat and should be covered by the RH OCA. @robilad Could you have a look at OCA clearance for @zhfeng. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22425#issuecomment-2505639462 PR Comment: https://git.openjdk.org/jdk/pull/22425#issuecomment-2519779633 From duke at openjdk.org Thu Jan 23 21:55:19 2025 From: duke at openjdk.org (Zheng Feng) Date: Thu, 23 Jan 2025 21:55:19 GMT Subject: RFR: 8344925: translet-name ignored, when package-name is also set via TransformerFactory.setAttribute In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng wrote: > ?String) > > This bug seems from the improper handling of package and class name initialization in `XSLTC` since there is a default value of `_packageName` with `die.verwandlung`. This fix is just adjusting to call `setPackageName` before `setClassName`. > > I've done the tire1 and tire2 tests. The tire1 tests passed and tire2 reports > > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR >>> jtreg:test/hotspot/jtreg:tier2 745 744 1 0 << >>> jtreg:test/jdk:tier2 4142 4137 2 3 << > jtreg:test/langtools:tier2 12 12 0 0 > jtreg:test/jaxp:tier2 514 514 0 0 > jtreg:test/docs:tier2 1 1 0 0 > ============================== > TEST FAILURE > > > The failed tests are > > JT Harness : Tests that failed > runtime/Thread/ThreadCountLimit.java#id0: Stress test that reaches the process limit for thread count, or time limit. > > JT Harness : Tests that failed > java/net/InetAddress/CheckJNI.java: java -Xcheck:jni failing in net code on Solaris / [Datagram]Socket.getLocalAddress() failure > java/net/Socket/LinkLocal.java: Connecting to a link-local IPv6 address should not causes a SocketException to be thrown. > > JT Harness : Tests that had errors > java/net/URL/EarlyOrDelayedParsing.java: URL built-in protocol handlers should parse the URL early to avoid constructing URLs for which openConnection would later throw an exception, when possible. > java/net/ipv6tests/UdpTest.java: IPv6 support for Windows XP and 2003 server. > java/nio/channels/DatagramChannel/SendReceiveMaxSize.java: Check that it is possible to send and receive datagrams of maximum size on macOS. Please keep it open and we will still wait for the OCA clearance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22425#issuecomment-2567713494 From iklam at openjdk.org Thu Jan 23 22:05:59 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 23 Jan 2025 22:05:59 GMT Subject: RFR: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 23:41:18 GMT, Coleen Phillimore wrote: >> Ioi Lam 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: >> >> - Merge branch 'master' into 8348240-remove-lookup_super_for_unregistered_class >> - @calvinccheung comments >> - 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() > > I like this change a lot, except for the name "unregistered" but that can be taken up in some other way. If I understand correctly, this just creates a dummy class loader to load the classes you want to share from the non-boot, app or system class loader. Thanks @coleenp @calvinccheung for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23226#issuecomment-2611107641 From iklam at openjdk.org Thu Jan 23 22:06:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 23 Jan 2025 22:06:00 GMT Subject: Integrated: 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam wrote: > I reimplemented `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java code. This removes hacks in `SystemDictionary::resolve_with_circularity_detection()` to facilitate future clean-ups there that are planned by @coleenp. Please see the [JBS issue](https://bugs.openjdk.org/browse/JDK-8348240) for a discussion of why the hack was there. > > The new Java code is in the `jdk/internal/misc/CDS$UnregisteredClassLoader` class. I also simplified `UnregisteredClasses::create_classloader()` by moving some unwieldy C++ `JavaCalls` code into Java. > > ### How this works: > > For example, let's assume you have the following classfiles in foo.jar: > > > interface MyInterface1 {} > interface MyInterface2 {} > class MyClass extends Object implements MyInterface1, MyInterface2 {} > > > The CDS classlist file can look like this: > > > java/lang/Object id: 1 > MyInterface1: id: 2 super: 1 source: foo.jar > MyInterface2: id: 3 super: 1 source: foo.jar > MyClass: id: 4 super: 1 interfaces: 2 3 source: foo.jar > > > When CDS handles the `MyClass: id: 4` line, it calls `CDS$UnregisteredClassLoader::load()` with the following parameters: > > - `name` = "MyClass" > - `superClass` = java.lang.Object > - `interfaces` = {MyInterface1, MyInterface2} > > `CDS$UnregisteredClassLoader::load()` will start parsing MyClass.class from foo.jar. The ClassFileParser will see symbolic references to the supertypes of `MyClass`. These supertypes will be resolved by `CDS$UnregisteredClassLoader::findClass()`, using the classes provided by `superClass` and `interfaces`. This pull request has now been integrated. Changeset: 7f16a087 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/7f16a0875ced8669b9d2131c67496a66e74ea36f Stats: 346 lines in 10 files changed: 193 ins; 115 del; 38 mod 8348240: Remove SystemDictionaryShared::lookup_super_for_unregistered_class() Reviewed-by: ccheung, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/23226 From jlu at openjdk.org Thu Jan 23 22:25:49 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 23 Jan 2025 22:25:49 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v3] In-Reply-To: <-8D25Trp1PhvgxTPRGw1l-6euL3ZpX6pOJCAMx6OU94=.00faa9e8-8639-465e-807f-a788703bd602@github.com> References: <-8D25Trp1PhvgxTPRGw1l-6euL3ZpX6pOJCAMx6OU94=.00faa9e8-8639-465e-807f-a788703bd602@github.com> Message-ID: On Thu, 23 Jan 2025 20:04:04 GMT, Chen Liang wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> include copyright bump for missed file in JDK-834836501 > > src/java.base/share/classes/java/util/TimeZone.java line 659: > >> 657: * @since 25 >> 658: */ >> 659: public static synchronized Stream availableIDs(int rawOffset) { > > Why are these new methods synchronized? I think the streams and the spliterators are late-binding, so the synchronization does not synchronize the access to the underlying arrays. synchronized modifier also does not appear in Javadoc and is not part of the API surface, so it can be safely removed. Right, it can be removed. Actually, I think `getAvailableIDs()` and `getAvailableIDs(int)` also do not need to be synchronized. The internal IDs are eagerly initialized in the static block of `ZoneInfoFile.java` and are effectively final and not modified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927760206 From forax at univ-mlv.fr Thu Jan 23 22:35:12 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 23 Jan 2025 23:35:12 +0100 (CET) Subject: Adding BigDecimal.valueOf(float val) constructor In-Reply-To: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> References: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> Message-ID: <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr> Hello Jan, what you are suggesting is not a backward compatible change. If we add BigDecimal,valueOf(float), then a program recompiled with the new JDK may change its behavior, you can think that the new behavior is more "correct" that the current one, but changing the behavior of existing programs is usually a big NO ! in Java. Also, I believe that the reason there is no such factory method that takes a float is that doing computations on floats is not recommanded, it becomes a mess rapidly of the imprecision of the float32 representation, . For the same reason, in Java, 2.0 is a double and there is no FloatStream while there is a DoubleStream. regards, R?mi > From: "Kevin Bourrillion" > To: "Jan Kowalski" > Cc: "core-libs-dev" > Sent: Thursday, January 23, 2025 10:46:51 PM > Subject: Re: Adding BigDecimal.valueOf(float val) constructor > Hi, > Before addressing your request I want to try to just add a little context as to > what?s really going on (after which Joe will probably correct me). You might > know some or all of this, but it?s a refresher for everyone (including myself). > First, the value 0.1d is a ?human-friendly? representation of the actual binary > value, which is more accurately expressed as the hex literal > 0x1.999999999999Ap-4 > Notice it?s a repeating expansion, and it has to be rounded up at the end to > make it fit into 13 hex digits. > The true decimal representation of this value is > 0.1000000000000000055511151231257827021181583404541015625 > If we?d rounded that last digit (A) down (to 9) we would get this instead: > 0.09999999999999999167332731531132594682276248931884765625 > Now, the only reason we even call this value ?0.1? at all (which it is not!), > and that Java even calls it ?0.1? when it is talking to us , is simply this: > It happens to be the nearest representable value to 0.1 (which you can observe > for yourself if you look very closely at the full decimal expansions I just > gave). > All that this means is that the short string ?0.1? becomes a suitably > unambiguous way to refer to that number. A ?shorthand? for it. > Now, the fact that BigDecimal.valueOf(0.1d) decides to produce a value with > scale set to 1 is ? interesting: > jshell> double a = 0.1 > a ==> 0.1 > jshell> double b = 0.2 > b ==> 0.2 > jshell> BigDecimal.valueOf(a).scale() > $14 ==> 1 > jshell> BigDecimal.valueOf(b).scale() > $15 ==> 1 > jshell> BigDecimal.valueOf(a + b).scale() > $16 ==> 17 > You?ve described its behavior as ?correct?, but I would question whether that?s > really the right term for it. It feels uncomfortably arbitrary to me. > When your goal is to get the BigDecimal value ?0.1? (with scale 1), the safe and > recommended way to do that is with `new BigDecimal(?0.1?)`. Maybe some > variation on this idea will help you in your case; I?m not sure. > Again, I?m not directly commenting on your suggestion, just providing context. >> On Jan 23, 2025, at 1:20 PM, Jan Kowalski wrote: >> Hi! >> I?m currently working on a project that heavily relies on float values, and we >> occasionally use BigDecimal for more precise mathematical operations. However, >> I?ve noticed that the current BigDecimal constructor implementation only >> supports double, which can lead to unintentional type conversion and precision >> loss when creating a BigDecimal from a float. >> The documentation suggests using BigDecimal.valueOf(double val) as the preferred >> method for converting double or float values to BigDecimal, but since method >> takes double as an argument, it leads much more often to precision loss when >> float is passed. >> For example: >> - BigDecimal.valueOf(0.1d) correctly produces 0.1. >> - However, BigDecimal.valueOf(0.1f) produces 0.10000000149011612, which >> introduces unwanted precision artifacts. >> What would you think about introducing a static factory method specifically for >> float values, such as: >> public static BigDecimal valueOf(float val) { >> return new BigDecimal(Float.toString(val)); >> } >> This addition should improve usability and ensure that float values are handled >> more precisely within the BigDecimal API -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Thu Jan 23 22:50:47 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 23 Jan 2025 22:50:47 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v3] In-Reply-To: References: <-8D25Trp1PhvgxTPRGw1l-6euL3ZpX6pOJCAMx6OU94=.00faa9e8-8639-465e-807f-a788703bd602@github.com> Message-ID: On Thu, 23 Jan 2025 22:23:29 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/util/TimeZone.java line 659: >> >>> 657: * @since 25 >>> 658: */ >>> 659: public static synchronized Stream availableIDs(int rawOffset) { >> >> Why are these new methods synchronized? I think the streams and the spliterators are late-binding, so the synchronization does not synchronize the access to the underlying arrays. synchronized modifier also does not appear in Javadoc and is not part of the API surface, so it can be safely removed. > > Right, it can be removed. Actually, I think `getAvailableIDs()` and `getAvailableIDs(int)` also do not need to be synchronized. The internal IDs are eagerly initialized in the static block of `ZoneInfoFile.java` and are effectively final and not modified. Yep; their synchronized are incorrect. The object monitor lock should have been on `ZoneInfoFile.class` to be effective. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1927788351 From joe.darcy at oracle.com Thu Jan 23 23:50:39 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 23 Jan 2025 15:50:39 -0800 Subject: Adding BigDecimal.valueOf(float val) constructor In-Reply-To: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> References: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> Message-ID: <34b678c5-bd28-4156-adf4-bcc6294ee89d@oracle.com> Hello, On 1/23/2025 1:46 PM, Kevin Bourrillion wrote: > Hi, > > Before addressing your request I want to try to just add a little > context as to what?s really going on (after which Joe will probably > correct me). I'll augment Kevin's reply anyway :-) > You might know some or all of this, but it?s a refresher for everyone > (including myself). For some other quick background, please see the discussion of? "Decimal <-> Binary Conversion Issues" in the javadoc for java.lang.Double: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Double.html#decimalToBinaryConversion In terms of concrete advice, if you want a BigDecimal equivalent to the string form of a float value, use the BigDecimal string constructor; e.g. ??? float f = 0.1f; ??? new BigDecimal(Float.toString(f)); // BigDecimal with a numerical value of 0.1 As Kevin noted, a numerical value of 0.1 is not the exact numerical value of the float value 0.1f, neither 0.1 the exact numerical value of 0.1d, although the double value is much closer to 0.1. For a more detailed explanation, my half-hour 2021 talk "What Every Java Programmer Should Know About Floating-Point Arithmetic" [1] covers this situation in more detail. HTH, -Joe [1] https://cr.openjdk.org/~darcy/Presentations/OracleDevLive/OracleDevLive-2021-09-FloatingPoint.pdf https://www.youtube.com/watch?v=ajaHQ9S4uTA From joe.darcy at oracle.com Thu Jan 23 23:59:16 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 23 Jan 2025 15:59:16 -0800 Subject: Adding BigDecimal.valueOf(float val) constructor In-Reply-To: <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr> References: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On 1/23/2025 2:35 PM, Remi Forax wrote: > Hello Jan, > what you are suggesting is not a backward compatible change. There is a source compatibility impact, meaning that for some call sites, the mapping of existing code using BigDecimal before and after the addition of the overloaded method would change. That wouldn't necessarily preclude us from making such a change (and such changes have been made in the past), but extra caution and analysis would be called for. Cheers, -Joe > > If we add BigDecimal,valueOf(float), then a program recompiled with > the new JDK may change its behavior, > you can think that the new behavior is more "correct" that the current > one, but changing the behavior of existing programs is usually a big > NO ! in Java. > > Also, I believe that the reason there is no such factory method that > takes a float is that doing computations on floats is not recommanded, > it becomes a mess rapidly of the imprecision of the float32 > representation, . > For the same reason, in Java, 2.0 is a double and there is no > FloatStream while there is a DoubleStream. > > regards, > R?mi > > ------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchristi at openjdk.org Fri Jan 24 00:06:50 2025 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 24 Jan 2025 00:06:50 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: On Thu, 23 Jan 2025 08:51:38 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: > > - No instantiation for BufferCleaner, javadocs > - Remove hasReferencePendingList > - Revert test exclusion, moved to JDK-8348301 The reference processing and Cleaner stuff all looks fine to me. ------------- Marked as reviewed by bchristi (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2571367180 From bchristi at openjdk.org Fri Jan 24 00:11:49 2025 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 24 Jan 2025 00:11:49 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: On Thu, 23 Jan 2025 08:51:38 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: > > - No instantiation for BufferCleaner, javadocs > - Remove hasReferencePendingList > - Revert test exclusion, moved to JDK-8348301 src/java.base/share/classes/java/nio/Bits.java line 151: > 149: // Trigger GC to perform reference processing and then cleaning. > 150: canary = BufferCleaner.newCanary(); > 151: System.gc(); So the Canary functions only to avoid calling `System.gc()` again if we've not yet seen progress from the previous call to `System.gc()`. Is that right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1927908860 From joehw at openjdk.org Fri Jan 24 00:32:51 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 24 Jan 2025 00:32:51 GMT Subject: RFR: 8343609: Broken links in java.xml [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 00:46:07 GMT, Joe Wang wrote: >> Fix broken links in java.xml: >> >> Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. >> >> QName: rewrote the javadocs. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > s/javax.xml.XMLConstants/XMLConstants Thanks all! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23242#issuecomment-2611290157 From joehw at openjdk.org Fri Jan 24 00:32:51 2025 From: joehw at openjdk.org (Joe Wang) Date: Fri, 24 Jan 2025 00:32:51 GMT Subject: Integrated: 8343609: Broken links in java.xml In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 18:55:10 GMT, Joe Wang wrote: > Fix broken links in java.xml: > > Catalog: contacted Oasis. The standard page (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF version. That is what I'm using now, replacing the html pages. Not ideal, but at least it's displayed within the browser rather than downloaded as the html version did. > > QName: rewrote the javadocs. This pull request has now been integrated. Changeset: 471d63c9 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/471d63c91f9fdc9468cb4d483a242511bad026da Stats: 95 lines in 7 files changed: 2 ins; 42 del; 51 mod 8343609: Broken links in java.xml Reviewed-by: naoto, lancea, iris ------------- PR: https://git.openjdk.org/jdk/pull/23242 From lmesnik at openjdk.org Fri Jan 24 01:14:35 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 24 Jan 2025 01:14:35 GMT Subject: RFR: 8318098: Update jfr tests to replace keyword jfr with vm.flagless Message-ID: A lot of jfr tests are very specific. Currently all of them are marked with jfr keyword and excluded when VM flags are set. It makes sense to mark them with @requires to be complaint with all other openjdk tests. The next step is to review tests and remove vm.flagless from tests that should be executed with different VM flags. Bug https://bugs.openjdk.org/browse/JDK-8318097 is filed for this activity. ------------- Commit messages: - 8318098: Update jfr tests to replace keyword jfr with vm.flagless Changes: https://git.openjdk.org/jdk/pull/23285/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23285&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318098 Stats: 1090 lines in 582 files changed: 2 ins; 0 del; 1088 mod Patch: https://git.openjdk.org/jdk/pull/23285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23285/head:pull/23285 PR: https://git.openjdk.org/jdk/pull/23285 From shade at openjdk.org Fri Jan 24 07:09:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 24 Jan 2025 07:09:51 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: <1b5VRpKPgM2EGuxUuIfypPqdaAQCUiPYSb9es1R7jVE=.b96b6d9f-4165-4014-9325-92dc14a8016d@github.com> On Fri, 24 Jan 2025 00:09:00 GMT, Brent Christian wrote: >> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: >> >> - No instantiation for BufferCleaner, javadocs >> - Remove hasReferencePendingList >> - Revert test exclusion, moved to JDK-8348301 > > src/java.base/share/classes/java/nio/Bits.java line 151: > >> 149: // Trigger GC to perform reference processing and then cleaning. >> 150: canary = BufferCleaner.newCanary(); >> 151: System.gc(); > > So the Canary functions only to avoid calling `System.gc()` again if we've not yet seen progress from the previous call to `System.gc()`. Is that right? Yes. There is no point in flooding the JVM with GC requests if Cleaner have not responded yet. It is, by nature, similar to the waiting for pending reference processing hack we had before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1928186438 From asotona at openjdk.org Fri Jan 24 07:27:49 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 24 Jan 2025 07:27:49 GMT Subject: RFR: 8348283: java.lang.classfile.components.snippets.PackageSnippets shipped in java.base.jmod In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 07:14:42 GMT, Adam Sotona wrote: > JDK-8345486 moved java.lang.classfile.components.snippet-files.PackageSnippets to jdk.internal.classfile.components.snippet-files folder. However change of the package name declared in the snippet file was omitted. > > Please review. > > Thank you, > Adam Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23254#issuecomment-2611778830 From asotona at openjdk.org Fri Jan 24 07:27:49 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 24 Jan 2025 07:27:49 GMT Subject: Integrated: 8348283: java.lang.classfile.components.snippets.PackageSnippets shipped in java.base.jmod In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 07:14:42 GMT, Adam Sotona wrote: > JDK-8345486 moved java.lang.classfile.components.snippet-files.PackageSnippets to jdk.internal.classfile.components.snippet-files folder. However change of the package name declared in the snippet file was omitted. > > Please review. > > Thank you, > Adam This pull request has now been integrated. Changeset: 2daafe49 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/2daafe49c7883d224b6dc45d934cfde9101edaa1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8348283: java.lang.classfile.components.snippets.PackageSnippets shipped in java.base.jmod Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/23254 From asotona at openjdk.org Fri Jan 24 08:19:45 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 24 Jan 2025 08:19:45 GMT Subject: [jdk24] RFR: 8342466: Improve API documentation for java.lang.classfile.attribute In-Reply-To: <59Vo0cAaCMCzjMNZMNlZWTtmz3WxtEEPHOcIVAhS66Q=.9cc8e72c-09f2-4138-aa1e-6c9a399f2ef1@github.com> References: <59Vo0cAaCMCzjMNZMNlZWTtmz3WxtEEPHOcIVAhS66Q=.9cc8e72c-09f2-4138-aa1e-6c9a399f2ef1@github.com> Message-ID: On Thu, 23 Jan 2025 16:55:20 GMT, Chen Liang wrote: > This is a non-clean backport the java.lang.classfile.attribute documentation improvements 973c630777d4075bc85c7ddc1eb02cc65904344d to JDK 24 , the release where the API is finalized. Also backported a tier1 docs build hotfix 28e01e6559a79720d03355444a4e1c1fbf0b0373 for the broken links. > > No related failure in tier 1-3 on all platforms. Marked as reviewed by asotona (Reviewer). Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23273#pullrequestreview-2571988001 PR Review: https://git.openjdk.org/jdk/pull/23273#pullrequestreview-2571990098 From aturbanov at openjdk.org Fri Jan 24 08:38:46 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 24 Jan 2025 08:38:46 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v3] In-Reply-To: References: <-8D25Trp1PhvgxTPRGw1l-6euL3ZpX6pOJCAMx6OU94=.00faa9e8-8639-465e-807f-a788703bd602@github.com> Message-ID: <46Kr8dEXCGaQtA3fPLsH2O-DkIF9NjTFZdq1MPYCE-Q=.a559c504-367f-4065-b379-1507274212cc@github.com> On Thu, 23 Jan 2025 22:48:17 GMT, Chen Liang wrote: >> Right, it can be removed. Actually, I think `getAvailableIDs()` and `getAvailableIDs(int)` also do not need to be synchronized. The internal IDs are eagerly initialized in the static block of `ZoneInfoFile.java` and are effectively final and not modified. > > Yep; their synchronized are incorrect. The object monitor lock should have been on `ZoneInfoFile.class` to be effective. Related PR waiting for review - https://github.com/openjdk/jdk/pull/17441 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23251#discussion_r1928323534 From raffaello.giulietti at oracle.com Fri Jan 24 09:39:00 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Fri, 24 Jan 2025 10:39:00 +0100 Subject: Adding BigDecimal.valueOf(float val) constructor In-Reply-To: References: Message-ID: <58a7f920-03cd-4c08-bf00-c9b2ca044fe2@oracle.com> Hi Jan, to add to the other replies, it's a bit unfortunate that the doc of valueOf(double) suggests that this method should preferably be used to convert _float_ values as well. You are right that your valueOf(float) would be a better fit, but again, that's hardly possible for source compatibility reasons after more than 20 years of valueOf(double) existence. Recompiling an existing source code that happens to invoke valueOf(double) with a float argument would suddenly change behavior for no apparent reasons. One way out would be to add your method with a different name, like valueOfFloat(float) or similar, which would however break a long naming tradition of valueOf() conversion methods. Greetings Raffaello On 2025-01-23 22:20, Jan Kowalski wrote: > Hi! > > I?m currently working on a project that heavily relies on float values, > and we occasionally use BigDecimal for more precise mathematical > operations. However, I?ve noticed that the current BigDecimal > constructor implementation only supports double, which can lead to > unintentional type conversion and precision loss when creating a > BigDecimal from a float. > > The documentation suggests using BigDecimal.valueOf(double val) as the > preferred method for converting double or float values to BigDecimal, > but since method takes double as an argument, it leads much more often > to precision loss when float is passed. > > For example: > > - BigDecimal.valueOf(0.1d) correctly produces 0.1. > > - However, BigDecimal.valueOf(0.1f) produces 0.10000000149011612, which > introduces unwanted precision artifacts. > > What would you think about introducing a static factory method > specifically for float values, such as: > > public static BigDecimal valueOf(float val) { > ? ? return new BigDecimal(Float.toString(val)); > } > > This addition should improve usability and ensure that float values are > handled more precisely within the BigDecimal API From jbhateja at openjdk.org Fri Jan 24 10:39:34 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 24 Jan 2025 10:39:34 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v12] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Rebasing to jdk mainline - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103 - Refining IR match rule - Review suggestions incorporated. - Review comments resolutions - Updating copyright year of modified files. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103 - Review suggestions incorporated. - Review comments resolutions - Addressing review comments - ... and 4 more: https://git.openjdk.org/jdk/compare/4a375e5b...e0602c1d ------------- Changes: https://git.openjdk.org/jdk/pull/22754/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=11 Stats: 2864 lines in 56 files changed: 2797 ins; 0 del; 67 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From jbhateja at openjdk.org Fri Jan 24 10:39:34 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 24 Jan 2025 10:39:34 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 16:02:55 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review suggestions incorporated. > test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java Hi @eme64 , Rebased to the latest mainline code please proceed with test runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2612203710 From hannesw at openjdk.org Fri Jan 24 10:58:24 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 24 Jan 2025 10:58:24 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: > Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. > > [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 > > For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. > > Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Update @serialData text to CSR-approved version ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22980/files - new: https://git.openjdk.org/jdk/pull/22980/files/c4be23a7..b686fb10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22980&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22980&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22980/head:pull/22980 PR: https://git.openjdk.org/jdk/pull/22980 From jan7493 at gmail.com Fri Jan 24 11:11:41 2025 From: jan7493 at gmail.com (Jan Kowalski) Date: Fri, 24 Jan 2025 12:11:41 +0100 Subject: Adding BigDecimal.valueOf(float val) constructor In-Reply-To: References: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Thank you all for your replies! I'm aware of the workaround (we are using this approach in our project) and the problematic issues with decimal conversions. However, I also think that we should make sure that the behaviour of the code is more predictable. For me and other developers, it might be confusing that values of *new BigDecimal(Float.toString(val))*, and then *BigDecimal.valueOf(double val)* are different. I'd say that, if it's possible, we should reduce the arithmetic artifacts, rather than introduce them through not really needed, and not visible at the first sight, type conversions. Unfortunately, I was aware about potential backwards compatibility issues and I was curious what is your opinion on this (I also thought about introducing a factory method like fromFloat to eliminate it, but I'm not sure if it sounds like a good idea). Do you think introducing such change would be beneficial to simplify the code, or rather introduce minor precision improvement, while we still don't have 100% decimal precision? Also out of curiosity I ran a benchmark on how lack of this constructor impacts performance, and it seems like type conversion makes it around 7 times slower, than direct Float usage @Benchmark public void oldApiFloat(Blackhole blackhole) { for (int i = 0; i < iterations; i++) { blackhole.consume(BigDecimal.valueOf(0.1f)); } } @Benchmark public void newApiFloat(Blackhole blackhole) { for (int i = 0; i < iterations; i++) { blackhole.consume(valueOf(0.1f)); } } public static BigDecimal valueOf(float val) { return new BigDecimal(Float.toString(val)); } Benchmark (iterations) Mode Cnt Score Error Units BigDecimalBenchmark.newApiFloat 1000 thrpt 25 28355,359 ? 502,195 ops/s BigDecimalBenchmark.newApiFloat 2000 thrpt 25 14132,275 ? 206,593 ops/s BigDecimalBenchmark.newApiFloat 5000 thrpt 25 5667,007 ? 71,941 ops/s BigDecimalBenchmark.newApiFloat 10000 thrpt 25 2808,114 ? 32,403 ops/s BigDecimalBenchmark.newApiFloat 100000 thrpt 25 278,405 ? 4,642 ops/s BigDecimalBenchmark.oldApiFloat 1000 thrpt 25 3559,235 ? 40,931 ops/s BigDecimalBenchmark.oldApiFloat 2000 thrpt 25 1782,190 ? 21,805 ops/s BigDecimalBenchmark.oldApiFloat 5000 thrpt 25 712,045 ? 6,495 ops/s BigDecimalBenchmark.oldApiFloat 10000 thrpt 25 355,959 ? 6,006 ops/s BigDecimalBenchmark.oldApiFloat 100000 thrpt 25 36,239 ? 0,423 ops/s pt., 24 sty 2025 o 00:59 Joseph D. Darcy napisa?(a): > On 1/23/2025 2:35 PM, Remi Forax wrote: > > Hello Jan, > what you are suggesting is not a backward compatible change. > > > There is a source compatibility impact, meaning that for some call sites, > the mapping of existing code using BigDecimal before and after the addition > of the overloaded method would change. That wouldn't necessarily preclude > us from making such a change (and such changes have been made in the past), > but extra caution and analysis would be called for. > > Cheers, > > -Joe > > > > If we add BigDecimal,valueOf(float), then a program recompiled with the > new JDK may change its behavior, > you can think that the new behavior is more "correct" that the current > one, but changing the behavior of existing programs is usually a big NO ! > in Java. > > Also, I believe that the reason there is no such factory method that takes > a float is that doing computations on floats is not recommanded, it becomes > a mess rapidly of the imprecision of the float32 representation, . > For the same reason, in Java, 2.0 is a double and there is no FloatStream > while there is a DoubleStream. > > regards, > R?mi > > ------------------------------ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Fri Jan 24 11:32:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 24 Jan 2025 11:32:56 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: On Thu, 23 Jan 2025 08:51:38 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [ ] Linux x86_64 server fastdebug, `all` >> - [ ] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: > > - No instantiation for BufferCleaner, javadocs > - Remove hasReferencePendingList > - Revert test exclusion, moved to JDK-8348301 Testing is still clean on my side. I would appreciate if folks can run this through their CIs. I am planning to integrate this on Monday, as long as we discover no new issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2612301921 From raffaello.giulietti at oracle.com Fri Jan 24 11:42:16 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Fri, 24 Jan 2025 12:42:16 +0100 Subject: Adding BigDecimal.valueOf(float val) constructor In-Reply-To: References: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hi Jan, just to note that the benchmark results only measure the case 0.1f. For more general floats, the perf gains might look less impressive (but I didn't check). Anyway, a fresh name seems to be the less risky solution, if we agree that the problem is widespread enough to justify adding the new fromFloat() factory method. R On 2025-01-24 12:11, Jan Kowalski wrote: > Thank you all for your replies! > > I'm aware of the workaround (we are using this approach in our project) > and the problematic issues with decimal conversions. However, I also > think that we should make sure that the behaviour of the code is more > predictable. For me and other developers, it might be confusing that > values of /new BigDecimal(Float.toString(val))/, and then / > BigDecimal.valueOf(double val)/?are different. I'd say that, if it's > possible, we should reduce the arithmetic artifacts, rather than > introduce them through not really needed, and not visible at the first > sight, type conversions. > > Unfortunately, I was aware about potential backwards compatibility > issues and I was curious what is your opinion on this (I also thought > about introducing a factory method like fromFloat to eliminate it, but > I'm not sure if it sounds like a good idea). Do you think introducing > such change would be beneficial to simplify the code, or rather > introduce minor precision improvement, while we still don't have 100% > decimal precision? > > Also out of curiosity I ran a benchmark on how lack of this constructor > impacts performance, and it seems like type conversion makes it around 7 > times slower, than direct Float usage > > ? ? @Benchmark > ? ? public void oldApiFloat(Blackhole blackhole) { > ? ? ? ? for (int i = 0; i < iterations; i++) { > ? ? ? ? ? ? blackhole.consume(BigDecimal.valueOf(0.1f)); > ? ? ? ? } > ? ? } > > ? ? @Benchmark > ? ? public void newApiFloat(Blackhole blackhole) { > ? ? ? ? for (int i = 0; i < iterations; i++) { > ? ? ? ? ? ? blackhole.consume(valueOf(0.1f)); > ? ? ? ? } > ? ? } > > ? ? public static BigDecimal valueOf(float val) { > ? ? ? ? return new BigDecimal(Float.toString(val)); > ? ? } > > > ? ? Benchmark? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(iterations) Mode > ?Cnt? ? Score? ? ? ? ? ?Error ?Units > BigDecimalBenchmark.newApiFloat ? ? ? ? ?1000 ?thrpt ? 25 ?28355,359 ? > 502,195 ?ops/s > BigDecimalBenchmark.newApiFloat ? ? ? ? ?2000 ?thrpt ? 25 ?14132,275 ? > 206,593 ?ops/s > BigDecimalBenchmark.newApiFloat ? ? ? ? ?5000 ?thrpt ? 25 ? 5667,007 ? > ?71,941 ?ops/s > BigDecimalBenchmark.newApiFloat ? ? ? ? 10000 ?thrpt ? 25 ? 2808,114 ? > ?32,403 ?ops/s > BigDecimalBenchmark.newApiFloat ? ? ? ?100000 ?thrpt ? 25 ? ?278,405 ? > 4,642 ?ops/s > BigDecimalBenchmark.oldApiFloat ? ? ? ? ?1000 ?thrpt ? 25 ? 3559,235 ? > ?40,931 ?ops/s > BigDecimalBenchmark.oldApiFloat ? ? ? ? ?2000 ?thrpt ? 25 ? 1782,190 ? > ?21,805 ?ops/s > BigDecimalBenchmark.oldApiFloat ? ? ? ? ?5000 ?thrpt ? 25 ? ?712,045 ? > 6,495 ?ops/s > BigDecimalBenchmark.oldApiFloat ? ? ? ? 10000 ?thrpt ? 25 ? ?355,959 ? > 6,006 ?ops/s > BigDecimalBenchmark.oldApiFloat ? ? ? ?100000 ?thrpt ? 25 ? ? 36,239 ? > 0,423 ?ops/s > > pt., 24 sty 2025 o 00:59?Joseph D. Darcy > napisa?(a): > > __ > On 1/23/2025 2:35 PM, Remi Forax wrote: >> Hello Jan, >> what you are suggesting is not a backward compatible change. > > > There is a source compatibility impact, meaning that for some call > sites, the mapping of existing code using BigDecimal before and > after the addition of the overloaded method would change. That > wouldn't necessarily preclude us from making such a change (and such > changes have been made in the past), but extra caution and analysis > would be called for. > > Cheers, > > -Joe > > >> >> If we add BigDecimal,valueOf(float), then a program recompiled >> with the new JDK may change its behavior, >> you can think that the new behavior is more "correct" that the >> current one, but changing the behavior of existing programs is >> usually a big NO ! in Java. >> >> Also, I believe that the reason there is no such factory method >> that takes a float is that doing computations on floats is not >> recommanded, it becomes a mess rapidly of the imprecision of the >> float32 representation, . >> For the same reason, in Java, 2.0 is a double and there is no >> FloatStream while there is a DoubleStream. >> >> regards, >> R?mi >> >> ------------------------------------------------------------------------ > From maurizio.cimadamore at oracle.com Fri Jan 24 11:50:27 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 24 Jan 2025 11:50:27 +0000 Subject: New candidate JEP: 502: Stable Values (Preview) In-Reply-To: References: <20250122151005.3CB71787B60@eggemoggin.niobe.net> Message-ID: <4eb86dce-e930-4f1a-a46f-3c142af672c7@oracle.com> Hi Alan, I think it's fair to say that the StableValue API is a safe view of the `@Stable` JVM internal annotation that has been around for quite some time. If you look inside the JDK code, you will see that `@Stable` is used frequently in conjunction with lazily populated caches of method handles and var handles, as that's where it gives most benefits (method handles like to be constant, but deferred init makes constant-ness impossible). While we started working on this for MH/VH-related use cases (for instance, FFM's jextract will be a big user of stable values), we also realized that this abstraction is actually quite useful in other cases too. The class holder idiom is quite widespread when it comes to lazy init. I think the StableValue gives you a more elegant way to do this (although, yes, maybe not as elegant as a keyword). While we're not shy of making language changes, we need to be absolutely certain that such language changes are required. This often requires consideration that are not merely syntactic -- e.g. because saying `lazy Foo` is better than saying `StableValue` -- but ones affecting semantics (e.g. does having a keywod make some shifting of computation that would otherwise not be possible with an API approach) ? I think John's email on leyden-dev pains some broad strokes of what such an evolution would look like: https://mail.openjdk.org/pipermail/leyden-dev/2025-January/001283.html My personal opinion is that an API like StableValue would be the building block of any language feature that will provide laziness. E.g. consider a lazy _instance_ field. How would we make sure that such a field is updated at-most-once, and atomically across multiple threads? In such cases having something like StableValue seems unavoidable (unless one would like to push all this complexity down to the JVM level, which I'm not sure buys much). So, while I can imagine a world where _direct_ use of StableValue becomes more niche, I don't think StableValue will really become "obsolete". I also believe we're at the beginning of this story -- and we're still learning of what we can do with stable values. A fruitful avenue of exploration will likely be trying to plug stable values in the innards of existing dependency injection frameworks. This is another example of how _indirect_ use of stable values might benefit the wider ecosystem. Maurizio On 22/01/2025 21:53, Alan Snyder wrote: > The JEP describes StableValue as a step towards deferred immutability, defined as: > > "What we are missing is a way to promise that a field will be initialized by the time it is used, with a value that is computed at most once and, furthermore, safely with respect to concurrency. In other words, we need a way to defer immutability.? > > What is the roadmap for getting the rest of the way? > > StableValue looks to me like an implementation mechanism, something that someday the compiler and JVM might use. > It does not look like something I would want to use in my source code. > If introduced as a public API, will StableValue be obsolete soon thereafter? > > > > > >> On Jan 22, 2025, at 7:10?AM, Mark Reinhold wrote: >> >> https://openjdk.org/jeps/502 >> >> Summary: Introduce an API for stable values, which are objects that >> hold immutable data. Stable values are treated as constants by the >> JVM, enabling the same performance optimizations that are enabled >> by declaring a field final. Compared to final fields, however, >> stable values offer greater flexibility as to the timing of their >> initialization. This is a preview API. >> >> - Mark From mcimadamore at openjdk.org Fri Jan 24 11:59:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 24 Jan 2025 11:59:47 GMT Subject: RFR: 8345687: Improve the implementation of SegmentFactories::allocateSegment [v3] In-Reply-To: <4T4xAZGj1lmd8-KBdRCsBF5oltxC0mQzseUIJGTKaCE=.f71ab6fc-a247-45af-9000-9d1288bdf5d4@github.com> References: <5bAs8hhqvy-c776n0_9Xqw6n8quA-c_a59ii-nWFhuE=.2eae9a1b-b46a-4626-9ac5-3ee35a34b82c@github.com> <4T4xAZGj1lmd8-KBdRCsBF5oltxC0mQzseUIJGTKaCE=.f71ab6fc-a247-45af-9000-9d1288bdf5d4@github.com> Message-ID: <_wjpvTZLmQbjFr0fWIJnB8hyZo0PDFnfnmTDeh7ujXo=.64334ac1-d6bd-45f3-a1c3-a4da05053768@github.com> On Wed, 22 Jan 2025 16:45:39 GMT, Quan Anh Mai wrote: >> test/micro/org/openjdk/bench/java/lang/foreign/AllocTest.java line 77: >> >>> 75: var freeAddr = lookup.findOrThrow("free"); >>> 76: CALLOC = linker.downcallHandle(callocAddr, FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG, ValueLayout.JAVA_LONG)); >>> 77: FREE = linker.downcallHandle(freeAddr, FunctionDescriptor.ofVoid(ValueLayout.JAVA_LONG)); >> >> I'm not sure these changes are needed. It seems the main goal here is to avoid the cost of the capture associated with `CLayouts::freeMemory` ? If so, can't we just store that consumer into a static final and call it a day? I think then we could avoid the `static` init, and leave most of the code unchanged, except for the additional static field? > > The main goal here is that passing/receiving raw addresses as longs is cheaper than as `MemorySegment`s. But the address is immediately converted to memory segment using MemorySegment::ofAddress, which is what the linker does anyway? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22610#discussion_r1928571827 From hannesw at openjdk.org Fri Jan 24 14:42:47 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 24 Jan 2025 14:42:47 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 16:16:03 GMT, Hannes Walln?fer wrote: >> There's not a great number of "good" examples of this in the JDK, so probably OK except it >> seems like most cases will do it like a normal javadoc method so you'd want an @param tag too. >> >> note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others > > I've created a CSR with a slightly modified version of the text proposed in this PR: > https://bugs.openjdk.org/browse/JDK-8348408 > > Other doc tags such as `@param` and `@throws` are inherited from the overridden method. Also, this is the only change in this PR that modifies the serialization spec. CSR was approved, and I updated the PR with the slightly modified spec text from the CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1928785006 From jan7493 at gmail.com Fri Jan 24 14:44:26 2025 From: jan7493 at gmail.com (Jan Kowalski) Date: Fri, 24 Jan 2025 15:44:26 +0100 Subject: Adding BigDecimal.valueOf(float val) constructor In-Reply-To: References: <7E17AB44-D674-4C0B-AF71-BF92A350A22C@oracle.com> <1595099054.75679369.1737671712186.JavaMail.zimbra@univ-eiffel.fr> Message-ID: I ran the benchmark once again for a smaller float, and a bigger float, and seems like suggested implementation still outperforms current one, however as the number grows the difference seems to be less significant. Benchmark (iterations) (value) Mode Cnt Score Error Units BigDecimalBenchmark.newApiFloat 1000 111.111f thrpt 25 11609,412 ? 51,333 ops/s BigDecimalBenchmark.newApiFloat 1000 1343453.2344f thrpt 25 10081,560 ? 74,885 ops/s BigDecimalBenchmark.oldApiFloat 1000 111.111f thrpt 25 4325,049 ? 40,065 ops/s BigDecimalBenchmark.oldApiFloat 1000 1343453.2344f thrpt 25 7228,148 ? 78,640 ops/s For value 111.111f suggested constructor outperformed current implementation by 2.68 times, but for value 1343453.2344f 1.4 times. I still think it's a change that might be worthwhile (but without breaking backwards compatbility of course), especially considering the original issue, which was a precision loss when converting float to big decimal through valueOf. pt., 24 sty 2025 o 12:11 Jan Kowalski napisa?(a): > Thank you all for your replies! > > I'm aware of the workaround (we are using this approach in our project) > and the problematic issues with decimal conversions. However, I also think > that we should make sure that the behaviour of the code is more > predictable. For me and other developers, it might be confusing that values > of *new BigDecimal(Float.toString(val))*, and then *BigDecimal.valueOf(double > val)* are different. I'd say that, if it's possible, we should reduce the > arithmetic artifacts, rather than introduce them through not really needed, > and not visible at the first sight, type conversions. > > Unfortunately, I was aware about potential backwards compatibility issues > and I was curious what is your opinion on this (I also thought about > introducing a factory method like fromFloat to eliminate it, but I'm not > sure if it sounds like a good idea). Do you think introducing such change > would be beneficial to simplify the code, or rather introduce minor > precision improvement, while we still don't have 100% decimal precision? > > Also out of curiosity I ran a benchmark on how lack of this constructor > impacts performance, and it seems like type conversion makes it around 7 > times slower, than direct Float usage > > @Benchmark > public void oldApiFloat(Blackhole blackhole) { > for (int i = 0; i < iterations; i++) { > blackhole.consume(BigDecimal.valueOf(0.1f)); > } > } > > @Benchmark > public void newApiFloat(Blackhole blackhole) { > for (int i = 0; i < iterations; i++) { > blackhole.consume(valueOf(0.1f)); > } > } > > public static BigDecimal valueOf(float val) { > return new BigDecimal(Float.toString(val)); > } > > > Benchmark (iterations) Mode Cnt > Score Error Units > BigDecimalBenchmark.newApiFloat 1000 thrpt 25 28355,359 ? > 502,195 ops/s > BigDecimalBenchmark.newApiFloat 2000 thrpt 25 14132,275 ? > 206,593 ops/s > BigDecimalBenchmark.newApiFloat 5000 thrpt 25 5667,007 ? > 71,941 ops/s > BigDecimalBenchmark.newApiFloat 10000 thrpt 25 2808,114 ? > 32,403 ops/s > BigDecimalBenchmark.newApiFloat 100000 thrpt 25 278,405 ? > 4,642 ops/s > BigDecimalBenchmark.oldApiFloat 1000 thrpt 25 3559,235 ? > 40,931 ops/s > BigDecimalBenchmark.oldApiFloat 2000 thrpt 25 1782,190 ? > 21,805 ops/s > BigDecimalBenchmark.oldApiFloat 5000 thrpt 25 712,045 ? > 6,495 ops/s > BigDecimalBenchmark.oldApiFloat 10000 thrpt 25 355,959 ? > 6,006 ops/s > BigDecimalBenchmark.oldApiFloat 100000 thrpt 25 36,239 ? > 0,423 ops/s > > pt., 24 sty 2025 o 00:59 Joseph D. Darcy > napisa?(a): > >> On 1/23/2025 2:35 PM, Remi Forax wrote: >> >> Hello Jan, >> what you are suggesting is not a backward compatible change. >> >> >> There is a source compatibility impact, meaning that for some call sites, >> the mapping of existing code using BigDecimal before and after the addition >> of the overloaded method would change. That wouldn't necessarily preclude >> us from making such a change (and such changes have been made in the past), >> but extra caution and analysis would be called for. >> >> Cheers, >> >> -Joe >> >> >> >> If we add BigDecimal,valueOf(float), then a program recompiled with the >> new JDK may change its behavior, >> you can think that the new behavior is more "correct" that the current >> one, but changing the behavior of existing programs is usually a big NO ! >> in Java. >> >> Also, I believe that the reason there is no such factory method that >> takes a float is that doing computations on floats is not recommanded, it >> becomes a mess rapidly of the imprecision of the float32 representation, . >> For the same reason, in Java, 2.0 is a double and there is no FloatStream >> while there is a DoubleStream. >> >> regards, >> R?mi >> >> ------------------------------ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Fri Jan 24 14:48:56 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 24 Jan 2025 14:48:56 GMT Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 13:02:34 GMT, Andrey Turbanov wrote: >> There are 3 methods in `java.util.TimeZone` which are `public static` and marked as `synchronized`: >> 1. getTimeZone(String) >> 2. getAvailableIDs(int) >> 3. getAvailableIDs() >> >> This means it is a bottle neck for the whole VM. >> I've checked the implementation and concluded that `synchronized` is unnecessary. > > Andrey Turbanov 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 remote-tracking branch 'refs/remotes/origin/master' into JDK-8291027-TimeZone-synchronized > > # Conflicts: > # src/java.base/share/classes/java/util/TimeZone.java > - 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily Looks good. synchronized modifier is not reflected in Javadoc, so I think we are fine without a CSR. @naotoj can you review too, since the synchronizations here are invalid and keeping them is for no good? ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17441#pullrequestreview-2572841189 From liach at openjdk.org Fri Jan 24 14:59:55 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 24 Jan 2025 14:59:55 GMT Subject: [jdk24] RFR: 8342466: Improve API documentation for java.lang.classfile.attribute In-Reply-To: <59Vo0cAaCMCzjMNZMNlZWTtmz3WxtEEPHOcIVAhS66Q=.9cc8e72c-09f2-4138-aa1e-6c9a399f2ef1@github.com> References: <59Vo0cAaCMCzjMNZMNlZWTtmz3WxtEEPHOcIVAhS66Q=.9cc8e72c-09f2-4138-aa1e-6c9a399f2ef1@github.com> Message-ID: On Thu, 23 Jan 2025 16:55:20 GMT, Chen Liang wrote: > This is a non-clean backport the java.lang.classfile.attribute documentation improvements 973c630777d4075bc85c7ddc1eb02cc65904344d to JDK 24 , the release where the API is finalized. Also backported a tier1 docs build hotfix 28e01e6559a79720d03355444a4e1c1fbf0b0373 for the broken links. > > No related failure in tier 1-3 on all platforms. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23273#issuecomment-2612727749 From liach at openjdk.org Fri Jan 24 14:59:56 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 24 Jan 2025 14:59:56 GMT Subject: [jdk24] Integrated: 8342466: Improve API documentation for java.lang.classfile.attribute In-Reply-To: <59Vo0cAaCMCzjMNZMNlZWTtmz3WxtEEPHOcIVAhS66Q=.9cc8e72c-09f2-4138-aa1e-6c9a399f2ef1@github.com> References: <59Vo0cAaCMCzjMNZMNlZWTtmz3WxtEEPHOcIVAhS66Q=.9cc8e72c-09f2-4138-aa1e-6c9a399f2ef1@github.com> Message-ID: On Thu, 23 Jan 2025 16:55:20 GMT, Chen Liang wrote: > This is a non-clean backport the java.lang.classfile.attribute documentation improvements 973c630777d4075bc85c7ddc1eb02cc65904344d to JDK 24 , the release where the API is finalized. Also backported a tier1 docs build hotfix 28e01e6559a79720d03355444a4e1c1fbf0b0373 for the broken links. > > No related failure in tier 1-3 on all platforms. This pull request has now been integrated. Changeset: 564e0a20 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/564e0a20763486cfc7bfce7cb14b2f947c69d8df Stats: 2561 lines in 70 files changed: 1594 ins; 125 del; 842 mod 8342466: Improve API documentation for java.lang.classfile.attribute 8347762: ClassFile attribute specification refers to non-SE modules Reviewed-by: asotona Backport-of: 973c630777d4075bc85c7ddc1eb02cc65904344d ------------- PR: https://git.openjdk.org/jdk/pull/23273 From asotona at openjdk.org Fri Jan 24 15:01:47 2025 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 24 Jan 2025 15:01:47 GMT Subject: RFR: 8342465: Improve API documentation for java.lang.classfile In-Reply-To: References: Message-ID: <9Lngs1-gEktO8gxO-PvajEDUkVEnUP34eZ9AiCHgvIg=.1369d0d7-1c13-48ed-a062-4e1111c75770@github.com> On Thu, 23 Jan 2025 19:48:55 GMT, Chen Liang wrote: > This is the last piece in the API documentation improvement of the Class-File API. > > This includes general documentation about transforms, models (and traversals), options, constants, and CodeBuilder factories. In particular, this preserves the package summary to avoid extra disruptions. See the APIDiff for more details. > > Please forgive this messy commit history; the work began before attribute changes were integrated and based off that, and in the process there were a few merges back and forth. > The files changed/webrev should be reliable. > > Please review the associated CSR as well. > > Note that this intends to be backported to 24; this won't be clean, as the `JAVA_25_VERSION` constant is a new addition that does not exist on 24. > > Testing: Tier 1-3. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-overall/java.base/java/lang/classfile/package-summary.html > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-overall/java.base/java/lang/classfile/package-summary.html Great job, thank you! ------------- Marked as reviewed by asotona (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23277#pullrequestreview-2572145988 From mcimadamore at openjdk.org Fri Jan 24 15:47:55 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 24 Jan 2025 15:47:55 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test The additional warnings seem to be creating some confusion among new adopters of the script ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2612836407 From jvernee at openjdk.org Fri Jan 24 15:50:47 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 24 Jan 2025 15:50:47 GMT Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 18:23:01 GMT, Volodymyr Paprotski wrote: >> Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace > > src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 185: > >> 183: // On ECore, restore with signaling flags enabled >> 184: MxCsr |= 0x3F; >> 185: } > > @JornVernee I came across your comment https://github.com/openjdk/jdk/pull/14523/files#r1236920072 > > I believe I am following the 'spirit' of that comment here, but would appreciate you having a look. Yes, I think so. Originally I was seeing some cases where we were always resetting MxCsr, even for unrelated exceptions. The new code still only resets it for the FLT_* exceptions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22673#discussion_r1928894440 From ihse at openjdk.org Fri Jan 24 16:38:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 24 Jan 2025 16:38:53 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: On Fri, 24 Jan 2025 15:45:19 GMT, Maurizio Cimadamore wrote: > The additional warnings seem to be creating some confusion among new adopters of the script Ok, that's bad. I'll fix it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2612943000 From ihse at openjdk.org Fri Jan 24 17:11:52 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 24 Jan 2025 17:11:52 GMT Subject: RFR: 8347825: Make IDEA ide support use proper build system mechanisms [v2] In-Reply-To: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> References: <5daucv0V888YTfU5EzKc09L6IjAn2rMTJ4yZEFHkHHk=.50b1e6a1-56b1-47da-8b7c-dedb4a4181aa@github.com> Message-ID: On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote: >> The idea.sh script which creates a configuration for IDEA does at some point call a makefile, to extract information from the build system. However, this is done in an ad-hoc manner that does not fit properly in the build system. >> >> I ran into this as a problem when trying to implement another change, so this needs to be fixed, and should be fixed separately. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix broken make:idea test https://github.com/openjdk/jdk/pull/23302 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomment-2613008559 From ihse at openjdk.org Fri Jan 24 17:13:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 24 Jan 2025 17:13:58 GMT Subject: RFR: 8348586: Optionally silence make warnings about non-control variables Message-ID: When you set a variable on the make command line that is not a known control variable, make emits a note like this: Note: Command line contains non-control variables: * MODULES= * IDEA_OUTPUT=/mnt/h/openjdk/git-jdk2/.idea Make sure it is not mistyped, and that you intend to override this variable. 'make help' will list known control variables. Since [JDK-8347825](https://bugs.openjdk.org/browse/JDK-8347825), this happens whenever you run idea.sh, and it is confusing to users. I introduce a general way of silencing such complaints using the new control variable `ALLOW`, and start by applying it on the idea.sh script. ------------- Commit messages: - 8348586: Optionally silence make warnings about non-control variables Changes: https://git.openjdk.org/jdk/pull/23302/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23302&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348586 Stats: 14 lines in 3 files changed: 6 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23302.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23302/head:pull/23302 PR: https://git.openjdk.org/jdk/pull/23302 From ihse at openjdk.org Fri Jan 24 17:13:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 24 Jan 2025 17:13:58 GMT Subject: RFR: 8348586: Optionally silence make warnings about non-control variables In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 17:08:42 GMT, Magnus Ihse Bursie wrote: > When you set a variable on the make command line that is not a known control variable, make emits a note like this: > > > Note: Command line contains non-control variables: > * MODULES= > * IDEA_OUTPUT=/mnt/h/openjdk/git-jdk2/.idea > Make sure it is not mistyped, and that you intend to override this variable. > 'make help' will list known control variables. > > > Since [JDK-8347825](https://bugs.openjdk.org/browse/JDK-8347825), this happens whenever you run idea.sh, and it is confusing to users. > > I introduce a general way of silencing such complaints using the new control variable `ALLOW`, and start by applying it on the idea.sh script. The difference between INIT_CONTROL_VARIABLES and MAKE_CONTROL_VARIABLES had been messed up over the years, so I cleaned that up as well. Since this has worked nevertheless it is likely that this distinction is not needed (anymore?), but at any rate it is informative about where responsibility lies so I kept it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23302#issuecomment-2613013238 From rgiulietti at openjdk.org Fri Jan 24 17:23:52 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 24 Jan 2025 17:23:52 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v6] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 15:53:36 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused > - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java > > Co-authored-by: Chen Liang I believe the following implementation of `Integer.parseInt(String,int)` is correct, shorter, and more readable. On my M1 Pro, the benchmark is even slightly faster than the proposed one, but I didn't check on other platforms. The same holds for `Long.parseLong(String,int)` (simply copy the text and change the type or `result` to be `long`). Please have a look. public static int parseInt(String s, int radix) throws NumberFormatException { int len; byte[] value; if (s == null || radix != 10 || (len = (value = s.value()).length) == 0 || !s.isLatin1()) { return parseInt0(s, radix); } int fc = value[0]; int result = Integer.isDigitLatin1(fc) ? '0' - fc : len != 1 && (fc == '-' || fc == '+') ? 0 : 1; // or any value > 0 int i = 1; int d; while (i + 1 < len && (d = DecimalDigits.digit2(value, i)) != -1 && MIN_VALUE / 100 <= result) { result = result * 100 - d; // overflow from d => result > 0 i += 2; } if (i < len && Integer.isDigitLatin1(d = value[i]) && MIN_VALUE / 10 <= result && result <= 0) { result = result * 10 + '0' - d; // overflow from '0' - d => result > 0 i += 1; } if (i == len & result <= 0 & (MIN_VALUE < result || fc == '-')) { return fc == '-' ? result : -result; } throw NumberFormatException.forInputString(s); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2613033520 From naoto at openjdk.org Fri Jan 24 17:25:57 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 24 Jan 2025 17:25:57 GMT Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily [v2] In-Reply-To: References: Message-ID: <5gnLdZ6dNnCxnON5tlLKl_vyElOjBCFjR2ETxF5Y28U=.5dfa56de-28fa-4527-ac85-41dfebe53f29@github.com> On Thu, 16 Jan 2025 13:02:34 GMT, Andrey Turbanov wrote: >> There are 3 methods in `java.util.TimeZone` which are `public static` and marked as `synchronized`: >> 1. getTimeZone(String) >> 2. getAvailableIDs(int) >> 3. getAvailableIDs() >> >> This means it is a bottle neck for the whole VM. >> I've checked the implementation and concluded that `synchronized` is unnecessary. > > Andrey Turbanov 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 remote-tracking branch 'refs/remotes/origin/master' into JDK-8291027-TimeZone-synchronized > > # Conflicts: > # src/java.base/share/classes/java/util/TimeZone.java > - 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily Yes, I think this change is benign. Those synchronization was (I think) leftovers from the old refactoring (https://mail.openjdk.org/pipermail/core-libs-dev/2022-July/092860.html) Sorry for taking so long for the review. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17441#pullrequestreview-2573212778 From jlu at openjdk.org Fri Jan 24 17:58:58 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 24 Jan 2025 17:58:58 GMT Subject: RFR: 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jan 2025 13:02:34 GMT, Andrey Turbanov wrote: >> There are 3 methods in `java.util.TimeZone` which are `public static` and marked as `synchronized`: >> 1. getTimeZone(String) >> 2. getAvailableIDs(int) >> 3. getAvailableIDs() >> >> This means it is a bottle neck for the whole VM. >> I've checked the implementation and concluded that `synchronized` is unnecessary. > > Andrey Turbanov 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 remote-tracking branch 'refs/remotes/origin/master' into JDK-8291027-TimeZone-synchronized > > # Conflicts: > # src/java.base/share/classes/java/util/TimeZone.java > - 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily Looks good ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/17441#pullrequestreview-2573276256 From jlu at openjdk.org Fri Jan 24 18:00:06 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 24 Jan 2025 18:00:06 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v4] In-Reply-To: References: Message-ID: > Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. > > A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: new methods do not need to be synchronized ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23251/files - new: https://git.openjdk.org/jdk/pull/23251/files/db907223..ef3e275b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23251&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23251&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23251/head:pull/23251 PR: https://git.openjdk.org/jdk/pull/23251 From naoto at openjdk.org Fri Jan 24 18:32:48 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 24 Jan 2025 18:32:48 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v4] In-Reply-To: References: Message-ID: <_atWY1tKwxF1zZ1qGQWZgcrjcA5fwVsqdv50mMuYUIs=.c0004c71-34f7-4491-ba43-a2c0bff28845@github.com> On Fri, 24 Jan 2025 18:00:06 GMT, Justin Lu wrote: >> Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. >> >> A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > new methods do not need to be synchronized LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23251#pullrequestreview-2573335643 From rgiulietti at openjdk.org Fri Jan 24 18:45:52 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 24 Jan 2025 18:45:52 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v6] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 15:53:36 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused > - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java > > Co-authored-by: Chen Liang Correction: I forgot to add a check for `result <= 0` in the `while` condition. Without it, `Integer.parseInt("0214748369900")` wrongly returns `5100`, for example. The correction has no statistical impact on the benchmarks on my platform. public static int parseInt(String s, int radix) throws NumberFormatException { int len; byte[] value; if (s == null || radix != 10 || (len = (value = s.value()).length) == 0 || !s.isLatin1()) { return parseInt0(s, radix); } int fc = value[0]; int result = Integer.isDigitLatin1(fc) ? '0' - fc : len != 1 && (fc == '-' || fc == '+') ? 0 : 1; // or any value > 0 int i = 1; int d; while (i + 1 < len && (d = DecimalDigits.digit2(value, i)) != -1 && MIN_VALUE / 100 <= result & result <= 0) { result = result * 100 - d; // overflow from d => result > 0 i += 2; } if (i < len && Integer.isDigitLatin1(d = value[i]) && MIN_VALUE / 10 <= result & result <= 0) { result = result * 10 + '0' - d; // overflow from '0' - d => result > 0 i += 1; } if (i == len & result <= 0 & (MIN_VALUE < result || fc == '-')) { return fc == '-' ? result : -result; } throw NumberFormatException.forInputString(s); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2613166860 From swen at openjdk.org Fri Jan 24 19:02:47 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 24 Jan 2025 19:02:47 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v6] In-Reply-To: References: Message-ID: <1BRUOUe0YSHH1Ma1lmYbljZWHYDm3r9-owo56CRiRSs=.728a2332-dcb8-46e0-81e8-9561c65010a9@github.com> On Fri, 24 Jan 2025 18:42:44 GMT, Raffaello Giulietti wrote: > Correction: I forgot to add a check for `result <= 0` in the `while` condition. Without it, `Integer.parseInt("0214748369900")` wrongly returns `5100`, for example. > > The correction has no statistical impact on the benchmarks on my platform. > > ``` > public static int parseInt(String s, int radix) > throws NumberFormatException { > int len; > byte[] value; > if (s == null || radix != 10 || (len = (value = s.value()).length) == 0 || !s.isLatin1()) { > return parseInt0(s, radix); > } > int fc = value[0]; > int result = Integer.isDigitLatin1(fc) > ? '0' - fc > : len != 1 && (fc == '-' || fc == '+') > ? 0 > : 1; // or any value > 0 > int i = 1; > int d; > while (i + 1 < len > && (d = DecimalDigits.digit2(value, i)) != -1 > && MIN_VALUE / 100 <= result & result <= 0) { > result = result * 100 - d; // overflow from d => result > 0 > i += 2; > } > if (i < len > && Integer.isDigitLatin1(d = value[i]) > && MIN_VALUE / 10 <= result & result <= 0) { > result = result * 10 + '0' - d; // overflow from '0' - d => result > 0 > i += 1; > } > if (i == len > & result <= 0 > & (MIN_VALUE < result || fc == '-')) { > return fc == '-' ? result : -result; > } > throw NumberFormatException.forInputString(s); > } > ``` Why is `&` used here instead of `&&`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2613194796 From eirbjo at openjdk.org Fri Jan 24 19:31:55 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 24 Jan 2025 19:31:55 GMT Subject: RFR: 8344943: Mark not subclassable classes final in java.base exported classes [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 18:19:56 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. >> >> The classes were identified using an automated analysis. See CSR for details. >> >> Besides simply adding the `final` access modifier, the PR: >> >> * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. >> * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` >> * Updates the copyright year of affected source files > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright headers for 2025 Thanks everyone for your patient reviews in this PR. I'll integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22389#issuecomment-2613236074 From eirbjo at openjdk.org Fri Jan 24 19:31:56 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 24 Jan 2025 19:31:56 GMT Subject: Integrated: 8344943: Mark not subclassable classes final in java.base exported classes In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which adds the `final` modifier to non-subclassable classes in `java.base`. > > The classes were identified using an automated analysis. See CSR for details. > > Besides simply adding the `final` access modifier, the PR: > > * Updates a note in `java.lang.constant.DynamicCallSiteDesc` to not reference subtypes. See CSR for discussion. > * Removes the class `java.lang.Runtime` from the test `test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java` > * Updates the copyright year of affected source files This pull request has now been integrated. Changeset: 8e8f8000 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/8e8f800071851f479f9e8b493bc38c0a38165bab Stats: 47 lines in 22 files changed: 0 ins; 3 del; 44 mod 8344943: Mark not subclassable classes final in java.base exported classes Reviewed-by: weijun, liach, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/22389 From rgiulietti at openjdk.org Fri Jan 24 19:41:47 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 24 Jan 2025 19:41:47 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v6] In-Reply-To: References: Message-ID: On Tue, 14 Jan 2025 15:53:36 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - remove unused > - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java > > Co-authored-by: Chen Liang I might be wrong, but I think that `&&` are compiled down to conditionals? The code optimistically assumes that the string is parsable as an `int|long`, so `&` might lead to simpler machine code. Of course, if the benchmarks are good with `&&`, then please feel free to replace. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2613253311 From eirbjo at openjdk.org Fri Jan 24 19:42:53 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 24 Jan 2025 19:42:53 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v5] In-Reply-To: <1wf30qWLDemMhhOQbMmD_O7lUD1_Q-pdqJqHsEiYSq8=.dbf9961b-4f1e-4124-a07d-c96f71966fee@github.com> References: <1wf30qWLDemMhhOQbMmD_O7lUD1_Q-pdqJqHsEiYSq8=.dbf9961b-4f1e-4124-a07d-c96f71966fee@github.com> Message-ID: On Tue, 21 Jan 2025 16:25:34 GMT, Roger Riggs wrote: > I agree doing (in this PR) anything more than fix the link is out of scope. Good. My understanding is that we are converging on a consensus to: * Change the broken IBM AIX emprempral port link to the suggested IBM FAQ one in `PortConfig.java` * Remove the "unofficial" pasc.org link from `ProcessImpl_md.c` * Handle any other changes rooted in the discussion about signals and child processes under https://bugs.openjdk.org/browse/JDK-8348183 If reviewers agree to this, I would welcome a final review of the changes in this PR based on the above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2613254996 From duke at openjdk.org Fri Jan 24 20:14:27 2025 From: duke at openjdk.org (He-Pin (kerr)) Date: Fri, 24 Jan 2025 20:14:27 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message Message-ID: Motivation: When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. Modification: Add detail error messages. Result: Helpful messages. ------------- Commit messages: - . - chore: add messages for NPE - chore: tweak the error messages - chore: add test cases - 8347491: Add detail error messages when ThreadPoolExecutor's parameter is illegal. Changes: https://git.openjdk.org/jdk/pull/23050/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23050&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347491 Stats: 164 lines in 3 files changed: 101 ins; 0 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/23050.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23050/head:pull/23050 PR: https://git.openjdk.org/jdk/pull/23050 From duke at openjdk.org Fri Jan 24 20:14:27 2025 From: duke at openjdk.org (He-Pin (kerr)) Date: Fri, 24 Jan 2025 20:14:27 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: References: Message-ID: On Sat, 11 Jan 2025 07:10:53 GMT, He-Pin(kerr) wrote: > Motivation: > When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. > > Modification: > Add detail error messages. > > Result: > Helpful messages. @viktorklang-ora @AlanBateman @DougLea This PR is a kind of *happen before* :) I have another PR, I will wait before oca is completed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2587983639 PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2599681035 From jwaters at openjdk.org Fri Jan 24 20:14:27 2025 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 24 Jan 2025 20:14:27 GMT Subject: RFR: 8347491: IllegalArgumentationException thrown by ThreadPoolExecutor doesn't have a useful message In-Reply-To: References: Message-ID: <_CM6JuYnUWnPOorAD2xD8G6wuHBYgSIAwm9B4iQHp6Y=.e5f646a1-5202-4b29-8933-255494a6d7d3@github.com> On Sat, 11 Jan 2025 07:10:53 GMT, He-Pin(kerr) wrote: > Motivation: > When a user passes a wrong parameter, the current implementation throws an IllegalArgumentException with an error message `null`, which is not helpful. > > Modification: > Add detail error messages. > > Result: > Helpful messages. Hang tight, the verification takes a looooooong time, so it might be a while before your work is seen... ------------- PR Comment: https://git.openjdk.org/jdk/pull/23050#issuecomment-2592966205 From aturbanov at openjdk.org Fri Jan 24 20:16:51 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 24 Jan 2025 20:16:51 GMT Subject: Integrated: 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily In-Reply-To: References: Message-ID: On Tue, 16 Jan 2024 10:19:44 GMT, Andrey Turbanov wrote: > There are 3 methods in `java.util.TimeZone` which are `public static` and marked as `synchronized`: > 1. getTimeZone(String) > 2. getAvailableIDs(int) > 3. getAvailableIDs() > > This means it is a bottle neck for the whole VM. > I've checked the implementation and concluded that `synchronized` is unnecessary. This pull request has now been integrated. Changeset: bef5f565 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/bef5f56544ded9307e5f1095bd42ae46fdc2adda Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8291027: Some of TimeZone methods marked 'synchronized' unnecessarily Reviewed-by: liach, naoto, jlu ------------- PR: https://git.openjdk.org/jdk/pull/17441 From lancea at openjdk.org Fri Jan 24 20:39:50 2025 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 24 Jan 2025 20:39:50 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater In-Reply-To: References: Message-ID: <9m7nN7Dhjm_iA-zdvdR4WHqbOmeBHFb7-3xSKZq15vo=.5320abc0-4aff-48a2-84e1-3d9f86c272a7@github.com> On Fri, 19 Jul 2024 15:16:01 GMT, Lance Andersen wrote: >>> I understand the request here, but is there a current use case for needing a custom Deflater? >> >> I think the primary use case is when you want to set a non-default compression level, e.g., "best" or "fast". This is a pretty normal thing to do and matches what people expect from the `gzip(1)` command line flags. Allowing a custom `Deflater` is the simplest way to accomplish this; it also solves some other less common use cases, e.g., you want to set "no compression" for an already compressed file, or you want to keep the `Deflater` open so you can gather stats or whatever. >> >>> Before adding additional features, I think GZIP could benefit with more test coverage. >> >> Agreed. `GZIPOutputStream` does get some coverage in some of the `GZIPInputStream` tests, and this PR adds more testing, but certainly more is better. > >> > I understand the request here, but is there a current use case for needing a custom Deflater? >> >> I think the primary use case is when you want to set a non-default compression level, e.g., "best" or "fast". This is a pretty normal thing to do and matches what people expect from the `gzip(1)` command line flags. Allowing a custom `Deflater` is the simplest way to accomplish this; it also solves some other less common use cases, e.g., you want to set "no compression" for an already compressed file, or you want to keep the `Deflater` open so you can gather stats or whatever. > > thank you Archie. I don't have an issue with the feature request, but given this API has been around for since JDK 1.1 and there has not been a must have push for this enhancement, I would prefer to focus on JDK-8322256 closed out and adding more overall test coverage before tackling this. >> >> > Before adding additional features, I think GZIP could benefit with more test coverage. >> >> Agreed. `GZIPOutputStream` does get some coverage in some of the `GZIPInputStream` tests, and this PR adds more testing, but certainly more is better. > > Yes which why we should look to add additional tests, including more coverage from gzip files created via the gzip command line tool. > @LanceAndersen, if you have time now I'd like to pick this one back up. A review for the CSR is also needed. Thanks for any comments. I think it might be worth discussing the merits of whether other classes which extend DeflaterOutputStream should be given similar consideration and if consensus is reached should be addressed at the same time ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2613339129 From rriggs at openjdk.org Fri Jan 24 20:40:48 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 24 Jan 2025 20:40:48 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v5] In-Reply-To: References: Message-ID: <4reIl6A8cVFpOcjKH-OPiMCbDJG0DDoNgNg-PHAHM0Y=.8961d504-18b8-4cd1-b35a-43dfd5bb6833@github.com> On Tue, 21 Jan 2025 13:56:30 GMT, Eirik Bj?rsn?s wrote: >> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. >> >> Links in `java.security` and `share/data/tzdata` are excluded from this PR. >> >> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. >> >> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). >> >> Changes beyond the obvious are as follows: >> >> `linux/native/libsimdsort/xss-common-qsort.h`: >> The current link uses a non-default port number. Changed to using the default port number. Reported and fixed upstream as intel/x86-simd-sort#170 >> >> `share/man/keytool.md`: >> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. >> >> `unix/classes/sun/net/PortConfig.java` >> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. >> >> `unix/native/libjava/*`, >> Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs >> >> `unix/native/libjava/ProcessImpl_md.c` >> A link to an "unofficial" document on pasc.org now requires authentication. This document is probably outdated and the link is removed. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright headers for 2025 for Oracle files Thanks for the updates. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21633#pullrequestreview-2573536614 From eirbjo at openjdk.org Fri Jan 24 20:59:51 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 24 Jan 2025 20:59:51 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v3] In-Reply-To: References: Message-ID: On Thu, 2 Jan 2025 18:26:16 GMT, Archie Cobbs wrote: >> The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding. >> >> However, while `DeflaterOutputStream` provides constructors that take a custom `Deflater` argument supplied by the caller, `GZIPOutputStream` has no such constructors. >> >> As a result, it's not possible to do entirely reasonable customization, such as configuring a `GZIPOutputStream` for a non-default compression level. >> >> This change adds a new `GZIPOutputStream` constructor that accepts a custom `Deflater`, and also adds a basic unit test for it and all of the other `GZIPOutputStream` constructors, based on the existing test `BasicGZIPInputStreamTest.java` which does the same thing for `GZIPInputStream`. > > Archie Cobbs 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 six additional commits since the last revision: > > - Bump copyright year to 2025. > - Merge branch 'master' into JDK-4452735 > - Address review comments. > - Merge branch 'master' into JDK-4452735 > - Merge branch 'master' into JDK-4452735 > - Add a GZIPOutputStream() constructor that takes a Deflator. A tangential concern when allowing a custom deflater / inflater is to document the resposibility for resource management. With https://bugs.openjdk.org/browse/JDK-8225763 making Inflater/Deflater implement AutoCloseable perhaps some documentation / snippet examples could be added to document best practise for making sure a custom Deflater does not leak. See https://bugs.openjdk.org/browse/JDK-8066583 for an existing issue for DeflaterOutputStream, but I guess this is relevant for any API consuming custom Inflater/Deflaters. Maybe not for this PR to implement, but worth thinking through while considering this change I think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2613366756 From redestad at openjdk.org Fri Jan 24 21:07:52 2025 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 24 Jan 2025 21:07:52 GMT Subject: RFR: 8343962: [REDO] Move getChars to DecimalDigits [v14] In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote: >> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. >> >> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. >> >> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 >> >> 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess >> Eliminate duplicate code in BigDecimal >> >> 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. > > Shaojin Wen 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 29 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202411 > - fix comments > - use putCharUnaligned > - bug fix > - from rgiulietti > - Coding style consistency, from rgiulietti > - fix benchmark, from rgiulietti > - Coding style consistency, from rgiulietti > - fix comment > - fix comment, from @rgiulietti > - ... and 19 more: https://git.openjdk.org/jdk/compare/e9cf6b0d...be1f88ab Thanks, looks good. (I'm on temporary leave, sorry for the late response) ------------- Marked as reviewed by redestad (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22023#pullrequestreview-2573573796 From joe.darcy at oracle.com Fri Jan 24 21:12:43 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 24 Jan 2025 13:12:43 -0800 Subject: Proposal to extend Math.min and Math.max to support multiple parameters In-Reply-To: References: Message-ID: Hello Aviad, A brief reply here, there is some utility in having direct support for finding the min or max over an aggregate of data and min/max methods taking an array is something that could have been added to the platform at any point since its inception. The fact that such methods weren't added before doesn't completely rule out adding them now, but does give pause. Additionally, with streams finding the min/max is an easy operation so I would see less justification to adding array-based min/max in JDK 25+ than before streams were added in JDK 8. An analysis showing existing use of array-based min/max method as JDK-internal APIs would strengthen the case, but I believe the default solution at this point is "use streams." HTH, -Joe On 1/22/2025 9:45 PM, Aviad Zer wrote: > > Dear Core-Libs Dev Team, > > I hope this message finds you well. > > I would like to propose an enhancement to the |Math|?class to extend > the |Math.min|?and |Math.max|?methods to support multiple parameters > using varargs. This enhancement aims to improve code readability and > provide a more intuitive way to find the minimum or maximum value > among multiple numbers without requiring nested calls or external logic. > > Motivation: > Currently, developers must either nest multiple calls to |Math.min|?or > use the Streams API (|Arrays.stream(values).min()|), which can feel > cumbersome for simple cases. By introducing varargs-based > |Math.min|?and |Math.max|?methods for |int|, |long|, |float|, and > |double|, this proposal simplifies the process and aligns with the > expected functionality of these utility methods. > > Current Progress: > I have submitted a pull request for this enhancement: PR #23138 > . The PR includes: > > * Implementation of |Math.min|?and |Math.max|?with varargs for > |int|, |long|, |float|, and |double|. > > Feedback and Next Steps: > I am reaching out to gather your feedback on this proposal and > determine whether this enhancement aligns with the goals of the > core-libs. I understand that significant changes like this may require > a CSR, and I am fully prepared to follow the process once I have a > response from the community. > > Thank you for your time and consideration. I look forward to hearing > your thoughts and engaging with the community on this proposal. > > Best regards, > > Aviad Zer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Fri Jan 24 21:42:46 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 24 Jan 2025 21:42:46 +0000 Subject: Proposal to extend Math.min and Math.max to support multiple parameters In-Reply-To: References: Message-ID: On a side note, there are already Collections.min and Collections.max. We can use Collections.min(Arrays.asList(v1, v2, v3)) to find the minimum, too, and it works for antique Java versions. Regards, Chen ________________________________ From: core-libs-dev on behalf of Joseph D. Darcy Sent: Friday, January 24, 2025 3:12 PM To: Aviad Zer ; core-libs-dev at openjdk.org Subject: Re: Proposal to extend Math.min and Math.max to support multiple parameters Hello Aviad, A brief reply here, there is some utility in having direct support for finding the min or max over an aggregate of data and min/max methods taking an array is something that could have been added to the platform at any point since its inception. The fact that such methods weren't added before doesn't completely rule out adding them now, but does give pause. Additionally, with streams finding the min/max is an easy operation so I would see less justification to adding array-based min/max in JDK 25+ than before streams were added in JDK 8. An analysis showing existing use of array-based min/max method as JDK-internal APIs would strengthen the case, but I believe the default solution at this point is "use streams." HTH, -Joe On 1/22/2025 9:45 PM, Aviad Zer wrote: Dear Core-Libs Dev Team, I hope this message finds you well. I would like to propose an enhancement to the Math class to extend the Math.min and Math.max methods to support multiple parameters using varargs. This enhancement aims to improve code readability and provide a more intuitive way to find the minimum or maximum value among multiple numbers without requiring nested calls or external logic. Motivation: Currently, developers must either nest multiple calls to Math.min or use the Streams API (Arrays.stream(values).min()), which can feel cumbersome for simple cases. By introducing varargs-based Math.min and Math.max methods for int, long, float, and double, this proposal simplifies the process and aligns with the expected functionality of these utility methods. Current Progress: I have submitted a pull request for this enhancement: PR #23138. The PR includes: * Implementation of Math.min and Math.max with varargs for int, long, float, and double. Feedback and Next Steps: I am reaching out to gather your feedback on this proposal and determine whether this enhancement aligns with the goals of the core-libs. I understand that significant changes like this may require a CSR, and I am fully prepared to follow the process once I have a response from the community. Thank you for your time and consideration. I look forward to hearing your thoughts and engaging with the community on this proposal. Best regards, Aviad Zer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlu at openjdk.org Fri Jan 24 21:46:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 24 Jan 2025 21:46:51 GMT Subject: RFR: 8347498: JDK 24 RDP2 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jan 2025 18:39:47 GMT, Justin Lu wrote: >> Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. >> >> Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. >> >> Once this pull request is integrated, it will be back-ported to the jdk24 branch. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect jlink review Thank you all for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23184#issuecomment-2613427519 From jlu at openjdk.org Fri Jan 24 21:46:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 24 Jan 2025 21:46:52 GMT Subject: Integrated: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote: > Please review this PR which contains the l10n translations for between RDP1 and RDP2 for the JDK24 stabilization branch. > > Note that these translations are only associated with changes made to the stabilization branch. This PR will not include any translations for changes since RDP1, that were not back-ported to the stabilization branch. Also note that while most changes here are associated with an English change, there were some standalone translation improvements. > > Once this pull request is integrated, it will be back-ported to the jdk24 branch. This pull request has now been integrated. Changeset: dec93675 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea Stats: 93 lines in 26 files changed: 33 ins; 15 del; 45 mod 8347498: JDK 24 RDP2 L10n resource files update Reviewed-by: sgehwolf, dnguyen, naoto, joehw, asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/23184 From jlu at openjdk.org Fri Jan 24 21:57:24 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 24 Jan 2025 21:57:24 GMT Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update Message-ID: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24. The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk. ------------- Commit messages: - Backport dec93675ab3e4c271b14a254df75dc838f1346ea Changes: https://git.openjdk.org/jdk/pull/23307/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23307&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347498 Stats: 93 lines in 26 files changed: 33 ins; 15 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/23307.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23307/head:pull/23307 PR: https://git.openjdk.org/jdk/pull/23307 From bchristi at openjdk.org Fri Jan 24 22:04:48 2025 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 24 Jan 2025 22:04:48 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: On Fri, 24 Jan 2025 11:30:16 GMT, Aleksey Shipilev wrote: > Testing is still clean on my side. I would appreciate if folks can run this through their CIs. > > I am planning to integrate this on Monday, as long as we discover no new issues. Did the change to `test/jdk/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java` get lost? I'm pretty sure it was updated, but I no longer see that in the changes, and it failed in my automated test run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2613455704 From joe.darcy at oracle.com Fri Jan 24 22:09:55 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 24 Jan 2025 14:09:55 -0800 Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <878414661.63084619.1737013455052.JavaMail.zimbra@univ-eiffel.fr> <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> Message-ID: On 1/17/2025 5:49 PM, David Alayachew wrote: > > It definitely helps. > > I guess my next question is, there is no bridge method, which is why > this fails. Why not add a bridge method? What is stopping Java from > doing this? > The default response to the question "Should we fundamentally change how Java source files are compiled into class files?" is "No." ;-) Covariant returns "work" for instance methods for several reasons. Such behavior is expected from object-oriented type theory where it is sound for an overridden method to return a more specialized type in a subtype. Also, when presented with a single snapshot of the type hierarchy, as during compilation, it is relatively straightforward for the compiler to compute which bridge methods are needed, roughly look over the superclass and implemented interfaces for methods with the same name and set of arguments, but a different return type. Muddier on both accounts for how static methods would be handled by such a bridge method feature. -Joe > And to be clear, it is obvious to me that SewuencedSet.of is the right > answer. I am just trying to understand the point you raised. > > > On Fri, Jan 17, 2025, 8:14?PM Joseph D. Darcy > wrote: > > > On 1/17/2025 5:00 PM, David Alayachew wrote: >> >> Thanks for the corrections folks. I was thinking from the >> perspective of LSP. I now see that there is the performance >> perspective to consider too. >> >> Now that said, I don't understand your comment Joe Darcy. Could >> you explain it in more detail? >> > Say you compile your code against JDK 24 and use the 1-argument > Set.Of() method. For that call site, your class file will refer to > a method using information akin to > > ??? "In the class java.util.Set, a method named "of" that *returns > a java.util.Set* and take a java.lang.Object as an argument" > > (The generic information is basically erased in the class file, > hence Set rather than Set and Object rather than E.) > > If we were then in JDK 25 to replace in java.util.Set > > ??? static Set of(E e1){...} > > with > > ??? static SequencedSet of(E e1){...} > > when your class file ran against JDK 25, there would be no method > > ??? "In the class java.util.Set, a method named "of" that *returns > a java.util.Set* and take a java.lang.Object as an argument" > > for your class to call and the linkage would fail. > > For static methods, the change is equivalent to removing a method > and adding back a different, same-named method. > > HTH, > > -Joe > > >> My initial pick up of your comment is that, the parameter types >> and the return types of a method must match the types exactly >> between releases, otherwise there are no bridge methods FOR >> STATIC TYPES. But as for why, I don't understand. >> >> I know that static methods are not so much inherited as they are >> just given as is (hence why there is not really a static abstract >> method). But I don't quite see the line connecting that with no >> bridge methods for static. Maybe I don't understand bridge >> methods well enough. >> >> >> On Fri, Jan 17, 2025, 12:32?PM Joseph D. Darcy >> wrote: >> >> On 1/16/2025 11:26 PM, Rafael Winterhalter wrote: >>> Would it even be possible to change the return types of >>> Set.of(...) and Map.of(...) without breaking binary >>> compatibility? >> >> >> In short, no. >> >> The methods in question are *static* methods. Switching to >> covariant overrides with more precise return types works for >> subclasses because of bridge methods. >> >> In a bit more detail, in a covariant override a single method >> in the source code gets translated into multiply methods in >> the class file. References to methods in the class file use >> the argument types and return type so if an old class file >> refers to the previously declared source-level return type, >> there is the bridge method present to be linked to (for >> binary compatibility) and then executed. >> >> -Joe >> >> >>> >>> I also think that the randomization of Set.of(...) and >>> Map.of(...) is a good property as it uncovers bugs early if >>> one relies on iteration order. This especially since those >>> methods are often used in tests where production code would >>> use a proper HashSet which cannot guarantee iteration order >>> for good reasons. Exactly here I think the new interfaces >>> are a good addition as it uncovers such misconceptions. If >>> code relies on insertion order, providing a Set.of(...) does >>> no longer compile, what is a good thing. >>> >>> To me, adding SequencedSet.of(...) and SequencedMap.of(...) >>> sounds like the right approach, with implementations similar >>> to that of Set.of(...) and Map.of(...). As for megamorphism, >>> I think the chance of encounter at a call site is similar, >>> as Set12 and SetN from the Set interface are typically >>> combined with HashMap. As for a possible SequencedSet12 and >>> SequencedSetN, I think they would normally be seen with >>> LinkedHashSet. >>> >>> Best regards, Rafael >>> >>> Am Fr., 17. Jan. 2025 um 00:36?Uhr schrieb David Alayachew >>> : >>> >>> I should also add, the documentation went out of their >>> way to specify that iteration order is unspecified. >>> >>> Also, I see R?mi's comment, but that's even more >>> unconvincing to me. >>> >>> Map.of has an upper limit of 10 entries, and >>> Map.ofEntries has an upper limit of that Java max file >>> size limit thing. You all know what I am talking about. >>> >>> Point is, both of these static factories were meant to >>> be used on a small number of entries. If it truly has >>> just been not done until now, then the bug database will >>> confirm that easily. >>> >>> When I get back, I can check myself. >>> >>> >>> On Thu, Jan 16, 2025, 6:25?PM David Alayachew >>> wrote: >>> >>> I guess let me ask the obvious question. >>> >>> Chesterton's fence -- why wasn't this done before? I >>> refuse to believe that this idea wasn't thought up >>> years ago, which leads me to believe there was a >>> reason that it hasn't been done. >>> >>> Is there any way we can look this up in the bug >>> database or something? >>> >>> >>> On Thu, Jan 16, 2025, 2:28?PM Jens Lidestr?m >>> wrote: >>> >>> Having the result Map.of and Set.of preserve the >>> insertion order would >>> often be convenient. >>> >>> More often than not programs iterate over the >>> contents of a maps and >>> sets at some point. For example to present the >>> values in a GUI, for >>> serialisation, or even for error printouts. In >>> all those cases having a >>> fixed iteration order is much better than having >>> a random iteration >>> order. >>> >>> Often it is even a subtle bug to have a random >>> iteration order. For >>> example, I ran in to a situation where jdeps >>> printed a error message >>> containing a list of modules. But the list was >>> in a different order on >>> each run of the program! It took me a while to >>> figure out that it was >>> actually the same list. A possible explanation >>> is that jdeps is >>> implemented using Map.of or Set.of. >>> >>> Because of this I think I would be better if the >>> most commonly used >>> standard collection factories produced >>> collections with a fixed >>> iteration order. >>> >>> Guavas ImmutableMap and ImmutableSet also >>> preserve insertion order. >>> >>> Regards, >>> Jens Lidestr?m >>> >>> >>> On 2025-01-16 08:44, Remi Forax wrote: >>> >>> > ------------------------- >>> > >>> >> From: "Rafael Winterhalter" >>> >>> >> To: "core-libs-dev" >>> >>> >> Sent: Thursday, January 16, 2025 8:13:17 AM >>> >> Subject: Factory methods for SequencedSet and >>> SequencedMap >>> > >>> >> Hello, >>> > >>> > Hello, >>> > >>> >> I am happily taking SequencedSet and >>> SequencedMap into use, but one >>> >> inconvenience I encounter is the lack of >>> factory methods for the two. >>> >> In code where many (initial) collections have >>> zero or one element (for >>> >> later aggregation), I now write >>> Set.of()/Set.of(one) and >>> >> Map.of()/Map.of(key, value), as it makes the >>> code shorter and more >>> >> readable. Those collections are of course >>> implicitly sequenced, but >>> >> now I must make the variable type of the >>> surrounding monad Set and >>> >> Map, and simply assume that a LinkedHashSet >>> or LinkedHashMap is used >>> >> when a collection of more than one element is >>> set, without requiring >>> >> the interface type. This does not require any >>> type casting, as I rely >>> >> on the iteration order only, but the code >>> loses some of its >>> >> expressiveness. >>> >> I did not find any discussion around >>> introducing factories for >>> >> SequencedSet.of(...) and >>> SequencedMap.of(...), similar to those that >>> >> exist in the Set and Map interfaces. Was this >>> ever considered, and if >>> >> not, could it be? >>> > >>> > Thanks for re-starting that discussion, it was >>> talked a bit, but not as >>> > it should be. >>> > >>> > So the issue is that currently we do not have >>> any compact, unmodifiable >>> > and ordered Set/Map implementation, >>> > one use case is when you have data that comes >>> from a JSON object as a >>> > Map and you want to keep the inserted order, >>> if by example the JSON is >>> > a config file editable by a human, an other >>> example is in unit tests >>> > where you want to help the dev to read the >>> output of the test so the >>> > code that creates a Set/Map and what is >>> outputed by the test should be >>> > in the same order. >>> > Currently there is no good solution for those >>> use cases because >>> > Set|Map.copyOf() does not keep the ordering. >>> > >>> > I see two solutions, either we add a new >>> > SequenceSet|SequenceMap.of/copyOf, or we >>> change the impleemntation of >>> > Set|Map.of()/copyOf(). >>> > Python had gone for the latter solution, which >>> has the advantage a >>> > being simple from the user POV, but from an >>> algorithm expert POV, a Set >>> > and a SequencedSet are different concepts we >>> may want to emphasis ? >>> > >>> >> Best regards, Rafael >>> > >>> > regards, >>> > R?mi >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnguyen at openjdk.org Fri Jan 24 22:31:46 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 24 Jan 2025 22:31:46 GMT Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> Message-ID: <-BBvNQbrAoMMC_FayqUfV3YMlvRVWXOHVnpI6yhcuQ4=.dad22090-982f-4546-8f69-b5aef9178355@github.com> On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu wrote: > Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24. > > The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk. Backport looks fine and normal to me. ------------- Marked as reviewed by dnguyen (Committer). PR Review: https://git.openjdk.org/jdk/pull/23307#pullrequestreview-2573707535 From liach at openjdk.org Fri Jan 24 22:42:27 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 24 Jan 2025 22:42:27 GMT Subject: RFR: 8342465: Improve API documentation for java.lang.classfile [v2] In-Reply-To: References: Message-ID: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> > This is the last piece in the API documentation improvement of the Class-File API. > > This includes general documentation about transforms, models (and traversals), options, constants, and CodeBuilder factories. In particular, this preserves the package summary to avoid extra disruptions. See the APIDiff for more details. > > Please forgive this messy commit history; the work began before attribute changes were integrated and based off that, and in the process there were a few merges back and forth. > The files changed/webrev should be reliable. > > Please review the associated CSR as well. > > Note that this intends to be backported to 24; this won't be clean, as the `JAVA_25_VERSION` constant is a new addition that does not exist on 24. > > Testing: Tier 1-3. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-overall/java.base/java/lang/classfile/package-summary.html > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-overall/java.base/java/lang/classfile/package-summary.html Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Better specification of range of u2 values, flag masks and versions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23277/files - new: https://git.openjdk.org/jdk/pull/23277/files/d4b1c1ed..9fd144c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23277&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23277&range=00-01 Stats: 21 lines in 10 files changed: 12 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/23277.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23277/head:pull/23277 PR: https://git.openjdk.org/jdk/pull/23277 From ihse at openjdk.org Fri Jan 24 22:56:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 24 Jan 2025 22:56:54 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:56:30 GMT, Eirik Bj?rsn?s wrote: >> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. >> >> Links in `java.security` and `share/data/tzdata` are excluded from this PR. >> >> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. >> >> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). >> >> Changes beyond the obvious are as follows: >> >> `linux/native/libsimdsort/xss-common-qsort.h`: >> The current link uses a non-default port number. Changed to using the default port number. Reported and fixed upstream as intel/x86-simd-sort#170 >> >> `share/man/keytool.md`: >> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. >> >> `unix/classes/sun/net/PortConfig.java` >> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. >> >> `unix/native/libjava/*`, >> Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs >> >> `unix/native/libjava/ProcessImpl_md.c` >> A link to an "unofficial" document on pasc.org now requires authentication. This document is probably outdated and the link is removed. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright headers for 2025 for Oracle files Sounds good to me.(But I'm not really a stakeholder) ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21633#pullrequestreview-2573740496 From naoto at openjdk.org Fri Jan 24 23:08:47 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 24 Jan 2025 23:08:47 GMT Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> Message-ID: On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu wrote: > Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24. > > The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23307#pullrequestreview-2573755873 From liach at openjdk.org Fri Jan 24 23:08:47 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 24 Jan 2025 23:08:47 GMT Subject: RFR: 8342465: Improve API documentation for java.lang.classfile [v2] In-Reply-To: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> References: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> Message-ID: On Fri, 24 Jan 2025 22:42:27 GMT, Chen Liang wrote: >> This is the last piece in the API documentation improvement of the Class-File API. >> >> This includes general documentation about transforms, models (and traversals), options, constants, and CodeBuilder factories. In particular, this preserves the package summary to avoid extra disruptions. See the APIDiff for more details. >> >> Please forgive this messy commit history; the work began before attribute changes were integrated and based off that, and in the process there were a few merges back and forth. >> The files changed/webrev should be reliable. >> >> Please review the associated CSR as well. >> >> Note that this intends to be backported to 24; this won't be clean, as the `JAVA_25_VERSION` constant is a new addition that does not exist on 24. >> >> Testing: Tier 1-3. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-overall/java.base/java/lang/classfile/package-summary.html >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-overall/java.base/java/lang/classfile/package-summary.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Better specification of range of u2 values, flag masks and versions >From the CSR review, an update is made to better describe the u2 values: that the returned int is not itself an unsigned short, but it is in the range of unsigned short, and gives out the exact range in decimal for versions and in hexadecimal for flags. The CR previews have been updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23277#issuecomment-2613563995 From schernyshev at openjdk.org Fri Jan 24 23:38:50 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 24 Jan 2025 23:38:50 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11] In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > added details in the log message Hi Jonas, The PR is now ready and under review. I couldn't get back to it earlier due to ongoing work. Apologies for the delay. Am Fr., 24. Jan. 2025 um 11:07 Uhr schrieb Jonas ***@***.***>: > Hi @sercher and @jerboaa > may I ask what the current state of this PR > is, because we are waiting for the bug fix? > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2613597123 From jlu at openjdk.org Sat Jan 25 00:02:17 2025 From: jlu at openjdk.org (Justin Lu) Date: Sat, 25 Jan 2025 00:02:17 GMT Subject: RFR: 8348205: Improve cutover time selection when building available currencies set Message-ID: Please review this PR which improves the time measurement for cut-over time comparisons when building the available set of currencies in _java.util.Currency._ Currently, a new time was measured for each special case currency. This PR updates the behavior to use the same time for all such cases ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/23309/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23309&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348205 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23309/head:pull/23309 PR: https://git.openjdk.org/jdk/pull/23309 From swen at openjdk.org Sat Jan 25 00:18:17 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 25 Jan 2025 00:18:17 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v7] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @rgiulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/eb867978..e2b228cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=05-06 Stats: 73 lines in 2 files changed: 0 ins; 29 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From darcy at openjdk.org Sat Jan 25 00:43:47 2025 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 25 Jan 2025 00:43:47 GMT Subject: RFR: 8342465: Improve API documentation for java.lang.classfile [v2] In-Reply-To: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> References: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> Message-ID: On Fri, 24 Jan 2025 22:42:27 GMT, Chen Liang wrote: >> This is the last piece in the API documentation improvement of the Class-File API. >> >> This includes general documentation about transforms, models (and traversals), options, constants, and CodeBuilder factories. In particular, this preserves the package summary to avoid extra disruptions. See the APIDiff for more details. >> >> Please forgive this messy commit history; the work began before attribute changes were integrated and based off that, and in the process there were a few merges back and forth. >> The files changed/webrev should be reliable. >> >> Please review the associated CSR as well. >> >> Note that this intends to be backported to 24; this won't be clean, as the `JAVA_25_VERSION` constant is a new addition that does not exist on 24. >> >> Testing: Tier 1-3. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-overall/java.base/java/lang/classfile/package-summary.html >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-overall/java.base/java/lang/classfile/package-summary.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Better specification of range of u2 values, flag masks and versions Updates for CSR comments look good; thanks. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23277#pullrequestreview-2573850693 From iris at openjdk.org Sat Jan 25 01:20:59 2025 From: iris at openjdk.org (Iris Clark) Date: Sat, 25 Jan 2025 01:20:59 GMT Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> Message-ID: <7HHGVvdg10IEwU0ntbgYFeXJ5L3btQgva7Ey3pmD83Y=.f5442616-24c2-422d-a090-9f46086b98ba@github.com> On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu wrote: > Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24. > > The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23307#pullrequestreview-2573871901 From swen at openjdk.org Sat Jan 25 02:20:34 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 25 Jan 2025 02:20:34 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v8] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: use & ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/e2b228cb..dc2a6758 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=06-07 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From qamai at openjdk.org Sat Jan 25 02:35:52 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Sat, 25 Jan 2025 02:35:52 GMT Subject: RFR: 8345687: Improve the implementation of SegmentFactories::allocateSegment [v3] In-Reply-To: <_wjpvTZLmQbjFr0fWIJnB8hyZo0PDFnfnmTDeh7ujXo=.64334ac1-d6bd-45f3-a1c3-a4da05053768@github.com> References: <5bAs8hhqvy-c776n0_9Xqw6n8quA-c_a59ii-nWFhuE=.2eae9a1b-b46a-4626-9ac5-3ee35a34b82c@github.com> <4T4xAZGj1lmd8-KBdRCsBF5oltxC0mQzseUIJGTKaCE=.f71ab6fc-a247-45af-9000-9d1288bdf5d4@github.com> <_wjpvTZLmQbjFr0fWIJnB8hyZo0PDFnfnmTDeh7ujXo=.64334ac1-d6bd-45f3-a1c3-a4da05053768@github.com> Message-ID: On Fri, 24 Jan 2025 11:57:06 GMT, Maurizio Cimadamore wrote: >> The main goal here is that passing/receiving raw addresses as longs is cheaper than as `MemorySegment`s. > > But the address is immediately converted to memory segment using MemorySegment::ofAddress, which is what the linker does anyway? Only the return value of `CALLOC` is converted to `MemorySegment` in an equivalent way, I believe passing a `MemorySegment` to a downcall involves acquiring the corresponding segment? As a result, `FREE` is made to accept the raw address, and `CALLOC` is changed in the same manner for consistency. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22610#discussion_r1929440246 From swen at openjdk.org Sat Jan 25 03:08:47 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 25 Jan 2025 03:08:47 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v8] In-Reply-To: References: Message-ID: <2TtGkqEdO2p5TyVFP_gRqu798_RC5BUPzGNCMVDL400=.fc731c22-11c5-416a-82a4-ec83188e3eb0@github.com> On Sat, 25 Jan 2025 02:20:34 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > use & After accepting rgiulietti's suggestion, the performance was further improved, and the performance numbers are as follows ## 1. Script git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao #master git checkout 5bb9644202a8b961faad02439c95a81ca6862168 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" git checkout f97093d324fbb7de322c86d52db11cafcff2de87 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" # current git checkout dc2a6758f33daacde63189a2239b1fac1470a937 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" ## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa) Benchmark (size) Mode Cnt Score Error Units (5bb9644) Longs.parseLong 500 avgt 15 3.538 ? 0.019 us/op Integers.parseInt 500 avgt 15 3.276 ? 0.004 us/op Benchmark (size) Mode Cnt Score Error Units (f97093d) Longs.parseLong 500 avgt 15 2.960 ? 0.013 us/op +19.52% Integers.parseInt 500 avgt 15 3.116 ? 0.004 us/op +5.13% Benchmark (size) Mode Cnt Score Error Units (dc2a675) Longs.parseLong 500 avgt 15 2.911 ? 0.016 us/op +21.58% Integers.parseInt 500 avgt 15 2.985 ? 0.011 us/op +9.74% ## 3. aliyun_ecs_c8i_x64 (CPU Intel?Xeon?Emerald Rapids) Benchmark (size) Mode Cnt Score Error Units (5bb9644) Longs.parseLong 500 avgt 15 3.468 ? 0.010 us/op Integers.parseInt 500 avgt 15 3.137 ? 0.007 us/op Benchmark (size) Mode Cnt Score Error Units (f97093d) Longs.parseLong 500 avgt 15 2.996 ? 0.020 us/op +15.75% Integers.parseInt 500 avgt 15 2.822 ? 0.005 us/op +11.16% Benchmark (size) Mode Cnt Score Error Units (dc2a675) Longs.parseLong 500 avgt 15 2.850 ? 0.009 us/op +21.68% Integers.parseInt 500 avgt 15 2.772 ? 0.004 us/op +13.16% ## 4. aliyun_ecs_c8y_aarch64 (CPU Aliyun Yitian 710) Benchmark (size) Mode Cnt Score Error Units (5bb9644) Longs.parseLong 500 avgt 15 3.827 ? 0.033 us/op Integers.parseInt 500 avgt 15 3.589 ? 0.038 us/op Benchmark (size) Mode Cnt Score Error Units (f97093d) Longs.parseLong 500 avgt 15 3.394 ? 0.033 us/op +12.75% Integers.parseInt 500 avgt 15 3.090 ? 0.014 us/op +16.14% Benchmark (size) Mode Cnt Score Error Units (dc2a675) Longs.parseLong 500 avgt 15 3.293 ? 0.080 us/op +16.21% Integers.parseInt 500 avgt 15 3.102 ? 0.010 us/op +15.69% ## 5. orange_pi5_aarch64 (CPU RK3588S) Benchmark (size) Mode Cnt Score Error Units Longs.parseLong 500 avgt 15 9.342 ? 0.610 us/op (5bb9644) Integers.parseInt 500 avgt 15 9.217 ? 0.572 us/op Benchmark (size) Mode Cnt Score Error Units (f97093d) Longs.parseLong 500 avgt 15 7.986 ? 0.499 us/op +16.97% Integers.parseInt 500 avgt 15 6.093 ? 0.020 us/op +15.13% Benchmark (size) Mode Cnt Score Error Units (dc2a675) Longs.parseLong 500 avgt 15 6.882 ? 0.240 us/op +35.74% Integers.parseInt 500 avgt 15 6.104 ? 0.226 us/op +50.99% # 6. MacBook M1 Pro (aarch64) Benchmark (size) Mode Cnt Score Error Units (5bb9644) Longs.parseLong 500 avgt 15 2.673 ? 0.026 us/op Integers.parseInt 500 avgt 15 2.358 ? 0.035 us/op Benchmark (size) Mode Cnt Score Error Units (f97093d) Longs.parseLong 500 avgt 15 2.283 ? 0.027 us/op +17.08% Integers.parseInt 500 avgt 15 2.045 ? 0.027 us/op +15.30% Benchmark (size) Mode Cnt Score Error Units (dc2a675) Longs.parseLong 500 avgt 15 2.212 ? 0.016 us/op +20.84% Integers.parseInt 500 avgt 15 1.994 ? 0.010 us/op +18.25% ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2613746684 From swen at openjdk.org Sat Jan 25 03:15:55 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 25 Jan 2025 03:15:55 GMT Subject: Integrated: 8343962: [REDO] Move getChars to DecimalDigits In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 01:25:16 GMT, Shaojin Wen wrote: > This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed. > > 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication. > > 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16 > > 3) Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess > Eliminate duplicate code in BigDecimal > > 4) This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe. In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check. This pull request has now been integrated. Changeset: f446cefe Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/f446cefee0715da6532b68f65a5a15775e20945d Stats: 761 lines in 12 files changed: 379 ins; 352 del; 30 mod 8343962: [REDO] Move getChars to DecimalDigits Reviewed-by: redestad, rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/22023 From swen at openjdk.org Sat Jan 25 03:25:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 25 Jan 2025 03:25:52 GMT Subject: Withdrawn: 8315585: Optimization for decimal to string In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 11:21:01 GMT, Shaojin Wen wrote: > Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22009 From swen at openjdk.org Sat Jan 25 04:01:47 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 25 Jan 2025 04:01:47 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v9] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501 # Conflicts: # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java - use & - from @rgiulietti - remove unused - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Chen Liang - vector digit2 - emptyInput -> nullInput - use CharacterDataLatin1.instance::isDigit - add comments - reduce codeSize - ... and 15 more: https://git.openjdk.org/jdk/compare/f446cefe...0bacfa01 ------------- Changes: https://git.openjdk.org/jdk/pull/22919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=08 Stats: 174 lines in 5 files changed: 98 ins; 26 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From shade at openjdk.org Sat Jan 25 07:14:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Sat, 25 Jan 2025 07:14:51 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v10] In-Reply-To: References: Message-ID: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [x] Linux x86_64 server fastdebug, `all` > - [x] Linux AArch64 server fastdebug, `all` 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 14 additional commits since the last revision: - Merge branch 'master' into JDK-8344332-dbb-cleaner - No instantiation for BufferCleaner, javadocs - Remove hasReferencePendingList - Revert test exclusion, moved to JDK-8348301 - Alan's review - Remove vestigial reference to waitForReferenceProcessing in tests - Track Cleaner progress with canaries - Amend benchmarks - Fix tests - Review feedback and benchmarks - ... and 4 more: https://git.openjdk.org/jdk/compare/c8e9921d...bcfab1ba ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/2831bc84..bcfab1ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=08-09 Stats: 14358 lines in 2002 files changed: 5683 ins; 5459 del; 3216 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From shade at openjdk.org Sat Jan 25 07:14:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Sat, 25 Jan 2025 07:14:51 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: <-vJ0hBTDWcQy99ecAeITRv6rvV1szyZgnVoKRqpi2V0=.87d6e7a1-f821-4545-a7ce-076a0b96ac49@github.com> On Fri, 24 Jan 2025 22:01:59 GMT, Brent Christian wrote: > Did the change to `test/jdk/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java` get lost? I'm pretty sure it was updated, but I no longer see that in the changes, and it failed in my automated test run. It was a test bug, I fixed it separately: [JDK-8348301](https://bugs.openjdk.org/browse/JDK-8348301). I merged current master to this PR branch now, so it should work well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2613819873 From alanb at openjdk.org Sat Jan 25 07:28:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 25 Jan 2025 07:28:50 GMT Subject: Integrated: 8299504: Resolve `uses` and `provides` at run time if the service is optional and missing In-Reply-To: References: Message-ID: <_sMFQmWyZG1sKf7R7RdLEM40wV7EZiANMnS_fTWAIS8=.345e5902-691c-40bd-9af3-51c8fc276eb1@github.com> On Thu, 16 Jan 2025 11:38:19 GMT, Alan Bateman wrote: > Extend the support for optional dependences to allow for a service to be optional. The post-resolution consistency check specified by `Configuration.resolve` is relaxed to allow for the possibility that the service from a module in the module graph at compile-time but the module is not in the module graph at run-time. > > ConfigurationTest is ported from TestNG to JUnit and updated to add new tests testUsesOptionalService$N and testProvidesOptionalService$N. The port to JUnit is mostly trivial/mechanical changes but it does create a bit of noise - I can move this port to another issue if it makes the harder to see the additions to the test. This pull request has now been integrated. Changeset: 1d2eb2fb Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/1d2eb2fbaea700fc77b644b5eb5a8a7c40ede108 Stats: 581 lines in 4 files changed: 279 ins; 51 del; 251 mod 8299504: Resolve `uses` and `provides` at run time if the service is optional and missing Co-authored-by: Alan Bateman Co-authored-by: Alex Buckley Reviewed-by: sundar ------------- PR: https://git.openjdk.org/jdk/pull/23147 From stuefe at openjdk.org Sat Jan 25 08:06:48 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 25 Jan 2025 08:06:48 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v3] In-Reply-To: References: <8tyc5YtyUIp3AiJc6lZ1FoqfPgYXeG8-8rgHbMOGv_Q=.77908a0d-04d9-4947-a051-95fb76123360@github.com> Message-ID: On Tue, 21 Jan 2025 06:51:10 GMT, Thomas Stuefe wrote: >>> In ProcessImpl_md.c, we have adopted the Posix APIs and semantics for process handling. I suggest removing the "unofficial" link, it does not include useful information at this point and is fragile. >>> >>> The current behavior always setting SIGCHLD to SIG_DFL is/has been reliable and does not depend on the behavior of the parent process. (Good) @tstuefe May also be interested in reviewing this change. >> >> https://pubs.opengroup.org/onlinepubs/9799919799/ seems to indicate that the "default action is to ignore the signal", which is unclear to me. I think it means that the signal will not cause invocation of a user handler or abort the process, but does this also mean that wait and waited won't work? >> >> In any case, I agree with @RogerRiggs that keeping this behavior is fine. >> >>> >>> The previous sentence mentions Solaris and that should be removed at some point but out of scope for this PR. > >> @tstuefe And you also agree that the link should be removed? (Which is what this PR is about) > > The 20+ years old link to the PASC error report I would probably remove; it is likely outdated now. If one wanted to invest the time, one could test the current behavior on our supported Unices. As long as that is not done, we can live with setting SIG_DFL manually. > > I would replace it with a link to https://pubs.opengroup.org/onlinepubs/007904875/functions/wait.html and point to the section that says: > > [XSI] [Option Start] If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, > and the process has no unwaited-for children that were transformed into zombie processes, > the calling thread shall block until all of the children of the process containing > the calling thread terminate, and wait() and waitpid() shall fail and > set errno to [ECHILD]. [Option End] > > > Again, that is XSI though; I am not sure which of our Unices comply to that. Linux does only partially, so one would have to test that behavior. > > Another question @RogerRiggs , I was surprised to see that we set the SIGCHLD default behavior only at Java_java_lang_ProcessImpl_init. Should we also set it in jspawnhelper before the exec? But I guess the assumption is that no java process will fork before Java_java_lang_ProcessImpl_init, so maybe its okay. > > > @tstuefe And you also agree that the link should be removed? (Which is what this PR is about) > > > > > > The 20+ years old link to the PASC error report I would probably remove; it is likely outdated now. If one wanted to invest the time, one could test the current behavior on our supported Unices. As long as that is not done, we can live with setting SIG_DFL manually. > > Thanks for looking into this Thomas, much appreciated! > > I think the improvements you suggest here are perhaps streching the scope of this particular PR, which was mostly to update links to use HTTPS. I must also admit that I have a very limited understanding of these low-level Unix APIs, so I'm reluctant to include material changes in this PR. > > I have filed https://bugs.openjdk.org/browse/JDK-8348183 to track a review/update of the comment in ProcessImpl_md.c and suggest that we simply remove the "unofficial" link for this PR. > > Would this be ok with you? Yes thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2613833730 From forax at univ-mlv.fr Sat Jan 25 13:01:53 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 25 Jan 2025 14:01:53 +0100 (CET) Subject: Factory methods for SequencedSet and SequencedMap In-Reply-To: References: <5a01aa83c18f7065a6bc5930c55a9727@lidestrom.se> <04253a54-909e-48a3-8c8c-52c67be70b4a@oracle.com> <1054038972.68527184.1737299922796.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1719088925.76549388.1737810113058.JavaMail.zimbra@univ-eiffel.fr> > From: "Rafael Winterhalter" > To: "Remi Forax" > Cc: "core-libs-dev" , "joe darcy" > > Sent: Tuesday, January 21, 2025 10:17:35 AM > Subject: Re: Factory methods for SequencedSet and SequencedMap > Wouldn't this already be possible with today's union types? > static & SequencedSet> S of(E... elements) { ... } No, because when you have a type variable declared on a method, it means \forall, so here, the method of() has to work for all implementations of S, so all implementations of a SeqenceSet. To see the issue, you can fix the type argument, by example TreeSet set = Set.>of("foo") is obviously wrong but allowed by the declaration. > Then again, I do not think that the regular Set and Map implementations should > be sequenced, mainly to avoid that tests suffer from this sequencing. I do not disagree :) R?mi > Am So., 19. Jan. 2025 um 16:18 Uhr schrieb Remi Forax < [ > mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >: >> What can be done is to have Set.of()/Map.of() to delegate to >> SequenceSet.of()/SequenceMap.of() so there is only one implementation at >> runtime. >> Also, technically, there is a way to change the return type in a binary >> compatible way ... if union types are supported in the language. >> In that case, Set.of() can be declared like this >> static Set | SequenceSet of(E... ) { >> ... >> } >> because of erasure, the binary descriptor will use Set, but the Signature will >> be Set | SequenceSet so the compiler will see the return type as a >> SequencedSet . >> Obviously, union types is a far bigger features than adding >> SequenceSet/SequenceMap so it's a big if, but it may happen in the future. >> R?mi >>> From: "joe darcy" < [ mailto:joe.darcy at oracle.com | joe.darcy at oracle.com ] > >>> To: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.org | >>> core-libs-dev at openjdk.org ] > >>> Sent: Friday, January 17, 2025 6:30:40 PM >>> Subject: Re: Factory methods for SequencedSet and SequencedMap >>> On 1/16/2025 11:26 PM, Rafael Winterhalter wrote: >>>> Would it even be possible to change the return types of Set.of(...) and >>>> Map.of(...) without breaking binary compatibility? >>> In short, no. >> [...] >>> -Joe >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From acobbs at openjdk.org Sat Jan 25 16:13:11 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 25 Jan 2025 16:13:11 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v4] In-Reply-To: References: Message-ID: > The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding. > > However, while `DeflaterOutputStream` provides constructors that take a custom `Deflater` argument supplied by the caller, `GZIPOutputStream` has no such constructors. > > As a result, it's not possible to do entirely reasonable customization, such as configuring a `GZIPOutputStream` for a non-default compression level. > > This change adds a new `GZIPOutputStream` constructor that accepts a custom `Deflater`, and also adds a basic unit test for it and all of the other `GZIPOutputStream` constructors, based on the existing test `BasicGZIPInputStreamTest.java` which does the same thing for `GZIPInputStream`. Archie Cobbs 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 eight additional commits since the last revision: - Add Javadoc explaining that Deflater.end() will not be invoked. - Merge branch 'master' into JDK-4452735 - Bump copyright year to 2025. - Merge branch 'master' into JDK-4452735 - Address review comments. - Merge branch 'master' into JDK-4452735 - Merge branch 'master' into JDK-4452735 - Add a GZIPOutputStream() constructor that takes a Deflator. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20226/files - new: https://git.openjdk.org/jdk/pull/20226/files/b3a40b1c..3807de16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20226&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20226&range=02-03 Stats: 57418 lines in 3269 files changed: 22191 ins; 23198 del; 12029 mod Patch: https://git.openjdk.org/jdk/pull/20226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20226/head:pull/20226 PR: https://git.openjdk.org/jdk/pull/20226 From swen at openjdk.org Sat Jan 25 16:15:38 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 25 Jan 2025 16:15:38 GMT Subject: RFR: 8344168: Change Unsafe base offset from int to long [v5] In-Reply-To: References: Message-ID: > The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed. > > @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea. Shaojin Wen 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 eight additional commits since the last revision: - fix DecimalDigits - Merge remote-tracking branch 'upstream/master' into long_unsafe_offset_202411 - Typos - Fix type expectations - Make base offset method and invalid offset long - Merge remote-tracking branch 'upstream/master' into long_unsafe_offset_202411 - long BaseAndScale base, from @JornVernee - long Unsafe offset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22095/files - new: https://git.openjdk.org/jdk/pull/22095/files/6d4bb369..76f6f3fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=03-04 Stats: 287804 lines in 7071 files changed: 168735 ins; 95338 del; 23731 mod Patch: https://git.openjdk.org/jdk/pull/22095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22095/head:pull/22095 PR: https://git.openjdk.org/jdk/pull/22095 From acobbs at openjdk.org Sat Jan 25 16:20:49 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 25 Jan 2025 16:20:49 GMT Subject: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v3] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 20:57:15 GMT, Eirik Bj?rsn?s wrote: > A tangential concern when allowing a custom deflater / inflater is to document the resposibility for resource management. I've added a Javadoc blurb to that effect in 3807de16b70. Something similar (once the verbiage is agreed upon) should work for JDK-8066583 too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20226#issuecomment-2614017642 From duke at openjdk.org Sat Jan 25 18:49:50 2025 From: duke at openjdk.org (Jonas) Date: Sat, 25 Jan 2025 18:49:50 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v8] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 10:06:39 GMT, Sergey Chernyshev wrote: >> Sergey Chernyshev has updated the pull request incrementally with three additional commits since the last revision: >> >> - update cgroup v1 in metrics >> - Apply suggestions from code review >> >> Co-authored-by: Severin Gehwolf >> - updated test (path is reduced) > > Here's the summary of the latest state of the PR. The updated code > - special cases the condition when `_root` is `/`, and `cgroup_path` includes `../`. The condition appears in containers when a process's cgroup is moved to a supergroup. Then the cgroup files are mapped inside the container at the controller's mount point. The reason for this - path adjustment will always fail with cgroup path prefix `../`; > - calls `stat()` on cgroup path to make sure the directory exists - only when `_root` != `/` and `_root` != `cgroup_path`. This issue is specific to cgroup v1 containers, where /proc/self/cgroup is from host, cgroup files are mapped at controller's mount point, the mapping may include subgroups that need to be walked through to locate the smallest limits ; > - sets Java Metrics in alignment with hotspot logic ; > - fixes an NPE in Java Metrics ; > - fixes an uninitialized path issue in hotspot / cgroup v1 subsystem when `_root` != `/` and `_root` != `cgroup_path`; > - fixes a logical error with `lowest_limit` in the path adjustment in `CgroupUtil::adjust_controller()` methods ; > - adds container tests on subgroups in hotspot and metrics. Hi @sercher and @jerboaa may I ask what the current state of this PR is, because we are waiting for the bug fix? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2612141043 From alanb at openjdk.org Sun Jan 26 07:33:02 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 26 Jan 2025 07:33:02 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: On Fri, 24 Jan 2025 22:01:59 GMT, Brent Christian wrote: > Testing is still clean on my side. I would appreciate if folks can run this through their CIs. > > I am planning to integrate this on Monday, as long as we discover no new issues. I ran it through our CI and we seem to have a few tests that aren't in the jdk repo but have a dependency on jdk.internal.ref.Cleaner so they will need to be fixed and/or excluded. Would you mind holding off until Tuesday to give time to get that done? Otherwise I didn't see any issues. I see there is a referenced Graal issue as it looks like they have to do an update to align with the changes here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2614254369 From markus at headcrashing.eu Sun Jan 26 16:37:22 2025 From: markus at headcrashing.eu (Markus KARG) Date: Sun, 26 Jan 2025 17:37:22 +0100 Subject: Request for Enhancement: java.io.Writer.of(Appendable) as an efficient alternative to java.io.StringWriter In-Reply-To: <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu> References: <3d41a187-87f5-4a99-80c7-ba0593d4dbc1@headcrashing.eu> <6ed5af05-6cc8-46ae-8ef4-4dbbc7f410e8@headcrashing.eu> Message-ID: <538b0443-bd36-4286-9a5f-cc6c7d161e37@headcrashing.eu> As there have not been any more comments so far in the past weeks, I assume there is common agreement with my current proposal. If not, please chime in ASAP. If there are no further comments, I will continue with the existing PR next. -Markus Am 31.12.2024 um 14:43 schrieb Markus KARG: > > Hi Chen, > > thank you for your ideas! > > Actually I cannot see what is "safer" in your proposal, but maybe I am > missing to see a hidden risk in instanceof. Can you please outline the > potential risk you actually see in "if (appendable implements > Flushable f) f.flush();"? > > I mean, Flushable and Closable are simply *mix-ins* existing for > exactly the purpose of "flushing-if-flusing-is-supported" and > "closing-if-closing-is-supported", which is what we do need right > here. Nobody wants to pass in a standalone "flusher" or standalone > "closer" in addition to the actual object to flush and close, i. e., > the Appendable. In particular, nobody actually reported the need to > build a Writer from three distrinct implementation objects (or I > missed this need). Explicitly passing "null" feels rather unintuitive > and IMHO is doubtful. Why should someone want to do that? Again, > apparently you see that use case, so if you really have strong > feelings, then please make me understand who needs that and for what > actual purpose.? :-) > > To be all on the same side, again, please always share the core idea > that this API more or less solely is the combination of > "Writer.of(StringBuilder)" with "Writer.of(StringBuffer)" and > "Writer.of(CharSet)". > > Note that the sole target still is to pass in a StringBuilder, > StringWriter, or CharBuffer, as wrapping *them* is *the driver* for > the new API. While someone *can* do that, it is *not the target* of > this API to pass in any Writer or any arbitrary Appendable. Therefore, > we just need to be able *to deal with that case* once it happens -- > which is why it is IMHO absolutely fine to directly return Writers > *non-wrapped*. The API so far just says, "passing a Writer in turn > returns a Writer", but it does *not* propose to enhance or limit that > Writer in any way, and that is why it is (IMHO absolutely) safe to > check all other Appendables for *their* actual ability to get flushed > or to get closed. Remember, the target of *this* API proposal is *not* > to be able to write into any Flushable-and-Closable-Appendable > *without* flushing or closing it. Having that said, *I do not veto* > adding an *additional* method like Writer.of(Appendable, boolean > preventFlush, preventClose) *later* **if needed**, but IMHO that > should rather be *separate* wrappers like > Writer.withoutFlushing(Writer) and Writer.withoutClosing(Writer) > (either you have the need to not-flush/not-close, or you don't have > it, so it is not a special case of *this* API), or something like > that, which both are, again, *non-targets* of my current proposal. In > fact I still do not see *any* benefit of passing in a Writer into > Writer.of(), neither as a single reference, nor split up into three > interfaces (and BTW, I did *not* say a Writer is a combination of > Appendable, Flushable and Closable). Neither do I see *any benefit* of > being able to pass in in three different implementation objects. But > what I do see in your proposal actually is: > > * It would make up a can of worms due to the possibility of providing > three different implementation objects for that three parameters. > Someone could do Writer.of(new StringBuilder(), > Files.newBufferedWriter(), new CharBuffer()) and the outcome would be > rather dubious (and mostly useless but confusing). > > * As the sole target is to allow wrapping StringBuilder, StringWriter, > and CharBuffer, and as we solely came to Flushable and Closable due to > the question about "How to call flush and close ON THE PASSED > REFERENCE, IFF the Appendable implements them?" it would be a real > pain for alle users to be FORCED to repeat the same object three times. > > Having said that, my proposal is (as this is it what is IMHO mostly > intuitive and most wanted): > > * Let's have solely Writer.of(Appendable) without any other parameters > *in the first PR*; discuss the use case of more parameters *in > subsequent PRs* IFF NEEDED as these should be *additional* method > signatures to not torture the 90% standard case users with parameters > they never need. > > * Let's return Writer non-wrapped, and clearly document that in the > JavaDocs. Have separate discussions about > Writer.withoutFlushing(Writer) and Writer.withourClosing(Writer) *in > subsequent threads* IFF NEEDED. > > * Let's use "if (appendable instanceof Flushable f) f.flush()" and "if > (appendable instanceof Closebale c) c.close()", and clearly document > that in the JavaDocs. In case users do really want non-flushed, > non-closed appendables wrapped as Writer, they do not lose something, > but have to wait for the outcome of *subsequent* discussions about > *additional* wrappers. > > I think that could be a clean, safe and straightforward way towards > the replacement of StringWriter. > > Regards and a happy new year! :-) > > -Markus > > > Am 31.12.2024 um 06:42 schrieb Chen Liang: >> Hi Markus, >> Thanks for your analysis that a Writer can be seen as a composition >> as an Appendable, a Flushable, and a Closeable. >> Given this view, I think we should add a Writer.of(Appenable, >> Flushable, Closeable) to specify the 3 component behaviors of the >> returned writer. >> Each of the 3 arguments can be null, so that component will be no-op >> (Writer's Appendable methods only need to trivially return the Writer >> itself; all other methods return void). >> We will always require all 3 arguments to be passed; a null component >> means the caller knowingly demands no-op behavior for that component. >> I believe this approach would be safer, and avoids the accidental >> delegation of unwanted features from a given input Appendable when it >> happens to duck type. >> >> Regards, >> Chen Liang >> >> On Sat, Dec 28, 2024 at 10:41?PM Markus KARG >> wrote: >> >> Chen, >> >> thank you for your comments! My ideas to address them are: >> >> * flush(): If the Appendable implements Flushable, then perform >> Flushable.flush() on it. Otherwise, Writer.flush() will be a >> no-op (besides checking if Writer is open). >> >> * close(): If the Appendable implements Closeable, then perform >> Closeable.close() on it. Otherwise, Writer.close() will be a >> no-op (besides calling this.flush() if open, and internally >> marking itself as closed). >> >> * Writer.of(Writer): The original sense of the new API is to >> create a Writer wrapping non-Writers like StringBuilder, >> CharBuffer etc., but not to reduce a Writer to an Appendable >> (that would rather be Appendable.narrow(Writer) or so). IMHO >> there is neither any need nor benefit to return a limited Writer >> instead of the actual writer. So actually I would plea for >> directly returning the given writer itself, so Writer.of(Writer) >> is a no-op. I do not see why someone would intentionally pass in >> a Writer in the hope to get back a more limited, non-flushing / >> non-closing variant of it, and I have a bad feeling about >> returning a Writer which is deliberately cutting away the ability >> to flush and close without any technical need. Maybe you could >> elaborate on your idea if you have strong feelings about that use >> case? >> >> * StringWriter: Writer.of() is -by intention- not a "fire and >> forget" drop-in replacement, but a "real" Writer. It comes with a >> price, but in do not see a big problem here. If one is such happy >> with StringWriter that dealing with IOException would be a no-go, >> then simply keep the app as-is. But if one really wants the >> benefits provided by Writer.of(), then dealing with IOExcpetion >> should be worth it. This is a (IMHO very) low price the >> programmer has to pay for the benefit of gaining non-sync, >> non-copy behavior. In most code using StringWriter I have seen so >> far, IOException was dealt with anyways, as the code was mostly >> IO-bound already (it expects "some" Writer, not a StringWriter, >> as it wants to perform I/O, but the target is "by incident" a >> String). >> >> To sum up: IMHO still it sounds feasible and the benefits >> outweigh the costs. :-) >> >> -Markus >> >> >> Am 28.12.2024 um 01:51 schrieb Chen Liang: >>> >>> Hi Markus, >>> I think the idea makes sense,?but it comes with more >>> difficulties than in the case of Reader.of. An Appendable is a >>> higher abstraction modeling only the character writing aspects, >>> without concerns with resource control (such as flush or close). >>> >>> One detail of note is that Writer itself implements Appendable, >>> but I don't think the new method should return a Writer as-is; I >>> think it should return?another writer whose close will not close >>> the underlying writer as we are only modelling the appendable >>> behavior without exporting the resource control methods. Not >>> sure about flush. >>> >>> One use case you have mentioned is StringWriter. StringWriter is >>> distinct from StringReader: its write and append methods do not >>> throw IOE while the base Writer does. So Writer.of cannot >>> adequately replace StringWriter without use-site ugliness, until >>> we have generic types that represent the bottom type. >>> >>> Regards, >>> >>> Chen Liang >>> >>> >>> On Fri, Dec 20, 2024, 11:12?PM Markus KARG >>> wrote: >>> >>> Dear Sirs, >>> >>> JDK 24 comes with Reader.of(CharSequence), now let's provide >>> the >>> symmetrical counterpart Writer.of(Appendable) in JDK 25! :-) >>> >>> For performance reasons, hereby I like to propose the new >>> public factory >>> method Writer.of(Appendable). This will provide the same >>> benefits for >>> writing, that Reader.of(CharSequence) provides for reading >>> since JDK 24 >>> (see JDK-8341566). Before sharing a pull request, I'd kindly >>> like to >>> request for comments. >>> >>> Since Java 1.1 we have the StringWriter class. Since Java >>> 1.5 we have >>> the Appendable interface. StringBuilder, StringBuffer and >>> CharBuffer are >>> first-class implementations of it in the JDK, and there >>> might exist >>> third-party implementations of non-String text sinks. Until >>> today, >>> however, we do not have a Writer for Appendables, but need >>> to go costly >>> detours. >>> >>> Text sinks in Java are expected to implement the Writer >>> interface. >>> Libraries and frameworks expect application code to provide >>> Writers to >>> consume text produced by the library or framework, for example. >>> Application code often wants to modify the received text, e. >>> g. embed >>> received SVG text into in a larger HTML text document, or >>> simply forward >>> the text as-is to I/O, so StringBuilder or CharBuffer is >>> what the >>> application code actually uses, but not Strings! In such >>> cases, taking >>> the StringWriter.toString() detour is common but >>> inefficient: It implies >>> duplicating the COMPLETE text for the sole sake of creating >>> a temporary >>> String, while the subsequent processing will copy the data >>> anyways or >>> just uses a small piece of it. This eats up time and memory >>> uselessly, >>> and increases GC pressure. Also, StringWriter is >>> synchronized (not >>> explicitly, but de-facto, as it uses StringBuffer), which >>> implies >>> another needless slowdown. In many cases, the >>> synchronization has no use >>> at all, as in real-world applications least Writers are >>> actually >>> accessed concurrently. As a result, today the major benefit of >>> StringBuilder over StringBuffer (being non-synchronized) >>> vanishes as >>> soon as a StringWriter is used to provide its content. This >>> means, >>> "stringBuilder.append(stringWriter.toString())" imposes slower >>> performance than essentially needed, in two ways: >>> toString(), synchronized. >>> >>> In an attempt to improve performance of this rather typical >>> use case, I >>> like to contribute a pull request providing the new public >>> factory >>> method java.io.Writer.of(Appendable). This is symmetrical to >>> the >>> solution we implemented in JDK-8341566 for the reversed case: >>> java.io.Reader.of(CharSequence). >>> >>> My idea is to mostly copy the existing code of StringWriter, >>> but wrap a >>> caller-provided Appendable instead of an internally created >>> StringBuilder; this strips synchronization; then add >>> optimized use for >>> the StringBuffer, StringBuilder and CharBuffer >>> implementations (in the >>> sense of write(char[],start,end) to prevent a char-by-char >>> loop in these >>> cases). >>> >>> Alternatives: >>> >>> - Applications could use Apache Commons IO's >>> StringBuilderWriter, which >>> is limited to StringBuilder, so is not usable for the >>> CharBuffer or >>> custom Appendable case. As it is an open-source third-party >>> dependency, >>> some authors might not be allowed to use it, or may not want >>> to carry >>> this additional burden just for the sake of this single >>> performance >>> improvement. In addition, this library is not actively >>> modernized; its >>> Java baseline still is Java 8. There is no commercial support. >>> >>> - Applications could write their own Writer implementation. >>> Given the >>> assumption that this is a rather common use case, this imposes >>> unjustified additional work for the authors of thousands of >>> applications. It is hard to justify why there is a >>> StringWriter but not >>> a Writer for other Appendables. >>> >>> - Instead of writing a new Writer factory method, we could >>> slightly >>> modify StringWriter, so it uses StringBuilder (instead of >>> StringBuffer). >>> This (still) results in unnecessary duplication of the full >>> text at >>> toString() and (now also) at getBuffer(), and it will break >>> existing >>> applications due the missing synchronization. >>> >>> - Instead of writing a new Writer factory method, we could >>> write a new >>> AppendableWriter class. This piles up the amount of public >>> classes, >>> which was the main reason in JDK-8341566 to go with the >>> "Reader.of(CharSequence)" factory method instead of the >>> "CharSequenceReader" class. Also it would be confusing to have >>> Reader.of(...) but not Writer.of(...) in the API. >>> >>> - We could go with a specific Appendable class (like >>> StringBuilder) >>> instead of supporting all Appendable implementations. This >>> would reduce >>> the number of applicable use cases daramatically (in >>> particular as >>> CharBuffer is not supported any more) without providing any >>> considerable >>> benefit (other than making the OpenJDK-internal source code >>> a bit >>> shorter). In particular it makes it impossible to opt-in for >>> the below >>> option: >>> >>> Option: >>> >>> - Once we have Writer.of(Appendable), we could replace the full >>> implementation of StringWriter by synchronized calls to the >>> new Writer. >>> This would reduce duplicate code. >>> >>> Kindly requesting comments. >>> >>> -Markus Karg >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yujige at gmail.com Sun Jan 26 22:03:31 2025 From: yujige at gmail.com (Jige Yu) Date: Sun, 26 Jan 2025 14:03:31 -0800 Subject: mapConcurrent() with InterruptedException In-Reply-To: References: Message-ID: Checking in on what you've found out, Viktor. >From where we left off, I understand that you were looking at alternatives instead of silent truncation? Have you reached any conclusion? We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc : API Note: In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements. In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic: 1. The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources. 2. One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs. Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability. My 2c, On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang wrote: > Hi Ben, > > Thanks for raising these questions?getting feedback is crucial in the > Preview stage of features. > > I wrote a reply to the Reddit thread so I'll just summarize here: > > It is important to note that *mapConcurrent()* is not a part of the > Structured Concurrency JEPs, so it is not designed to join SC scopes. > > I'm currently experimenting with ignoring-but-restoring interrupts on the > "calling thread" for *mapConcurrent()*, as well as capping > work-in-progress to *maxConcurrency* (not only capping the concurrency > but also the amount of completed-but-yet-to-be-pushed work). Both of these > adjustments should increase predictability of behavior in the face of > blocking operations with variable delays. > > Another adjustment I'm looking at right now is to harden/improve the > cleanup to wait for concurrent tasks to acknowledge cancellation, so that > once the finisher is done executing the VTs are known to have terminated. > > As for not preserving the encounter order, that would be a completely > different thing, and I'd encourage you to experiment with that if that > functionality would be interesting for your use-case(s). > > Again, thanks for your feedback! > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Friday, 3 January 2025 17:53 > *To:* core-libs-dev at openjdk.org > *Subject:* mapConcurrent() with InterruptedException > > Hi Java Experts, > > I sent this email incorrectly to loom-dev@ and was told on Reddit that > core-libs-dev is the right list. > > The question is about the behavior of mapConcurrent() when the thread is > interrupted. > > Currently mapConcurrent()'s finisher phase will re-interrupt the thread, > then stop at whatever element that has already been processed and return. > > This strikes me as a surprising behavior, because for example if I'm > running: > > Stream.of(1, 2, 3) > .gather(mapConcurrent(i -> i * 2)) > .toList() > > and the thread is being interrupted, the result could be any of [2], [2, > 4] or [2, 4, 6]. > > Since thread interruption is cooperative, there is no guarantee that the > thread being interrupted will just abort. It's quite possible that it'll > keep going and then will use for example [2] as the result of doubling the > list of [1, 2, 3], which is imho incorrect. > > In the Reddit > > thread, someone argued that interruption rarely happens so it's more of a > theoretical issue. But interruption can easily happen in Structured > Concurrency or in mapConcurrent() itself if any subtask has failed in order > to cancel/interrupt the other ongoing tasks. > > There had been discussion about alternative strategies: > > 1. Don't respond to interruption and just keep running to completion. > 2. Re-interrupt thread and wrap the InterruptedException in a standard > unchecked exception (StructuredConcurrencyInterruptedException?). > > > I have concerns with option 1 because it disables cancellation propagation > when mapConcurrent() itself is used in a subtask of a parent > mapConcurrent() or in a StructuredConcurrencyScope. > > Both equivalent Future-composition async code, or C++'s fiber trees > support cancellation propagation and imho it's a critical feature or else > it's possible that a zombie thread is still sending RPCs long after the > main thread has exited (failed, or falled back to some default action). > > My arguments for option 2: > > 1. InterruptedException is more error prone than traditional checked > exceptions for *users* to catch and handle. They can forget to > re-interrupt the thread. It's so confusing that even seasoned programmers > may not know they are *supposed to* re-interrupt the thread. > 2. With Stream API using functional interfaces like Supplier, > Function, the option of just tacking on "throws IE" isn't available to many > users. > 3. With Virtual Threads, it will be more acceptable, or even become > common to do blocking calls from a stream operation (including but > exclusive to mapConcurrent()). So the chance users are forced to deal with > IE will become substantially higher. > 4. Other APIs such as the Structured Concurrency API have already > started wrapping system checked exceptions like ExecutionException, > TimeoutException in unchecked exceptions ( join() > for > example). > 5. Imho, exceptions that we'd rather users not catch and handle but > instead should mostly just propagate up as is, should be unchecked. > > There is also a side discussion > > about whether mapConcurrent() is better off preserving input order or push > to downstream as soon as an element is computed. I'd love to discuss that > topic too but maybe it's better to start a separate thread? > > Thank you and cheers! > > Ben Yu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sun Jan 26 23:41:42 2025 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 27 Jan 2025 00:41:42 +0100 Subject: UUIDv7 Message-ID: <5A66E55E-3955-8D40-8A8F-3B3E58D5819D@hxcore.ol> An HTML attachment was scrubbed... URL: From epeter at openjdk.org Mon Jan 27 07:32:52 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 27 Jan 2025 07:32:52 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 10:36:29 GMT, Jatin Bhateja wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review suggestions incorporated. > >> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java > > Hi @eme64 , Rebased to the latest mainline code please proceed with test runs. @jatin-bhateja Thanks for the merge, testing is running! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2615015991 From epeter at openjdk.org Mon Jan 27 07:45:54 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 27 Jan 2025 07:45:54 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v11] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 10:36:29 GMT, Jatin Bhateja wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review suggestions incorporated. > >> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java > > Hi @eme64 , Rebased to the latest mainline code please proceed with test runs. @jatin-bhateja I'm getting a bad Copyright issue: [2025-01-27T07:30:55,551Z] BAD COPYRIGHT LINE: .../test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java [2025-01-27T07:30:55,552Z] 1 header format error(s). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2615032561 From epeter at openjdk.org Mon Jan 27 07:45:57 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 27 Jan 2025 07:45:57 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v12] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 10:39:34 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Rebasing to jdk mainline > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103 > - Refining IR match rule > - Review suggestions incorporated. > - Review comments resolutions > - Updating copyright year of modified files. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103 > - Review suggestions incorporated. > - Review comments resolutions > - Addressing review comments > - ... and 4 more: https://git.openjdk.org/jdk/compare/4a375e5b...e0602c1d test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights vectorReserved. Suggestion: * Copyright (c) 2025, Oracle and/or its affiliates. All rights Reserved. Looks like a "vector" snuck in there ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1930090362 From jbhateja at openjdk.org Mon Jan 27 08:35:44 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 27 Jan 2025 08:35:44 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v13] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Copyright header fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22754/files - new: https://git.openjdk.org/jdk/pull/22754/files/e0602c1d..4f22ed85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From jbhateja at openjdk.org Mon Jan 27 08:35:47 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 27 Jan 2025 08:35:47 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v12] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 07:42:48 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Rebasing to jdk mainline >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103 >> - Refining IR match rule >> - Review suggestions incorporated. >> - Review comments resolutions >> - Updating copyright year of modified files. >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8342103 >> - Review suggestions incorporated. >> - Review comments resolutions >> - Addressing review comments >> - ... and 4 more: https://git.openjdk.org/jdk/compare/4a375e5b...e0602c1d > > test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 2: > >> 1: /* >> 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights vectorReserved. > > Suggestion: > > * Copyright (c) 2025, Oracle and/or its affiliates. All rights Reserved. > > Looks like a "vector" snuck in there ? DONE ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1930140699 From asotona at openjdk.org Mon Jan 27 08:41:46 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 27 Jan 2025 08:41:46 GMT Subject: RFR: 8342465: Improve API documentation for java.lang.classfile [v2] In-Reply-To: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> References: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> Message-ID: On Fri, 24 Jan 2025 22:42:27 GMT, Chen Liang wrote: >> This is the last piece in the API documentation improvement of the Class-File API. >> >> This includes general documentation about transforms, models (and traversals), options, constants, and CodeBuilder factories. In particular, this preserves the package summary to avoid extra disruptions. See the APIDiff for more details. >> >> Please forgive this messy commit history; the work began before attribute changes were integrated and based off that, and in the process there were a few merges back and forth. >> The files changed/webrev should be reliable. >> >> Please review the associated CSR as well. >> >> Note that this intends to be backported to 24; this won't be clean, as the `JAVA_25_VERSION` constant is a new addition that does not exist on 24. >> >> Testing: Tier 1-3. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-overall/java.base/java/lang/classfile/package-summary.html >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-overall/java.base/java/lang/classfile/package-summary.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Better specification of range of u2 values, flag masks and versions Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23277#pullrequestreview-2574806515 From jkern at openjdk.org Mon Jan 27 08:45:47 2025 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 27 Jan 2025 08:45:47 GMT Subject: RFR: 8342807: Update links in java.base to use https:// [v5] In-Reply-To: References: Message-ID: On Tue, 21 Jan 2025 13:56:30 GMT, Eirik Bj?rsn?s wrote: >> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. >> >> Links in `java.security` and `share/data/tzdata` are excluded from this PR. >> >> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. >> >> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). >> >> Changes beyond the obvious are as follows: >> >> `linux/native/libsimdsort/xss-common-qsort.h`: >> The current link uses a non-default port number. Changed to using the default port number. Reported and fixed upstream as intel/x86-simd-sort#170 >> >> `share/man/keytool.md`: >> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. >> >> `unix/classes/sun/net/PortConfig.java` >> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. >> >> `unix/native/libjava/*`, >> Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs >> >> `unix/native/libjava/ProcessImpl_md.c` >> A link to an "unofficial" document on pasc.org now requires authentication. This document is probably outdated and the link is removed. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright headers for 2025 for Oracle files Marked as reviewed by jkern (Committer). src/java.base/unix/classes/sun/net/PortConfig.java line 57: > 55: case AIX: > 56: // The ephemeral port is OS version dependent on AIX: > 57: // https://www.ibm.com/support/pages/node/886227 LGTM ------------- PR Review: https://git.openjdk.org/jdk/pull/21633#pullrequestreview-2574814301 PR Review Comment: https://git.openjdk.org/jdk/pull/21633#discussion_r1930152051 From shade at openjdk.org Mon Jan 27 09:11:55 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 27 Jan 2025 09:11:55 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: <_Ma82xOEruDRHPxNMNEAVwCs1CAOp0D3ozJMVmVrSFc=.50beb18b-1587-49da-98b9-42b7601f3ea8@github.com> On Sun, 26 Jan 2025 07:30:22 GMT, Alan Bateman wrote: > Would you mind holding off until Tuesday to give time to get that done? Sure, there is no rush with this PR. I'll wait. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2615197062 From jvernee at openjdk.org Mon Jan 27 11:15:05 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 27 Jan 2025 11:15:05 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v18] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix test under VThread factory Tests came back green. I think this is good to go. ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23142#pullrequestreview-2575149904 From duke at openjdk.org Mon Jan 27 12:03:50 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 27 Jan 2025 12:03:50 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v18] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix test under VThread factory Thanks, looks ready to me, too. This is my first contribution - as far as I understand, any further concerns can still be voiced between '/integrate' and '/sponsor', so I'll go ahead ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2615568809 From duke at openjdk.org Mon Jan 27 12:03:51 2025 From: duke at openjdk.org (duke) Date: Mon, 27 Jan 2025 12:03:51 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v18] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix test under VThread factory @mernst-github Your change (at version c314d6a17c2d0b257ed4025c3a59cec84de38e80) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2615571994 From eirbjo at openjdk.org Mon Jan 27 12:49:50 2025 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 27 Jan 2025 12:49:50 GMT Subject: Integrated: 8342807: Update links in java.base to use https:// In-Reply-To: References: Message-ID: <2L9EfcptTq_Rc2jnpREVLEcPfxk5-R6Y2m8-o7wMh3o=.adea58e8-5a86-4fca-8970-db533249e82d@github.com> On Tue, 22 Oct 2024 10:19:23 GMT, Eirik Bj?rsn?s wrote: > Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http. > > Links in `java.security` and `share/data/tzdata` are excluded from this PR. > > This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. > > There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`). > > Changes beyond the obvious are as follows: > > `linux/native/libsimdsort/xss-common-qsort.h`: > The current link uses a non-default port number. Changed to using the default port number. Reported and fixed upstream as intel/x86-simd-sort#170 > > `share/man/keytool.md`: > www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. > > `unix/classes/sun/net/PortConfig.java` > The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports. > > `unix/native/libjava/*`, > Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs > > `unix/native/libjava/ProcessImpl_md.c` > A link to an "unofficial" document on pasc.org now requires authentication. This document is probably outdated and the link is removed. This pull request has now been integrated. Changeset: ffeb9b5a Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/ffeb9b5aff6b91297b4bbedb7b33670dc17309ed Stats: 18 lines in 8 files changed: 0 ins; 1 del; 17 mod 8342807: Update links in java.base to use https:// Reviewed-by: rriggs, ihse, jkern ------------- PR: https://git.openjdk.org/jdk/pull/21633 From liach at openjdk.org Mon Jan 27 14:06:55 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Jan 2025 14:06:55 GMT Subject: RFR: 8342465: Improve API documentation for java.lang.classfile [v2] In-Reply-To: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> References: <3JFgkE5IMlIZwB6lZOuPE0wnmdskiaOtN5irku2ZGZ8=.ec89650e-1a31-4902-bbee-54a1fe5c5ec4@github.com> Message-ID: On Fri, 24 Jan 2025 22:42:27 GMT, Chen Liang wrote: >> This is the last piece in the API documentation improvement of the Class-File API. >> >> This includes general documentation about transforms, models (and traversals), options, constants, and CodeBuilder factories. In particular, this preserves the package summary to avoid extra disruptions. See the APIDiff for more details. >> >> Please forgive this messy commit history; the work began before attribute changes were integrated and based off that, and in the process there were a few merges back and forth. >> The files changed/webrev should be reliable. >> >> Please review the associated CSR as well. >> >> Note that this intends to be backported to 24; this won't be clean, as the `JAVA_25_VERSION` constant is a new addition that does not exist on 24. >> >> Testing: Tier 1-3. >> >> APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-overall/java.base/java/lang/classfile/package-summary.html >> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-overall/java.base/java/lang/classfile/package-summary.html > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Better specification of range of u2 values, flag masks and versions Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23277#issuecomment-2615845305 From liach at openjdk.org Mon Jan 27 14:06:58 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Jan 2025 14:06:58 GMT Subject: Integrated: 8342465: Improve API documentation for java.lang.classfile In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 19:48:55 GMT, Chen Liang wrote: > This is the last piece in the API documentation improvement of the Class-File API. > > This includes general documentation about transforms, models (and traversals), options, constants, and CodeBuilder factories. In particular, this preserves the package summary to avoid extra disruptions. See the APIDiff for more details. > > Please forgive this messy commit history; the work began before attribute changes were integrated and based off that, and in the process there were a few merges back and forth. > The files changed/webrev should be reliable. > > Please review the associated CSR as well. > > Note that this intends to be backported to 24; this won't be clean, as the `JAVA_25_VERSION` constant is a new addition that does not exist on 24. > > Testing: Tier 1-3. > > APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-overall/java.base/java/lang/classfile/package-summary.html > Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-overall/java.base/java/lang/classfile/package-summary.html This pull request has now been integrated. Changeset: 1d8ccb89 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/1d8ccb89204cc5efbcecdaa0c9de7b2c5a109d5d Stats: 2962 lines in 44 files changed: 1948 ins; 30 del; 984 mod 8342465: Improve API documentation for java.lang.classfile Reviewed-by: asotona, darcy ------------- PR: https://git.openjdk.org/jdk/pull/23277 From viktor.klang at oracle.com Mon Jan 27 14:11:07 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Mon, 27 Jan 2025 14:11:07 +0000 Subject: [External] : Re: mapConcurrent() with InterruptedException In-Reply-To: References: Message-ID: Hi! Please see: https://github.com/openjdk/jdk/pull/23100 Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu Sent: Sunday, 26 January 2025 23:03 To: Viktor Klang Cc: core-libs-dev at openjdk.org Subject: [External] : Re: mapConcurrent() with InterruptedException Checking in on what you've found out, Viktor. From where we left off, I understand that you were looking at alternatives instead of silent truncation? Have you reached any conclusion? We touched on disallowing interruption during mapConcurrent(). I still have concerns with disabling cancellation, because it basically undoes this API note from the javadoc: API Note: In progress tasks will be attempted to be cancelled, on a best-effort basis, in situations where the downstream no longer wants to receive any more elements. In reality, people will use mapConcurrent() to fan out rpcs. Sometimes these rpcs are just a single blocking call; yet sometimes they may themselves be a Structured Concurrency scope, with 2 or 3 rpcs that constitute a single logical operation. Under two conditions, cancellation is imho important semantic: 1. The downstream code uses filter().findFirst(), and when it sees an element, it will return and no longer needs the other pending rpcs to complete. If cancellation is disabled, these unnecessary rpcs will waste system resources. 2. One of the rpc throws and the Stream pipeline needs to propagate the exception. Again, if the other rpcs cannot be cancelled, we'll have many zombie rpcs. Zombie rpcs may or may not be a deal breaker, depending on the specific use case. But for a JDK library, losing cancellation would have a negative impact on usability. My 2c, On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang > wrote: Hi Ben, Thanks for raising these questions?getting feedback is crucial in the Preview stage of features. I wrote a reply to the Reddit thread so I'll just summarize here: It is important to note that mapConcurrent() is not a part of the Structured Concurrency JEPs, so it is not designed to join SC scopes. I'm currently experimenting with ignoring-but-restoring interrupts on the "calling thread" for mapConcurrent(), as well as capping work-in-progress to maxConcurrency (not only capping the concurrency but also the amount of completed-but-yet-to-be-pushed work). Both of these adjustments should increase predictability of behavior in the face of blocking operations with variable delays. Another adjustment I'm looking at right now is to harden/improve the cleanup to wait for concurrent tasks to acknowledge cancellation, so that once the finisher is done executing the VTs are known to have terminated. As for not preserving the encounter order, that would be a completely different thing, and I'd encourage you to experiment with that if that functionality would be interesting for your use-case(s). Again, thanks for your feedback! Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev > on behalf of Jige Yu > Sent: Friday, 3 January 2025 17:53 To: core-libs-dev at openjdk.org > Subject: mapConcurrent() with InterruptedException Hi Java Experts, I sent this email incorrectly to loom-dev@ and was told on Reddit that core-libs-dev is the right list. The question is about the behavior of mapConcurrent() when the thread is interrupted. Currently mapConcurrent()'s finisher phase will re-interrupt the thread, then stop at whatever element that has already been processed and return. This strikes me as a surprising behavior, because for example if I'm running: Stream.of(1, 2, 3) .gather(mapConcurrent(i -> i * 2)) .toList() and the thread is being interrupted, the result could be any of [2], [2, 4] or [2, 4, 6]. Since thread interruption is cooperative, there is no guarantee that the thread being interrupted will just abort. It's quite possible that it'll keep going and then will use for example [2] as the result of doubling the list of [1, 2, 3], which is imho incorrect. In the Reddit thread, someone argued that interruption rarely happens so it's more of a theoretical issue. But interruption can easily happen in Structured Concurrency or in mapConcurrent() itself if any subtask has failed in order to cancel/interrupt the other ongoing tasks. There had been discussion about alternative strategies: 1. Don't respond to interruption and just keep running to completion. 2. Re-interrupt thread and wrap the InterruptedException in a standard unchecked exception (StructuredConcurrencyInterruptedException?). I have concerns with option 1 because it disables cancellation propagation when mapConcurrent() itself is used in a subtask of a parent mapConcurrent() or in a StructuredConcurrencyScope. Both equivalent Future-composition async code, or C++'s fiber trees support cancellation propagation and imho it's a critical feature or else it's possible that a zombie thread is still sending RPCs long after the main thread has exited (failed, or falled back to some default action). My arguments for option 2: 1. InterruptedException is more error prone than traditional checked exceptions for users to catch and handle. They can forget to re-interrupt the thread. It's so confusing that even seasoned programmers may not know they are supposed to re-interrupt the thread. 2. With Stream API using functional interfaces like Supplier, Function, the option of just tacking on "throws IE" isn't available to many users. 3. With Virtual Threads, it will be more acceptable, or even become common to do blocking calls from a stream operation (including but exclusive to mapConcurrent()). So the chance users are forced to deal with IE will become substantially higher. 4. Other APIs such as the Structured Concurrency API have already started wrapping system checked exceptions like ExecutionException, TimeoutException in unchecked exceptions ( join() for example). 5. Imho, exceptions that we'd rather users not catch and handle but instead should mostly just propagate up as is, should be unchecked. There is also a side discussion about whether mapConcurrent() is better off preserving input order or push to downstream as soon as an element is computed. I'd love to discuss that topic too but maybe it's better to start a separate thread? Thank you and cheers! Ben Yu -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Mon Jan 27 15:22:21 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Jan 2025 15:22:21 GMT Subject: [jdk24] RFR: 8342465: Improve API documentation for java.lang.classfile Message-ID: Please review a non-clean backport of #23277, the final patch in the improvements to the Class-File API. The backport is non-clean because a new JAVA_25_VERSION constant was added in 25; otherwise the patch applied cleanly. Tests: Submitted tier 1-3 ------------- Commit messages: - Backport 1d8ccb89204cc5efbcecdaa0c9de7b2c5a109d5d Changes: https://git.openjdk.org/jdk/pull/23317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342465 Stats: 2959 lines in 44 files changed: 1946 ins; 30 del; 983 mod Patch: https://git.openjdk.org/jdk/pull/23317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23317/head:pull/23317 PR: https://git.openjdk.org/jdk/pull/23317 From yujige at gmail.com Mon Jan 27 16:00:26 2025 From: yujige at gmail.com (Jige Yu) Date: Mon, 27 Jan 2025 08:00:26 -0800 Subject: [External] : Re: mapConcurrent() with InterruptedException In-Reply-To: References: Message-ID: Thanks Viktor! It looks like the current fix ignores interruption. I want to make sure my concern of it defeating cancellation is heard and understood. The scenarios I worry about is for a mapConcurrent() that fans out to another method call, which internally calls mapConcurrent() as implementation detail. An example: List refundHelper(transaction) { transaction.creditCardAccounts.stream() .gather(mapConcurrent(acct -> service.refund(acct)) .toList(); } transactions.stream() .gather(mapConcurrent(transaction -> refundHelper(transaction)); It seems undesirable that in such a case all the service.refund() calls become non cancellable, because the only way the outer mapConcurrent() cancels the refundHelper() calls is through Thread.interrupt() the virtual threads that call refundHelper(), which would then be disabled by the inner mapConcurrent(). Does this example make sense to you? I can further explain if anything isn't clear. But I want to make sure the decision to disable interruption is deliberate judgement call that such nested mapConcurrent() is unlikely,or not important. Cheers, On Mon, Jan 27, 2025 at 6:11?AM Viktor Klang wrote: > Hi! > > Please see: https://github.com/openjdk/jdk/pull/23100 > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* Jige Yu > *Sent:* Sunday, 26 January 2025 23:03 > *To:* Viktor Klang > *Cc:* core-libs-dev at openjdk.org > *Subject:* [External] : Re: mapConcurrent() with InterruptedException > > Checking in on what you've found out, Viktor. > > From where we left off, I understand that you were looking at alternatives > instead of silent truncation? > > Have you reached any conclusion? > > We touched on disallowing interruption during mapConcurrent(). I still > have concerns with disabling cancellation, because it basically undoes this > API note from the javadoc > > : > > API Note: > In progress tasks will be attempted to be cancelled, on a best-effort > basis, in situations where the downstream no longer wants to receive any > more elements. > > In reality, people will use mapConcurrent() to fan out rpcs. Sometimes > these rpcs are just a single blocking call; yet sometimes they may > themselves be a Structured Concurrency scope, with 2 or 3 rpcs that > constitute a single logical operation. Under two conditions, cancellation > is imho important semantic: > > 1. The downstream code uses filter().findFirst(), and when it sees an > element, it will return and no longer needs the other pending rpcs to > complete. If cancellation is disabled, these unnecessary rpcs will waste > system resources. > 2. One of the rpc throws and the Stream pipeline needs to propagate > the exception. Again, if the other rpcs cannot be cancelled, we'll have > many zombie rpcs. > > Zombie rpcs may or may not be a deal breaker, depending on the specific > use case. But for a JDK library, losing cancellation would have a negative > impact on usability. > > My 2c, > > > On Fri, Jan 3, 2025 at 9:18?AM Viktor Klang > wrote: > > Hi Ben, > > Thanks for raising these questions?getting feedback is crucial in the > Preview stage of features. > > I wrote a reply to the Reddit thread so I'll just summarize here: > > It is important to note that *mapConcurrent()* is not a part of the > Structured Concurrency JEPs, so it is not designed to join SC scopes. > > I'm currently experimenting with ignoring-but-restoring interrupts on the > "calling thread" for *mapConcurrent()*, as well as capping > work-in-progress to *maxConcurrency* (not only capping the concurrency > but also the amount of completed-but-yet-to-be-pushed work). Both of these > adjustments should increase predictability of behavior in the face of > blocking operations with variable delays. > > Another adjustment I'm looking at right now is to harden/improve the > cleanup to wait for concurrent tasks to acknowledge cancellation, so that > once the finisher is done executing the VTs are known to have terminated. > > As for not preserving the encounter order, that would be a completely > different thing, and I'd encourage you to experiment with that if that > functionality would be interesting for your use-case(s). > > Again, thanks for your feedback! > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > ------------------------------ > *From:* core-libs-dev on behalf of Jige > Yu > *Sent:* Friday, 3 January 2025 17:53 > *To:* core-libs-dev at openjdk.org > *Subject:* mapConcurrent() with InterruptedException > > Hi Java Experts, > > I sent this email incorrectly to loom-dev@ and was told on Reddit that > core-libs-dev is the right list. > > The question is about the behavior of mapConcurrent() when the thread is > interrupted. > > Currently mapConcurrent()'s finisher phase will re-interrupt the thread, > then stop at whatever element that has already been processed and return. > > This strikes me as a surprising behavior, because for example if I'm > running: > > Stream.of(1, 2, 3) > .gather(mapConcurrent(i -> i * 2)) > .toList() > > and the thread is being interrupted, the result could be any of [2], [2, > 4] or [2, 4, 6]. > > Since thread interruption is cooperative, there is no guarantee that the > thread being interrupted will just abort. It's quite possible that it'll > keep going and then will use for example [2] as the result of doubling the > list of [1, 2, 3], which is imho incorrect. > > In the Reddit > > thread, someone argued that interruption rarely happens so it's more of a > theoretical issue. But interruption can easily happen in Structured > Concurrency or in mapConcurrent() itself if any subtask has failed in order > to cancel/interrupt the other ongoing tasks. > > There had been discussion about alternative strategies: > > 1. Don't respond to interruption and just keep running to completion. > 2. Re-interrupt thread and wrap the InterruptedException in a standard > unchecked exception (StructuredConcurrencyInterruptedException?). > > > I have concerns with option 1 because it disables cancellation propagation > when mapConcurrent() itself is used in a subtask of a parent > mapConcurrent() or in a StructuredConcurrencyScope. > > Both equivalent Future-composition async code, or C++'s fiber trees > support cancellation propagation and imho it's a critical feature or else > it's possible that a zombie thread is still sending RPCs long after the > main thread has exited (failed, or falled back to some default action). > > My arguments for option 2: > > 1. InterruptedException is more error prone than traditional checked > exceptions for *users* to catch and handle. They can forget to > re-interrupt the thread. It's so confusing that even seasoned programmers > may not know they are *supposed to* re-interrupt the thread. > 2. With Stream API using functional interfaces like Supplier, > Function, the option of just tacking on "throws IE" isn't available to many > users. > 3. With Virtual Threads, it will be more acceptable, or even become > common to do blocking calls from a stream operation (including but > exclusive to mapConcurrent()). So the chance users are forced to deal with > IE will become substantially higher. > 4. Other APIs such as the Structured Concurrency API have already > started wrapping system checked exceptions like ExecutionException, > TimeoutException in unchecked exceptions ( join() > for > example). > 5. Imho, exceptions that we'd rather users not catch and handle but > instead should mostly just propagate up as is, should be unchecked. > > There is also a side discussion > > about whether mapConcurrent() is better off preserving input order or push > to downstream as soon as an element is computed. I'd love to discuss that > topic too but maybe it's better to start a separate thread? > > Thank you and cheers! > > Ben Yu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Mon Jan 27 16:34:54 2025 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 27 Jan 2025 16:34:54 GMT Subject: [jdk24] RFR: 8342465: Improve API documentation for java.lang.classfile In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 15:16:12 GMT, Chen Liang wrote: > Please review a non-clean backport of #23277, the final patch in the improvements to the Class-File API. The backport is non-clean because a new JAVA_25_VERSION constant was added in 25; otherwise the patch applied cleanly. > > Tests: No related failure in tier 1-3 so far Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23317#pullrequestreview-2575939041 From jlu at openjdk.org Mon Jan 27 17:27:53 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 27 Jan 2025 17:27:53 GMT Subject: [jdk24] RFR: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> Message-ID: On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu wrote: > Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24. > > The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23307#issuecomment-2616430340 From jlu at openjdk.org Mon Jan 27 17:27:54 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 27 Jan 2025 17:27:54 GMT Subject: [jdk24] Integrated: 8347498: JDK 24 RDP2 L10n resource files update In-Reply-To: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> References: <9eZVlXjnon7RUI2OlWNx8IwwUB9bqw4VGnjw2GMmw_Q=.b1061b6e-0d5b-4c8e-bdb1-675ba197b69c@github.com> Message-ID: <9auIj0WRflyzVXt6UFfMaOa8CzlSwgPYww5cJ13905Q=.2fa6a88b-514e-4ac6-b814-f29f58bb7005@github.com> On Fri, 24 Jan 2025 21:51:39 GMT, Justin Lu wrote: > Please review this PR which is a backport of [dec93675](https://github.com/openjdk/jdk/commit/dec93675ab3e4c271b14a254df75dc838f1346ea) that updates the l10n translations for jdk24. > > The commit being backported was authored by Justin Lu on 24 Jan 2025 and was reviewed by Severin Gehwolf, Damon Nguyen, Naoto Sato, Joe Wang and Alexey Semenyuk. This pull request has now been integrated. Changeset: a315b932 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/a315b9326b07a6241858c55d15e4cbec4ab3773b Stats: 93 lines in 26 files changed: 33 ins; 15 del; 45 mod 8347498: JDK 24 RDP2 L10n resource files update Reviewed-by: dnguyen, naoto, iris Backport-of: dec93675ab3e4c271b14a254df75dc838f1346ea ------------- PR: https://git.openjdk.org/jdk/pull/23307 From naoto at openjdk.org Mon Jan 27 18:07:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 27 Jan 2025 18:07:53 GMT Subject: RFR: 8348205: Improve cutover time selection when building available currencies set In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 23:56:46 GMT, Justin Lu wrote: > Please review this PR which improves the time measurement for cut-over time comparisons when building the available set of currencies in _java.util.Currency._ Currently, a new time was measured for each special case currency. This PR updates the behavior to use the same time for all such cases Looks good. Please update the copyright year to 2025 src/java.base/share/classes/java/util/Currency.java line 447: > 445: synchronized(Currency.class) { > 446: if (available == null) { > 447: // reuse same time for all special case cut-over date checks The comment is correct, but it might not be necessary, as it would not be significant unless one knows the background ------------- PR Review: https://git.openjdk.org/jdk/pull/23309#pullrequestreview-2576192283 PR Review Comment: https://git.openjdk.org/jdk/pull/23309#discussion_r1930978307 From swen at openjdk.org Mon Jan 27 18:16:49 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 27 Jan 2025 18:16:49 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v6] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 19:39:00 GMT, Raffaello Giulietti wrote: >> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove unused >> - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java >> >> Co-authored-by: Chen Liang > > I might be wrong, but I think that `&&` are compiled down to conditionals? > The code optimistically assumes that the string is parsable as an `int|long`, so `&` might lead to simpler machine code. > > Of course, if the benchmarks are good with `&&`, then please feel free to replace. @rgiulietti I've made improvements based on your suggestions. Could you please review this PR again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2616554692 From jlu at openjdk.org Mon Jan 27 18:30:39 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 27 Jan 2025 18:30:39 GMT Subject: RFR: 8348205: Improve cutover time selection when building available currencies set [v2] In-Reply-To: References: Message-ID: > Please review this PR which improves the time measurement for cut-over time comparisons when building the available set of currencies in _java.util.Currency._ Currently, a new time was measured for each special case currency. This PR updates the behavior to use the same time for all such cases Justin Lu has updated the pull request incrementally with one additional commit since the last revision: reflect review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23309/files - new: https://git.openjdk.org/jdk/pull/23309/files/9305f954..c49fb581 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23309&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23309&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23309/head:pull/23309 PR: https://git.openjdk.org/jdk/pull/23309 From naoto at openjdk.org Mon Jan 27 18:30:39 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 27 Jan 2025 18:30:39 GMT Subject: RFR: 8348205: Improve cutover time selection when building available currencies set [v2] In-Reply-To: References: Message-ID: <7EoHuRcobvcccS5xwG03u0ESFoMqJSJp1C8kMmu274E=.f0f73e1d-280f-4e64-90ca-decf03f4d330@github.com> On Mon, 27 Jan 2025 18:26:46 GMT, Justin Lu wrote: >> Please review this PR which improves the time measurement for cut-over time comparisons when building the available set of currencies in _java.util.Currency._ Currently, a new time was measured for each special case currency. This PR updates the behavior to use the same time for all such cases > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23309#pullrequestreview-2576239042 From jlu at openjdk.org Mon Jan 27 18:30:40 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 27 Jan 2025 18:30:40 GMT Subject: RFR: 8348205: Improve cutover time selection when building available currencies set [v2] In-Reply-To: References: Message-ID: <2yM8Ie2BoFxsdzSwGm-Vbmr1ia2AOmN3ZCtLa8Wkvrw=.2440cbec-9444-49f7-83dd-6fd64b8e968e@github.com> On Mon, 27 Jan 2025 18:03:48 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> reflect review > > src/java.base/share/classes/java/util/Currency.java line 447: > >> 445: synchronized(Currency.class) { >> 446: if (available == null) { >> 447: // reuse same time for all special case cut-over date checks > > The comment is correct, but it might not be necessary, as it would not be significant unless one knows the background Comment removed and year bumped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23309#discussion_r1930998048 From rriggs at openjdk.org Mon Jan 27 19:43:47 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 27 Jan 2025 19:43:47 GMT Subject: RFR: 8348205: Improve cutover time selection when building available currencies set [v2] In-Reply-To: References: Message-ID: <1NwduEg0kqwemkb6KkCpXCjBD1w5nNVdltTLNMZ-YmY=.b83b0895-cbf8-4de7-aebb-793567eb284d@github.com> On Mon, 27 Jan 2025 18:30:39 GMT, Justin Lu wrote: >> Please review this PR which improves the time measurement for cut-over time comparisons when building the available set of currencies in _java.util.Currency._ Currently, a new time was measured for each special case currency. This PR updates the behavior to use the same time for all such cases > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23309#pullrequestreview-2576396678 From duke at openjdk.org Mon Jan 27 19:48:06 2025 From: duke at openjdk.org (Matthias Ernst) Date: Mon, 27 Jan 2025 19:48:06 GMT Subject: Integrated: 8287788: Implement a better allocator for downcalls In-Reply-To: References: Message-ID: On Wed, 15 Jan 2025 21:39:05 GMT, Matthias Ernst wrote: > Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. > > Sample stack trace: > > java.lang.Thread.State: RUNNABLE > at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) > ... > at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) > at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) > ... > at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) > > > To alleviate this, this PR implements a per carrier-thread stacked allocator. > > Performance (MBA M3): > > > Before: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op > CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op > > After: > Benchmark Mode Cnt Score Error Units > CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op > CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op > > > `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. This pull request has now been integrated. Changeset: 8cc13045 Author: Matthias Ernst Committer: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/8cc13045428eebb8933df865f9a87f0f91909ba5 Stats: 488 lines in 7 files changed: 468 ins; 14 del; 6 mod 8287788: Implement a better allocator for downcalls Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/23142 From rriggs at openjdk.org Mon Jan 27 20:04:49 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 27 Jan 2025 20:04:49 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v4] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 18:00:06 GMT, Justin Lu wrote: >> Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. >> >> A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > new methods do not need to be synchronized Looks good ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23251#pullrequestreview-2576435401 From rgiulietti at openjdk.org Mon Jan 27 20:09:54 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 27 Jan 2025 20:09:54 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v9] In-Reply-To: References: Message-ID: On Sat, 25 Jan 2025 04:01:47 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java > - use & > - from @rgiulietti > - remove unused > - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java > > Co-authored-by: Chen Liang > - vector digit2 > - emptyInput -> nullInput > - use CharacterDataLatin1.instance::isDigit > - add comments > - reduce codeSize > - ... and 15 more: https://git.openjdk.org/jdk/compare/f446cefe...0bacfa01 This line on a test is now failing because it's expecting a specific `NumberFormatException` message. https://github.com/openjdk/jdk/blob/21feef32803b2593b097fb225c7a4c7cd46525da/test/jdk/com/sun/jdi/JdbExprTest.java#L114 I don't have much time to have a look during this week, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2616783945 From jiangli at openjdk.org Mon Jan 27 21:58:47 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 27 Jan 2025 21:58:47 GMT Subject: RFR: 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 02:11:29 GMT, Jiangli Zhou wrote: > Please review this trivial cleanup that removes the #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks. I would appreciate if anyone can help take a look of this, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23247#issuecomment-2616980741 From asemenyuk at openjdk.org Mon Jan 27 22:08:22 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 27 Jan 2025 22:08:22 GMT Subject: RFR: 8347272: [ubsan] JvmLauncher.cpp:262:52: runtime error: applying non-zero offset 40 to null pointer In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:03:41 GMT, Alexey Semenyuk wrote: > Rework pointer arithmetic to avoid null pointer @sashamatveev, @MBaesken PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/23320#issuecomment-2616993852 From asemenyuk at openjdk.org Mon Jan 27 22:08:22 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 27 Jan 2025 22:08:22 GMT Subject: RFR: 8347272: [ubsan] JvmLauncher.cpp:262:52: runtime error: applying non-zero offset 40 to null pointer Message-ID: Rework pointer arithmetic to avoid null pointer ------------- Commit messages: - Fix compilation error on Linux: - Bugfix - Copyright year updated - 8347272: [ubsan] JvmLauncher.cpp:262:52: runtime error: applying non-zero offset 40 to null pointer Changes: https://git.openjdk.org/jdk/pull/23320/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23320&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347272 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23320/head:pull/23320 PR: https://git.openjdk.org/jdk/pull/23320 From almatvee at openjdk.org Mon Jan 27 23:02:46 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 27 Jan 2025 23:02:46 GMT Subject: RFR: 8347272: [ubsan] JvmLauncher.cpp:262:52: runtime error: applying non-zero offset 40 to null pointer In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:03:41 GMT, Alexey Semenyuk wrote: > Rework pointer arithmetic to avoid null pointer Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23320#pullrequestreview-2576723626 From sviswanathan at openjdk.org Mon Jan 27 23:29:50 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 27 Jan 2025 23:29:50 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v13] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 08:35:44 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Copyright header fix test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Year should be 2024, 2025, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1931316524 From liach at openjdk.org Mon Jan 27 23:34:56 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Jan 2025 23:34:56 GMT Subject: [jdk24] RFR: 8342465: Improve API documentation for java.lang.classfile In-Reply-To: References: Message-ID: <2B0ZgMFhpSe1po2XqEdacJWRN6U3YsZHNi93G9gdRV4=.1cc3a5a7-18d0-4843-b45c-e1980ebc3a5c@github.com> On Mon, 27 Jan 2025 15:16:12 GMT, Chen Liang wrote: > Please review a non-clean backport of #23277, the final patch in the improvements to the Class-File API. The backport is non-clean because a new JAVA_25_VERSION constant was added in 25; otherwise the patch applied cleanly. > > Tests: No related failure in tier 1-3 so far Thanks for the reviews! Tests tier 1-3 look good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23317#issuecomment-2617129456 From liach at openjdk.org Mon Jan 27 23:34:57 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 27 Jan 2025 23:34:57 GMT Subject: [jdk24] Integrated: 8342465: Improve API documentation for java.lang.classfile In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 15:16:12 GMT, Chen Liang wrote: > Please review a non-clean backport of #23277, the final patch in the improvements to the Class-File API. The backport is non-clean because a new JAVA_25_VERSION constant was added in 25; otherwise the patch applied cleanly. > > Tests: No related failure in tier 1-3 so far This pull request has now been integrated. Changeset: 612ae737 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/612ae737c0333861ae7c59a50909c6a2694c69a2 Stats: 2959 lines in 44 files changed: 1946 ins; 30 del; 983 mod 8342465: Improve API documentation for java.lang.classfile Reviewed-by: asotona Backport-of: 1d8ccb89204cc5efbcecdaa0c9de7b2c5a109d5d ------------- PR: https://git.openjdk.org/jdk/pull/23317 From swen at openjdk.org Tue Jan 28 01:24:43 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 01:24:43 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v10] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: error message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/0bacfa01..284ad6a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=08-09 Stats: 18 lines in 3 files changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From sviswanathan at openjdk.org Tue Jan 28 01:34:52 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 28 Jan 2025 01:34:52 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v13] In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 08:35:44 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Copyright header fix Some more minor comments. src/hotspot/share/opto/addnode.cpp line 1546: > 1544: > 1545: // As per IEEE 754 specification, floating point comparison consider +ve and -ve > 1546: // zeros as equals. Thus, performing signed integral comparison for max value Should be "min value detection". src/hotspot/share/opto/addnode.cpp line 1624: > 1622: // As per IEEE 754 specification, floating point comparison consider +ve and -ve > 1623: // zeros as equals. Thus, performing signed integral comparison for min value > 1624: // detection. Should be "max value detection". src/hotspot/share/opto/divnode.cpp line 848: > 846: // If the dividend is a constant zero > 847: // Note: if t1 and t2 are zero then result is NaN (JVMS page 213) > 848: // Test TypeF::ZERO is not sufficient as it could be negative zero Comment should be TypeH:ZERO is not sufficient ------------- PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2576801437 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1931347845 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1931347430 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1931376932 From swen at openjdk.org Tue Jan 28 01:44:56 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 01:44:56 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v10] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 01:24:43 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > error message The error behavior of these two methods before PR #16050 merged on October 7, 2023 was as follows. int parseInt(CharSequence s, int beginIndex, int endIndex, int radix) { throw NumberFormatException.forInputString("", radix); } long parseLong(CharSequence s, int beginIndex, int endIndex, int radix) { throw new NumberFormatException(""); } This error message is not fixed, so I think it can be changed. To be compatible with the error, I made a change to use the exception information of forInputString(String, int) when s is a String and beginIndex is 0 and endIndex == s.length(). ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2617468773 From vlivanov at openjdk.org Tue Jan 28 04:06:45 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 28 Jan 2025 04:06:45 GMT Subject: RFR: 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas wrote: > The proposed change here is the following: > 1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object > 2. Remove the Context object and its corresponding cleaner > > (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose. > > First what goes wrong without this patch. > > Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. > > For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. > > The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection. > > If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. > > For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ... Good work, Axel. `Cleaner`-based solution to manage nmethod dependencies on `java.lang.invoke.CallSite`s does look redundant. If that's the case, then I'd expect that by the time cleanup action is invoked corresponding dependency list is empty. Is it the case in practice? But the original problem makes me wonder whether `Cleaner`-based approach to manage native resources is broken or not. Dependent instance is used to avoid referent to be artificially kept alive by cleanup action. If it is not safe to access it in order to perform cleanup, how the whole approach is intended to work? Or does anything make 'CallSite` use case special? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23194#issuecomment-2617796038 From galder at openjdk.org Tue Jan 28 06:10:49 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Tue, 28 Jan 2025 06:10:49 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> <4NGZx_gqvc7xMcXCTef2c_ns-nMxznsB42NnlQJqX4Q=.8cdc00f9-c9a7-409a-b5c3-885d0677b952@github.com> Message-ID: <2Eoj5haSgq0ueNj4nGE-7nqR-4t0xhnmmAUAsFuNjck=.1e748c98-8c34-42c9-ae80-d460e41e3ba3@github.com> On Mon, 20 Jan 2025 08:00:52 GMT, Emanuel Peter wrote: >> @eme64 I've addressed all the comments. I've not run the `VectorReduction2` for the reasons explained in the previous comment. Happy to add more details to `MinMaxVector` if you feel it's necessary. > > @galderz Ah, right. I understand about the branch probability. > > Hmm, maybe we should eventually change the `VectorReduction2` benchmark, or just remove the `min/max` benchmark there completely, as it depends on the random input values. > > Ah, though we have a fixed `seed`, so rerunning the benchmark would at least have consistent branching characteristics. So then it could make sense to run the benchmark, we just don't know the probability. I mean I ran it before for the `in/float/double min/max`, and all of them see a solid speedup. So I would expect the same for `long`, it would be nice to at least see the numbers. > > You could extend your benchmark to `float / double` as well, to make it complete. But that could also be a follow-up RFE. > >>I would expect a similar thing to happen when it comes to asimd envs with max vector size >= 32 (e.g. Graviton 3). Those will see vectorization occur and improvements kick in at 100%. Other systems (e.g. Graviton 4) will see a regression at 100%. This means that your work in https://github.com/openjdk/jdk/pull/20098#discussion_r1901576209 to avoid the max vector size limitation might become more important once my PR here goes in. > > So are you saying there are machines where we are now getting some regressions with your patch (2-element cases)? It would be nice to see the numbers summarized here. I'm losing the overview a little over the 50+ messages now ? @eme64 Fair points. I'll provide a detailed summary with some final numbers after FOSDEM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2617968437 From jwaters at openjdk.org Tue Jan 28 06:21:53 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 28 Jan 2025 06:21:53 GMT Subject: RFR: 8342868: Errors related to unused code on Windows after 8339120 in core libs [v2] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove the got local Keep open please ------------- PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-2617997626 From jbhateja at openjdk.org Tue Jan 28 06:26:11 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 28 Jan 2025 06:26:11 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v14] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Updating typos in comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22754/files - new: https://git.openjdk.org/jdk/pull/22754/files/4f22ed85..854fc73f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=12-13 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From aboldtch at openjdk.org Tue Jan 28 07:26:48 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 28 Jan 2025 07:26:48 GMT Subject: RFR: 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 04:04:39 GMT, Vladimir Ivanov wrote: > Good work, Axel. `Cleaner`-based solution to manage nmethod dependencies on `java.lang.invoke.CallSite`s does look redundant. If that's the case, then I'd expect that by the time cleanup action is invoked corresponding dependency list is empty. Is it the case in practice? For our STW collectors this should always be the case, as the cleaner will run its code after the collection where the CallSite dies, which will in turn have unlinked the nmethods. For the concurrent collectors, because references processing is done before nmethod unlinking, we might run the cleaner code before the GC gets to the nmethod, and as such observe a none empty list. I've run some sanity stress tests locally with G1 and the following patch: diff --git a/src/hotspot/share/prims/methodHandles.cpp b/src/hotspot/share/prims/methodHandles.cpp index 97e3eae1a2f..fadcec9bd90 100644 --- a/src/hotspot/share/prims/methodHandles.cpp +++ b/src/hotspot/share/prims/methodHandles.cpp @@ -1330,6 +1331,7 @@ JVM_ENTRY(void, MHN_clearCallSiteContext(JNIEnv* env, jobject igcls, jobject con NoSafepointVerifier nsv; MutexLocker ml(THREAD, CodeCache_lock, Mutex::_no_safepoint_check_flag); DependencyContext deps = java_lang_invoke_MethodHandleNatives_CallSiteContext::vmdependencies(context()); + guarantee(deps.is_empty(), "just checking"); deps.remove_and_mark_for_deoptimization_all_dependents(&deopt_scope); // This is assumed to be an 'atomic' operation by verification. // So keep it under lock for now. But I'll take it a spin through our CI as well. But if this were to occur it would mean we must have either missed adding a dependent CallSite oop to a linked nmethod, or that GC failed to unlink a nmethod with a dead oop. Neither would be very healthy. > But the original problem makes me wonder whether `Cleaner`-based approach to manage native resources is broken or not. _Tangent: `Cleaner`-based native resource management may be broken but not because of this. (It suffers from a similar problem to finalisers, namely that they are triggered at the GCs discretion, and the GC have no real insight into the cost of a "native resource" so it may never be cleaned. Trying to create scoped lifetimes, with try-with-resource should always be preferred)_ > Dependent instance is used to avoid referent to be artificially kept alive by cleanup action. If it is not safe to access it in order to perform cleanup, how the whole approach is intended to work? Or does anything make 'CallSite` use case special? `CallSite` is special, because the GC knows about it. The reason being is that the GC must remove all nmethod dependencies when unlinking, otherwise we would have a dangling pointer and an ABA problem. When unlinking the GC runs the following code. for (Dependencies::DepStream deps(this); deps.next(); ) { if (deps.type() == Dependencies::call_site_target_value) { // CallSite dependencies are managed on per-CallSite instance basis. oop call_site = deps.argument_oop(0); MethodHandles::clean_dependency_context(call_site); } The `call_site` in question here may or may not be dead. But regardless it will have a link to the currently unlinking nmethod, which must be removed. After unlinking the GC will phase the system (by a handshake or by the property of doing all this work in a safepoint). If it was not removed it is a dangling pointer, not only that it is a pointer we are more than likely going to reuse for a new nmethod, which will make them indistinguishable, leading to ABA. There is a world where we move this to java. Having some object representing the nmethod. Letting CallSites have a linked list of weak references to these objects, etc. Having thee GC solve the memory reclamation problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23194#issuecomment-2618104075 From mbaesken at openjdk.org Tue Jan 28 07:59:45 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 28 Jan 2025 07:59:45 GMT Subject: RFR: 8347272: [ubsan] JvmLauncher.cpp:262:52: runtime error: applying non-zero offset 40 to null pointer In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:03:41 GMT, Alexey Semenyuk wrote: > Rework pointer arithmetic to avoid null pointer Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23320#pullrequestreview-2577374445 From swen at openjdk.org Tue Jan 28 08:12:28 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 08:12:28 GMT Subject: RFR: 8315585: Optimization for decimal to string Message-ID: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code ------------- Commit messages: - simplify and comments - simplify - simplify - code style - revert change - bug fix - bug fix - refactor - Revert "simplify scale2" - simplify scale2 - ... and 15 more: https://git.openjdk.org/jdk/compare/f446cefe...cb88e0ef Changes: https://git.openjdk.org/jdk/pull/23310/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23310&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315585 Stats: 448 lines in 3 files changed: 237 ins; 118 del; 93 mod Patch: https://git.openjdk.org/jdk/pull/23310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23310/head:pull/23310 PR: https://git.openjdk.org/jdk/pull/23310 From liach at openjdk.org Tue Jan 28 08:12:29 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 08:12:29 GMT Subject: RFR: 8315585: Optimization for decimal to string In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Message-ID: <16lRl5KdUi94z1RI5ZI6cp6rWhv-TJA3ufbApqiNSxs=.ffbcea14-1d1a-437e-9051-eb0db5f94f48@github.com> On Sat, 25 Jan 2025 07:25:40 GMT, Shaojin Wen wrote: > Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code A great cleanup that consolidates scale2, unscaledAbsString, and unscaledString. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23310#issuecomment-2614544055 From swen at openjdk.org Tue Jan 28 08:12:29 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 08:12:29 GMT Subject: RFR: 8315585: Optimization for decimal to string In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Message-ID: On Sat, 25 Jan 2025 07:25:40 GMT, Shaojin Wen wrote: > Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code The performance numbers as follows. In the smallScale2EngineeringToString and smallScale2LayoutCharsToString scenarios, the performance is the same as before, but there are very significant performance improvements in other scenarios. ## 1. Script git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao #baseline git checkout 4040d766e9cecf781be1d790e5e7836368acc7bd make test TEST="micro:java.math.BigDecimals.huge" make test TEST="micro:java.math.BigDecimals.large" make test TEST="micro:java.math.BigDecimals.small" # current git checkout cb88e0efe6cc3e241b49951b076dccb1c690f7cb make test TEST="micro:java.math.BigDecimals.huge" make test TEST="micro:java.math.BigDecimals.large" make test TEST="micro:java.math.BigDecimals.small" ## 2. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa) -# baseline -Benchmark Mode Cnt Score Error Units (4040d766e9c) -BigDecimals.hugeEngineeringToString avgt 15 170.621 ? 0.834 ns/op -BigDecimals.hugeLayoutCharsToString avgt 15 169.597 ? 0.373 ns/op -BigDecimals.hugePlainToString avgt 15 156.598 ? 1.141 ns/op -BigDecimals.largeScale2EngineeringToString avgt 15 34.733 ? 2.767 ns/op -BigDecimals.largeScale2LayoutCharsToString avgt 15 33.044 ? 0.153 ns/op -BigDecimals.largeScale2PlainToString avgt 15 30.302 ? 0.042 ns/op -BigDecimals.largeScale3EngineeringToString avgt 15 39.054 ? 0.084 ns/op -BigDecimals.largeScale3LayoutCharsToString avgt 15 39.180 ? 0.065 ns/op -BigDecimals.largeScale3PlainToString avgt 15 31.261 ? 0.081 ns/op -BigDecimals.smallScale2EngineeringToString avgt 15 11.364 ? 0.019 ns/op -BigDecimals.smallScale2LayoutCharsToString avgt 15 11.387 ? 0.038 ns/op -BigDecimals.smallScale2PlainToString avgt 15 29.513 ? 0.045 ns/op -BigDecimals.smallScale3EngineeringToString avgt 15 33.208 ? 0.166 ns/op -BigDecimals.smallScale3LayoutCharsToString avgt 15 33.171 ? 0.084 ns/op -BigDecimals.smallScale3PlainToString avgt 15 28.995 ? 0.037 ns/op +# current +Benchmark Mode Cnt Score Error Units (cb88e0efe6c) +BigDecimals.hugeEngineeringToString avgt 15 158.130 ? 2.980 ns/op +BigDecimals.hugeLayoutCharsToString avgt 15 156.163 ? 0.591 ns/op +BigDecimals.hugePlainToString avgt 15 157.425 ? 1.655 ns/op +BigDecimals.largeScale2EngineeringToString avgt 15 18.381 ? 0.037 ns/op +BigDecimals.largeScale2LayoutCharsToString avgt 15 18.158 ? 0.048 ns/op +BigDecimals.largeScale2PlainToString avgt 15 18.416 ? 0.034 ns/op +BigDecimals.largeScale3EngineeringToString avgt 15 19.319 ? 0.035 ns/op +BigDecimals.largeScale3LayoutCharsToString avgt 15 19.081 ? 0.021 ns/op +BigDecimals.largeScale3PlainToString avgt 15 19.771 ? 0.063 ns/op +BigDecimals.smallScale2EngineeringToString avgt 15 11.122 ? 0.031 ns/op +BigDecimals.smallScale2LayoutCharsToString avgt 15 11.105 ? 0.037 ns/op +BigDecimals.smallScale2PlainToString avgt 15 11.531 ? 0.030 ns/op +BigDecimals.smallScale3EngineeringToString avgt 15 15.830 ? 0.032 ns/op +BigDecimals.smallScale3LayoutCharsToString avgt 15 15.821 ? 0.047 ns/op +BigDecimals.smallScale3PlainToString avgt 15 15.430 ? 0.176 ns/op | | baseline | current | delta | | --- | --- | --- | --- | | BigDecimals.hugeEngineeringToString | 170.621 | 158.130 | 7.90% | | BigDecimals.hugeLayoutCharsToString | 169.597 | 156.163 | 8.60% | | BigDecimals.hugePlainToString | 156.598 | 157.425 | -0.53% | | BigDecimals.largeScale2EngineeringToString | 34.733 | 18.381 | 88.96% | | BigDecimals.largeScale2LayoutCharsToString | 33.044 | 18.158 | 81.98% | | BigDecimals.largeScale2PlainToString | 30.302 | 18.416 | 64.54% | | BigDecimals.largeScale3EngineeringToString | 39.054 | 19.319 | 102.15% | | BigDecimals.largeScale3LayoutCharsToString | 39.180 | 19.081 | 105.34% | | BigDecimals.largeScale3PlainToString | 31.261 | 19.771 | 58.12% | | BigDecimals.smallScale2EngineeringToString | 11.364 | 11.122 | 2.18% | | BigDecimals.smallScale2LayoutCharsToString | 11.387 | 11.105 | 2.54% | | BigDecimals.smallScale2PlainToString | 29.513 | 11.531 | 155.94% | | BigDecimals.smallScale3EngineeringToString | 33.208 | 15.830 | 109.78% | | BigDecimals.smallScale3LayoutCharsToString | 33.171 | 15.821 | 109.66% | | BigDecimals.smallScale3PlainToString | 28.995 | 15.430 | 87.91% | ## 3. The performance numbers under MacBook M1 Pro -# baseline -Benchmark Mode Cnt Score Error Units (cb88e0efe6c) -BigDecimals.hugeEngineeringToString avgt 15 193.054 ? 26.472 ns/op -BigDecimals.hugeLayoutCharsToString avgt 15 212.770 ? 6.918 ns/op -BigDecimals.hugePlainToString avgt 15 230.857 ? 4.276 ns/op -BigDecimals.largeScale2EngineeringToString avgt 15 45.413 ? 1.318 ns/op -BigDecimals.largeScale2LayoutCharsToString avgt 15 46.862 ? 0.878 ns/op -BigDecimals.largeScale2PlainToString avgt 15 33.184 ? 2.787 ns/op -BigDecimals.largeScale3EngineeringToString avgt 15 71.579 ? 3.913 ns/op -BigDecimals.largeScale3LayoutCharsToString avgt 15 70.623 ? 4.559 ns/op -BigDecimals.largeScale3PlainToString avgt 15 30.200 ? 1.164 ns/op -BigDecimals.smallScale2EngineeringToString avgt 15 9.788 ? 0.097 ns/op -BigDecimals.smallScale2LayoutCharsToString avgt 15 9.741 ? 0.046 ns/op -BigDecimals.smallScale2PlainToString avgt 15 35.357 ? 1.161 ns/op -BigDecimals.smallScale3EngineeringToString avgt 15 53.001 ? 2.682 ns/op -BigDecimals.smallScale3LayoutCharsToString avgt 15 52.704 ? 2.706 ns/op -BigDecimals.smallScale3PlainToString avgt 15 35.690 ? 2.847 ns/op +# current +Benchmark Mode Cnt Score Error Units (cb88e0efe6c) +BigDecimals.hugeEngineeringToString avgt 15 194.490 ? 39.908 ns/op +BigDecimals.hugeLayoutCharsToString avgt 15 170.158 ? 39.788 ns/op +BigDecimals.hugePlainToString avgt 15 139.038 ? 0.640 ns/op +BigDecimals.largeScale2EngineeringToString avgt 15 15.172 ? 0.186 ns/op +BigDecimals.largeScale2LayoutCharsToString avgt 15 15.118 ? 0.082 ns/op +BigDecimals.largeScale2PlainToString avgt 15 15.247 ? 0.125 ns/op +BigDecimals.largeScale3EngineeringToString avgt 15 16.643 ? 0.085 ns/op +BigDecimals.largeScale3LayoutCharsToString avgt 15 16.653 ? 0.229 ns/op +BigDecimals.largeScale3PlainToString avgt 15 16.970 ? 0.115 ns/op +BigDecimals.smallScale2EngineeringToString avgt 15 9.893 ? 0.051 ns/op +BigDecimals.smallScale2LayoutCharsToString avgt 15 9.952 ? 0.149 ns/op +BigDecimals.smallScale2PlainToString avgt 15 10.058 ? 0.023 ns/op +BigDecimals.smallScale3EngineeringToString avgt 15 14.146 ? 0.198 ns/op +BigDecimals.smallScale3LayoutCharsToString avgt 15 14.147 ? 0.035 ns/op +BigDecimals.smallScale3PlainToString avgt 15 14.068 ? 0.029 ns/op | | baseline | current | delta | | --- | --- | --- | --- | | BigDecimals.hugeEngineeringToString | 193.054 | 194.490 | -0.74% | | BigDecimals.hugeLayoutCharsToString | 212.770 | 170.158 | 25.04% | | BigDecimals.hugePlainToString | 230.857 | 139.038 | 66.04% | | BigDecimals.largeScale2EngineeringToString | 45.413 | 15.172 | 199.32% | | BigDecimals.largeScale2LayoutCharsToString | 46.862 | 15.118 | 209.97% | | BigDecimals.largeScale2PlainToString | 33.184 | 15.247 | 117.64% | | BigDecimals.largeScale3EngineeringToString | 71.579 | 16.643 | 330.08% | | BigDecimals.largeScale3LayoutCharsToString | 70.623 | 16.653 | 324.09% | | BigDecimals.largeScale3PlainToString | 30.200 | 16.970 | 77.96% | | BigDecimals.smallScale2EngineeringToString | 9.788 | 9.893 | -1.06% | | BigDecimals.smallScale2LayoutCharsToString | 9.741 | 9.952 | -2.12% | | BigDecimals.smallScale2PlainToString | 35.357 | 10.058 | 251.53% | | BigDecimals.smallScale3EngineeringToString | 53.001 | 14.146 | 274.67% | | BigDecimals.smallScale3LayoutCharsToString | 52.704 | 14.147 | 272.55% | | BigDecimals.smallScale3PlainToString | 35.690 | 14.068 | 153.70% | ------------- PR Comment: https://git.openjdk.org/jdk/pull/23310#issuecomment-2618074326 From duke at openjdk.org Tue Jan 28 08:12:29 2025 From: duke at openjdk.org (Johannes Graham) Date: Tue, 28 Jan 2025 08:12:29 GMT Subject: RFR: 8315585: Optimization for decimal to string In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Message-ID: On Sat, 25 Jan 2025 07:25:40 GMT, Shaojin Wen wrote: > Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code src/java.base/share/classes/java/math/BigDecimal.java line 3538: > 3536: return (signum < 0 ? "-0." : "0.").concat(intString); > 3537: } else if (insertionPoint > 0) { /* Point goes inside intVal */ > 3538: buf = new StringBuilder(); Could calculate the precise size for the StringBuilder src/java.base/share/classes/java/math/BigDecimal.java line 3542: > 3540: buf.append('-'); > 3541: buf.append(intString) > 3542: .insert(insertionPoint + (signum < 0 ? 1 : 0), '.'); Instead of the insert, could do an append of the prefix, then dot, then the suffix. src/java.base/share/classes/java/math/BigDecimal.java line 4209: > 4207: > 4208: private String layoutCharsE(boolean sci, String coeff, int coeffLen, long adjusted) { > 4209: StringBuilder buf = new StringBuilder(32); The comment above about constructing a buffer probably belongs here. Also could calculate a better approximation of the size - possibly coeffLen+14 if that comment is accurate. src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 347: > 345: * @return index of the most significant digit or minus sign, if present > 346: */ > 347: public static int getChars(long i, int index, char[] buf) { Before dropping this method, there is another candidate to use it here : https://github.com/openjdk/jdk/blob/1d2eb2fbaea700fc77b644b5eb5a8a7c40ede108/src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java#L367 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1929857010 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1929857288 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1929860496 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1929495730 From swen at openjdk.org Tue Jan 28 08:12:29 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 08:12:29 GMT Subject: RFR: 8315585: Optimization for decimal to string In-Reply-To: References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Message-ID: <8MHMPX9Vqgv4X67MTuxS_712aLUoP703q_y-sljJHss=.1100c63b-d8a2-4558-8514-cdcf7d67c5c1@github.com> On Sun, 26 Jan 2025 19:31:08 GMT, Johannes Graham wrote: >> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code > > src/java.base/share/classes/java/math/BigDecimal.java line 3538: > >> 3536: return (signum < 0 ? "-0." : "0.").concat(intString); >> 3537: } else if (insertionPoint > 0) { /* Point goes inside intVal */ >> 3538: buf = new StringBuilder(); > > Could calculate the precise size for the StringBuilder The performance will degrade if you precompute the length of the StringBuilder. > src/java.base/share/classes/java/math/BigDecimal.java line 3542: > >> 3540: buf.append('-'); >> 3541: buf.append(intString) >> 3542: .insert(insertionPoint + (signum < 0 ? 1 : 0), '.'); > > Instead of the insert, could do an append of the prefix, then dot, then the suffix. buf.append(intString, 0, insertionPoint) .append('.') .append(intString, insertionPoint, intString.length()); This is another way to write it, but the performance will be reduced. > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 347: > >> 345: * @return index of the most significant digit or minus sign, if present >> 346: */ >> 347: public static int getChars(long i, int index, char[] buf) { > > Before dropping this method, there is another candidate to use it here : https://github.com/openjdk/jdk/blob/1d2eb2fbaea700fc77b644b5eb5a8a7c40ede108/src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java#L367 I took a look at the FloatingDecimal related code. The relevant code in FloatingDecimal can be refactored and simplified so that the removed code does not need to be used. I submitted a PR to simplify FloatingDecimal https://github.com/openjdk/jdk/pull/23311 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1930019634 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1930024839 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1929539931 From duke at openjdk.org Tue Jan 28 08:12:29 2025 From: duke at openjdk.org (Johannes Graham) Date: Tue, 28 Jan 2025 08:12:29 GMT Subject: RFR: 8315585: Optimization for decimal to string In-Reply-To: <8MHMPX9Vqgv4X67MTuxS_712aLUoP703q_y-sljJHss=.1100c63b-d8a2-4558-8514-cdcf7d67c5c1@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> <8MHMPX9Vqgv4X67MTuxS_712aLUoP703q_y-sljJHss=.1100c63b-d8a2-4558-8514-cdcf7d67c5c1@github.com> Message-ID: <87cuDWd3LMuVtfS8iKaVOn_Dcb6CaPsyIHTcJZQam8s=.b93658dd-b94b-41a6-ba6c-0a5ae97af2fb@github.com> On Mon, 27 Jan 2025 06:03:17 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/math/BigDecimal.java line 3538: >> >>> 3536: return (signum < 0 ? "-0." : "0.").concat(intString); >>> 3537: } else if (insertionPoint > 0) { /* Point goes inside intVal */ >>> 3538: buf = new StringBuilder(); >> >> Could calculate the precise size for the StringBuilder > > The performance will degrade if you precompute the length of the StringBuilder. That?s interesting - should the precomputed lengths be removed in the other ones as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r1930371369 From asemenyuk at openjdk.org Tue Jan 28 13:53:51 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 28 Jan 2025 13:53:51 GMT Subject: Integrated: 8347272: [ubsan] JvmLauncher.cpp:262:52: runtime error: applying non-zero offset 40 to null pointer In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:03:41 GMT, Alexey Semenyuk wrote: > Rework pointer arithmetic to avoid null pointer This pull request has now been integrated. Changeset: fb066cae Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/fb066caea8a6bbf5b7a6fbe1ca51282e2c7c1ff2 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8347272: [ubsan] JvmLauncher.cpp:262:52: runtime error: applying non-zero offset 40 to null pointer Reviewed-by: almatvee, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/23320 From swen at openjdk.org Tue Jan 28 15:13:56 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 15:13:56 GMT Subject: RFR: 8348870: Optimization for DecimalDigits Message-ID: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> Expand DIGITS length to 128 and eliminate array bounds checking by using & 0x7F when accessing DIGITS ------------- Commit messages: - & 0x7f Changes: https://git.openjdk.org/jdk/pull/23335/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23335&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348870 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23335/head:pull/23335 PR: https://git.openjdk.org/jdk/pull/23335 From swen at openjdk.org Tue Jan 28 15:13:56 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 15:13:56 GMT Subject: RFR: 8348870: Optimization for DecimalDigits In-Reply-To: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> References: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> Message-ID: On Tue, 28 Jan 2025 14:49:45 GMT, Shaojin Wen wrote: > Expand DIGITS length to 128 and eliminate array bounds checking by using & 0x7F when accessing DIGITS This minor change achieves a ~3-5% performance improvement on MacBook M1 Pro. ## 1. Script git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao #baseline git checkout 2bef5b4a877f4d3bc766558b8782b7b57dee79a8 make test TEST="micro:java.lang.StringBuilders.appendWithLong" make test TEST="micro:java.lang.StringBuilders.appendWithInt" # current git checkout 2bd9f306bdfb6b3a6082bece69bfe7f7c029d289 make test TEST="micro:java.lang.StringBuilders.appendWithLong" make test TEST="micro:java.lang.StringBuilders.appendWithInt" ## 2. The performance numbers under MacBook M1 Pro -# baseline -Benchmark Mode Cnt Score Error Units (2bef5b4a877) -StringBuilders.appendWithLongLatin1 avgt 15 203.001 ? 0.369 ns/op -StringBuilders.appendWithLongUtf16 avgt 15 225.749 ? 2.675 ns/op -StringBuilders.appendWithIntLatin1 avgt 15 137.246 ? 1.220 ns/op -StringBuilders.appendWithIntUtf16 avgt 15 154.522 ? 0.889 ns/op +# current +Benchmark Mode Cnt Score Error Units +StringBuilders.appendWithLongLatin1 avgt 15 191.743 ? 0.700 ns/op +5.87% +StringBuilders.appendWithLongUtf16 avgt 15 218.538 ? 2.553 ns/op +3.29% +StringBuilders.appendWithIntLatin1 avgt 15 132.107 ? 0.509 ns/op +3.89% +StringBuilders.appendWithIntUtf16 avgt 15 149.093 ? 2.551 ns/op +3.64% ------------- PR Comment: https://git.openjdk.org/jdk/pull/23335#issuecomment-2619265149 From mcimadamore at openjdk.org Tue Jan 28 15:46:01 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 28 Jan 2025 15:46:01 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v18] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix test under VThread factory Thanks a lot for the fine work!! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2619369994 From liach at openjdk.org Tue Jan 28 15:59:46 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 15:59:46 GMT Subject: RFR: 8348870: Eliminate array bound checks in DecimalDigits In-Reply-To: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> References: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> Message-ID: On Tue, 28 Jan 2025 14:49:45 GMT, Shaojin Wen wrote: > Expand DIGITS length to 128 and eliminate array bounds checking by using & 0x7F when accessing DIGITS Can we rename this to have a more descriptive title, like "Eliminate array bound checks in DecimalDigits"? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23335#issuecomment-2619405402 From liach at openjdk.org Tue Jan 28 16:03:46 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 16:03:46 GMT Subject: RFR: 8348870: Eliminate array bound checks in DecimalDigits In-Reply-To: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> References: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> Message-ID: On Tue, 28 Jan 2025 14:49:45 GMT, Shaojin Wen wrote: > Expand DIGITS length to 128 and eliminate array bounds checking by using & 0x7F when accessing DIGITS Simple optimization, unfortunately this is a nice feature of the JVM not properly exposed in the language or libraries. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23335#pullrequestreview-2578731387 From liach at openjdk.org Tue Jan 28 16:09:53 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 16:09:53 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v7] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: On Thu, 23 Jan 2025 02:50:46 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu 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 eight additional commits since the last revision: > > - make 'available' un-volatile > - Merge branch 'master' into 8347949-Currency-Stream > - reflect feedback > - provide message for test assertion > - reflect Roger's review > - init hashset w/ accurate size via HashSet.newHashSet(int) > - synchronize init method over block > - init The PR looks good in the current form. Since I am no professional in locale area, requesting another review from Naoto or Roger. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23165#pullrequestreview-2578750128 From sgehwolf at openjdk.org Tue Jan 28 16:27:46 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 28 Jan 2025 16:27:46 GMT Subject: RFR: 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 02:11:29 GMT, Jiangli Zhou wrote: > Please review this trivial cleanup that removes the #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks. Looks good. `DEF_STATIC_JNI_OnLoad` will do the right thing based on the `STATIC_BUILD` define here: https://github.com/openjdk/jdk/blob/fb066caea8a6bbf5b7a6fbe1ca51282e2c7c1ff2/src/java.base/share/native/libjava/jni_util.h#L364-L414 ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23247#pullrequestreview-2578801792 From swen at openjdk.org Tue Jan 28 16:34:21 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 16:34:21 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE Message-ID: ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. ------------- Commit messages: - Update src/java.base/share/classes/java/time/ZoneOffset.java - MINUTES_15_CACHE use AtomicReferenceArray instead of ConcurrentMap Changes: https://git.openjdk.org/jdk/pull/23337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348880 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From liach at openjdk.org Tue Jan 28 16:34:22 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 16:34:22 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 16:11:53 GMT, Shaojin Wen wrote: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. src/java.base/share/classes/java/time/ZoneOffset.java line 139: > 137: > 138: /** Cache of time-zone offset by offset in seconds. */ > 139: private static final int MINUTES_15_SECONDS = 15 * SECONDS_PER_MINUTE; I think a name like `SECONDS_PER_15_MINUTES` or `SECONDS_PER_QUARTER` might be better. src/java.base/share/classes/java/time/ZoneOffset.java line 429: > 427: throw new DateTimeException("Zone offset not in valid range: -18:00 to +18:00"); > 428: } > 429: int minutes15Rem = totalSeconds / MINUTES_15_SECONDS; I suggest renaming `minutes15Rem` to `quarters`. "Rem" is wrong, as this result is a quotient instead of a remainder. src/java.base/share/classes/java/time/ZoneOffset.java line 435: > 433: if (result == null) { > 434: result = new ZoneOffset(totalSeconds); > 435: var existing = MINUTES_15_CACHE.getAndSet(cacheIndex, result); Suggestion: var existing = MINUTES_15_CACHE.compareAndExchange(cacheIndex, null, result); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23337#discussion_r1932485129 PR Review Comment: https://git.openjdk.org/jdk/pull/23337#discussion_r1932489786 PR Review Comment: https://git.openjdk.org/jdk/pull/23337#discussion_r1932482577 From jiangli at openjdk.org Tue Jan 28 16:36:46 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 16:36:46 GMT Subject: RFR: 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 16:24:57 GMT, Severin Gehwolf wrote: >> Please review this trivial cleanup that removes the #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks. > > Looks good. `DEF_STATIC_JNI_OnLoad` will do the right thing based on the `STATIC_BUILD` define here: > https://github.com/openjdk/jdk/blob/fb066caea8a6bbf5b7a6fbe1ca51282e2c7c1ff2/src/java.base/share/native/libjava/jni_util.h#L364-L414 Thanks for the review, @jerboaa! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23247#issuecomment-2619507052 From swen at openjdk.org Tue Jan 28 16:39:04 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 16:39:04 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE [v2] In-Reply-To: References: Message-ID: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/2394c087..3ec3c64c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From swen at openjdk.org Tue Jan 28 16:44:17 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 16:44:17 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE [v3] In-Reply-To: References: Message-ID: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - simplify - MINUTES_15_CACHE -> QUARTER_CACHE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/3ec3c64c..2402d5c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From jiangli at openjdk.org Tue Jan 28 16:44:56 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 16:44:56 GMT Subject: Integrated: 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 02:11:29 GMT, Jiangli Zhou wrote: > Please review this trivial cleanup that removes the #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c. Thanks. This pull request has now been integrated. Changeset: 81032560 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/81032560f797dc18bd6a4a75b44c26925aabac5b Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8348348: Remove unnecessary #ifdef STATIC_BUILD around DEF_STATIC_JNI_OnLoad from zip_util.c Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/23247 From liach at openjdk.org Tue Jan 28 16:52:48 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 16:52:48 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE [v3] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 16:44:17 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. > > Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: > > - simplify > - MINUTES_15_CACHE -> QUARTER_CACHE src/java.base/share/classes/java/time/ZoneOffset.java line 138: > 136: implements TemporalAccessor, TemporalAdjuster, Comparable, Serializable { > 137: > 138: /** Cache of time-zone offset by offset in seconds. */ Suggestion: /** Cache of time-zone offset by offset in quarters. */ src/java.base/share/classes/java/time/ZoneOffset.java line 431: > 429: int quarters = totalSeconds / SECONDS_PER_QUARTER; > 430: if (totalSeconds - quarters * SECONDS_PER_QUARTER == 0) { > 431: ZoneOffset result = QUARTER_CACHE.getOpaque(quarters & 0xff); For the ease of future maintenance, I recommend replacing `quarters & 0xFF` with a new variable `key`: // quarters range from -72 to 72. // & 0xFF maps them to 0-72 and 184-255. int key = quarters & 0xFF; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23337#discussion_r1932514778 PR Review Comment: https://git.openjdk.org/jdk/pull/23337#discussion_r1932526383 From swen at openjdk.org Tue Jan 28 17:00:27 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 17:00:27 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE [v4] In-Reply-To: References: Message-ID: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/time/ZoneOffset.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/2402d5c8..12f27a62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From swen at openjdk.org Tue Jan 28 17:06:24 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 17:06:24 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE [v5] In-Reply-To: References: Message-ID: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/12f27a62..1800ba8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=03-04 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From naoto at openjdk.org Tue Jan 28 17:17:50 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 28 Jan 2025 17:17:50 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v7] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: On Thu, 23 Jan 2025 02:50:46 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu 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 eight additional commits since the last revision: > > - make 'available' un-volatile > - Merge branch 'master' into 8347949-Currency-Stream > - reflect feedback > - provide message for test assertion > - reflect Roger's review > - init hashset w/ accurate size via HashSet.newHashSet(int) > - synchronize init method over block > - init We could add @Stable to `available` for now, but forseeing the stable values, not that significant. So fine by me as in its current form ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23165#pullrequestreview-2578935131 From jlu at openjdk.org Tue Jan 28 17:43:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 28 Jan 2025 17:43:52 GMT Subject: RFR: 8348205: Improve cutover time selection when building available currencies set [v2] In-Reply-To: References: Message-ID: <0vSqV6tkTpTYsDcUP4MPYqAJL9x-FIwkZEJ0pdcw-Qg=.463cebed-4064-43f0-bbd1-5f57d6ee1d02@github.com> On Mon, 27 Jan 2025 18:30:39 GMT, Justin Lu wrote: >> Please review this PR which improves the time measurement for cut-over time comparisons when building the available set of currencies in _java.util.Currency._ Currently, a new time was measured for each special case currency. This PR updates the behavior to use the same time for all such cases > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > reflect review Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23309#issuecomment-2619662014 From jlu at openjdk.org Tue Jan 28 17:43:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 28 Jan 2025 17:43:52 GMT Subject: Integrated: 8348205: Improve cutover time selection when building available currencies set In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 23:56:46 GMT, Justin Lu wrote: > Please review this PR which improves the time measurement for cut-over time comparisons when building the available set of currencies in _java.util.Currency._ Currently, a new time was measured for each special case currency. This PR updates the behavior to use the same time for all such cases This pull request has now been integrated. Changeset: a224f12c Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/a224f12cb701b45df4706a403a05c66de2d623af Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod 8348205: Improve cutover time selection when building available currencies set Reviewed-by: naoto, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/23309 From jiangli at openjdk.org Tue Jan 28 19:28:57 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 19:28:57 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 Message-ID: Please review this workaround for the compiler error on Windows. This error occurs in closed build with custom make logic that uses zip_util.c. The error indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on Windows for now until the cause is fully understood. [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2085: 'ZFILE_Open': not in formal parameter list [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2143: syntax error: missing ';' before '{' [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776): warning C4013: 'ZFILE_Open' undefined; assuming extern returning int ------------- Commit messages: - Workaround compiler error on windows. Changes: https://git.openjdk.org/jdk/pull/23340/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23340&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348888 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23340.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23340/head:pull/23340 PR: https://git.openjdk.org/jdk/pull/23340 From kcr at openjdk.org Tue Jan 28 19:31:46 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 19:31:46 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: <0VRCbeS95kua62O_oF5RKfkt4bXTIQo_AQ8lg4Ar1sI=.9564100c-2dbe-46b5-9d0d-bcb194dfdcad@github.com> On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote: > Please review this workaround for the compiler error on Windows. This error occurs in closed build with custom make logic that uses zip_util.c. The error indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on Windows for now until the cause is fully understood. > > > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2085: 'ZFILE_Open': not in formal parameter list > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2143: syntax error: missing ';' before '{' > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776): warning C4013: 'ZFILE_Open' undefined; assuming extern returning int @alexeysemenyukoracle please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619884181 From kcr at openjdk.org Tue Jan 28 19:34:53 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 19:34:53 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote: > Please review this workaround for the compiler error on Windows. This error occurs in closed build with custom make logic that uses zip_util.c. The error indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on Windows for now until the cause is fully understood. > > > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2085: 'ZFILE_Open': not in formal parameter list > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2143: syntax error: missing ';' before '{' > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776): warning C4013: 'ZFILE_Open' undefined; assuming extern returning int Since the only failures we've seen are on Windows, this fix should work. Alexey will be able to confirm this. ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/23340#pullrequestreview-2579235302 From jiangli at openjdk.org Tue Jan 28 19:38:45 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 19:38:45 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote: > Please review this workaround for the compiler error on Windows. This error occurs in closed build with custom make logic that uses zip_util.c. The error indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on Windows for now until the cause is fully understood. > > > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2085: 'ZFILE_Open': not in formal parameter list > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2143: syntax error: missing ';' before '{' > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776): warning C4013: 'ZFILE_Open' undefined; assuming extern returning int Will wait for @alexeysemenyukoracle's confirmation for testing. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619897417 From liach at openjdk.org Tue Jan 28 19:41:45 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 19:41:45 GMT Subject: RFR: 8348870: Eliminate array bound checks in DecimalDigits In-Reply-To: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> References: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> Message-ID: <1JMxGny5X2chi0KHCJRTatCqgvbpKZJTEZ53yT1BJbI=.97cf6691-35b0-40b6-a8ac-15337f1331d7@github.com> On Tue, 28 Jan 2025 14:49:45 GMT, Shaojin Wen wrote: > Expand DIGITS length to 128 and eliminate array bounds checking by using & 0x7F when accessing DIGITS Ran tests tier 1-3, no failure besides a known serviceability one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23335#issuecomment-2619901837 From liach at openjdk.org Tue Jan 28 19:42:49 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 19:42:49 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v10] In-Reply-To: References: Message-ID: <18GzgCOHLT1CTN5AQ2sPo58GFSUCsFkBhRoNKvKHPak=.7e2f566f-ae7d-470c-9c9b-3f638d2fc4f5@github.com> On Tue, 28 Jan 2025 01:24:43 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > error message Ran tier 1-3 for latest commit as of comment. No failure besides a known one in serviceability. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2619903454 From asemenyuk at openjdk.org Tue Jan 28 19:56:51 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 28 Jan 2025 19:56:51 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: <5zL6ChNkoYWtws3DGlIcGYU7nLrThaJLhVQMUBJc7m0=.08a08c95-9964-4ee4-813f-f33fed0f5d98@github.com> On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote: > zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' It doesn't look like it complains about undefined DEF_STATIC_JNI_OnLoad ------------- PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619931580 From liach at openjdk.org Tue Jan 28 20:11:48 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 20:11:48 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote: > Please review this workaround for the compiler error on Windows. This error occurs in closed build with custom make logic that uses zip_util.c. The error indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on Windows for now until the cause is fully understood. > > > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2085: 'ZFILE_Open': not in formal parameter list > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2143: syntax error: missing ';' before '{' > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776): warning C4013: 'ZFILE_Open' undefined; assuming extern returning int Closed windows uninstaller build affected by the original issue now builds successfully. This patch should be fine. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23340#pullrequestreview-2579310995 From asemenyuk at openjdk.org Tue Jan 28 20:11:48 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 28 Jan 2025 20:11:48 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote: > Please review this workaround for the compiler error on Windows. This error occurs in closed build with custom make logic that uses zip_util.c. The error indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on Windows for now until the cause is fully understood. > > > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2085: 'ZFILE_Open': not in formal parameter list > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2143: syntax error: missing ';' before '{' > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776): warning C4013: 'ZFILE_Open' undefined; assuming extern returning int Marked as reviewed by asemenyuk (Reviewer). I believe it complained about the way DEF_STATIC_JNI_OnLoad is defined. That is why disabling the usage of DEF_STATIC_JNI_OnLoad fixes the problem. ------------- PR Review: https://git.openjdk.org/jdk/pull/23340#pullrequestreview-2579313034 PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619958603 From kcr at openjdk.org Tue Jan 28 20:11:49 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 20:11:49 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: <5zL6ChNkoYWtws3DGlIcGYU7nLrThaJLhVQMUBJc7m0=.08a08c95-9964-4ee4-813f-f33fed0f5d98@github.com> References: <5zL6ChNkoYWtws3DGlIcGYU7nLrThaJLhVQMUBJc7m0=.08a08c95-9964-4ee4-813f-f33fed0f5d98@github.com> Message-ID: On Tue, 28 Jan 2025 19:54:21 GMT, Alexey Semenyuk wrote: > > zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' > > It doesn't look like it complains about undefined DEF_STATIC_JNI_OnLoad The compilation error I saw did. A Mach5 job I submitted passed in one case where it was failing, so I think the fix is good. @alexeysemenyukoracle Please confirm, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619955687 From prr at openjdk.org Tue Jan 28 20:16:47 2025 From: prr at openjdk.org (Phil Race) Date: Tue, 28 Jan 2025 20:16:47 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: <5rLwREvBwD_4oD3b2to9uvQafxCJ8XFVCXyvjxvMuIY=.198a6e8f-46fa-4b2c-8960-492d7d9f3307@github.com> On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer wrote: >> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. >> >> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 >> >> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. >> >> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Update @serialData text to CSR-approved version Approving the datatransfer portion .. at least ... ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2579320786 PR Comment: https://git.openjdk.org/jdk/pull/22980#issuecomment-2619967593 From jiangli at openjdk.org Tue Jan 28 20:17:46 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 20:17:46 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 20:08:54 GMT, Alexey Semenyuk wrote: > I believe it complained about the way DEF_STATIC_JNI_OnLoad is defined. That is why disabling the usage of DEF_STATIC_JNI_OnLoad fixes the problem. That probably describes the issue more clear. Thumbs up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619968964 From jiangli at openjdk.org Tue Jan 28 20:17:47 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 20:17:47 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: <5zL6ChNkoYWtws3DGlIcGYU7nLrThaJLhVQMUBJc7m0=.08a08c95-9964-4ee4-813f-f33fed0f5d98@github.com> Message-ID: On Tue, 28 Jan 2025 20:07:17 GMT, Kevin Rushforth wrote: > A Mach5 job I submitted passed @kevinrushforth Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619970106 From bpb at openjdk.org Tue Jan 28 20:24:24 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 28 Jan 2025 20:24:24 GMT Subject: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v2] In-Reply-To: References: Message-ID: > Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8024695: Change implementation to work for empty path ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22821/files - new: https://git.openjdk.org/jdk/pull/22821/files/5e210314..9d6d9105 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=00-01 Stats: 254 lines in 4 files changed: 204 ins; 2 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/22821.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22821/head:pull/22821 PR: https://git.openjdk.org/jdk/pull/22821 From bpb at openjdk.org Tue Jan 28 20:24:24 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 28 Jan 2025 20:24:24 GMT Subject: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 00:36:44 GMT, Brian Burkhalter wrote: > Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class. Commit 9d6d910 removes the change of specification of `File.exists` and changes the implementation of `File` to treat the empty path `""` as the current directory `"."` where appropriate. - The test primarily verifies the `File` methods which differed in manual testing for `new File("")` from the equivalent methods of `Path` and `Files` for `Path.of("")`. - The `lengthUnix` and `lengthWindows` tests could likely be collapsed to just test `File.length` against `Files.size(path)`. - The `get*Space` checks could instead be against +/-5% of the values returned by the equivalent NIO methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2619980771 From jiangli at openjdk.org Tue Jan 28 20:26:52 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 20:26:52 GMT Subject: RFR: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote: > Please review this workaround for the compiler error on Windows. This error occurs in closed build with custom make logic that uses zip_util.c. The error indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on Windows for now until the cause is fully understood. > > > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2085: 'ZFILE_Open': not in formal parameter list > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2143: syntax error: missing ';' before '{' > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776): warning C4013: 'ZFILE_Open' undefined; assuming extern returning int Thanks all, for reviews and testing! I created [JDK-8348892](https://bugs.openjdk.org/browse/JDK-8348892) to follow up on the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23340#issuecomment-2619982716 From jiangli at openjdk.org Tue Jan 28 20:26:52 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 20:26:52 GMT Subject: Integrated: 8348888: tier1 closed build failure on Windows after JDK-8348348 In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 19:22:52 GMT, Jiangli Zhou wrote: > Please review this workaround for the compiler error on Windows. This error occurs in closed build with custom make logic that uses zip_util.c. The error indicates `DEF_STATIC_JNI_OnLoad` is not defined, thus disable the macro on Windows for now until the cause is fully understood. > > > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2054: expected '(' to follow 'DEF_STATIC_JNI_OnLoad' > [2025-01-28T16:57:35,721Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2085: 'ZFILE_Open': not in formal parameter list > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(94): error C2143: syntax error: missing ';' before '{' > [2025-01-28T16:57:35,737Z] c:\sb\prod\1738083154\workspace\open\src\java.base\share\native\libzip\zip_util.c(776): warning C4013: 'ZFILE_Open' undefined; assuming extern returning int This pull request has now been integrated. Changeset: 1efae9a4 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/1efae9a41e36859ccf31dbe64524a46af6823269 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8348888: tier1 closed build failure on Windows after JDK-8348348 Reviewed-by: kcr, liach, asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/23340 From rgiulietti at openjdk.org Tue Jan 28 21:06:45 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 28 Jan 2025 21:06:45 GMT Subject: RFR: 8348870: Eliminate array bound checks in DecimalDigits In-Reply-To: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> References: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> Message-ID: On Tue, 28 Jan 2025 14:49:45 GMT, Shaojin Wen wrote: > Expand DIGITS length to 128 and eliminate array bounds checking by using & 0x7F when accessing DIGITS Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23335#pullrequestreview-2579409987 From vlivanov at openjdk.org Tue Jan 28 21:10:46 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 28 Jan 2025 21:10:46 GMT Subject: RFR: 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas wrote: > The proposed change here is the following: > 1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object > 2. Remove the Context object and its corresponding cleaner > > (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose. > > First what goes wrong without this patch. > > Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. > > For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. > > The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection. > > If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. > > For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ... Thanks for the clarifications, Axel. The fix looks good. > But I'll take it a spin through our CI as well. Thanks! ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23194#pullrequestreview-2579417360 From jlu at openjdk.org Tue Jan 28 21:34:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 28 Jan 2025 21:34:51 GMT Subject: RFR: 8347955: TimeZone methods to stream the available timezone IDs [v4] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 18:00:06 GMT, Justin Lu wrote: >> Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. >> >> A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > new methods do not need to be synchronized Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23251#issuecomment-2620095137 From jlu at openjdk.org Tue Jan 28 21:34:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 28 Jan 2025 21:34:52 GMT Subject: Integrated: 8347955: TimeZone methods to stream the available timezone IDs In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 02:49:49 GMT, Justin Lu wrote: > Please review this PR and CSR which add a pair of methods to _java.util.TimeZone_ that return a stream of the available IDs. See the CSR for the motivation. > > A number of existing tests are modified to use the new methods. See _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which tests the new methods. This pull request has now been integrated. Changeset: 3a564ed1 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/3a564ed1019c66c28afa729973948d3a6e6c4c41 Stats: 180 lines in 16 files changed: 146 ins; 3 del; 31 mod 8347955: TimeZone methods to stream the available timezone IDs Reviewed-by: naoto, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/23251 From rriggs at openjdk.org Tue Jan 28 22:01:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 28 Jan 2025 22:01:52 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v7] In-Reply-To: References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: On Thu, 23 Jan 2025 02:50:46 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu 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 eight additional commits since the last revision: > > - make 'available' un-volatile > - Merge branch 'master' into 8347949-Currency-Stream > - reflect feedback > - provide message for test assertion > - reflect Roger's review > - init hashset w/ accurate size via HashSet.newHashSet(int) > - synchronize init method over block > - init lgtm ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23165#pullrequestreview-2579505814 From swen at openjdk.org Tue Jan 28 22:07:55 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 28 Jan 2025 22:07:55 GMT Subject: RFR: 8348898: Remove unused OctalDigits to clean up code Message-ID: This PR removes OctalDigits as it is no longer used after the removal of StringTemplate. ------------- Commit messages: - remove OctalDigits Changes: https://git.openjdk.org/jdk/pull/23338/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348898 Stats: 130 lines in 1 file changed: 0 ins; 130 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23338/head:pull/23338 PR: https://git.openjdk.org/jdk/pull/23338 From liach at openjdk.org Tue Jan 28 22:19:50 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 22:19:50 GMT Subject: RFR: 8348898: Remove unused OctalDigits to clean up code In-Reply-To: References: Message-ID: <_KgxDYpL7Y568dMsVjlb6t7LKFng2tiHMuAVjg4zkBY=.bb4e7ddd-869b-491a-8595-b03e3c2ef802@github.com> On Tue, 28 Jan 2025 17:17:07 GMT, Shaojin Wen wrote: > This PR removes OctalDigits as it is no longer used after the removal of StringTemplate. Removal of burdens is always good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23338#pullrequestreview-2579540810 From asemenyuk at openjdk.org Tue Jan 28 22:51:56 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 28 Jan 2025 22:51:56 GMT Subject: RFR: 8348892: Properly fix compilation error for zip_util.c on Windows Message-ID: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> Reapply [JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348) ------------- Commit messages: - JDK-8348892: Properly fix compilation error for zip_util.c on Windows Changes: https://git.openjdk.org/jdk/pull/23344/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23344&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348892 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23344.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23344/head:pull/23344 PR: https://git.openjdk.org/jdk/pull/23344 From kcr at openjdk.org Tue Jan 28 22:51:56 2025 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 28 Jan 2025 22:51:56 GMT Subject: RFR: 8348892: Properly fix compilation error for zip_util.c on Windows In-Reply-To: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> References: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> Message-ID: <3Ihfl4MtmrAgQkOuavaGa-LWrSmIIn1XFWCgjDyJnKU=.b62f9bfd-23e3-44a8-82a3-44871ad70b91@github.com> On Tue, 28 Jan 2025 22:42:00 GMT, Alexey Semenyuk wrote: > Reapply [JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348) This looks good. I confirm that this is the correct backout patch for[JDK-8348888](https://bugs.openjdk.org/browse/JDK-8348888), thus resotring the fix for[JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348). @jianglizhou Can you also review? ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/23344#pullrequestreview-2579582484 PR Comment: https://git.openjdk.org/jdk/pull/23344#issuecomment-2620212653 From asemenyuk at openjdk.org Tue Jan 28 22:51:57 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 28 Jan 2025 22:51:57 GMT Subject: RFR: 8348892: Properly fix compilation error for zip_util.c on Windows In-Reply-To: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> References: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> Message-ID: On Tue, 28 Jan 2025 22:42:00 GMT, Alexey Semenyuk wrote: > Reapply [JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348) @jianglizhou, @jerboaa, @kevinrushforth please review. This PR will be integrated after integrating a patch to the closed Oracle JDK build so it will not result in the build failure as it happened to [JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23344#issuecomment-2620211013 From jiangli at openjdk.org Tue Jan 28 22:59:45 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 28 Jan 2025 22:59:45 GMT Subject: RFR: 8348892: Properly fix compilation error for zip_util.c on Windows In-Reply-To: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> References: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> Message-ID: <0WB_ykMWKLFLPOtvBD9EQfryNSUJv5mkz_0r9MxEQeQ=.fe715df5-51da-46d7-a847-4d3ed1f7747e@github.com> On Tue, 28 Jan 2025 22:42:00 GMT, Alexey Semenyuk wrote: > Reapply [JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348) Marked as reviewed by jiangli (Reviewer). Looks good. @alexeysemenyukoracle, Is the actual change addressing the compilation issue in closed repo? If so, is it to properly add `-Zc:preprocessor`? ------------- PR Review: https://git.openjdk.org/jdk/pull/23344#pullrequestreview-2579599518 PR Comment: https://git.openjdk.org/jdk/pull/23344#issuecomment-2620226841 From asemenyuk at openjdk.org Tue Jan 28 23:08:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 28 Jan 2025 23:08:50 GMT Subject: RFR: 8348892: Properly fix compilation error for zip_util.c on Windows In-Reply-To: <0WB_ykMWKLFLPOtvBD9EQfryNSUJv5mkz_0r9MxEQeQ=.fe715df5-51da-46d7-a847-4d3ed1f7747e@github.com> References: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> <0WB_ykMWKLFLPOtvBD9EQfryNSUJv5mkz_0r9MxEQeQ=.fe715df5-51da-46d7-a847-4d3ed1f7747e@github.com> Message-ID: <2uCYfHs76xXDrKykvteaVqo_TMbjKcoRAuqlDW5w-so=.6f5dd7e9-9f22-4aab-87d0-30cf68ab584d@github.com> On Tue, 28 Jan 2025 22:56:51 GMT, Jiangli Zhou wrote: > Is the actual change addressing the compilation issue in closed repo? Yes. > If so, is it to properly add -Zc:preprocessor? No. The fix was to add missing `DEF_STATIC_JNI_OnLoad` define. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23344#issuecomment-2620238212 From asemenyuk at openjdk.org Tue Jan 28 23:08:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 28 Jan 2025 23:08:50 GMT Subject: Integrated: 8348892: Properly fix compilation error for zip_util.c on Windows In-Reply-To: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> References: <5THtfAXJe6tTvedQvWj9e_8Pd3tShZyioI8ebXVY2DE=.f06ea177-0792-4176-9dee-6cb9f284e942@github.com> Message-ID: On Tue, 28 Jan 2025 22:42:00 GMT, Alexey Semenyuk wrote: > Reapply [JDK-8348348](https://bugs.openjdk.org/browse/JDK-8348348) This pull request has now been integrated. Changeset: 5e81fa6a Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/5e81fa6a1f53e3efb93f32ee44eff20cabcf125f Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8348892: Properly fix compilation error for zip_util.c on Windows Reviewed-by: kcr, jiangli ------------- PR: https://git.openjdk.org/jdk/pull/23344 From liach at openjdk.org Tue Jan 28 23:36:46 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 28 Jan 2025 23:36:46 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 17:06:24 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @liach Looks good to me. No related failures in tier 1-3 tests. Please wait for another java.time reviewer too. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23337#pullrequestreview-2579640891 From naoto at openjdk.org Tue Jan 28 23:57:45 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 28 Jan 2025 23:57:45 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.MINUTES_15_CACHE [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 17:06:24 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @liach The change looks good to me. Maybe you could write a test case for all the quarters that indeed return cached ZoneOffsets? Also, titles (PR/Issue) can reflect the renamed cache name ------------- PR Comment: https://git.openjdk.org/jdk/pull/23337#issuecomment-2620289635 From sviswanathan at openjdk.org Wed Jan 29 00:39:55 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 29 Jan 2025 00:39:55 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v14] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 06:26:11 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Updating typos in comments Some more minor comments below. Rest of the PR looks good to me. src/hotspot/share/opto/subnode.hpp line 549: > 547: SqrtHFNode(Compile* C, Node* c, Node* in1) : Node(c, in1) { > 548: init_flags(Flag_is_expensive); > 549: C->add_expensive_node(this); Do we need to set SqrtHF as expensive node? It translates to a single instruction. src/hotspot/share/opto/type.hpp line 2031: > 2029: > 2030: inline const TypeH* Type::is_half_float_constant() const { > 2031: assert( _base == HalfFloatCon, "Not a Float" ); Should be "Not a HalfFloat" here. test/hotspot/jtreg/compiler/c2/irTests/ConvF2HFIdealizationTests.java line 32: > 30: /* > 31: * @test > 32: * @bug 8338061 This should now refer to bug 8342103. test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java line 33: > 31: /* > 32: * @test > 33: * @bug 8336406 This should now refer to bug 8342103. test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 27: > 25: /** > 26: * @test > 27: * @bug 8308363 8336406 This should now refer to bug 8342103. ------------- PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2579221309 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1932741039 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1932906990 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933045205 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933045649 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933045837 From duke at openjdk.org Wed Jan 29 01:58:02 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 29 Jan 2025 01:58:02 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v10] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 01:24:43 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > error message A nice enhancement would be to allow `String.parseInt(CharSequence,int,int,int)` to also use this code when the CharSequence actually was a String. Could benefit, for example, `java.util.Formatter` ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2620464925 From swen at openjdk.org Wed Jan 29 02:44:31 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 02:44:31 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v6] In-Reply-To: References: Message-ID: <6fVZ1Sk4TlmicFYHa9P9VwkNklOVbur1wwHVe4ipCAg=.88d141ea-0688-48ee-bbf3-7cca5b35b1d2@github.com> > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: add test for quarter cache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/1800ba8a..4858b0f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=04-05 Stats: 29 lines in 1 file changed: 29 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From swen at openjdk.org Wed Jan 29 02:46:57 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 02:46:57 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 23:53:01 GMT, Naoto Sato wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> from @liach > > The change looks good to me. Maybe you could write a test case for all the quarters that indeed return cached ZoneOffsets? Also, titles (PR/Issue) can reflect the renamed cache name Thanks @naotoj, I have changed the title and added a test case to ensure that the cache works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23337#issuecomment-2620507748 From jbhateja at openjdk.org Wed Jan 29 06:26:41 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 29 Jan 2025 06:26:41 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v15] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Fixing a typo error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22754/files - new: https://git.openjdk.org/jdk/pull/22754/files/854fc73f..19fc6c2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From jbhateja at openjdk.org Wed Jan 29 06:26:43 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 29 Jan 2025 06:26:43 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v14] In-Reply-To: References: Message-ID: <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com> On Wed, 29 Jan 2025 00:36:54 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating typos in comments > > Some more minor comments below. Rest of the PR looks good to me. Hi @sviswa7 , your comments have been addressed. > src/hotspot/share/opto/subnode.hpp line 549: > >> 547: SqrtHFNode(Compile* C, Node* c, Node* in1) : Node(c, in1) { >> 548: init_flags(Flag_is_expensive); >> 549: C->add_expensive_node(this); > > Do we need to set SqrtHF as expensive node? It translates to a single instruction. Its latency is around 15 cycles. Thus, GVN commoning, which leads to its placement onto a frequently executed control path, may be costly. In addition, it is also marked as an expensive node by ADLC to prevent rematerialization by the allocator. > src/hotspot/share/opto/type.hpp line 2031: > >> 2029: >> 2030: inline const TypeH* Type::is_half_float_constant() const { >> 2031: assert( _base == HalfFloatCon, "Not a Float" ); > > Should be "Not a HalfFloat" here. Fixed this typo error. > test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 27: > >> 25: /** >> 26: * @test >> 27: * @bug 8308363 8336406 > > This should now refer to bug 8342103. Test was added on lworld+fp16 branch and appropriately reflects the JBS entry. Same, applies to above two comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2620812050 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933322657 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933322637 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1933322576 From swen at openjdk.org Wed Jan 29 06:39:38 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 06:39:38 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v7] In-Reply-To: References: Message-ID: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: simplify test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/4858b0f3..e99d2627 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=05-06 Stats: 23 lines in 1 file changed: 0 ins; 15 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From swen at openjdk.org Wed Jan 29 06:42:02 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 06:42:02 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8] In-Reply-To: References: Message-ID: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: rename to test_quarter_cache ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/e99d2627..bfafdef7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From duke at openjdk.org Wed Jan 29 10:40:53 2025 From: duke at openjdk.org (altrisi) Date: Wed, 29 Jan 2025 10:40:53 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 06:42:02 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > rename to test_quarter_cache Why not have the key be quarters + 72 so the array can be smaller? That'd lower the constant memory overhead added by this change, as the CHM was smaller initially. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23337#issuecomment-2621267958 From shade at openjdk.org Wed Jan 29 11:00:48 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Jan 2025 11:00:48 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: <_Ma82xOEruDRHPxNMNEAVwCs1CAOp0D3ozJMVmVrSFc=.50beb18b-1587-49da-98b9-42b7601f3ea8@github.com> References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> <_Ma82xOEruDRHPxNMNEAVwCs1CAOp0D3ozJMVmVrSFc=.50beb18b-1587-49da-98b9-42b7601f3ea8@github.com> Message-ID: On Mon, 27 Jan 2025 09:08:56 GMT, Aleksey Shipilev wrote: > > Would you mind holding off until Tuesday to give time to get that done? > > Sure, there is no rush with this PR. I'll wait. How is it going, @AlanBateman? Any progress on closed tests? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2621313239 From jvernee at openjdk.org Wed Jan 29 11:25:32 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 29 Jan 2025 11:25:32 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping Message-ID: Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the cleanup actions one by one. However, due to this linked list format, plus the control flow introduced by the cleanup loop, C2's escape analysis can not keep track of the nodes of this linked list (`ResourceList.ResourceCleanup`), and as a result, they can not be scalar replaced. We can prevent just the first `ResourceCleanup` instance from escaping, by pulling out the first element of the list into a separate field. I also tried a setup where I had 2 separate fields for the first 2 elements, as well as a setup with an array with a fixed set of elements. While these also worked to prevent the first node from escaping, they were not able to provide the same benefit for multiple resource cleanup instances. Nevertheless, avoiding the allocation of the first element is relatively simple, and seems like a low-hanging fruit. I've changed the `AllocTest` benchmark a bit so that we don't return the `MemorySegment` in `alloc_confined`, which would make it always escape. That way, we can use this existing benchmark to test whether there are any allocations when calling `allocate` on a confined arena. This matches what we were doing in the other benchmark methods in the same class. ------------- Commit messages: - polish v2 - simplify benchmark - polish - One element cache - fix bench Changes: https://git.openjdk.org/jdk/pull/23321/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348668 Stats: 46 lines in 3 files changed: 30 ins; 9 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23321/head:pull/23321 PR: https://git.openjdk.org/jdk/pull/23321 From liach at openjdk.org Wed Jan 29 11:25:32 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 11:25:32 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:06:58 GMT, Jorn Vernee wrote: > Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the cleanup actions one by one. > > However, due to this linked list format, plus the control flow introduced by the cleanup loop, C2's escape analysis can not keep track of the nodes of this linked list (`ResourceList.ResourceCleanup`), and as a result, they can not be scalar replaced. > > We can prevent just the first `ResourceCleanup` instance from escaping, by pulling out the first element of the list into a separate field. I also tried a setup where I had 2 separate fields for the first 2 elements, as well as a setup with an array with a fixed set of elements. While these also worked to prevent the first node from escaping, they were not able to provide the same benefit for multiple resource cleanup instances. Nevertheless, avoiding the allocation of the first element is relatively simple, and seems like a low-hanging fruit. > > I've changed the `AllocTest` benchmark a bit so that we don't return the `MemorySegment` in `alloc_confined`, which would make it always escape. That way, we can use this existing benchmark to test whether there are any allocations when calling `allocate` on a confined arena. This matches what we were doing in the other benchmark methods in the same class. This somewhat reminds me of #22043, don't know how applicable the block trick is for cleanup, but it doesn't help escape analysis... src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java line 112: > 110: if (fst != ResourceCleanup.CLOSED_LIST) { > 111: ResourceCleanup prev = fst; > 112: fst = ResourceCleanup.CLOSED_LIST; Is there a reason why usage of fst here doesn't prevent successful escape analysis? ------------- PR Review: https://git.openjdk.org/jdk/pull/23321#pullrequestreview-2576802578 PR Review Comment: https://git.openjdk.org/jdk/pull/23321#discussion_r1931348181 From jvernee at openjdk.org Wed Jan 29 11:25:33 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 29 Jan 2025 11:25:33 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 00:08:27 GMT, Chen Liang wrote: >> Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the cleanup actions one by one. >> >> However, due to this linked list format, plus the control flow introduced by the cleanup loop, C2's escape analysis can not keep track of the nodes of this linked list (`ResourceList.ResourceCleanup`), and as a result, they can not be scalar replaced. >> >> We can prevent just the first `ResourceCleanup` instance from escaping, by pulling out the first element of the list into a separate field. I also tried a setup where I had 2 separate fields for the first 2 elements, as well as a setup with an array with a fixed set of elements. While these also worked to prevent the first node from escaping, they were not able to provide the same benefit for multiple resource cleanup instances. Nevertheless, avoiding the allocation of the first element is relatively simple, and seems like a low-hanging fruit. >> >> I've changed the `AllocTest` benchmark a bit so that we don't return the `MemorySegment` in `alloc_confined`, which would make it always escape. That way, we can use this existing benchmark to test whether there are any allocations when calling `allocate` on a confined arena. This matches what we were doing in the other benchmark methods in the same class. > > src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java line 112: > >> 110: if (fst != ResourceCleanup.CLOSED_LIST) { >> 111: ResourceCleanup prev = fst; >> 112: fst = ResourceCleanup.CLOSED_LIST; > > Is there a reason why usage of fst here doesn't prevent successful escape analysis? Why do you think it should? We never assign the newly allocated resource cleanup to `fst`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23321#discussion_r1931467325 From liach at openjdk.org Wed Jan 29 11:25:33 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 11:25:33 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 03:20:22 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java line 112: >> >>> 110: if (fst != ResourceCleanup.CLOSED_LIST) { >>> 111: ResourceCleanup prev = fst; >>> 112: fst = ResourceCleanup.CLOSED_LIST; >> >> Is there a reason why usage of fst here doesn't prevent successful escape analysis? > > Why do you think it should? We never assign the newly allocated resource cleanup to `fst`. So was the culprit `cleanup.next = fst;`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23321#discussion_r1931472966 From jvernee at openjdk.org Wed Jan 29 11:25:33 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 29 Jan 2025 11:25:33 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 03:31:58 GMT, Chen Liang wrote: >> Why do you think it should? We never assign the newly allocated resource cleanup to `fst`. > > So was the culprit `cleanup.next = fst;`? Yes, in combination with the while loop which runs all the cleanups, which adds a phi node that merges the instance with `null`, at which point EA gives up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23321#discussion_r1931999047 From swen at openjdk.org Wed Jan 29 11:34:57 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 11:34:57 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 10:38:39 GMT, altrisi wrote: > quarters The size of AtomicReferenceArray is 256, and using `& 0xff` can eliminate array bounds checking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23337#issuecomment-2621393609 From swen at openjdk.org Wed Jan 29 11:56:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 11:56:52 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v10] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 01:55:10 GMT, Johannes Graham wrote: > A nice enhancement would be to allow `String.parseInt(CharSequence,int,int,int)` to also use this code when the CharSequence actually was a String. Could benefit, for example, `java.util.Formatter` Your suggestion is very good, but I think we can submit another PR after the current PR is completed to expand the scenarios supported by this optimization and reduce duplicate code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-2621436661 From swen at openjdk.org Wed Jan 29 13:09:49 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 13:09:49 GMT Subject: Integrated: 8348870: Eliminate array bound checks in DecimalDigits In-Reply-To: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> References: <-j7LWj4khIbZccwtmm0WMO98PhWiHL4rC7RPUMmHduM=.78261aba-b99e-471c-bfc7-53cb6f09c764@github.com> Message-ID: On Tue, 28 Jan 2025 14:49:45 GMT, Shaojin Wen wrote: > Expand DIGITS length to 128 and eliminate array bounds checking by using & 0x7F when accessing DIGITS This pull request has now been integrated. Changeset: f98d9a33 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/f98d9a330128302207fb66dfa2555885ad93135f Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8348870: Eliminate array bound checks in DecimalDigits Reviewed-by: liach, rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/23335 From liach at openjdk.org Wed Jan 29 15:09:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 15:09:48 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:06:58 GMT, Jorn Vernee wrote: > Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the cleanup actions one by one. > > However, due to this linked list format, plus the control flow introduced by the cleanup loop, C2's escape analysis can not keep track of the nodes of this linked list (`ResourceList.ResourceCleanup`), and as a result, they can not be scalar replaced. > > We can prevent just the first `ResourceCleanup` instance from escaping, by pulling out the first element of the list into a separate field. I also tried a setup where I had 2 separate fields for the first 2 elements, as well as a setup with an array with a fixed set of elements. While these also worked to prevent the first node from escaping, they were not able to provide the same benefit for multiple resource cleanup instances. Nevertheless, avoiding the allocation of the first element is relatively simple, and seems like a low-hanging fruit. > > I've changed the `AllocTest` benchmark a bit so that we don't return the `MemorySegment` in `alloc_confined`, which would make it always escape. That way, we can use this existing benchmark to test whether there are any allocations when calling `allocate` on a confined arena. This matches what we were doing in the other benchmark methods in the same class. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23321#pullrequestreview-2581356155 From liach at openjdk.org Wed Jan 29 15:10:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 15:10:48 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 06:42:02 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > rename to test_quarter_cache test/jdk/java/time/test/java/time/TestZoneOffset.java line 1: > 1: /* Can you update the copyright year in this file? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23337#discussion_r1934066736 From liach at openjdk.org Wed Jan 29 15:12:49 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 15:12:49 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:06:58 GMT, Jorn Vernee wrote: > Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the cleanup actions one by one. > > However, due to this linked list format, plus the control flow introduced by the cleanup loop, C2's escape analysis can not keep track of the nodes of this linked list (`ResourceList.ResourceCleanup`), and as a result, they can not be scalar replaced. > > We can prevent just the first `ResourceCleanup` instance from escaping, by pulling out the first element of the list into a separate field. I also tried a setup where I had 2 separate fields for the first 2 elements, as well as a setup with an array with a fixed set of elements. While these also worked to prevent the first node from escaping, they were not able to provide the same benefit for multiple resource cleanup instances. Nevertheless, avoiding the allocation of the first element is relatively simple, and seems like a low-hanging fruit. > > I've changed the `AllocTest` benchmark a bit so that we don't return the `MemorySegment` in `alloc_confined`, which would make it always escape. That way, we can use this existing benchmark to test whether there are any allocations when calling `allocate` on a confined arena. This matches what we were doing in the other benchmark methods in the same class. test/micro/org/openjdk/bench/java/lang/foreign/AllocTest.java line 1: > 1: /* This file can get a copyright year update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23321#discussion_r1934069379 From swen at openjdk.org Wed Jan 29 15:17:21 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 15:17:21 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v9] In-Reply-To: References: Message-ID: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/bfafdef7..2765c4da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=07-08 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From liach at openjdk.org Wed Jan 29 15:26:49 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 15:26:49 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v9] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 15:17:21 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23337#pullrequestreview-2581405788 From liach at openjdk.org Wed Jan 29 15:35:57 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 15:35:57 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v8] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 10:38:39 GMT, altrisi wrote: > That'd lower the constant memory overhead added by this change, as the CHM started smaller. We use a size of 256 so C2 can apply array bound check elimination as it knows the resulting value from `& 0xFF` is ensured to be in the range of `[0, 255]`, which is always valid for the array, so its generated code will drop the bound check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23337#issuecomment-2621982177 From swen at openjdk.org Wed Jan 29 16:26:59 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 16:26:59 GMT Subject: Integrated: 8348898: Remove unused OctalDigits to clean up code In-Reply-To: References: Message-ID: On Tue, 28 Jan 2025 17:17:07 GMT, Shaojin Wen wrote: > This PR removes OctalDigits as it is no longer used after the removal of StringTemplate. This pull request has now been integrated. Changeset: cbc89a7a Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/cbc89a7ac6a45acd35ddfee4ab6fac9cc807d8fb Stats: 130 lines in 1 file changed: 0 ins; 130 del; 0 mod 8348898: Remove unused OctalDigits to clean up code Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/23338 From swen at openjdk.org Wed Jan 29 16:30:46 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 16:30:46 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v11] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/284ad6a0..0b04a706 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=09-10 Stats: 6 lines in 4 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From sviswanathan at openjdk.org Wed Jan 29 17:06:53 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 29 Jan 2025 17:06:53 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v15] In-Reply-To: References: Message-ID: <2mwDB7u60CMOcPcuaaWxn9XblgXILZtgOvNwQqQyBno=.0f042b54-c6b5-4bbe-bd7a-23792b7774f9@github.com> On Wed, 29 Jan 2025 06:26:41 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Fixing a typo error Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2581694270 From naoto at openjdk.org Wed Jan 29 17:11:53 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 29 Jan 2025 17:11:53 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v9] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 15:17:21 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright test/jdk/java/time/test/java/time/TestZoneOffset.java line 88: > 86: @Test > 87: public void test_quarter_cache() throws Exception { > 88: for (int hour = -18; hour < 18; hour++) { The offset range is inclusive, so you may want to test +18 hour as well, since it is the edge case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23337#discussion_r1934275318 From bchristi at openjdk.org Wed Jan 29 17:19:50 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 29 Jan 2025 17:19:50 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> <_Ma82xOEruDRHPxNMNEAVwCs1CAOp0D3ozJMVmVrSFc=.50beb18b-1587-49da-98b9-42b7601f3ea8@github.com> Message-ID: <8dL8MzvZq4DslLmaoXx5rAuq5FPcjopkblqYJ65qmBw=.d6a376cc-1271-498d-9a3d-d4bdf6468e85@github.com> On Wed, 29 Jan 2025 10:58:07 GMT, Aleksey Shipilev wrote: > > > Would you mind holding off until Tuesday to give time to get that done? > > > > > > Sure, there is no rush with this PR. I'll wait. > > How is it going, @AlanBateman? Any progress on closed tests? Nearly done - in review now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2622281311 From swen at openjdk.org Wed Jan 29 17:53:04 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 17:53:04 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v10] In-Reply-To: References: Message-ID: <6V4MJTvU6a8D5SMDBIBTYpJ-FB6eRSfFpxjrzzGHbC8=.6aff1c3e-69bc-48a6-8a69-e815fd0b0109@github.com> > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @naotoj ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23337/files - new: https://git.openjdk.org/jdk/pull/23337/files/2765c4da..a30914b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23337&range=08-09 Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/23337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23337/head:pull/23337 PR: https://git.openjdk.org/jdk/pull/23337 From swen at openjdk.org Wed Jan 29 18:04:14 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 29 Jan 2025 18:04:14 GMT Subject: RFR: 8344168: Change Unsafe base offset from int to long [v6] In-Reply-To: References: Message-ID: > The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed. > > @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea. Shaojin Wen 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 nine additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into long_unsafe_offset_202411 - fix DecimalDigits - Merge remote-tracking branch 'upstream/master' into long_unsafe_offset_202411 - Typos - Fix type expectations - Make base offset method and invalid offset long - Merge remote-tracking branch 'upstream/master' into long_unsafe_offset_202411 - long BaseAndScale base, from @JornVernee - long Unsafe offset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22095/files - new: https://git.openjdk.org/jdk/pull/22095/files/76f6f3fb..d1d5bdfe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=04-05 Stats: 9236 lines in 820 files changed: 5405 ins; 1049 del; 2782 mod Patch: https://git.openjdk.org/jdk/pull/22095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22095/head:pull/22095 PR: https://git.openjdk.org/jdk/pull/22095 From naoto at openjdk.org Wed Jan 29 18:03:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 29 Jan 2025 18:03:51 GMT Subject: RFR: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE [v10] In-Reply-To: <6V4MJTvU6a8D5SMDBIBTYpJ-FB6eRSfFpxjrzzGHbC8=.6aff1c3e-69bc-48a6-8a69-e815fd0b0109@github.com> References: <6V4MJTvU6a8D5SMDBIBTYpJ-FB6eRSfFpxjrzzGHbC8=.6aff1c3e-69bc-48a6-8a69-e815fd0b0109@github.com> Message-ID: On Wed, 29 Jan 2025 17:53:04 GMT, Shaojin Wen wrote: >> ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @naotoj LGTM. Thanks for the fix ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23337#pullrequestreview-2581828756 From jlu at openjdk.org Wed Jan 29 18:35:31 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 29 Jan 2025 18:35:31 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v8] In-Reply-To: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: <_CDQ3uLBMJfvBSVd5rN7q3P_2wXxLoyHBqnauie2uTs=.a985f8eb-8af3-41ee-bcff-77552dab67c5@github.com> > Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. > > The motivation can be found in the CSR. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - merge master and resolve conflicts - make 'available' un-volatile - Merge branch 'master' into 8347949-Currency-Stream - reflect feedback - provide message for test assertion - reflect Roger's review - init hashset w/ accurate size via HashSet.newHashSet(int) - synchronize init method over block - init ------------- Changes: https://git.openjdk.org/jdk/pull/23165/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23165&range=07 Stats: 122 lines in 2 files changed: 78 ins; 1 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/23165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165 PR: https://git.openjdk.org/jdk/pull/23165 From duke at openjdk.org Wed Jan 29 18:49:47 2025 From: duke at openjdk.org (Johannes Graham) Date: Wed, 29 Jan 2025 18:49:47 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v11] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 16:30:46 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 181: > 179: return -1; > 180: } > 181: return ((d & 0xF) << 3) + ((d & 0xF) << 1) // (d & 0xF) * 10 Is simply using `(d & 0xF) * 10` any worse? I expect the compiler knows this trick and would use it when appropriate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1934408496 From jvernee at openjdk.org Wed Jan 29 19:20:34 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 29 Jan 2025 19:20:34 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping [v2] In-Reply-To: References: Message-ID: > Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the cleanup actions one by one. > > However, due to this linked list format, plus the control flow introduced by the cleanup loop, C2's escape analysis can not keep track of the nodes of this linked list (`ResourceList.ResourceCleanup`), and as a result, they can not be scalar replaced. > > We can prevent just the first `ResourceCleanup` instance from escaping, by pulling out the first element of the list into a separate field. I also tried a setup where I had 2 separate fields for the first 2 elements, as well as a setup with an array with a fixed set of elements. While these also worked to prevent the first node from escaping, they were not able to provide the same benefit for multiple resource cleanup instances. Nevertheless, avoiding the allocation of the first element is relatively simple, and seems like a low-hanging fruit. > > I've changed the `AllocTest` benchmark a bit so that we don't return the `MemorySegment` in `alloc_confined`, which would make it always escape. That way, we can use this existing benchmark to test whether there are any allocations when calling `allocate` on a confined arena. This matches what we were doing in the other benchmark methods in the same class. Jorn Vernee 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 seven additional commits since the last revision: - update copyright year - Merge branch 'master' into NoEscape - polish v2 - simplify benchmark - polish - One element cache - fix bench ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23321/files - new: https://git.openjdk.org/jdk/pull/23321/files/dc386bbe..05774fc2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23321&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23321&range=00-01 Stats: 21481 lines in 2734 files changed: 9957 ins; 5708 del; 5816 mod Patch: https://git.openjdk.org/jdk/pull/23321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23321/head:pull/23321 PR: https://git.openjdk.org/jdk/pull/23321 From naoto at openjdk.org Wed Jan 29 19:22:56 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 29 Jan 2025 19:22:56 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v8] In-Reply-To: <_CDQ3uLBMJfvBSVd5rN7q3P_2wXxLoyHBqnauie2uTs=.a985f8eb-8af3-41ee-bcff-77552dab67c5@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <_CDQ3uLBMJfvBSVd5rN7q3P_2wXxLoyHBqnauie2uTs=.a985f8eb-8af3-41ee-bcff-77552dab67c5@github.com> Message-ID: <6Dl7o0NmNHi4XmMTyDd9z0sR7UplJ7eSCW8R0rWD4O0=.d1e7ac1d-6ce4-4fba-a59b-b2e91eddfb98@github.com> On Wed, 29 Jan 2025 18:35:31 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - merge master and resolve conflicts > - make 'available' un-volatile > - Merge branch 'master' into 8347949-Currency-Stream > - reflect feedback > - provide message for test assertion > - reflect Roger's review > - init hashset w/ accurate size via HashSet.newHashSet(int) > - synchronize init method over block > - init Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23165#pullrequestreview-2582004770 From kbarrett at openjdk.org Wed Jan 29 19:32:09 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 29 Jan 2025 19:32:09 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v10] In-Reply-To: References: Message-ID: On Sat, 25 Jan 2025 07:14:51 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [x] Linux x86_64 server fastdebug, `all` >> - [x] Linux AArch64 server fastdebug, `all` > > 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 14 additional commits since the last revision: > > - Merge branch 'master' into JDK-8344332-dbb-cleaner > - No instantiation for BufferCleaner, javadocs > - Remove hasReferencePendingList > - Revert test exclusion, moved to JDK-8348301 > - Alan's review > - Remove vestigial reference to waitForReferenceProcessing in tests > - Track Cleaner progress with canaries > - Amend benchmarks > - Fix tests > - Review feedback and benchmarks > - ... and 4 more: https://git.openjdk.org/jdk/compare/915b951b...bcfab1ba src/java.base/share/classes/java/lang/ref/Reference.java line 282: > 280: // references, or (2) the reference processing thread is > 281: // processing references. Otherwise, returns false immediately. > 282: private static boolean waitForReferenceProcessing() Removing waitForReferenceProcessing is contrary to https://bugs.openjdk.org/browse/JDK-8305186 Reference.waitForReferenceProcessing should be more accessible I've pointed to JDK-8305186 in a number of discussions about problems encountered with various tests. So I'm doubtful about removing it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1934462036 From shade at openjdk.org Wed Jan 29 19:46:01 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Jan 2025 19:46:01 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v10] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 19:28:31 GMT, Kim Barrett wrote: >> 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 14 additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8344332-dbb-cleaner >> - No instantiation for BufferCleaner, javadocs >> - Remove hasReferencePendingList >> - Revert test exclusion, moved to JDK-8348301 >> - Alan's review >> - Remove vestigial reference to waitForReferenceProcessing in tests >> - Track Cleaner progress with canaries >> - Amend benchmarks >> - Fix tests >> - Review feedback and benchmarks >> - ... and 4 more: https://git.openjdk.org/jdk/compare/f2507063...bcfab1ba > > src/java.base/share/classes/java/lang/ref/Reference.java line 282: > >> 280: // references, or (2) the reference processing thread is >> 281: // processing references. Otherwise, returns false immediately. >> 282: private static boolean waitForReferenceProcessing() > > Removing waitForReferenceProcessing is contrary to > https://bugs.openjdk.org/browse/JDK-8305186 > Reference.waitForReferenceProcessing should be more accessible > I've pointed to JDK-8305186 in a number of discussions about problems encountered with various tests. > So I'm doubtful about removing it. No problem, I will revert those removals. I did the removals proactively, thinking none of this infrastructure is needed after we migrate DBB, but since there are apparently plausible use cases for it, I'll leave it in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1934481142 From shade at openjdk.org Wed Jan 29 19:56:00 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Jan 2025 19:56:00 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11] In-Reply-To: References: Message-ID: > DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. > > We can migrate DBBs to use `java.lang.ref.Cleaner`. > > There are two pecularities during this rewrite. > > First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. > > Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. > > Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 > > Additional testing: > - [x] Linux x86_64 server fastdebug, `java/nio java/io` > - [x] Linux AArch64 server fastdebug, `java/nio java/io` > - [x] Linux x86_64 server fastdebug, `all` > - [x] Linux AArch64 server fastdebug, `all` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Revert waitForReferenceProcessing removals, see JDK-8305186 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22165/files - new: https://git.openjdk.org/jdk/pull/22165/files/bcfab1ba..dc3dab7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22165&range=09-10 Stats: 72 lines in 5 files changed: 70 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22165.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22165/head:pull/22165 PR: https://git.openjdk.org/jdk/pull/22165 From shade at openjdk.org Wed Jan 29 19:56:01 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 29 Jan 2025 19:56:01 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: Message-ID: <1kiBSlffsdUX423oAb73eb5uzJqw-QGhOlSOKQyYGIg=.34e8b7da-f266-41bb-a46e-7dd6e9fc578c@github.com> On Wed, 29 Jan 2025 19:42:49 GMT, Aleksey Shipilev wrote: >> src/java.base/share/classes/java/lang/ref/Reference.java line 282: >> >>> 280: * This method returns a strong reference to the referent. This may cause >>> 281: * the garbage collector to treat it as strongly reachable until some later >>> 282: * collection cycle. The {@link #refersTo(Object) refersTo} method can be >> >> Removing waitForReferenceProcessing is contrary to >> https://bugs.openjdk.org/browse/JDK-8305186 >> Reference.waitForReferenceProcessing should be more accessible >> I've pointed to JDK-8305186 in a number of discussions about problems encountered with various tests. >> So I'm doubtful about removing it. > > No problem, I will revert those removals. I did the removals proactively, thinking none of this infrastructure is needed after we migrate DBB, but since there are apparently plausible use cases for it, I'll leave it in. Done in new commit, thanks for taking a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1934492345 From liach at openjdk.org Wed Jan 29 20:17:50 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 20:17:50 GMT Subject: RFR: 8348668: Prevent first resource cleanup in confined arena from escaping [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 19:20:34 GMT, Jorn Vernee wrote: >> Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the cleanup actions one by one. >> >> However, due to this linked list format, plus the control flow introduced by the cleanup loop, C2's escape analysis can not keep track of the nodes of this linked list (`ResourceList.ResourceCleanup`), and as a result, they can not be scalar replaced. >> >> We can prevent just the first `ResourceCleanup` instance from escaping, by pulling out the first element of the list into a separate field. I also tried a setup where I had 2 separate fields for the first 2 elements, as well as a setup with an array with a fixed set of elements. While these also worked to prevent the first node from escaping, they were not able to provide the same benefit for multiple resource cleanup instances. Nevertheless, avoiding the allocation of the first element is relatively simple, and seems like a low-hanging fruit. >> >> I've changed the `AllocTest` benchmark a bit so that we don't return the `MemorySegment` in `alloc_confined`, which would make it always escape. That way, we can use this existing benchmark to test whether there are any allocations when calling `allocate` on a confined arena. This matches what we were doing in the other benchmark methods in the same class. > > Jorn Vernee 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 seven additional commits since the last revision: > > - update copyright year > - Merge branch 'master' into NoEscape > - polish v2 > - simplify benchmark > - polish > - One element cache > - fix bench Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23321#pullrequestreview-2582133422 From liach at openjdk.org Wed Jan 29 20:18:49 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 20:18:49 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v8] In-Reply-To: <_CDQ3uLBMJfvBSVd5rN7q3P_2wXxLoyHBqnauie2uTs=.a985f8eb-8af3-41ee-bcff-77552dab67c5@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <_CDQ3uLBMJfvBSVd5rN7q3P_2wXxLoyHBqnauie2uTs=.a985f8eb-8af3-41ee-bcff-77552dab67c5@github.com> Message-ID: <5Xffbk_74Sa9chHQpJCIgJrkXSKbdYyo_POpv6qUrZ4=.c0ed1381-ccde-42d4-ae11-4c89b58d17a4@github.com> On Wed, 29 Jan 2025 18:35:31 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - merge master and resolve conflicts > - make 'available' un-volatile > - Merge branch 'master' into 8347949-Currency-Stream > - reflect feedback > - provide message for test assertion > - reflect Roger's review > - init hashset w/ accurate size via HashSet.newHashSet(int) > - synchronize init method over block > - init Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23165#pullrequestreview-2582134346 From naoto at openjdk.org Wed Jan 29 20:49:24 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 29 Jan 2025 20:49:24 GMT Subject: RFR: 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode Message-ID: Force opening "tzmappings" file in text mode. Confirmed the fix with customer provided test case. Also replaced the file open function with the safer one. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/23356/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23356&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301875 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23356.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23356/head:pull/23356 PR: https://git.openjdk.org/jdk/pull/23356 From jlu at openjdk.org Wed Jan 29 21:36:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 29 Jan 2025 21:36:51 GMT Subject: RFR: 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode In-Reply-To: References: Message-ID: <7TpnnyZ-1SFNHDZT_8BO5_1dFqn6zZufGqlQqw6apjs=.80e4db0c-9b70-46c5-be5d-936dfaebc096@github.com> On Wed, 29 Jan 2025 20:42:30 GMT, Naoto Sato wrote: > Force opening "tzmappings" file in text mode. Confirmed the fix with customer provided test case. Also replaced the file open function with the safer one. Fix looks correct to force "text mode". Switch to `fopen_s` also looks good. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/23356#pullrequestreview-2582399663 From nbenalla at openjdk.org Wed Jan 29 22:18:27 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 29 Jan 2025 22:18:27 GMT Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 Message-ID: Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links. - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location. - Contacted ietf, these are the new links to use. This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either. Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs. ------------- Commit messages: - - fix broken ietf links Changes: https://git.openjdk.org/jdk/pull/23351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348975 Stats: 15 lines in 7 files changed: 0 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/23351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23351/head:pull/23351 PR: https://git.openjdk.org/jdk/pull/23351 From liach at openjdk.org Wed Jan 29 22:31:45 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Jan 2025 22:31:45 GMT Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla wrote: > Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links. > > - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location. > > - Contacted ietf, these are the new links to use. > > This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either. > > Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs. Looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23351#pullrequestreview-2582510381 From bchristi at openjdk.org Wed Jan 29 23:12:02 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 29 Jan 2025 23:12:02 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [x] Linux x86_64 server fastdebug, `all` >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Revert waitForReferenceProcessing removals, see JDK-8305186 Thanks for restoring `waitForReferenceProcessing()`. Closed test changes are in, so you should be good to go. ------------- Marked as reviewed by bchristi (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2582568958 From ihse at openjdk.org Wed Jan 29 23:17:45 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 29 Jan 2025 23:17:45 GMT Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla wrote: > Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links. > > - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location. > > - Contacted ietf, these are the new links to use. > > This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either. > > Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs. make/common/Modules.gmk line 95: > 93: SPEC_SUBDIRS += share/specs > 94: > 95: MAN_SUBDIRS += share/man windows/man Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1934785667 From kbarrett at openjdk.org Wed Jan 29 23:55:58 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 29 Jan 2025 23:55:58 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. >> >> Tests show that DirectBufferAlloc tests are still surviving this, possibly due to exponential sleep-backoff already built in. See the reclamation path in `Bits.unreserveMemory`: https://github.com/openjdk/jdk/blob/c207cc7e705d3f449f2387324d86cfb31ce40c44/src/java.base/share/classes/java/nio/Bits.java#L106-L186 >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [x] Linux x86_64 server fastdebug, `all` >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Revert waitForReferenceProcessing removals, see JDK-8305186 src/java.base/share/classes/java/nio/Bits.java line 146: > 144: } > 145: > 146: if (canary == null || canary.isDead()) { If we're keeping Reference.waitForPendingReferences, why not continue to use it, rather than introducing the canary as a new, ad hoc, reference processing progress detector? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1934820754 From swen at openjdk.org Thu Jan 30 00:19:18 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 00:19:18 GMT Subject: RFR: 8315585: Optimization for decimal to string [v2] In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Message-ID: > Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - copyright - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 # Conflicts: # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java - simplify and comments - simplify - simplify - code style - revert change - bug fix - bug fix - refactor - ... and 17 more: https://git.openjdk.org/jdk/compare/d985b31c...0e7b30be ------------- Changes: https://git.openjdk.org/jdk/pull/23310/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23310&range=01 Stats: 388 lines in 3 files changed: 239 ins; 54 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/23310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23310/head:pull/23310 PR: https://git.openjdk.org/jdk/pull/23310 From swen at openjdk.org Thu Jan 30 00:37:16 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 00:37:16 GMT Subject: RFR: 8344168: Change Unsafe base offset from int to long [v7] In-Reply-To: References: Message-ID: > The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed. > > @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22095/files - new: https://git.openjdk.org/jdk/pull/22095/files/d1d5bdfe..3e16ea0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=05-06 Stats: 49 lines in 49 files changed: 0 ins; 0 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/22095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22095/head:pull/22095 PR: https://git.openjdk.org/jdk/pull/22095 From joehw at openjdk.org Thu Jan 30 04:43:52 2025 From: joehw at openjdk.org (Joe Wang) Date: Thu, 30 Jan 2025 04:43:52 GMT Subject: RFR: 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 20:42:30 GMT, Naoto Sato wrote: > Force opening "tzmappings" file in text mode. Confirmed the fix with customer provided test case. Also replaced the file open function with the safer one. Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23356#pullrequestreview-2582900016 From swen at openjdk.org Thu Jan 30 05:34:32 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 05:34:32 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v12] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: multiply 10 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/0b04a706..a6d98468 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From swen at openjdk.org Thu Jan 30 05:36:56 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 05:36:56 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v11] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 18:47:25 GMT, Johannes Graham wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright > > src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 181: > >> 179: return -1; >> 180: } >> 181: return ((d & 0xF) << 3) + ((d & 0xF) << 1) // (d & 0xF) * 10 > > Is simply using `(d & 0xF) * 10` any worse? I expect the compiler knows this trick and would use it when appropriate. The performance results are identical across x64 and AArch64 platforms. ## 1. Script git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao #baseline (shift) git checkout 0b04a70609b3195aca6481c6f1c88b27c872a65b make test TEST="micro:java.lang.Longs.parseLong" # current (muliti 10) git checkout a6d9846809d6213fd70e852773ff2f57b5bf0201 make test TEST="micro:java.lang.Longs.parseLong" ## 2. MacBook M1 Pro (aarch64) Benchmark (size) Mode Cnt Score Error Units (0b04a70609b) Longs.parseLong 500 avgt 15 2.237 ? 0.029 us/op Benchmark (size) Mode Cnt Score Error Units (a6d9846809d) Longs.parseLong 500 avgt 15 2.225 ? 0.021 us/op ## 3. aliyun_ecs_c8a_x64 (CPU AMD EPYC? Genoa) Benchmark (size) Mode Cnt Score Error Units (0b04a70609b) Longs.parseLong 500 avgt 15 2.920 ? 0.018 us/op Benchmark (size) Mode Cnt Score Error Units (a6d9846809d) Longs.parseLong 500 avgt 15 2.912 ? 0.020 us/op ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r1935027236 From aboldtch at openjdk.org Thu Jan 30 08:35:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 30 Jan 2025 08:35:53 GMT Subject: RFR: 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas wrote: > The proposed change here is the following: > 1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object > 2. Remove the Context object and its corresponding cleaner > > (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose. > > First what goes wrong without this patch. > > Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. > > For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. > > The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection. > > If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. > > For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ... Ran tier1 through tier8 with G1 and the guarantee that the dependency list is empty, and it is indeed the case. Thanks for all the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23194#issuecomment-2623840786 From aboldtch at openjdk.org Thu Jan 30 08:35:54 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 30 Jan 2025 08:35:54 GMT Subject: Integrated: 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents In-Reply-To: References: Message-ID: On Mon, 20 Jan 2025 07:56:49 GMT, Axel Boldt-Christmas wrote: > The proposed change here is the following: > 1. Move the `vmdependencies` list head from the `Context` to the `CallSite` object > 2. Remove the Context object and its corresponding cleaner > > (1.) fixes the crash. (2.) is because without `vmdependencies` the Context and its cleaner serves no purpose. > > First what goes wrong without this patch. > > Currently when the GC unlinks a nmethod it clean/flush out all the dependency contexts. These are either attached to an InstanceKlass, or a Context object reachable through a CallSite oop. A nmethod is unlinked when either one of its oops have died or it is heuristically determined to be cold and should be unloaded. So when the GC clean's the context through a CallSite oop, it may be that that CallSite object is dead. > > For ZGC, which is a concurrent generational GC (the different generations are collected concurrently, but in a coordinated manner), it is important that the unlinking is coordinated with the reclamation of this dead object. In generational ZGC all nmethod oops are considered as strong roots if they reside in the young generation and thusly can only become unreachable / dead after promotion to the old generation. This means that the CallSite object at the time of unlinking is either reachable / live, or unreachable / dead and is reclaimed by the old generation collection (the same generation that does the unlinking). So we can make reading from this object safe by not reclaiming the object before unlinking is finished. > > The issue is that we do not have this guarantee for the Context object. As this is a distinct object it may be that it has not been promoted and resides in the young generation at the time of its CallSite object becoming unreachable and collected by the old generation collection. > > If this is the case and a young generation collection runs after old marking has finished, we have two bad scenarios. If it the young generation collection starts after reference processing and the cleaner has run, the Context object would be unreachable and the young generation collection would reclaim the memory. If it started before the reference processing it would still be reachable, but may be relocated. > > For reachable old CallSite objects the Context oop field would have been tracked and remapped if a young collection relocates the Context object, however this is not true then the CallSite is unreachable. The Context object may have moved or been reclaimed, and the load barrier on the field will produce ... This pull request has now been integrated. Changeset: 14136f8b Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/14136f8b1106137317393bc2ab0a2db0d212f8d8 Stats: 168 lines in 13 files changed: 8 ins; 143 del; 17 mod 8347564: ZGC: Crash in DependencyContext::clean_unloading_dependents Reviewed-by: eosterlund, stefank, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/23194 From alanb at openjdk.org Thu Jan 30 08:40:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Jan 2025 08:40:00 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 19:56:00 GMT, Aleksey Shipilev wrote: >> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner` implementation. That implementation carries a doubly-linked list, and so makes DBB suffer from the same issue fixed for generic `java.lang.ref.Cleaner` users with [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704). See the bug for the reproducer. >> >> We can migrate DBBs to use `java.lang.ref.Cleaner`. >> >> There are two pecularities during this rewrite. >> >> First, the old ad-hoc `Cleaner` implementation used to exit the VM when cleaning action failed. I presume it was to avoid memory leak / accidental reuse of the buffer. I moved the relevant block to `Deallocator` directly. Unfortunately, I cannot easily test it. >> >> Second is quite a bit hairy. Old DBB cleaning code was hooked straight into `Reference` processing loop. This was possible because we could infer that the weak references we are processing were DBB cleaning actions, since old `Cleaner` was the only use of this code. With standard `Cleaner`, we have lost this association, and so we cannot really do this from the reference processing loop. With the patched version, we now rely on normal `Cleaner` thread to do cleanups for us. >> >> Because of this, there is a new outpacing opportunity window where reference processing might have been over, but cleaner thread has not reacted yet. This is why we need another way to check progress that involves checking if cleaner has acted. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `java/nio java/io` >> - [x] Linux AArch64 server fastdebug, `java/nio java/io` >> - [x] Linux x86_64 server fastdebug, `all` >> - [x] Linux AArch64 server fastdebug, `all` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Revert waitForReferenceProcessing removals, see JDK-8305186 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22165#pullrequestreview-2583243848 From alanb at openjdk.org Thu Jan 30 08:40:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Jan 2025 08:40:01 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v9] In-Reply-To: References: <5jyLkYGrwl0zCPsaCj2-9dpglmONIXrI8BeJk3cysSY=.fbca0181-4a60-4178-9dba-aa5c5b1e28e8@github.com> Message-ID: On Sun, 26 Jan 2025 07:30:22 GMT, Alan Bateman wrote: >>> Testing is still clean on my side. I would appreciate if folks can run this through their CIs. >>> >>> I am planning to integrate this on Monday, as long as we discover no new issues. >> >> Did the change to `test/jdk/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java` get lost? >> I'm pretty sure it was updated, but I no longer see that in the changes, and it failed in my automated test run. > >> Testing is still clean on my side. I would appreciate if folks can run this through their CIs. >> >> I am planning to integrate this on Monday, as long as we discover no new issues. > > I ran it through our CI and we seem to have a few tests that aren't in the jdk repo but have a dependency on jdk.internal.ref.Cleaner so they will need to be fixed and/or excluded. Would you mind holding off until Tuesday to give time to get that done? Otherwise I didn't see any issues. I see there is a referenced Graal issue as it looks like they have to do an update to align with the changes here. > How is it going, @AlanBateman? Any progress on closed tests? Thanks for giving us time to get this sorted out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2623847692 From alanb at openjdk.org Thu Jan 30 08:40:02 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Jan 2025 08:40:02 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11] In-Reply-To: References: Message-ID: <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com> On Wed, 29 Jan 2025 23:52:40 GMT, Kim Barrett wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert waitForReferenceProcessing removals, see JDK-8305186 > > src/java.base/share/classes/java/nio/Bits.java line 146: > >> 144: } >> 145: >> 146: if (canary == null || canary.isDead()) { > > If we're keeping Reference.waitForPendingReferences, why not continue to use it, rather than introducing > the canary as a new, ad hoc, reference processing progress detector? @kimbarrett Do you have a change coming to allow waitForPendingReferences be used by WB? I assume this will at least add a comment to the method (or whatever it changes to) to make it clear that it's for testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1935209408 From swen at openjdk.org Thu Jan 30 09:22:33 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 09:22:33 GMT Subject: RFR: 8315585: Optimization for decimal to string [v3] In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Message-ID: > Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: remove getChars(long, int, char[]) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23310/files - new: https://git.openjdk.org/jdk/pull/23310/files/0e7b30be..cf67d847 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23310&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23310&range=01-02 Stats: 65 lines in 1 file changed: 0 ins; 65 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23310/head:pull/23310 PR: https://git.openjdk.org/jdk/pull/23310 From epeter at openjdk.org Thu Jan 30 10:01:52 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 30 Jan 2025 10:01:52 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v14] In-Reply-To: <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com> References: <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com> Message-ID: On Wed, 29 Jan 2025 06:23:25 GMT, Jatin Bhateja wrote: >> Some more minor comments below. Rest of the PR looks good to me. > > Hi @sviswa7 , your comments have been addressed. The updates look good, thanks @jatin-bhateja ! Running one more round of testing to verify copyright etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2624028178 From nbenalla at openjdk.org Thu Jan 30 10:15:05 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 30 Jan 2025 10:15:05 GMT Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla wrote: > Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links. > > - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location. > > - Contacted ietf, these are the new links to use. > > This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either. > > Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs. Thanks for the reviews, integrating now in order to backport this ahead of RC. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23351#issuecomment-2624053793 From nbenalla at openjdk.org Thu Jan 30 10:15:06 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 30 Jan 2025 10:15:06 GMT Subject: Integrated: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla wrote: > Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links. > > - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location. > > - Contacted ietf, these are the new links to use. > > This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either. > > Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs. This pull request has now been integrated. Changeset: 22069ff4 Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef Stats: 15 lines in 7 files changed: 0 ins; 1 del; 14 mod 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/23351 From nbenalla at openjdk.org Thu Jan 30 10:48:23 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 30 Jan 2025 10:48:23 GMT Subject: [jdk24] RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 Message-ID: Hi all, This pull request contains a backport of commit [22069ff4](https://github.com/openjdk/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Nizar Benalla on 30 Jan 2025 and was reviewed by Chen Liang. Thanks! ------------- Commit messages: - Backport 22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef Changes: https://git.openjdk.org/jdk/pull/23366/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23366&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348975 Stats: 15 lines in 7 files changed: 0 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/23366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23366/head:pull/23366 PR: https://git.openjdk.org/jdk/pull/23366 From jbhateja at openjdk.org Thu Jan 30 11:03:43 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 30 Jan 2025 11:03:43 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v16] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 9. X86 backend implementation for all supported intrinsics. > 10. Functional and Performance validation tests. > > Kindly review the patch and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Update test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java Co-authored-by: Emanuel Peter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22754/files - new: https://git.openjdk.org/jdk/pull/22754/files/19fc6c2d..8207c9ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754 PR: https://git.openjdk.org/jdk/pull/22754 From epeter at openjdk.org Thu Jan 30 11:03:45 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 30 Jan 2025 11:03:45 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v15] In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 06:26:41 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 9. X86 backend implementation for all supported intrinsics. >> 10. Functional and Performance validation tests. >> >> Kindly review the patch and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Fixing a typo error `[2025-01-30T10:01:50,247Z] BAD COPYRIGHT: ...test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java` There is yet another `vector` that snuck in later: 19c19 < * Please contact Oracle, 500 Oracle Parkway, Redwood ShovectorRes, CA 94065 USA --- > * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 19: > 17: * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > 18: * > 19: * Please contact Oracle, 500 Oracle Parkway, Redwood ShovectorRes, CA 94065 USA Suggestion: * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2624164650 PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1935412209 From epeter at openjdk.org Thu Jan 30 11:08:55 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 30 Jan 2025 11:08:55 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v14] In-Reply-To: <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com> References: <3qPSmi5JurXgnyLO6Vpr_GYzolS_gO25eiPCsohEglg=.3f240424-c59f-4105-89f8-7f3b56f7ddb0@github.com> Message-ID: On Wed, 29 Jan 2025 06:23:25 GMT, Jatin Bhateja wrote: >> Some more minor comments below. Rest of the PR looks good to me. > > Hi @sviswa7 , your comments have been addressed. @jatin-bhateja Launched testing again ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2624183368 From swen at openjdk.org Thu Jan 30 14:06:51 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 14:06:51 GMT Subject: RFR: 8337279: Optimize format instant [v11] In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: > By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved. Shaojin Wen 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 14 additional commits since the last revision: - remove JavaTimeAccess - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407 - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407 - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407 - suggestion from @jensli - Speed up Instant.toString using JavaTimeAccess - add JavaTimeAccess SharedSecrets - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407 - breaking out the printNano methods - copyright - ... and 4 more: https://git.openjdk.org/jdk/compare/538bbce7...8a73736d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20353/files - new: https://git.openjdk.org/jdk/pull/20353/files/a9c5a36e..8a73736d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=09-10 Stats: 650567 lines in 11254 files changed: 362414 ins; 227718 del; 60435 mod Patch: https://git.openjdk.org/jdk/pull/20353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353 PR: https://git.openjdk.org/jdk/pull/20353 From swen at openjdk.org Thu Jan 30 14:14:41 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 14:14:41 GMT Subject: RFR: 8337279: Optimize format instant [v12] In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: > By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20353/files - new: https://git.openjdk.org/jdk/pull/20353/files/8a73736d..ad48758c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=10-11 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353 PR: https://git.openjdk.org/jdk/pull/20353 From swen at openjdk.org Thu Jan 30 14:20:36 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 14:20:36 GMT Subject: RFR: 8337279: Optimize format instant [v13] In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: > By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20353/files - new: https://git.openjdk.org/jdk/pull/20353/files/ad48758c..c3b9dd55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=11-12 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353 PR: https://git.openjdk.org/jdk/pull/20353 From jpai at openjdk.org Thu Jan 30 14:20:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 30 Jan 2025 14:20:56 GMT Subject: RFR: 8341184: Clean up the interaction between the launcher native code and the LauncherHelper [v15] In-Reply-To: References: Message-ID: <-DhsoE0MTAqPvYYzRvNf2T06RmZk0tJCHy8vOQnUIgc=.ea3c6f9d-2650-40b4-88dc-e505182e2871@github.com> > Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? > > As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. > > Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code. > > No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - merge latest from master branch - ... and 5 more: https://git.openjdk.org/jdk/compare/2efb6aaa...73152bbf ------------- Changes: https://git.openjdk.org/jdk/pull/21256/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=14 Stats: 367 lines in 2 files changed: 105 ins; 172 del; 90 mod Patch: https://git.openjdk.org/jdk/pull/21256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21256/head:pull/21256 PR: https://git.openjdk.org/jdk/pull/21256 From duke at openjdk.org Thu Jan 30 14:24:55 2025 From: duke at openjdk.org (Johannes Graham) Date: Thu, 30 Jan 2025 14:24:55 GMT Subject: RFR: 8337279: Optimize format instant [v13] In-Reply-To: References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: On Thu, 30 Jan 2025 14:20:36 GMT, Shaojin Wen wrote: >> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > remove unused import src/java.base/share/classes/jdk/internal/util/DateTimeHelper.java line 26: > 24: * questions. > 25: */ > 26: package jdk.internal.util; Maybe `jdk.internal.time` would be appropriate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1935696569 From swen at openjdk.org Thu Jan 30 14:38:53 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 14:38:53 GMT Subject: RFR: 8337279: Optimize format instant [v13] In-Reply-To: References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: On Thu, 30 Jan 2025 14:22:04 GMT, Johannes Graham wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused import > > src/java.base/share/classes/jdk/internal/util/DateTimeHelper.java line 26: > >> 24: * questions. >> 25: */ >> 26: package jdk.internal.util; > > Maybe `jdk.internal.time` would be appropriate. Currently, since we only have the DateTimeHelper class, we can wait until there are two or more classes before creating the jdk.internal.time package. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1935717211 From jvernee at openjdk.org Thu Jan 30 14:58:57 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Jan 2025 14:58:57 GMT Subject: Integrated: 8348668: Prevent first resource cleanup in confined arena from escaping In-Reply-To: References: Message-ID: On Mon, 27 Jan 2025 22:06:58 GMT, Jorn Vernee wrote: > Currently, to free the memory allocated in a confined arena, we keep track of a list of 'cleanup actions', stored in linked list format in a so-called `ResourceList`, attached to the scope of the arena. When the scope is closed, we loop over all the entries in this resource list, and run all the cleanup actions one by one. > > However, due to this linked list format, plus the control flow introduced by the cleanup loop, C2's escape analysis can not keep track of the nodes of this linked list (`ResourceList.ResourceCleanup`), and as a result, they can not be scalar replaced. > > We can prevent just the first `ResourceCleanup` instance from escaping, by pulling out the first element of the list into a separate field. I also tried a setup where I had 2 separate fields for the first 2 elements, as well as a setup with an array with a fixed set of elements. While these also worked to prevent the first node from escaping, they were not able to provide the same benefit for multiple resource cleanup instances. Nevertheless, avoiding the allocation of the first element is relatively simple, and seems like a low-hanging fruit. > > I've changed the `AllocTest` benchmark a bit so that we don't return the `MemorySegment` in `alloc_confined`, which would make it always escape. That way, we can use this existing benchmark to test whether there are any allocations when calling `allocate` on a confined arena. This matches what we were doing in the other benchmark methods in the same class. This pull request has now been integrated. Changeset: fac63d43 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/fac63d4383c931ea515dcdf7a89e4285f753f41b Stats: 47 lines in 3 files changed: 30 ins; 9 del; 8 mod 8348668: Prevent first resource cleanup in confined arena from escaping Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/23321 From jvernee at openjdk.org Thu Jan 30 15:01:27 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 30 Jan 2025 15:01:27 GMT Subject: RFR: 8348976: MemorySegment::reinretpret should be force inlined Message-ID: See the JBS issue. Mark the implementation of `MemorySegment::reinterpret` with `@ForceInline` so that we prevent `Reflection.getCallerClass` from falling back to a slow stack walk. This is a leftover from an earlier performance investigation, in which we observed `reinterpret` not being inlined, causing significant slowdowns. ------------- Commit messages: - Force inline MemorySegment::reinterpret Changes: https://git.openjdk.org/jdk/pull/23352/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23352&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348976 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23352/head:pull/23352 PR: https://git.openjdk.org/jdk/pull/23352 From rriggs at openjdk.org Thu Jan 30 15:02:00 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 30 Jan 2025 15:02:00 GMT Subject: RFR: 8337279: Optimize format instant [v13] In-Reply-To: References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: On Thu, 30 Jan 2025 14:20:36 GMT, Shaojin Wen wrote: >> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > remove unused import src/java.base/share/classes/java/time/LocalDateTime.java line 74: > 72: import static java.time.LocalTime.SECONDS_PER_DAY; > 73: import static java.time.temporal.ChronoField.NANO_OF_SECOND; > 74: import static jdk.internal.util.DateTimeHelper.formatTo; Do not import static across package boundaries. I discourage it even within the same package. It makes the code hard to read and follow where the function is coming from. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1935748242 From liach at openjdk.org Thu Jan 30 15:05:49 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 30 Jan 2025 15:05:49 GMT Subject: [jdk24] RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 10:42:43 GMT, Nizar Benalla wrote: > Hi all, > > This pull request contains a backport of commit [22069ff4](https://github.com/openjdk/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Nizar Benalla on 30 Jan 2025 and was reviewed by Chen Liang. > > Thanks! Looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23366#pullrequestreview-2584160685 From swen at openjdk.org Thu Jan 30 15:11:28 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 15:11:28 GMT Subject: RFR: 8337279: Optimize format instant [v14] In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com> Message-ID: > By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: do not import static, from @RogerRiggs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20353/files - new: https://git.openjdk.org/jdk/pull/20353/files/c3b9dd55..5924935e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=12-13 Stats: 28 lines in 7 files changed: 13 ins; 7 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353 PR: https://git.openjdk.org/jdk/pull/20353 From liach at openjdk.org Thu Jan 30 15:12:47 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 30 Jan 2025 15:12:47 GMT Subject: RFR: 8348976: MemorySegment::reinretpret should be force inlined In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 16:15:51 GMT, Jorn Vernee wrote: > See the JBS issue. > > Mark the implementation of `MemorySegment::reinterpret` with `@ForceInline` so that we prevent `Reflection.getCallerClass` from falling back to a slow stack walk. > > This is a leftover from an earlier performance investigation, in which we observed `reinterpret` not being inlined, causing significant slowdowns. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23352#pullrequestreview-2584185394 From swen at openjdk.org Thu Jan 30 15:16:04 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 15:16:04 GMT Subject: Integrated: 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE In-Reply-To: References: Message-ID: <41ats03ASshIhBvxTMZMqHm6-EZtiaO-O1PITdMDHcM=.07055f4d-8051-488a-8715-87ad6bc8b65e@github.com> On Tue, 28 Jan 2025 16:11:53 GMT, Shaojin Wen wrote: > ZoneOffset.MINUTES_15_CACHE uses AtomicReferenceArray to replace ConcurrentMap to avoid object allocation caused by boxing from int to Integer during access. This pull request has now been integrated. Changeset: 3f8a8754 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/3f8a875497c0e8356f9104e32aa801b879c7b941 Stats: 29 lines in 2 files changed: 22 ins; 0 del; 7 mod 8348880: Replace ConcurrentMap with AtomicReferenceArray for ZoneOffset.QUARTER_CACHE Reviewed-by: naoto, liach ------------- PR: https://git.openjdk.org/jdk/pull/23337 From zjx001202 at gmail.com Thu Jan 30 15:22:00 2025 From: zjx001202 at gmail.com (Glavo) Date: Thu, 30 Jan 2025 23:22:00 +0800 Subject: All classes in jdk.internal.random are not serializable Message-ID: Hi, My friend was migrating from Random to RandomGenerator, but he ran into a roadblock: Random is serializable, but those new implementations of RandomGenerator are not serializable. Was this an oversight or an evaluated decision? Is it possible to make them serializable? Glavo -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Thu Jan 30 15:24:56 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 30 Jan 2025 15:24:56 GMT Subject: RFR: 8344168: Change Unsafe base offset from int to long [v7] In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 00:37:16 GMT, Shaojin Wen wrote: >> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed. >> >> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > copyright Tier 1-3 passes on Oracle's CI. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22095#pullrequestreview-2584222451 From bpb at openjdk.org Thu Jan 30 15:47:35 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Jan 2025 15:47:35 GMT Subject: RFR: 8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification Message-ID: The change made for [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated `File.getCanonicalPath` to resolve symbolic links on Windows, but its specification was not modified to reflect this. Here it is proposed to correct that omission. ------------- Commit messages: - 8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification Changes: https://git.openjdk.org/jdk/pull/23371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23371&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349006 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23371/head:pull/23371 PR: https://git.openjdk.org/jdk/pull/23371 From bpb at openjdk.org Thu Jan 30 15:58:37 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Jan 2025 15:58:37 GMT Subject: RFR: 8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification [v2] In-Reply-To: References: Message-ID: > The change made for [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated `File.getCanonicalPath` to resolve symbolic links on Windows, but its specification was not modified to reflect this. Here it is proposed to correct that omission. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8349006: Correct typo in File.setExecutable spec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23371/files - new: https://git.openjdk.org/jdk/pull/23371/files/0f091eea..964f601a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23371&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23371&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23371/head:pull/23371 PR: https://git.openjdk.org/jdk/pull/23371 From swen at openjdk.org Thu Jan 30 15:59:54 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 30 Jan 2025 15:59:54 GMT Subject: Integrated: 8344168: Change Unsafe base offset from int to long In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen wrote: > The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed. > > @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea. This pull request has now been integrated. Changeset: fdfb68c8 Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/fdfb68c8d0fddfe527291a7f4b75176c830dbb49 Stats: 164 lines in 53 files changed: 10 ins; 0 del; 154 mod 8344168: Change Unsafe base offset from int to long Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/22095 From kbarrett at openjdk.org Thu Jan 30 16:29:01 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 30 Jan 2025 16:29:01 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11] In-Reply-To: <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com> References: <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com> Message-ID: On Thu, 30 Jan 2025 08:36:34 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/nio/Bits.java line 146: >> >>> 144: } >>> 145: >>> 146: if (canary == null || canary.isDead()) { >> >> If we're keeping Reference.waitForPendingReferences, why not continue to use it, rather than introducing >> the canary as a new, ad hoc, reference processing progress detector? > > @kimbarrett Do you have a change coming to allow waitForPendingReferences be used by WB? I assume this will at least add a comment to the method (or whatever it changes to) to make it clear that it's for testing. @AlanBateman I've not done any work on JDK-8305186. There has also been discussion about making that function non-private or even public (though with concerns about specification difficulty) for use in places like this. @shipilev I'm working on a reply, but it might be long-ish. That outpacing issue for some tests is why this code wasn't switched away from jdk.internal.ref.Cleaner a long time ago. I'm still looking at it, but I currently don't think the canary provides a reliable solution to that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1935907473 From alanb at openjdk.org Thu Jan 30 16:57:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Jan 2025 16:57:00 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11] In-Reply-To: <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com> References: <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com> Message-ID: <95uXqmmcJ84nFyR6r0gw0aeGYBjFb_fdcUm_r7wtftQ=.9d0af897-c413-49dd-a09e-490a58bb1fda@github.com> On Thu, 30 Jan 2025 08:36:34 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/nio/Bits.java line 146: >> >>> 144: } >>> 145: >>> 146: if (canary == null || canary.isDead()) { >> >> If we're keeping Reference.waitForPendingReferences, why not continue to use it, rather than introducing >> the canary as a new, ad hoc, reference processing progress detector? > > @kimbarrett Do you have a change coming to allow waitForPendingReferences be used by WB? I assume this will at least add a comment to the method (or whatever it changes to) to make it clear that it's for testing. > @AlanBateman I've not done any work on JDK-8305186. There has also been discussion about making that function non-private or even public (though with concerns about specification difficulty) for use in places like this. Exposing this in this API might be scary, I think would need a lot of thinking to be confident it doesn't create an attractive nuisance. Keeping it for WB testing is okay of course. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1935953253 From shade at openjdk.org Thu Jan 30 17:07:06 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 30 Jan 2025 17:07:06 GMT Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer to use java.lang.ref.Cleaner [v11] In-Reply-To: <95uXqmmcJ84nFyR6r0gw0aeGYBjFb_fdcUm_r7wtftQ=.9d0af897-c413-49dd-a09e-490a58bb1fda@github.com> References: <9e-kLX5DVX9v0teMvEFIrp6QaKM5g66WCaR8-pOwF2E=.a2be9c9f-804f-4228-9032-535dbcb5ff50@github.com> <95uXqmmcJ84nFyR6r0gw0aeGYBjFb_fdcUm_r7wtftQ=.9d0af897-c413-49dd-a09e-490a58bb1fda@github.com> Message-ID: On Thu, 30 Jan 2025 16:54:16 GMT, Alan Bateman wrote: >> @kimbarrett Do you have a change coming to allow waitForPendingReferences be used by WB? I assume this will at least add a comment to the method (or whatever it changes to) to make it clear that it's for testing. > >> @AlanBateman I've not done any work on JDK-8305186. There has also been discussion about making that function non-private or even public (though with concerns about specification difficulty) for use in places like this. > > Exposing this in this API might be scary, I think would need a lot of thinking to be confident it doesn't create an attractive nuisance. Keeping it for WB testing is okay of course. The asynchronicity of buffer cleanup would IMO always be a headache, so we would need some sort of feedback loop. Cleaner canary is not a perfect vehicle for this, since it does not tell us directly that any buffer cleanup happened, like it used to be with reference handling thread invoking `jdk.internal.ref.Cleaner` directly. We could reinstate the similarly-shaped hack by tracking if buffer-attached cleaners have fired. That said, I have been in the room when this hack was introduced, we recognized it was not perfect, and I remember we were happy this kind of feedback still worked in practice, seeing no failures on `DirectBufferAllocTest` stress tests. So when introducing the canaries, I planned to arrive to the same happy point: stress`DirectBufferAllocTest` works in all practical configurations. There could probably be cases where we would throw OOME, when we could have waited a bit more or do a bit more cleanups. But then again, this would not be a correctness issue, but rather a performance pothole, which is, again, does not show up on stress tests, so the probability of it seems fairly low. So while we are discussing this, I think we should really keep an eye on practical cost-benefit balance here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22165#discussion_r1935969193 From jlu at openjdk.org Thu Jan 30 18:13:27 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 30 Jan 2025 18:13:27 GMT Subject: RFR: 8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification [v2] In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 15:58:37 GMT, Brian Burkhalter wrote: >> The change made for [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated `File.getCanonicalPath` to resolve symbolic links on Windows, but its specification was not modified to reflect this. Here it is proposed to correct that omission. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8349006: Correct typo in File.setExecutable spec The new wording looks correct to me, but the copyright year bump looks backwards. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/23371#pullrequestreview-2584679821 From bpb at openjdk.org Thu Jan 30 18:13:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Jan 2025 18:13:28 GMT Subject: RFR: 8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification [v2] In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 18:06:51 GMT, Justin Lu wrote: > [...], but the copyright year bump looks backwards. You're correct: that's lame. I didn't search far enough for `4,`. Thanks, will fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23371#issuecomment-2625227664 From jlu at openjdk.org Thu Jan 30 18:13:38 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 30 Jan 2025 18:13:38 GMT Subject: RFR: 8347949: Currency method to stream available Currencies [v8] In-Reply-To: <_CDQ3uLBMJfvBSVd5rN7q3P_2wXxLoyHBqnauie2uTs=.a985f8eb-8af3-41ee-bcff-77552dab67c5@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> <_CDQ3uLBMJfvBSVd5rN7q3P_2wXxLoyHBqnauie2uTs=.a985f8eb-8af3-41ee-bcff-77552dab67c5@github.com> Message-ID: On Wed, 29 Jan 2025 18:35:31 GMT, Justin Lu wrote: >> Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. >> >> The motivation can be found in the CSR. > > Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - merge master and resolve conflicts > - make 'available' un-volatile > - Merge branch 'master' into 8347949-Currency-Stream > - reflect feedback > - provide message for test assertion > - reflect Roger's review > - init hashset w/ accurate size via HashSet.newHashSet(int) > - synchronize init method over block > - init Thanks all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23165#issuecomment-2625193335 From jlu at openjdk.org Thu Jan 30 18:13:39 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 30 Jan 2025 18:13:39 GMT Subject: Integrated: 8347949: Currency method to stream available Currencies In-Reply-To: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> References: <38p38N40KXbQSsvwXZWLZ5SN7fMQQ2F0lXgkiaCCEcM=.49c3d101-afc1-4515-a275-f3b6642afaf7@github.com> Message-ID: <-jInmWUNmPn3vVH6UPEY0JOQyG6E1YRfvisOxph3YPk=.ddd0596b-9fe6-4ce8-bec4-0143e4096a43@github.com> On Thu, 16 Jan 2025 22:21:26 GMT, Justin Lu wrote: > Please review this PR and CSR which adds a method to _java.util.Currency_ which returns a stream of the available Currencies. > > The motivation can be found in the CSR. This pull request has now been integrated. Changeset: f05c53c2 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/f05c53c2c4adec4c4e875d8b84ec7682bbe356f8 Stats: 122 lines in 2 files changed: 78 ins; 1 del; 43 mod 8347949: Currency method to stream available Currencies Reviewed-by: naoto, liach, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/23165 From bpb at openjdk.org Thu Jan 30 18:40:28 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 30 Jan 2025 18:40:28 GMT Subject: RFR: 8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification [v3] In-Reply-To: References: Message-ID: > The change made for [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated `File.getCanonicalPath` to resolve symbolic links on Windows, but its specification was not modified to reflect this. Here it is proposed to correct that omission. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8349006: Fix copyright year gaffe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23371/files - new: https://git.openjdk.org/jdk/pull/23371/files/964f601a..665926bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23371&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23371&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23371/head:pull/23371 PR: https://git.openjdk.org/jdk/pull/23371 From jlu at openjdk.org Thu Jan 30 19:33:25 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 30 Jan 2025 19:33:25 GMT Subject: RFR: 8349000: Performance improvement for Currency.isPastCutoverDate(String) Message-ID: Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`. An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/23374/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23374&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349000 Stats: 14 lines in 1 file changed: 2 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/23374.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23374/head:pull/23374 PR: https://git.openjdk.org/jdk/pull/23374 From forax at univ-mlv.fr Thu Jan 30 23:17:08 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 31 Jan 2025 00:17:08 +0100 (CET) Subject: All classes in jdk.internal.random are not serializable In-Reply-To: References: Message-ID: <143153411.85524626.1738279028771.JavaMail.zimbra@univ-eiffel.fr> > From: "Glavo" > To: "core-libs-dev" > Sent: Thursday, January 30, 2025 4:22:00 PM > Subject: All classes in jdk.internal.random are not serializable > Hi, > My friend was migrating from Random to RandomGenerator, but he ran into a > roadblock: > Random is serializable, but those new implementations of RandomGenerator are not > serializable. > Was this an oversight or an evaluated decision? > Is it possible to make them serializable? For me, this is not an overlook and given that the interface RandomGenerator is open (anybody can implement it), this does not seem possible. If you read the doc of Random.from(), this is clear that a RandomGenerator is not serializable by design [ https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Random.html#from(java.util.random.RandomGenerator) | https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Random.html#from(java.util.random.RandomGenerator) ] > Glavo regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Fri Jan 31 00:29:34 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 31 Jan 2025 00:29:34 GMT Subject: RFR: 8349092: File.getFreeSpace violates specification if quotas are in effect (win) Message-ID: On Windows, for `File.getFreeSpace` return the same value as returned by `File.getUsableSpace`. ------------- Commit messages: - 8349092: File.getFreeSpace violates specification if quotas are in effect (win) Changes: https://git.openjdk.org/jdk/pull/23377/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23377&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349092 Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23377/head:pull/23377 PR: https://git.openjdk.org/jdk/pull/23377 From jlu at openjdk.org Fri Jan 31 00:30:34 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 31 Jan 2025 00:30:34 GMT Subject: RFR: 8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification [v3] In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 18:40:28 GMT, Brian Burkhalter wrote: >> The change made for [JDK-8003887](https://bugs.openjdk.org/browse/JDK-8003887) updated `File.getCanonicalPath` to resolve symbolic links on Windows, but its specification was not modified to reflect this. Here it is proposed to correct that omission. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8349006: Fix copyright year gaffe New changes and CSR looks good. ------------- Marked as reviewed by jlu (Committer). PR Review: https://git.openjdk.org/jdk/pull/23371#pullrequestreview-2585387976 From bpb at openjdk.org Fri Jan 31 00:30:34 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 31 Jan 2025 00:30:34 GMT Subject: RFR: 8349006: File.getCanonicalPath should remove "(on UNIX platforms)" from its specification [v3] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 00:19:38 GMT, Justin Lu wrote: > New changes and CSR looks good. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23371#issuecomment-2626013516 From bpb at openjdk.org Fri Jan 31 01:10:31 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 31 Jan 2025 01:10:31 GMT Subject: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v3] In-Reply-To: References: Message-ID: > Update the specification of `java.io.File.exists()` to match its behavior, which seems correct in the context of how the empty abstract pathname is documented elsewhere in the class. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8024695: Add test of length() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22821/files - new: https://git.openjdk.org/jdk/pull/22821/files/9d6d9105..021e9780 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22821&range=01-02 Stats: 13 lines in 1 file changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22821.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22821/head:pull/22821 PR: https://git.openjdk.org/jdk/pull/22821 From nbenalla at openjdk.org Fri Jan 31 01:17:55 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 31 Jan 2025 01:17:55 GMT Subject: [jdk24] Integrated: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 In-Reply-To: References: Message-ID: <6Q4dET5Tg8StYXpkRgqB2QITdEP_U3ItS28pDVLYnEw=.8d6b3e9e-5665-4e27-86e0-ebfb9b998e84@github.com> On Thu, 30 Jan 2025 10:42:43 GMT, Nizar Benalla wrote: > Hi all, > > This pull request contains a backport of commit [22069ff4](https://github.com/openjdk/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Nizar Benalla on 30 Jan 2025 and was reviewed by Chen Liang. > > Thanks! This pull request has now been integrated. Changeset: ec00b6b7 Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/ec00b6b7aceafd59eaec6149acec973eed561e82 Stats: 15 lines in 7 files changed: 0 ins; 1 del; 14 mod 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 Reviewed-by: liach Backport-of: 22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef ------------- PR: https://git.openjdk.org/jdk/pull/23366 From nbenalla at openjdk.org Fri Jan 31 01:17:54 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 31 Jan 2025 01:17:54 GMT Subject: [jdk24] RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33 In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 10:42:43 GMT, Nizar Benalla wrote: > Hi all, > > This pull request contains a backport of commit [22069ff4](https://github.com/openjdk/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Nizar Benalla on 30 Jan 2025 and was reviewed by Chen Liang. > > Thanks! Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23366#issuecomment-2626070036 From nbenalla at openjdk.org Fri Jan 31 02:08:30 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 31 Jan 2025 02:08:30 GMT Subject: RFR: 8347123: Add missing @serial tags to other modules [v2] In-Reply-To: References: Message-ID: On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer wrote: >> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19. >> >> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931 >> >> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. >> >> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation. > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Update @serialData text to CSR-approved version Code changes make sense and the updated text matches the text from the CSR. ------------- Marked as reviewed by nbenalla (Committer). PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2585511820 From matthew.swift at gmail.com Fri Jan 31 11:45:01 2025 From: matthew.swift at gmail.com (Matthew Swift) Date: Fri, 31 Jan 2025 12:45:01 +0100 Subject: Missing offset+length Arrays.hashCode() methods? Message-ID: Hello experts, Firstly, please let me know where to post this question if it is an inappropriate question for this mailing list. The java.util.Arrays utility class currently exposes pairs of methods for comparing arrays of primitives and objects, for example: java.util.Arrays#equals(byte[], byte[]) java.util.Arrays#equals(byte[], int, int, byte[], int, int) However, only a single method is provided for the equivalent hashCode() methods: java.util.Arrays#hashCode(byte[]) Specifically, the offset+length versions are not present, despite there being support in jdk.internal.util.ArraysSupport. Given the ubiquity of equals + hashCode, I would expect there to be symmetry between the equals and hashCode APIs in Arrays. The lack of support means that applications cannot take advantage of intrinsics. The use-case we have is parsing byte[] network protocol packets into their components, which are represented using objects containing offset+length pointers into the original packet. These components are frequently stored in hash sets and maps. More precisely, we are parsing ASN.1 BER packets, so our use-case is remarkably similar to JDK's sun.security.util.DerValue#hashCode, but could be applied equally to other network protocols. I know that the String class stopped using the offset+length low-allocation design some time ago, so perhaps the design I'm describing above is no longer best-practice thanks to JVM advancements, and hence there should be no need for offset+length Arrays#hashCode - but that doesn't explain the asymmetry with Arrays#equals. Thanks in advance, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From fmeum at openjdk.org Fri Jan 31 12:17:34 2025 From: fmeum at openjdk.org (Fabian Meumertzheim) Date: Fri, 31 Jan 2025 12:17:34 GMT Subject: RFR: 8258246: sun.net.www.ParseUtil.decode throws java.lang.IllegalArgumentException: Error decoding percent encoded characters Message-ID: `URLClassPath` called into `ParseUtil.fileToEncodedURL`, which misencoded characters with a four byte UTF-8 representation. Replacing that function with `toPath().toUri().toURL()` (and removing it, since its only used once) results in correct encoding for all Unicode characters. ------------- Commit messages: - 8258246: sun.net.www.ParseUtil.decode - Add and update tests Changes: https://git.openjdk.org/jdk/pull/23383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8258246 Stats: 222 lines in 4 files changed: 197 ins; 18 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/23383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23383/head:pull/23383 PR: https://git.openjdk.org/jdk/pull/23383 From fmeum at openjdk.org Fri Jan 31 12:17:34 2025 From: fmeum at openjdk.org (Fabian Meumertzheim) Date: Fri, 31 Jan 2025 12:17:34 GMT Subject: RFR: 8258246: sun.net.www.ParseUtil.decode throws java.lang.IllegalArgumentException: Error decoding percent encoded characters In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 09:47:35 GMT, Fabian Meumertzheim wrote: > `URLClassPath` called into `ParseUtil.fileToEncodedURL`, which misencoded characters with a four byte UTF-8 representation. Replacing that function with `toPath().toUri().toURL()` (and removing it, since its only used once) results in correct encoding for all Unicode characters. @jaikiran This is my attempt at making progress on https://mail.openjdk.org/pipermail/core-libs-dev/2024-November/135869.html without touching general URL/URI encoding code. I hope that this can fix the issue while avoiding backwards compatibility concerns. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23383#issuecomment-2627066685 From fmeum at openjdk.org Fri Jan 31 12:53:32 2025 From: fmeum at openjdk.org (Fabian Meumertzheim) Date: Fri, 31 Jan 2025 12:53:32 GMT Subject: RFR: 8258246: sun.net.www.ParseUtil.decode throws java.lang.IllegalArgumentException: Error decoding percent encoded characters [v2] In-Reply-To: References: Message-ID: > `URLClassPath` called into `ParseUtil.fileToEncodedURL`, which misencoded characters with a four byte UTF-8 representation. Replacing that function with `toPath().toUri().toURL()` (and removing it, since its only used once) results in correct encoding for all Unicode characters. Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision: Fix bug reference ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23383/files - new: https://git.openjdk.org/jdk/pull/23383/files/1846a5a8..87be70b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23383&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23383.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23383/head:pull/23383 PR: https://git.openjdk.org/jdk/pull/23383 From alanb at openjdk.org Fri Jan 31 14:32:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 31 Jan 2025 14:32:52 GMT Subject: RFR: 8258246: sun.net.www.ParseUtil.decode throws java.lang.IllegalArgumentException: Error decoding percent encoded characters [v2] In-Reply-To: References: Message-ID: <8P3aiW6O19QH6sxlrj1NvUA8tNj6GZjJD-GlXgsj7a8=.3c695887-c668-4d86-aff4-5f6e84094c3a@github.com> On Fri, 31 Jan 2025 12:53:32 GMT, Fabian Meumertzheim wrote: >> `URLClassPath` called into `ParseUtil.fileToEncodedURL`, which misencoded characters with a four byte UTF-8 representation. Replacing that function with `toPath().toUri().toURL()` (and removing it, since its only used once) results in correct encoding for all Unicode characters. > > Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug reference /reviewers:2 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23383#issuecomment-2627490621 From duke at openjdk.org Fri Jan 31 14:57:01 2025 From: duke at openjdk.org (duke) Date: Fri, 31 Jan 2025 14:57:01 GMT Subject: Withdrawn: 8329251: Print custom truststore/ keystore name In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com> References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com> Message-ID: <6-PdPUhEId28q2voGYFYUifXN7sXEecdD8HI1dyMT1I=.5158d0e8-a679-4b32-a9ad-c38810add3b2@github.com> On Thu, 1 Aug 2024 04:11:24 GMT, Prasadrao Koppula wrote: > This patch aims to enhance observability by logging the keystore's name at the TrustManagerFactory and KeyStore level across all keystore types and the default SSL implementation. It ensures that whenever an API user supplies a custom keystore with a file path, the file name is logged. > > Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20414 From jvernee at openjdk.org Fri Jan 31 15:07:12 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 31 Jan 2025 15:07:12 GMT Subject: RFR: 8348909: [BACKOUT] Implement a better allocator for downcalls Message-ID: <5mwJACJf1gxh1WWpaevniWzhrTeYblcH7jDai4SRwh0=.08982d02-ebab-485c-93df-c96885a2ddb3@github.com> This reverts https://github.com/openjdk/jdk/pull/23142 See the JBS issue. It seems that the changes are occasionally causing heap corruption, potentially due to use after free, which occasionally results in corrupt malloc headers being caught on mac. This failure was observed once in about 500 runs of this test, so it is quite intermittent. Backing this change out seems the easiest/safest to clear up the tier 1 failure, until we've had a chance to investigate the issue further. ------------- Commit messages: - Revert "8287788: Implement a better allocator for downcalls" Changes: https://git.openjdk.org/jdk/pull/23391/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23391&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8348909 Stats: 492 lines in 7 files changed: 18 ins; 472 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23391.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23391/head:pull/23391 PR: https://git.openjdk.org/jdk/pull/23391 From jvernee at openjdk.org Fri Jan 31 15:09:02 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 31 Jan 2025 15:09:02 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v18] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix test under VThread factory Sorry to say, but the implementation seems to have a bug that is causing occasional heap corruption, which is being caught by mac's malloc guards. Since this is failing in tier 1, and the issue seems like it will take some time to investigate and fix, I'm backing out the change for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2627569855 From jvernee at openjdk.org Fri Jan 31 15:12:09 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 31 Jan 2025 15:12:09 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v18] In-Reply-To: References: Message-ID: On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix test under VThread factory As to what's causing the issue, I wonder if the stack buffer is being freed while it is still in use, somehow. We reinterpret the segment from the shared arena, maybe the frame should keep that arena alive until it is closed itself (with a `Reference.reachabilityFence`). Looking at the code, the shared per-thread arena should be strongly reachable though, so I'm not sure if that is a plausible explanation... ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2627576484 From duke at openjdk.org Fri Jan 31 15:53:59 2025 From: duke at openjdk.org (Matthias Ernst) Date: Fri, 31 Jan 2025 15:53:59 GMT Subject: RFR: 8287788: Implement a better allocator for downcalls [v18] In-Reply-To: References: Message-ID: <8I2O8yM-dLHCTC_XhiuiFGZatEvsN2VCRI-QK7-N9ss=.bcb7f9fa-3366-4d25-8a17-96fe846d570b@github.com> On Thu, 23 Jan 2025 17:36:11 GMT, Matthias Ernst wrote: >> Certain signatures for foreign function calls (e.g. HVA return by value) require allocation of an intermediate buffer to adapt the FFM's to the native stub's calling convention. In the current implementation, this buffer is malloced and freed on every FFM invocation, a non-negligible overhead. >> >> Sample stack trace: >> >> java.lang.Thread.State: RUNNABLE >> at jdk.internal.misc.Unsafe.allocateMemory0(java.base at 25-ea/Native Method) >> ... >> at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(java.base at 25-ea/SharedUtils.java:386) >> at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base at 25-ea/Unknown Source) >> ... >> at java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base at 25-ea/Invokers$Holder) >> >> >> To alleviate this, this PR implements a per carrier-thread stacked allocator. >> >> Performance (MBA M3): >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 10 3.333 ? 0.152 ns/op >> CallOverheadByValue.byValue avgt 10 33.892 ? 0.034 ns/op >> >> After: >> Benchmark Mode Cnt Score Error Units >> CallOverheadByValue.byPtr avgt 30 3.311 ? 0.034 ns/op >> CallOverheadByValue.byValue avgt 30 6.143 ? 0.053 ns/op >> >> >> `-prof gc` also shows that the new call path is fully scalar-replaced vs 160 byte/call before. > > Matthias Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix test under VThread factory Thanks for the backout. That's java/foreign/TestBufferStack.java, let me try if I can force anything to repro. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2627668885 From fmeum at openjdk.org Fri Jan 31 15:53:47 2025 From: fmeum at openjdk.org (Fabian Meumertzheim) Date: Fri, 31 Jan 2025 15:53:47 GMT Subject: RFR: 8258246: sun.net.www.ParseUtil.decode throws java.lang.IllegalArgumentException: Error decoding percent encoded characters [v2] In-Reply-To: <8P3aiW6O19QH6sxlrj1NvUA8tNj6GZjJD-GlXgsj7a8=.3c695887-c668-4d86-aff4-5f6e84094c3a@github.com> References: <8P3aiW6O19QH6sxlrj1NvUA8tNj6GZjJD-GlXgsj7a8=.3c695887-c668-4d86-aff4-5f6e84094c3a@github.com> Message-ID: On Fri, 31 Jan 2025 14:30:35 GMT, Alan Bateman wrote: >> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix bug reference > > /reviewers:2 @AlanBateman Did you mean `/reviewers 2`? The required count per the PR body is still at 1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23383#issuecomment-2627669162 From shade at openjdk.org Fri Jan 31 15:56:45 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 31 Jan 2025 15:56:45 GMT Subject: RFR: 8348909: [BACKOUT] Implement a better allocator for downcalls In-Reply-To: <5mwJACJf1gxh1WWpaevniWzhrTeYblcH7jDai4SRwh0=.08982d02-ebab-485c-93df-c96885a2ddb3@github.com> References: <5mwJACJf1gxh1WWpaevniWzhrTeYblcH7jDai4SRwh0=.08982d02-ebab-485c-93df-c96885a2ddb3@github.com> Message-ID: On Fri, 31 Jan 2025 15:01:08 GMT, Jorn Vernee wrote: > This reverts https://github.com/openjdk/jdk/pull/23142 > > See the JBS issue. It seems that the changes are occasionally causing heap corruption, potentially due to use after free, which occasionally results in corrupt malloc headers being caught on mac. This failure was observed once in about 500 runs of this test, so it is quite intermittent. > > Backing this change out seems the easiest/safest to clear up the tier 1 failure, until we've had a chance to investigate the issue further. Backout looks fine. Looks like the clean mechanical `git revert`, and therefore trivial. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23391#pullrequestreview-2587145454 From jvernee at openjdk.org Fri Jan 31 16:05:45 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 31 Jan 2025 16:05:45 GMT Subject: RFR: 8348909: [BACKOUT] Implement a better allocator for downcalls In-Reply-To: References: <5mwJACJf1gxh1WWpaevniWzhrTeYblcH7jDai4SRwh0=.08982d02-ebab-485c-93df-c96885a2ddb3@github.com> Message-ID: On Fri, 31 Jan 2025 15:54:01 GMT, Aleksey Shipilev wrote: > Backout looks fine. Looks like the clean mechanical `git revert`, and therefore trivial. Yes, it's a clean `git revert` ------------- PR Comment: https://git.openjdk.org/jdk/pull/23391#issuecomment-2627694000 From coleenp at openjdk.org Fri Jan 31 16:43:56 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Jan 2025 16:43:56 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native Message-ID: This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java. Tested with tier1-4. ------------- Commit messages: - Fix the test. - 8349145: Make Class.getProtectionDomain() non-native Changes: https://git.openjdk.org/jdk/pull/23396/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349145 Stats: 57 lines in 8 files changed: 10 ins; 33 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/23396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23396/head:pull/23396 PR: https://git.openjdk.org/jdk/pull/23396 From liach at openjdk.org Fri Jan 31 16:48:48 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 31 Jan 2025 16:48:48 GMT Subject: RFR: 8348909: [BACKOUT] Implement a better allocator for downcalls In-Reply-To: <5mwJACJf1gxh1WWpaevniWzhrTeYblcH7jDai4SRwh0=.08982d02-ebab-485c-93df-c96885a2ddb3@github.com> References: <5mwJACJf1gxh1WWpaevniWzhrTeYblcH7jDai4SRwh0=.08982d02-ebab-485c-93df-c96885a2ddb3@github.com> Message-ID: On Fri, 31 Jan 2025 15:01:08 GMT, Jorn Vernee wrote: > This reverts https://github.com/openjdk/jdk/pull/23142 > > See the JBS issue. It seems that the changes are occasionally causing heap corruption, potentially due to use after free, which occasionally results in corrupt malloc headers being caught on mac. This failure was observed once in about 500 runs of this test, so it is quite intermittent. > > Backing this change out seems the easiest/safest to clear up the tier 1 failure, until we've had a chance to investigate the issue further. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23391#pullrequestreview-2587275589 From jvernee at openjdk.org Fri Jan 31 16:51:49 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 31 Jan 2025 16:51:49 GMT Subject: Integrated: 8348976: MemorySegment::reinretpret should be force inlined In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 16:15:51 GMT, Jorn Vernee wrote: > See the JBS issue. > > Mark the implementation of `MemorySegment::reinterpret` with `@ForceInline` so that we prevent `Reflection.getCallerClass` from falling back to a slow stack walk. > > This is a leftover from an earlier performance investigation, in which we observed `reinterpret` not being inlined, causing significant slowdowns. This pull request has now been integrated. Changeset: 137ad5d0 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/137ad5d03c598d5e2888d08e6fbc638936650f30 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8348976: MemorySegment::reinretpret should be force inlined Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/23352 From jvernee at openjdk.org Fri Jan 31 16:51:50 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 31 Jan 2025 16:51:50 GMT Subject: Integrated: 8348909: [BACKOUT] Implement a better allocator for downcalls In-Reply-To: <5mwJACJf1gxh1WWpaevniWzhrTeYblcH7jDai4SRwh0=.08982d02-ebab-485c-93df-c96885a2ddb3@github.com> References: <5mwJACJf1gxh1WWpaevniWzhrTeYblcH7jDai4SRwh0=.08982d02-ebab-485c-93df-c96885a2ddb3@github.com> Message-ID: On Fri, 31 Jan 2025 15:01:08 GMT, Jorn Vernee wrote: > This reverts https://github.com/openjdk/jdk/pull/23142 > > See the JBS issue. It seems that the changes are occasionally causing heap corruption, potentially due to use after free, which occasionally results in corrupt malloc headers being caught on mac. This failure was observed once in about 500 runs of this test, so it is quite intermittent. > > Backing this change out seems the easiest/safest to clear up the tier 1 failure, until we've had a chance to investigate the issue further. This pull request has now been integrated. Changeset: 77647421 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/77647421c5b13738f6fa145bf30cbb9dd741e164 Stats: 492 lines in 7 files changed: 18 ins; 472 del; 2 mod 8348909: [BACKOUT] Implement a better allocator for downcalls Reviewed-by: shade, liach ------------- PR: https://git.openjdk.org/jdk/pull/23391 From liach at openjdk.org Fri Jan 31 16:59:46 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 31 Jan 2025 16:59:46 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote: > This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java. > Tested with tier1-4. Marked as reviewed by liach (Reviewer). src/java.base/share/classes/java/lang/System.java line 2150: > 2148: } > 2149: > 2150: public ProtectionDomain protectionDomain(Class c) { This accessor has become pointless since the functinoal removal of SM, but it would be out of scope for this PR. ------------- PR Review: https://git.openjdk.org/jdk/pull/23396#pullrequestreview-2587285757 PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1937604899 From shade at openjdk.org Fri Jan 31 17:08:49 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 31 Jan 2025 17:08:49 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote: > This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java. > Tested with tier1-4. One thing to think about: does this mean `protectionDomain` is now discoverable by reflection? Should it be? Should it be filtered? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627825448 From naoto at openjdk.org Fri Jan 31 17:14:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 31 Jan 2025 17:14:51 GMT Subject: RFR: 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode In-Reply-To: References: Message-ID: On Wed, 29 Jan 2025 20:42:30 GMT, Naoto Sato wrote: > Force opening "tzmappings" file in text mode. Confirmed the fix with customer provided test case. Also replaced the file open function with the safer one. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23356#issuecomment-2627834134 From naoto at openjdk.org Fri Jan 31 17:14:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 31 Jan 2025 17:14:52 GMT Subject: Integrated: 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode In-Reply-To: References: Message-ID: <4lkTnkBH5zLSAHSGucGH847X9a6z5JANnnJhIkpipao=.a4a7c864-f2d1-4716-a79f-a03cda90d1bc@github.com> On Wed, 29 Jan 2025 20:42:30 GMT, Naoto Sato wrote: > Force opening "tzmappings" file in text mode. Confirmed the fix with customer provided test case. Also replaced the file open function with the safer one. This pull request has now been integrated. Changeset: 2d6045a2 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/2d6045a26f60fb36f69680e3a83b8303ab2c13e4 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8301875: java.util.TimeZone.getSystemTimeZoneID uses C library default file mode Reviewed-by: jlu, joehw ------------- PR: https://git.openjdk.org/jdk/pull/23356 From liach at openjdk.org Fri Jan 31 17:19:46 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 31 Jan 2025 17:19:46 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote: > This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java. > Tested with tier1-4. Reflection filtering was mostly a legacy measure to avoid write and read access to fields via reflection that can't hide in the VM. Now the access control of modules should be sufficient to block writes (and if java.lang is compromised, we can consider the whole VM compromised); we already grant free reads with the functional removal of SM. (The explicit move of `signers` did not filter that field, too) On a side note, if we filter more than 2 fields in `jdk.internal.reflect.Reflection`, we had better filter all fields. The filter is initialized very early in the bootstrap process, before `JavaLangAccess` is ready, so early that it couldn't access string hash code computation required for regular immutable sets. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627839902 From coleenp at openjdk.org Fri Jan 31 17:19:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Jan 2025 17:19:47 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native In-Reply-To: References: Message-ID: <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com> On Fri, 31 Jan 2025 17:06:13 GMT, Aleksey Shipilev wrote: > One thing to think about: does this mean protectionDomain is now discoverable by reflection? Should it be? Should it be filtered? We hid it in the past so it wouldn't be discoverable, but with the removal of the security manager, there doesn't seem to be a reason for hiding it. @seanjmullan can you confirm? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627840788 From alanb at openjdk.org Fri Jan 31 17:19:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 31 Jan 2025 17:19:47 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native In-Reply-To: <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com> References: <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com> Message-ID: On Fri, 31 Jan 2025 17:14:39 GMT, Coleen Phillimore wrote: > One thing to think about: does this mean `protectionDomain` is now discoverable by reflection? Should it be? Should it be filtered? Class::getProtectionDomain is a public API so anyone looking for it doesn't need reflection, but maybe you are thinking of something else? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627845207 From coleenp at openjdk.org Fri Jan 31 17:19:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Jan 2025 17:19:49 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 16:51:07 GMT, Chen Liang wrote: >> This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java. >> Tested with tier1-4. > > src/java.base/share/classes/java/lang/System.java line 2150: > >> 2148: } >> 2149: >> 2150: public ProtectionDomain protectionDomain(Class c) { > > This accessor has become pointless since the functinoal removal of SM, but it would be out of scope for this PR. Thanks for looking at this. I didn't want to change this with this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23396#discussion_r1937633847 From shade at openjdk.org Fri Jan 31 17:24:44 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 31 Jan 2025 17:24:44 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native In-Reply-To: References: <8t8V6-A3nLdnBCS_yjfVqurgQDNCrYkACZPN3V3lYvs=.3c35a2e0-917f-4801-ad1d-d1eb428adaff@github.com> Message-ID: On Fri, 31 Jan 2025 17:17:04 GMT, Alan Bateman wrote: > > One thing to think about: does this mean `protectionDomain` is now discoverable by reflection? Should it be? Should it be filtered? > > Class::getProtectionDomain is a public API so anyone looking for it doesn't need reflection, but maybe you are thinking of something else? I am thinking if anything new happens if we can reflect the field, `setAccessible(true)` it, and overwrite it. I guess the normal protection rules disallow the `setAccessible` part, but it does not hurt to think and confirm this is still enough and good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627854782 From coleenp at openjdk.org Fri Jan 31 17:33:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Jan 2025 17:33:45 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote: > This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java. > Tested with tier1-4. I was thinking of what happens if you use setAccessible(true) on this field. At worst we could add it to the filter of fields that we don't allow setAccessible(true) on. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23396#issuecomment-2627869508 From naoto at openjdk.org Fri Jan 31 18:56:47 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 31 Jan 2025 18:56:47 GMT Subject: RFR: 8349000: Performance improvement for Currency.isPastCutoverDate(String) In-Reply-To: References: Message-ID: On Thu, 30 Jan 2025 19:27:30 GMT, Justin Lu wrote: > Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`. > > An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise. Looks good. Since this code does not run in normal situations (only works when users provide a custom currency properties file), further (not concise) performance refactor may not be significant. src/java.base/share/classes/java/util/Currency.java line 1179: > 1177: } > 1178: > 1179: // cutOver adheres to: "yyyy-MM-ddTHH:mm:ss" In java.time, `YEAR` is represented as `u`, so "uuuu" is more accurate. ------------- PR Review: https://git.openjdk.org/jdk/pull/23374#pullrequestreview-2587539215 PR Review Comment: https://git.openjdk.org/jdk/pull/23374#discussion_r1937765445 From coleenp at openjdk.org Fri Jan 31 19:19:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 31 Jan 2025 19:19:29 GMT Subject: RFR: 8349145: Make Class.getProtectionDomain() non-native [v2] In-Reply-To: References: Message-ID: > This change removes the native call and injected field for ProtectionDomain in the java.lang.Class instance, and moves the field to be declared in Java. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix two tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23396/files - new: https://git.openjdk.org/jdk/pull/23396/files/ca88c32f..d7aafbaf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23396&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23396&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23396/head:pull/23396 PR: https://git.openjdk.org/jdk/pull/23396 From jlu at openjdk.org Fri Jan 31 19:46:37 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 31 Jan 2025 19:46:37 GMT Subject: RFR: 8349000: Performance improvement for Currency.isPastCutoverDate(String) [v2] In-Reply-To: References: Message-ID: <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com> > Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`. > > An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: generalize format comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23374/files - new: https://git.openjdk.org/jdk/pull/23374/files/0f1c27f3..a71a31bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23374&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23374&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23374.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23374/head:pull/23374 PR: https://git.openjdk.org/jdk/pull/23374 From jlu at openjdk.org Fri Jan 31 19:46:38 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 31 Jan 2025 19:46:38 GMT Subject: RFR: 8349000: Performance improvement for Currency.isPastCutoverDate(String) [v2] In-Reply-To: References: Message-ID: On Fri, 31 Jan 2025 18:43:58 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> generalize format comment > > src/java.base/share/classes/java/util/Currency.java line 1179: > >> 1177: } >> 1178: >> 1179: // cutOver adheres to: "yyyy-MM-ddTHH:mm:ss" > > In java.time, `YEAR` is represented as `u`, so "uuuu" is more accurate. > Looks good. Since this code does not run in normal situations (only works when users provide a custom currency properties file), further (not concise) performance refactor may not be significant. Agreed, this change is easy and more readable IMO, so I figured might as well, but won't do anything past this. > In java.time, YEAR is represented as u, so "uuuu" is more accurate. I used "`yyyy-MM-ddTHH:mm:ss`" because this is the literal date/time format specified by `Currency`. (It still uses DateFormat patterns). _The format of the timestamp must be of ISO 8601 format : 'yyyy-MM-dd'T'HH:mm:ss'_ But I understand the confusion. Changed the comment to use a generalized ISO 8601 format wording. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23374#discussion_r1937864232 From vyazici at openjdk.org Fri Jan 31 19:48:15 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 31 Jan 2025 19:48:15 GMT Subject: RFR: 8343074: test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt could be generated Message-ID: Adds `test.lib.Utils::createTempFileOfSize` to generate `test/jdk/com/sun/net/httpserver/docs` contents at runtime. This directory contains `largefile.txt` of size 2.6MiB showing up as the 4th largest file tracked by git: $ git ls-files | while read f; do echo -e $(stat -c %s "$f")"\t$f"; done >/tmp/trackedFileSizes.txt $ sort -n /tmp/trackedFileSizes.txt | tail -n 4 2730088 test/jdk/com/sun/net/httpserver/docs/test1/largefile.txt 2798680 src/java.base/share/data/unicodedata/NormalizationTest.txt 3574947 test/jdk/java/foreign/libTestDowncallStack.c 7128495 test/jdk/java/foreign/libTestUpcallStack.c **Other highlights:** - `jdk.httpclient.test.lib.common.TestUtil` is removed in favor of similar alternatives in `test.lib.Utils` and `test.lib.Asserts` - `test.lib.Asserts::assertFileContentsEqual` is added ------------- Commit messages: - Move file content assertion to `test/lib/Asserts` - Move HTTP-specific temp. file methods to `test.lib.Utils` - Replace the `docs/test1` folder with dynamically created files - Employ `TestUtil::assertFilesEqual` in `sun.net.httpserver` tests - Improve `TestUtil::getAFile` - Improve `TestUtil::compareFiles` Changes: https://git.openjdk.org/jdk/pull/23401/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23401&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343074 Stats: 680 lines in 15 files changed: 240 ins; 277 del; 163 mod Patch: https://git.openjdk.org/jdk/pull/23401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23401/head:pull/23401 PR: https://git.openjdk.org/jdk/pull/23401 From never at openjdk.org Fri Jan 31 22:18:32 2025 From: never at openjdk.org (Tom Rodriguez) Date: Fri, 31 Jan 2025 22:18:32 GMT Subject: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v3] In-Reply-To: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> Message-ID: > Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309. In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure. Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt. Tom Rodriguez 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 five additional commits since the last revision: - Disable test for Graal with Xcomp - Merge branch 'master' into tkr-oomeinaqs-ea - adjust OOMEInStampedLock.java too - Merge branch 'master' into tkr-oomeinaqs-ea - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21745/files - new: https://git.openjdk.org/jdk/pull/21745/files/98f63ef0..7ff217bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21745&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21745&range=01-02 Stats: 41928 lines in 2999 files changed: 19123 ins; 12252 del; 10553 mod Patch: https://git.openjdk.org/jdk/pull/21745.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21745/head:pull/21745 PR: https://git.openjdk.org/jdk/pull/21745 From never at openjdk.org Fri Jan 31 22:18:41 2025 From: never at openjdk.org (Tom Rodriguez) Date: Fri, 31 Jan 2025 22:18:41 GMT Subject: RFR: 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler [v2] In-Reply-To: References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com> Message-ID: On Thu, 16 Jan 2025 18:37:36 GMT, Tom Rodriguez wrote: >> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309. In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure. Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt. > > Tom Rodriguez 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: > > - adjust OOMEInStampedLock.java too > - Merge branch 'master' into tkr-oomeinaqs-ea > - 8342775: [Graal] java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME thrown from the UncaughtExceptionHandler I've disabled the test for Graal with Xcomp. Is that an acceptable solution? Testing indicates that it properly stops it for Graal without affecting other configurations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21745#issuecomment-2628490339 From naoto at openjdk.org Fri Jan 31 22:30:45 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 31 Jan 2025 22:30:45 GMT Subject: RFR: 8349000: Performance improvement for Currency.isPastCutoverDate(String) [v2] In-Reply-To: <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com> References: <44mZCe1gb7oIVFrfWrX0QB01AC8MPanddHyguOkwF7U=.92b8bb69-94c8-4f87-8ee8-9f12f5f9d47a@github.com> Message-ID: On Fri, 31 Jan 2025 19:46:37 GMT, Justin Lu wrote: >> Please review this PR which improves the performance of cut-over date checking when the user supplies a properties override via the `java.util.currency.data` sys prop. Replacing the `SimpleDateFormat` with a _java.time_ alternative has better performance. It should be noted that this method is only entered when the string `s` is confirmed to adhere to the format: `yyyy-MM-ddTHH:mm:ss`. >> >> An alternative is using `LocalDateTime.of(..)` and extracting the date/time values ourselves from `s` with the known positions which is considerably faster but not as concise. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > generalize format comment Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23374#pullrequestreview-2587989821