From plevart at openjdk.org Fri Jul 1 06:15:41 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 1 Jul 2022 06:15:41 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 12:08:19 GMT, ?????? ??????? wrote: >> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before _releasing store_. >> >> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8288327: Inline privateGetParameters() Changes requested by plevart (Reviewer). src/java.base/share/classes/java/lang/reflect/Executable.java line 457: > 455: private transient @Stable ParameterData parameterData; > 456: > 457: record ParameterData(@Stable Parameter[] parameters, boolean isReal) {} Record fields are implicitly "trusted final", which means they don't need @Stable annotation: https://github.com/openjdk/jdk/blob/124c63c17c897404e3c5c3615d6727303e4f3d06/src/hotspot/share/ci/ciField.cpp#L240 ------------- PR: https://git.openjdk.org/jdk/pull/9143 From duke at openjdk.org Fri Jul 1 07:22:49 2022 From: duke at openjdk.org (ExE Boss) Date: Fri, 1 Jul 2022 07:22:49 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 06:12:11 GMT, Peter Levart wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288327: Inline privateGetParameters() > > src/java.base/share/classes/java/lang/reflect/Executable.java line 457: > >> 455: private transient @Stable ParameterData parameterData; >> 456: >> 457: record ParameterData(@Stable Parameter[] parameters, boolean isReal) {} > > Record fields are implicitly "trusted final", which means they don't need @Stable annotation: > https://github.com/openjdk/jdk/blob/124c63c17c897404e3c5c3615d6727303e4f3d06/src/hotspot/share/ci/ciField.cpp#L240 The?[`@Stable`]?annotation is?there to?mark the?array?entries as?being?stable:[^1] https://github.com/openjdk/jdk/blob/d260a4e794681c6f4be4767350702754cfc2035c/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L51-L53 https://github.com/openjdk/jdk/blob/d260a4e794681c6f4be4767350702754cfc2035c/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L58-L62 [`@Stable`]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java [^1]: https://github.com/openjdk/jdk/pull/9143#discussion_r899993050 ------------- PR: https://git.openjdk.org/jdk/pull/9143 From duke at openjdk.org Fri Jul 1 07:31:43 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 1 Jul 2022 07:31:43 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: Message-ID: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> On Fri, 1 Jul 2022 06:12:11 GMT, Peter Levart wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288327: Inline privateGetParameters() > > src/java.base/share/classes/java/lang/reflect/Executable.java line 457: > >> 455: private transient @Stable ParameterData parameterData; >> 456: >> 457: record ParameterData(@Stable Parameter[] parameters, boolean isReal) {} > > Record fields are implicitly "trusted final", which means they don't need @Stable annotation: > https://github.com/openjdk/jdk/blob/124c63c17c897404e3c5c3615d6727303e4f3d06/src/hotspot/share/ci/ciField.cpp#L240 @plevart so should I remove it or keep as is? ------------- PR: https://git.openjdk.org/jdk/pull/9143 From dfuchs at openjdk.org Fri Jul 1 08:16:33 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 1 Jul 2022 08:16:33 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10] In-Reply-To: References: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com> <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com> Message-ID: On Thu, 30 Jun 2022 20:36:35 GMT, Roger Riggs wrote: >> I'm not sure if all unused object will be collected in one GC call always. The gc() specification says "When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all unused objects. ... There is also no guarantee that this effort will determine the change of reachability in any particular number of objects, or that any particular number of {@link java.lang.ref.Reference Reference} objects will be cleared and enqueued." But from the spec, I did not get a clear answer for the question. >> >> If the `booleanSupplier` object could be cleared in a collection other than the `ref` collection, the current code may be safer. > > True, knowing when GC is 'done' is not deterministic except for a specify Reference to a specific object. > System.gc is just a request, the checking for an object can more quickly exit the loop. > The code is as is, and already commented, might wait an extra cycle, but only in the case of a race between the requested predicate and the object being reclaimed. Ok as it. Maybe not for this PR - but it could be useful to have a version of ForceGC that takes as parameter a ReferenceQueue and a Reference. That would be more efficient than creating a new object and waiting for a different cleaner thread to cleanup that object. ------------- PR: https://git.openjdk.org/jdk/pull/8979 From xuelei at openjdk.org Fri Jul 1 08:29:39 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 1 Jul 2022 08:29:39 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10] In-Reply-To: References: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com> <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com> Message-ID: <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com> On Fri, 1 Jul 2022 08:12:59 GMT, Daniel Fuchs wrote: >> True, knowing when GC is 'done' is not deterministic except for a specify Reference to a specific object. >> System.gc is just a request, the checking for an object can more quickly exit the loop. >> The code is as is, and already commented, might wait an extra cycle, but only in the case of a race between the requested predicate and the object being reclaimed. Ok as it. > > Maybe not for this PR - but it could be useful to have a version of ForceGC that takes as parameter a ReferenceQueue and a Reference. That would be more efficient than creating a new object and waiting for a different cleaner thread to cleanup that object. @dfuch Taking a reference as parameter could simplify the use of ForceGC. I though about this idea as well, when I had to check lambada expressions in each call. I would like to do it in the future so that this PR could focus on less things. ------------- PR: https://git.openjdk.org/jdk/pull/8979 From xuelei at openjdk.org Fri Jul 1 08:35:37 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 1 Jul 2022 08:35:37 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v12] In-Reply-To: References: Message-ID: > This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in open part looks good to me. Please help to run Mach5 just case the closed test cases are impacted. Xue-Lei Andrew Fan 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 - update per feedback - Master - use Reference.refersTo - remove trailing whitespaces - use timeout factor - Merge - Merge master - Merge - add timeout parameter - ... and 5 more: https://git.openjdk.org/jdk/compare/d260a4e7...82b660af ------------- Changes: https://git.openjdk.org/jdk/pull/8979/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=11 Stats: 92 lines in 10 files changed: 13 ins; 38 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/8979.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8979/head:pull/8979 PR: https://git.openjdk.org/jdk/pull/8979 From xuelei at openjdk.org Fri Jul 1 08:35:39 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 1 Jul 2022 08:35:39 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11] In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 18:44:30 GMT, Xue-Lei Andrew Fan wrote: >> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in open part looks good to me. Please help to run Mach5 just case the closed test cases are impacted. > > Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision: > > update per feedback Could someone in Oracle help me run Mach 5 testing? ------------- PR: https://git.openjdk.org/jdk/pull/8979 From dfuchs at openjdk.org Fri Jul 1 08:43:33 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 1 Jul 2022 08:43:33 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10] In-Reply-To: <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com> References: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com> <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com> <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com> Message-ID: On Fri, 1 Jul 2022 08:26:30 GMT, Xue-Lei Andrew Fan wrote: >> Maybe not for this PR - but it could be useful to have a version of ForceGC that takes as parameter a `ReferenceQueue` and a `Reference`. That would be more efficient than creating a new object and waiting for a different cleaner thread to cleanup that object. > > @dfuch Taking a reference as parameter could simplify the use of ForceGC. I though about this idea as well, when I had to check lambada expressions in each call. I would like to do it in the future so that this PR could focus on less things. Thanks @XueleiFan, that's fine by me! ------------- PR: https://git.openjdk.org/jdk/pull/8979 From sergei.tsypanov at yandex.ru Fri Jul 1 09:18:58 2022 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 01 Jul 2022 11:18:58 +0200 Subject: Executable.hasRealParameterData() and Parameter.isNamePresent() don't work as expected In-Reply-To: <5b037acf-ee02-9201-7d0d-9284bce03ae7@oracle.com> References: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net> <5b037acf-ee02-9201-7d0d-9284bce03ae7@oracle.com> Message-ID: <2696061656667138@myt6-27f58919b1c4.qloud-c.yandex.net> Thanks! > If you want more information about parameters, use javac with its > "-parameters" option. > > -Joe > > On 6/28/2022 11:54 PM, ?????? ??????? wrote: > >> This question was asked originally here: https://stackoverflow.com/questions/72787286/executable-hasrealparameterdata-and-parameter-isnamepresent-dont-work-as-ex >> but as soon as I got no answer I've decided to try it here adding some concerns regarding JavaDoc of Parameter.isNamePresent() >> >> With ad-hoc built JDK 19 (having exposed `Executable.hasRealParameterData()`) I take the code >> >> public class Main { >> >> public static void main(String[] args) throws NoSuchMethodException { >> Method foo = Main.class.getMethod("foo", String.class, int.class); >> System.out.println(foo.hasRealParameterData()); >> } >> >> public void foo(String parameter1, int parameter2) {} >> } >> >> and compile it with >> >> % javac Main.java >> >> Then I run compiled Java class and it prints `false` into console. This is fine because decompiled `Main` class looks like >> >> public class Main { >> //... >> public void foo(String var1, int var2) {} // parameter names are not 'real' >> } >> >> i.e. parameter names are synthetic. >> >> This behaviour is understandable. >> >> Then I take the same Java sources and recompile the class with >> >> javac -g:vars Main.java >> >> I run the same code again and again it prints `false` to console. This puzzles me, because now the compiled code looks different: >> >> public class Main { >> //... >> public void foo(String parameter1, int parameter2) {} // parameter names are 'real' >> } >> >> Same happens if for recompilation I use plain -g flag (generates all auxiliary data). >> >> Now let's stop calling JDK's private API and rely only on the methods available out-of-the-box, >> e.g. `Parameter.isNamePresent()` (this one calls `Executable.hasRealParameterData()` under the hood): >> >> public static void main(String[] args) throws NoSuchMethodException { >> Method foo = Main.class.getMethod("foo", String.class, int.class); >> Parameter parameter1 = foo.getParameters()[0]; >> Parameter parameter2 = foo.getParameters()[1]; >> System.out.println(parameter1.isNamePresent()); >> System.out.println(parameter2.isNamePresent()); >> } >> >> public void foo(String parameter1, int parameter2) {} >> >> And again, no matter how I compile the sources, this code prints `false false`. >> >> So my two questions are >> 1) whether this is a bug or am I doing something wrong? >> 2) is it possible somehow to change the behaviour to have at least Parameter.isNamePresent() returning true >> >> P.S. Parameter.isNamePresent() works unexpectedly even when I run it on conventional, not hacked JDK. >> >> P.P.S. In compiled code I see 'real' parameter names, but if I stop at debug point in IDEA parameter name is suddenly `arg0` in `Parameter.name` field. >> >> P.P.P.S. I think that JavaDoc of Parameter.isNamePresent() should be changed as soon as now it points out to 'MethodParameters' attribute of a class file >> which is confusing to me as to end user of Java because I cannot understand from plain Java code what are those 'MethodParameters' and what will >> be returned for any of my methods. From sergei.tsypanov at yandex.ru Fri Jul 1 09:18:58 2022 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 01 Jul 2022 11:18:58 +0200 Subject: Executable.hasRealParameterData() and Parameter.isNamePresent() don't work as expected In-Reply-To: <5b037acf-ee02-9201-7d0d-9284bce03ae7@oracle.com> References: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net> <5b037acf-ee02-9201-7d0d-9284bce03ae7@oracle.com> Message-ID: <2696061656667138@myt6-27f58919b1c4.qloud-c.yandex.net> Thanks! > If you want more information about parameters, use javac with its > "-parameters" option. > > -Joe > > On 6/28/2022 11:54 PM, ?????? ??????? wrote: > >> This question was asked originally here: https://stackoverflow.com/questions/72787286/executable-hasrealparameterdata-and-parameter-isnamepresent-dont-work-as-ex >> but as soon as I got no answer I've decided to try it here adding some concerns regarding JavaDoc of Parameter.isNamePresent() >> >> With ad-hoc built JDK 19 (having exposed `Executable.hasRealParameterData()`) I take the code >> >> public class Main { >> >> public static void main(String[] args) throws NoSuchMethodException { >> Method foo = Main.class.getMethod("foo", String.class, int.class); >> System.out.println(foo.hasRealParameterData()); >> } >> >> public void foo(String parameter1, int parameter2) {} >> } >> >> and compile it with >> >> % javac Main.java >> >> Then I run compiled Java class and it prints `false` into console. This is fine because decompiled `Main` class looks like >> >> public class Main { >> //... >> public void foo(String var1, int var2) {} // parameter names are not 'real' >> } >> >> i.e. parameter names are synthetic. >> >> This behaviour is understandable. >> >> Then I take the same Java sources and recompile the class with >> >> javac -g:vars Main.java >> >> I run the same code again and again it prints `false` to console. This puzzles me, because now the compiled code looks different: >> >> public class Main { >> //... >> public void foo(String parameter1, int parameter2) {} // parameter names are 'real' >> } >> >> Same happens if for recompilation I use plain -g flag (generates all auxiliary data). >> >> Now let's stop calling JDK's private API and rely only on the methods available out-of-the-box, >> e.g. `Parameter.isNamePresent()` (this one calls `Executable.hasRealParameterData()` under the hood): >> >> public static void main(String[] args) throws NoSuchMethodException { >> Method foo = Main.class.getMethod("foo", String.class, int.class); >> Parameter parameter1 = foo.getParameters()[0]; >> Parameter parameter2 = foo.getParameters()[1]; >> System.out.println(parameter1.isNamePresent()); >> System.out.println(parameter2.isNamePresent()); >> } >> >> public void foo(String parameter1, int parameter2) {} >> >> And again, no matter how I compile the sources, this code prints `false false`. >> >> So my two questions are >> 1) whether this is a bug or am I doing something wrong? >> 2) is it possible somehow to change the behaviour to have at least Parameter.isNamePresent() returning true >> >> P.S. Parameter.isNamePresent() works unexpectedly even when I run it on conventional, not hacked JDK. >> >> P.P.S. In compiled code I see 'real' parameter names, but if I stop at debug point in IDEA parameter name is suddenly `arg0` in `Parameter.name` field. >> >> P.P.P.S. I think that JavaDoc of Parameter.isNamePresent() should be changed as soon as now it points out to 'MethodParameters' attribute of a class file >> which is confusing to me as to end user of Java because I cannot understand from plain Java code what are those 'MethodParameters' and what will >> be returned for any of my methods. From clanger at openjdk.org Fri Jul 1 09:21:41 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 1 Jul 2022 09:21:41 GMT Subject: [jdk19] RFR: 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run Message-ID: This pull request contains a backport of [JDK-8287672](https://bugs.openjdk.org/browse/JDK-8287672), commit [7e211d7d](https://github.com/openjdk/jdk/commit/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Rob McKenna on 21 Jun 2022 and was reviewed by Daniel Fuchs and Aleksei Efimov. It has already been brought to jdk19u but as it is a test fix I think it should still go into jdk19 as well. ------------- Commit messages: - Backport 7e211d7daac32dca8f26f408d1a3b2c7805b5a2e Changes: https://git.openjdk.org/jdk19/pull/97/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=97&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287672 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/97.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/97/head:pull/97 PR: https://git.openjdk.org/jdk19/pull/97 From sergei.tsypanov at yandex.ru Fri Jul 1 09:22:27 2022 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 01 Jul 2022 11:22:27 +0200 Subject: Executable.hasRealParameterData() and Parameter.isNamePresent() don't work as expected In-Reply-To: References: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net> Message-ID: <8897851656667347@vla3-de9b73712c73.qloud-c.yandex.net> Hi Daniel, thanks, this is what I was looking for! And what about JavaDoc of Parameter.isNamePresent()? Should we keep it as is, I mean pointing out to 'MethodParameters' attribute of a class file? Regards, Sergey > Hi Sergey, > > I believe you need to compile with `-parameters` > > https://docs.oracle.com/en/java/javase/18/docs/specs/man/javac.html > > best regards, > > -- daniel > > On 29/06/2022 07:54, ?????? ??????? wrote: > >> This question was asked originally here: https://stackoverflow.com/questions/72787286/executable-hasrealparameterdata-and-parameter-isnamepresent-dont-work-as-ex >> but as soon as I got no answer I've decided to try it here adding some concerns regarding JavaDoc of Parameter.isNamePresent() >> >> With ad-hoc built JDK 19 (having exposed `Executable.hasRealParameterData()`) I take the code >> >> public class Main { >> >> public static void main(String[] args) throws NoSuchMethodException { >> Method foo = Main.class.getMethod("foo", String.class, int.class); >> System.out.println(foo.hasRealParameterData()); >> } >> >> public void foo(String parameter1, int parameter2) {} >> } >> >> and compile it with >> >> % javac Main.java >> >> Then I run compiled Java class and it prints `false` into console. This is fine because decompiled `Main` class looks like >> >> public class Main { >> //... >> public void foo(String var1, int var2) {} // parameter names are not 'real' >> } >> >> i.e. parameter names are synthetic. >> >> This behaviour is understandable. >> >> Then I take the same Java sources and recompile the class with >> >> javac -g:vars Main.java >> >> I run the same code again and again it prints `false` to console. This puzzles me, because now the compiled code looks different: >> >> public class Main { >> //... >> public void foo(String parameter1, int parameter2) {} // parameter names are 'real' >> } >> >> Same happens if for recompilation I use plain -g flag (generates all auxiliary data). >> >> Now let's stop calling JDK's private API and rely only on the methods available out-of-the-box, >> e.g. `Parameter.isNamePresent()` (this one calls `Executable.hasRealParameterData()` under the hood): >> >> public static void main(String[] args) throws NoSuchMethodException { >> Method foo = Main.class.getMethod("foo", String.class, int.class); >> Parameter parameter1 = foo.getParameters()[0]; >> Parameter parameter2 = foo.getParameters()[1]; >> System.out.println(parameter1.isNamePresent()); >> System.out.println(parameter2.isNamePresent()); >> } >> >> public void foo(String parameter1, int parameter2) {} >> >> And again, no matter how I compile the sources, this code prints `false false`. >> >> So my two questions are >> 1) whether this is a bug or am I doing something wrong? >> 2) is it possible somehow to change the behaviour to have at least Parameter.isNamePresent() returning true >> >> P.S. Parameter.isNamePresent() works unexpectedly even when I run it on conventional, not hacked JDK. >> >> P.P.S. In compiled code I see 'real' parameter names, but if I stop at debug point in IDEA parameter name is suddenly `arg0` in `Parameter.name` field. >> >> P.P.P.S. I think that JavaDoc of Parameter.isNamePresent() should be changed as soon as now it points out to 'MethodParameters' attribute of a class file >> which is confusing to me as to end user of Java because I cannot understand from plain Java code what are those 'MethodParameters' and what will >> be returned for any of my methods. From daniel.fuchs at oracle.com Fri Jul 1 10:01:14 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 1 Jul 2022 11:01:14 +0100 Subject: [External] : Re: Executable.hasRealParameterData() and Parameter.isNamePresent() don't work as expected In-Reply-To: <8897851656667347@vla3-de9b73712c73.qloud-c.yandex.net> References: <3890111656485683@iva2-15a880c55b23.qloud-c.yandex.net> <8897851656667347@vla3-de9b73712c73.qloud-c.yandex.net> Message-ID: <4c3609ec-9f4d-c9de-a88e-4495d4293f1f@oracle.com> Hi Sergey, On 01/07/2022 10:22, ?????? ??????? wrote: > And what about JavaDoc of Parameter.isNamePresent()? Should we keep it as is, > I mean pointing out to 'MethodParameters' attribute of a class file? > AFAIU that's accurate, but it would probably deserve at least a link to the JLS? best regards, -- daniel From plevart at openjdk.org Fri Jul 1 10:38:43 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 1 Jul 2022 10:38:43 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> Message-ID: On Fri, 1 Jul 2022 07:27:59 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/reflect/Executable.java line 457: >> >>> 455: private transient @Stable ParameterData parameterData; >>> 456: >>> 457: record ParameterData(@Stable Parameter[] parameters, boolean isReal) {} >> >> Record fields are implicitly "trusted final", which means they don't need @Stable annotation: >> https://github.com/openjdk/jdk/blob/124c63c17c897404e3c5c3615d6727303e4f3d06/src/hotspot/share/ci/ciField.cpp#L240 > > @plevart so should I remove it or keep as is? Right, in that case, it should remain. ------------- PR: https://git.openjdk.org/jdk/pull/9143 From plevart at openjdk.org Fri Jul 1 10:42:44 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 1 Jul 2022 10:42:44 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: Message-ID: <5wZzn3BqlnIIlvrR7Fr-rx5nmVChvi3mdpRqQDD5uCk=.4eec0a41-a7ca-4aeb-a7db-5c2cf967b94a@github.com> On Thu, 30 Jun 2022 12:08:19 GMT, ?????? ??????? wrote: >> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before _releasing store_. >> >> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8288327: Inline privateGetParameters() Changes requested by plevart (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9143 From plevart at openjdk.org Fri Jul 1 10:42:45 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 1 Jul 2022 10:42:45 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> Message-ID: <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> On Fri, 1 Jul 2022 10:35:11 GMT, Peter Levart wrote: >> @plevart so should I remove it or keep as is? > > Right, in that case, it should remain. But, ... is any code path accessing the elements of the @Stable array by constant indexes? Only in that case would the annotation have any effect on the JIT-ed code. Otherwise it's just a waste of space. ------------- PR: https://git.openjdk.org/jdk/pull/9143 From plevart at openjdk.org Fri Jul 1 10:51:32 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 1 Jul 2022 10:51:32 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> Message-ID: On Fri, 1 Jul 2022 10:38:53 GMT, Peter Levart wrote: >> Right, in that case, it should remain. > > But, ... is any code path accessing the elements of the @Stable array by constant indexes? Only in that case would the annotation have any effect on the JIT-ed code. Otherwise it's just a waste of space. ... I can only see the array being cloned and not accessed directly. I don't belive cloning a @stable array is any different in JIT-ed code as cloning normal "mutable" array unless JIT "sees" through it and scalarizes the values of the cloned array. For example, if you have the following: static final Method method = ....; @Benchmark public Object getParameter0() { return method.getParameters()[0]; } ...would it run faster when the parameters field was marked as @stable as opposed to not? ------------- PR: https://git.openjdk.org/jdk/pull/9143 From mcimadamore at openjdk.org Fri Jul 1 11:12:13 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 1 Jul 2022 11:12:13 GMT Subject: [jdk19] RFR: 8289558: Need spec clarification of j.l.foreign.*Layout Message-ID: This patch fixes few javadoc issues in the memory layout API. The main issues are that `SequenceLayout::flatten` and `SequenceLayout::reshape` still mention failures caused by a lack of size. But that condition is no longer possible in the new API. The javadoc of `ValueLayout::arrayElementVarHandle` is suboptimal and can be clarified - UOE is only thrown if the value layout alignment is bigger than its size. Finally, the `MemoryLayout::equals` method does not mention value layout carriers. The JBS issue associated with this PR mentions also other issues, mostly related to the overly broad visibility of some of the methods in the javadoc (e.g. isPadding). Unfortunately, given the presence of an intermediate, non-public, abstract class, this is what we get from javadoc. Fixing these issues would require a deeper restructuring of the implementation, which would be too riskt at this stage. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk19/pull/98/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=98&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289558 Stats: 26 lines in 4 files changed: 15 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk19/pull/98.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/98/head:pull/98 PR: https://git.openjdk.org/jdk19/pull/98 From mcimadamore at openjdk.org Fri Jul 1 11:12:13 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 1 Jul 2022 11:12:13 GMT Subject: [jdk19] RFR: 8289558: Need spec clarification of j.l.foreign.*Layout In-Reply-To: References: Message-ID: <-ygc0nyp9d_CZHHtvNLIecmvp8ULO6Vwf2YYBPX_AE0=.74e0d7ca-d952-4186-9da8-8590d7f56bde@github.com> On Fri, 1 Jul 2022 11:03:23 GMT, Maurizio Cimadamore wrote: > This patch fixes few javadoc issues in the memory layout API. > The main issues are that `SequenceLayout::flatten` and `SequenceLayout::reshape` still mention failures caused by a lack of size. But that condition is no longer possible in the new API. > > The javadoc of `ValueLayout::arrayElementVarHandle` is suboptimal and can be clarified - UOE is only thrown if the value layout alignment is bigger than its size. > > Finally, the `MemoryLayout::equals` method does not mention value layout carriers. > > The JBS issue associated with this PR mentions also other issues, mostly related to the overly broad visibility of some of the methods in the javadoc (e.g. isPadding). Unfortunately, given the presence of an intermediate, non-public, abstract class, this is what we get from javadoc. Fixing these issues would require a deeper restructuring of the implementation, which would be too riskt at this stage. src/java.base/share/classes/java/lang/foreign/AbstractLayout.java line 162: > 160: > 161: return Objects.equals(name, ((AbstractLayout) that).name) && > 162: Objects.equals(size, ((AbstractLayout)that).size) && I've consolidated things a bit here - the superclass should check name, size and alignment - while subclasses should only check additional properties. ------------- PR: https://git.openjdk.org/jdk19/pull/98 From mcimadamore at openjdk.org Fri Jul 1 11:18:35 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 1 Jul 2022 11:18:35 GMT Subject: [jdk19] RFR: 8289558: Need spec clarification of j.l.foreign.*Layout [v2] In-Reply-To: References: Message-ID: > This patch fixes few javadoc issues in the memory layout API. > The main issues are that `SequenceLayout::flatten` and `SequenceLayout::reshape` still mention failures caused by a lack of size. But that condition is no longer possible in the new API. > > The javadoc of `ValueLayout::arrayElementVarHandle` is suboptimal and can be clarified - UOE is only thrown if the value layout alignment is bigger than its size. > > Finally, the `MemoryLayout::equals` method does not mention value layout carriers. > > The JBS issue associated with this PR mentions also other issues, mostly related to the overly broad visibility of some of the methods in the javadoc (e.g. isPadding). Unfortunately, given the presence of an intermediate, non-public, abstract class, this is what we get from javadoc. Fixing these issues would require a deeper restructuring of the implementation, which would be too riskt at this stage. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Use pattern match in equals implementation Consolidate hashcode ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/98/files - new: https://git.openjdk.org/jdk19/pull/98/files/7d993fe2..c5d3f2b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=98&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=98&range=00-01 Stats: 25 lines in 4 files changed: 0 ins; 7 del; 18 mod Patch: https://git.openjdk.org/jdk19/pull/98.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/98/head:pull/98 PR: https://git.openjdk.org/jdk19/pull/98 From mcimadamore at openjdk.org Fri Jul 1 11:36:16 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 1 Jul 2022 11:36:16 GMT Subject: [jdk19] RFR: 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec Message-ID: <4-YppanJDU1Uqiyu-104RKo9ObxVhRBeWKmUr95Xcys=.85cc5d09-d626-4bfe-a8f6-324e375d4a78@github.com> This simple patch fixes an issue where the API implementation for `SegmentAllocator::allocateUtf8String` does not conform to the javadoc implSpec. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk19/pull/99/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=99&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289570 Stats: 20 lines in 2 files changed: 19 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/99.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/99/head:pull/99 PR: https://git.openjdk.org/jdk19/pull/99 From duke at openjdk.org Fri Jul 1 12:29:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 1 Jul 2022 12:29:37 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> Message-ID: On Fri, 1 Jul 2022 10:48:32 GMT, Peter Levart wrote: >> But, ... is any code path accessing the elements of the @Stable array by constant indexes? Only in that case would the annotation have any effect on the JIT-ed code. Otherwise it's just a waste of space. > > ... I can only see the array being cloned and not accessed directly. I don't belive cloning a @stable array is any different in JIT-ed code as cloning normal "mutable" array unless JIT "sees" through it and scalarizes the values of the cloned array. For example, if you have the following: > > > static final Method method = ....; > > @Benchmark > public Object getParameter0() { > return method.getParameters()[0]; > } > > > ...would it run faster when the parameters field was marked as @stable as opposed to not? @plevart I've checked it with and without `@stable`, it's the same: with Benchmark Mode Cnt Score Error Units AccessParamsBenchmark.getParameter0 avgt 50 6,196 ? 0,142 ns/op AccessParamsBenchmark.getParameters avgt 50 4,636 ? 0,075 ns/op without Benchmark Mode Cnt Score Error Units AccessParamsBenchmark.getParameter0 avgt 50 6,196 ? 0,142 ns/op AccessParamsBenchmark.getParameters avgt 50 4,636 ? 0,075 ns/op This seems logical as effects of `@Stable` aren not propagated into cloned array. This is the benchmark I used: @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms1g", "-Xmx1g"}) public class AccessParamsBenchmark { private final Method method; public AccessParamsBenchmark() { try { method = getClass().getMethod("foo", int.class, String.class); } catch (NoSuchMethodException e) { throw new RuntimeException(e); } } @Benchmark public Object getParameters() { return method.getParameters(); } @Benchmark public Object getParameter0() { return method.getParameters()[0]; } public void foo(int parameter1, String parameter2) { } } So, should we rid the annotation from `parameters` field? ------------- PR: https://git.openjdk.org/jdk/pull/9143 From dholmes at openjdk.org Fri Jul 1 12:34:43 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Jul 2022 12:34:43 GMT Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel wrote: > Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold The changes seem fine, though the change to ObjectAlignmentInBytes is a bit disruptive. I don't really see a motivation for this though - the memory saving seems insignificant. src/hotspot/share/runtime/perfMemory.cpp line 2: > 1: /* > 2: * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved. 2022 ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9338 From alanb at openjdk.org Fri Jul 1 12:58:33 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Jul 2022 12:58:33 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v4] In-Reply-To: References: Message-ID: <23jI1ok1qwORE_X4PtTd2FVrysXejptCVmW61ZaCDDQ=.69b7a066-136e-43b0-9b43-1c5230608424@github.com> On Mon, 27 Jun 2022 16:43:55 GMT, Lance Andersen wrote: >> Hi, >> >> Please review the following patch which will: >> >> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods >> >> - public boolean exists(Path path, LinkOption... options) >> - public A readAttributesIfExists(Path path, Class type, LinkOption... options) >> >> >> This change allows for providers to provide optimizations when the file's attributes are not needed. >> >> Mach5 tiers 1 - 3 run clean with this change >> >> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) >> >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Updated tests based on feedback test/jdk/java/nio/file/spi/TestDelegation.java line 111: > 109: assertEquals(1, PROVIDER.findCall("exists").size()); > 110: assertEquals(2, PROVIDER.findCall("readAttributesIfExists").size()); > 111: PROVIDER.resetCalls(); One suggestion is to split these into testExists, testIsDirectory and testIsRegularFile so that the delegation of each method is tested in isolation. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From stuefe at openjdk.org Fri Jul 1 13:37:52 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 1 Jul 2022 13:37:52 GMT Subject: [jdk19] RFR: 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 09:10:07 GMT, Christoph Langer wrote: > This pull request contains a backport of [JDK-8287672](https://bugs.openjdk.org/browse/JDK-8287672), commit [7e211d7d](https://github.com/openjdk/jdk/commit/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rob McKenna on 21 Jun 2022 and was reviewed by Daniel Fuchs and Aleksei Efimov. > > It has already been brought to jdk19u but as it is a test fix I think it should still go into jdk19 as well. +1 ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk19/pull/97 From rriggs at openjdk.org Fri Jul 1 14:29:33 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Jul 2022 14:29:33 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10] In-Reply-To: References: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com> <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com> <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com> Message-ID: On Fri, 1 Jul 2022 08:40:06 GMT, Daniel Fuchs wrote: >> @dfuch Taking a reference as parameter could simplify the use of ForceGC. I though about this idea as well, when I had to check lambada expressions in each call. I would like to do it in the future so that this PR could focus on less things. > > Thanks @XueleiFan, that's fine by me! When using Reference/ReferenceQueue there is no Cleaner, only normal reference processing (via GC). ------------- PR: https://git.openjdk.org/jdk/pull/8979 From hseigel at openjdk.org Fri Jul 1 14:35:49 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 1 Jul 2022 14:35:49 GMT Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options [v2] In-Reply-To: References: Message-ID: > Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: Fix copyright date ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9338/files - new: https://git.openjdk.org/jdk/pull/9338/files/b71c60d8..7c973070 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9338&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9338&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9338.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9338/head:pull/9338 PR: https://git.openjdk.org/jdk/pull/9338 From hseigel at openjdk.org Fri Jul 1 14:35:50 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 1 Jul 2022 14:35:50 GMT Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options In-Reply-To: References: Message-ID: <8E9_o0CLkKkyN0H3XRgZ9AMoWczAwVD7U8xy69jvXIk=.77b3b599-3584-4dc4-b838-ff7ecfdccfde@github.com> On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel wrote: > Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Thanks Coleen and David for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9338 From hseigel at openjdk.org Fri Jul 1 14:35:52 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 1 Jul 2022 14:35:52 GMT Subject: RFR: 8289534: Change 'uncomplicated' hotspot runtime options [v2] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 12:28:35 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright date > > src/hotspot/share/runtime/perfMemory.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2001, 2021, Oracle and/or its affiliates. All rights reserved. > > 2022 Fixed. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9338 From hseigel at openjdk.org Fri Jul 1 14:35:53 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 1 Jul 2022 14:35:53 GMT Subject: Integrated: 8289534: Change 'uncomplicated' hotspot runtime options In-Reply-To: References: Message-ID: <2BSUfqtiSzV5aQTgb_etNzaBTT_Xp7gaPBhRVMQw0sI=.3adeb8a8-f159-4409-b1dd-3cd458552b56@github.com> On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel wrote: > Please review this small fix to change range constrained JVM runtime options from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: 09b4032f Author: Harold Seigel URL: https://git.openjdk.org/jdk/commit/09b4032f8b07335729e71b16b8f735514f3aebce Stats: 42 lines in 10 files changed: 1 ins; 0 del; 41 mod 8289534: Change 'uncomplicated' hotspot runtime options Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9338 From alanb at openjdk.org Fri Jul 1 14:45:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Jul 2022 14:45:39 GMT Subject: [jdk19] RFR: 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec In-Reply-To: <4-YppanJDU1Uqiyu-104RKo9ObxVhRBeWKmUr95Xcys=.85cc5d09-d626-4bfe-a8f6-324e375d4a78@github.com> References: <4-YppanJDU1Uqiyu-104RKo9ObxVhRBeWKmUr95Xcys=.85cc5d09-d626-4bfe-a8f6-324e375d4a78@github.com> Message-ID: On Fri, 1 Jul 2022 11:28:10 GMT, Maurizio Cimadamore wrote: > This simple patch fixes an issue where the API implementation for `SegmentAllocator::allocateUtf8String` does not conform to the javadoc implSpec. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/99 From alanb at openjdk.org Fri Jul 1 14:50:43 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Jul 2022 14:50:43 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v12] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 08:35:37 GMT, Xue-Lei Andrew Fan wrote: >> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in open part looks good to me. Please help to run Mach5 just case the closed test cases are impacted. > > Xue-Lei Andrew Fan 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 > - update per feedback > - Master > - use Reference.refersTo > - remove trailing whitespaces > - use timeout factor > - Merge > - Merge master > - Merge > - add timeout parameter > - ... and 5 more: https://git.openjdk.org/jdk/compare/d260a4e7...82b660af Does this address JDK-8288286 and allow ReflectionCallerCacheTest.java to be removed from ProblemList-Xcomp.txt? ------------- PR: https://git.openjdk.org/jdk/pull/8979 From dfuchs at openjdk.org Fri Jul 1 14:50:45 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 1 Jul 2022 14:50:45 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10] In-Reply-To: References: <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com> <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com> <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com> Message-ID: <64g5q52rXNZV6xMdrDBYCGlJn74vbKhY7ymN0LoTKF4=.ce4314be-f717-4c5f-96df-5eff4aae4865@github.com> On Fri, 1 Jul 2022 14:26:24 GMT, Roger Riggs wrote: >> Thanks @XueleiFan, that's fine by me! > > When using Reference/ReferenceQueue there is no Cleaner, only normal reference processing (via GC). I have tests that use Reference/ReferenceQueue to check that an object that uses a Cleaner has been garbage collected. I don't use ForceGC in those tests because it's much more efficient to wait on my ReferenceQueue rather than having ForceGC wait on something else. ------------- PR: https://git.openjdk.org/jdk/pull/8979 From rriggs at openjdk.org Fri Jul 1 15:30:41 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Jul 2022 15:30:41 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 08:31:28 GMT, Xue-Lei Andrew Fan wrote: > Could someone in Oracle help me run Mach 5 testing? The CI Passed for Tiers 1-3. ------------- PR: https://git.openjdk.org/jdk/pull/8979 From naoto at openjdk.org Fri Jul 1 16:09:53 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 1 Jul 2022 16:09:53 GMT Subject: [jdk19] Integrated: 8289549: ISO 4217 Amendment 172 Update In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 22:05:38 GMT, Naoto Sato wrote: > Trivial fix to currency data files. The change was only made to its amendment number, as the new Sierra Leone currency has already been active with amendment 171. This pull request has now been integrated. Changeset: 604ea90d Author: Naoto Sato URL: https://git.openjdk.org/jdk19/commit/604ea90d55ac8354fd7287490ef59b8e3ce020d1 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8289549: ISO 4217 Amendment 172 Update Reviewed-by: iris ------------- PR: https://git.openjdk.org/jdk19/pull/96 From psandoz at openjdk.org Fri Jul 1 16:27:50 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 1 Jul 2022 16:27:50 GMT Subject: [jdk19] RFR: 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec In-Reply-To: <4-YppanJDU1Uqiyu-104RKo9ObxVhRBeWKmUr95Xcys=.85cc5d09-d626-4bfe-a8f6-324e375d4a78@github.com> References: <4-YppanJDU1Uqiyu-104RKo9ObxVhRBeWKmUr95Xcys=.85cc5d09-d626-4bfe-a8f6-324e375d4a78@github.com> Message-ID: On Fri, 1 Jul 2022 11:28:10 GMT, Maurizio Cimadamore wrote: > This simple patch fixes an issue where the API implementation for `SegmentAllocator::allocateUtf8String` does not conform to the javadoc implSpec. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/99 From joehw at openjdk.org Fri Jul 1 17:12:11 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 1 Jul 2022 17:12:11 GMT Subject: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency Message-ID: To improve efficiency, this patch moves the limit check to within the Lexer and reports any overlimit situation as soon as it happens. Test: java.xml tests passed. ------------- Commit messages: - 8289486: Improve XSLT XPath operators count effiency Changes: https://git.openjdk.org/jdk19/pull/101/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289486 Stats: 49 lines in 2 files changed: 21 ins; 4 del; 24 mod Patch: https://git.openjdk.org/jdk19/pull/101.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/101/head:pull/101 PR: https://git.openjdk.org/jdk19/pull/101 From plevart at openjdk.org Fri Jul 1 18:35:43 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 1 Jul 2022 18:35:43 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> Message-ID: On Fri, 1 Jul 2022 12:26:04 GMT, ?????? ??????? wrote: >> ... I can only see the array being cloned and not accessed directly. I don't belive cloning a @stable array is any different in JIT-ed code as cloning normal "mutable" array unless JIT "sees" through it and scalarizes the values of the cloned array. For example, if you have the following: >> >> >> static final Method method = ....; >> >> @Benchmark >> public Object getParameter0() { >> return method.getParameters()[0]; >> } >> >> >> ...would it run faster when the parameters field was marked as @stable as opposed to not? > > @plevart I've checked it with and without `@stable`, it's the same: > > with > Benchmark Mode Cnt Score Error Units > AccessParamsBenchmark.getParameter0 avgt 50 6,196 ? 0,142 ns/op > AccessParamsBenchmark.getParameters avgt 50 4,636 ? 0,075 ns/op > > without > Benchmark Mode Cnt Score Error Units > AccessParamsBenchmark.getParameter0 avgt 50 6,196 ? 0,142 ns/op > AccessParamsBenchmark.getParameters avgt 50 4,636 ? 0,075 ns/op > > This seems logical as effects of `@Stable` aren not propagated into cloned array. > This is the benchmark I used: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms1g", "-Xmx1g"}) > public class AccessParamsBenchmark { > > private final Method method; > > public AccessParamsBenchmark() { > try { > method = getClass().getMethod("foo", int.class, String.class); > } catch (NoSuchMethodException e) { > throw new RuntimeException(e); > } > } > > @Benchmark > public Object getParameters() { > return method.getParameters(); > } > > @Benchmark > public Object getParameter0() { > return method.getParameters()[0]; > } > > public void foo(int parameter1, String parameter2) { > } > } > > > So, should we rid the annotation from `parameters` field? @Stable is only effective if the path leading to @Stable value can be constant-folded by JIT. In above test, you have an instance field Method method. This can not be constant-folded, so neither can @stable fiels in the Field object, nor array elements of a @stable array. You should replace that with "static final Method method = ..." and re-run the test. ------------- PR: https://git.openjdk.org/jdk/pull/9143 From xuelei at openjdk.org Fri Jul 1 18:40:06 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 1 Jul 2022 18:40:06 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 15:28:36 GMT, Roger Riggs wrote: > > Could someone in Oracle help me run Mach 5 testing? > > The CI Passed for Tiers 1-3. Thanks a lot! ------------- PR: https://git.openjdk.org/jdk/pull/8979 From asemenyuk at openjdk.org Fri Jul 1 19:34:41 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 1 Jul 2022 19:34:41 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 03:03:15 GMT, Alexander Matveev wrote: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be signed. > - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. > > Added additional test to validate signature when DMG or PKG is generated from predefined app image. src/jdk.jpackage/share/classes/jdk/jpackage/internal/AbstractAppImageBuilder.java line 83: > 81: if (Platform.isMac()) { > 82: new PackageFile(APP_NAME.fetchFrom(params)).save( > 83: ApplicationLayout.macAppImage().resolveAt(root)); If `.package` file is created in every app image, then this will result in app launchers of not installed apps attempting to read .cfg files from user home directory. The bigger issue on mac is that we can't modify app images after they are signed. We need a generic solution to the problem. ------------- PR: https://git.openjdk.org/jdk19/pull/89 From asemenyuk at openjdk.org Fri Jul 1 19:39:45 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 1 Jul 2022 19:39:45 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 03:03:15 GMT, Alexander Matveev wrote: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be signed. > - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. > > Added additional test to validate signature when DMG or PKG is generated from predefined app image. I think we can do the following for the signed image: don't add the `.package` file. Instead, write a warning saying that because the app image is signed, support for per-user configuration of the installed app will not be working. (https://bugs.openjdk.org/browse/JDK-8287060 refers to per-use configuration) ------------- PR: https://git.openjdk.org/jdk19/pull/89 From duke at openjdk.org Fri Jul 1 20:10:07 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 1 Jul 2022 20:10:07 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit Message-ID: This is a followup to simplify Shutdown.exit after the removal of finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement on the approach has been reached in this PR, a CSR will be filed to propose the spec change to Runtime.exit. ------------- Commit messages: - 8288984: Simplification in Shutdown.exit Changes: https://git.openjdk.org/jdk/pull/9351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288984 Stats: 10 lines in 2 files changed: 0 ins; 7 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9351/head:pull/9351 PR: https://git.openjdk.org/jdk/pull/9351 From psandoz at openjdk.org Fri Jul 1 20:15:46 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 1 Jul 2022 20:15:46 GMT Subject: [jdk19] RFR: 8289558: Need spec clarification of j.l.foreign.*Layout [v2] In-Reply-To: References: Message-ID: <7rYyWvqkHHvWguPNqyX1v1lmTvn4fjlrfXmEh_yhOWk=.11a03580-8723-45f6-b78b-b6aedb2e1331@github.com> On Fri, 1 Jul 2022 11:18:35 GMT, Maurizio Cimadamore wrote: >> This patch fixes few javadoc issues in the memory layout API. >> The main issues are that `SequenceLayout::flatten` and `SequenceLayout::reshape` still mention failures caused by a lack of size. But that condition is no longer possible in the new API. >> >> The javadoc of `ValueLayout::arrayElementVarHandle` is suboptimal and can be clarified - UOE is only thrown if the value layout alignment is bigger than its size. >> >> Finally, the `MemoryLayout::equals` method does not mention value layout carriers. >> >> The JBS issue associated with this PR mentions also other issues, mostly related to the overly broad visibility of some of the methods in the javadoc (e.g. isPadding). Unfortunately, given the presence of an intermediate, non-public, abstract class, this is what we get from javadoc. Fixing these issues would require a deeper restructuring of the implementation, which would be too riskt at this stage. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Use pattern match in equals implementation > Consolidate hashcode Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/98 From duke at openjdk.org Fri Jul 1 20:43:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 1 Jul 2022 20:43:50 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> Message-ID: On Fri, 1 Jul 2022 18:32:18 GMT, Peter Levart wrote: >> @plevart I've checked it with and without `@stable`, it's the same: >> >> with >> Benchmark Mode Cnt Score Error Units >> AccessParamsBenchmark.getParameter0 avgt 50 6,196 ? 0,142 ns/op >> AccessParamsBenchmark.getParameters avgt 50 4,636 ? 0,075 ns/op >> >> without >> Benchmark Mode Cnt Score Error Units >> AccessParamsBenchmark.getParameter0 avgt 50 6,196 ? 0,142 ns/op >> AccessParamsBenchmark.getParameters avgt 50 4,636 ? 0,075 ns/op >> >> This seems logical as effects of `@Stable` aren not propagated into cloned array. >> This is the benchmark I used: >> >> @State(Scope.Thread) >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> @Fork(jvmArgsAppend = {"-Xms1g", "-Xmx1g"}) >> public class AccessParamsBenchmark { >> >> private final Method method; >> >> public AccessParamsBenchmark() { >> try { >> method = getClass().getMethod("foo", int.class, String.class); >> } catch (NoSuchMethodException e) { >> throw new RuntimeException(e); >> } >> } >> >> @Benchmark >> public Object getParameters() { >> return method.getParameters(); >> } >> >> @Benchmark >> public Object getParameter0() { >> return method.getParameters()[0]; >> } >> >> public void foo(int parameter1, String parameter2) { >> } >> } >> >> >> So, should we rid the annotation from `parameters` field? > > @Stable is only effective if the path leading to @Stable value can be constant-folded by JIT. In above test, you have an instance field Method method. This can not be constant-folded, so neither can @stable fiels in the Field object, nor array elements of a @stable array. You should replace that with "static final Method method = ..." and re-run the test. With `static` and without `@Stable` the benchmark yields Benchmark Mode Cnt Score Error Units AccessParamsBenchmark.getParameter0 avgt 10 1,212 ? 0,083 ns/op AccessParamsBenchmark.getParameters avgt 10 2,493 ? 0,076 ns/op and with `@Stable` Benchmark Mode Cnt Score Error Units AccessParamsBenchmark.getParameter0 avgt 40 0,427 ? 0,007 ns/op AccessParamsBenchmark.getParameters avgt 40 2,123 ? 0,052 ns/op so the annotation is useful. ------------- PR: https://git.openjdk.org/jdk/pull/9143 From xuelei at openjdk.org Fri Jul 1 21:26:55 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 1 Jul 2022 21:26:55 GMT Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v12] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 14:45:44 GMT, Alan Bateman wrote: > Does this address JDK-8288286 and allow ReflectionCallerCacheTest.java to be removed from ProblemList-Xcomp.txt? I think JDK-8288286 should be addressed, but I would like to have it further evaluated via more Mach5 testing before remove the case from problem list. ------------- PR: https://git.openjdk.org/jdk/pull/8979 From mcimadamore at openjdk.org Fri Jul 1 21:48:43 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 1 Jul 2022 21:48:43 GMT Subject: [jdk19] Integrated: 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec In-Reply-To: <4-YppanJDU1Uqiyu-104RKo9ObxVhRBeWKmUr95Xcys=.85cc5d09-d626-4bfe-a8f6-324e375d4a78@github.com> References: <4-YppanJDU1Uqiyu-104RKo9ObxVhRBeWKmUr95Xcys=.85cc5d09-d626-4bfe-a8f6-324e375d4a78@github.com> Message-ID: On Fri, 1 Jul 2022 11:28:10 GMT, Maurizio Cimadamore wrote: > This simple patch fixes an issue where the API implementation for `SegmentAllocator::allocateUtf8String` does not conform to the javadoc implSpec. This pull request has now been integrated. Changeset: 8e01ffb3 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk19/commit/8e01ffb3a7914a67a66ce284029f19cdf845b626 Stats: 20 lines in 2 files changed: 19 ins; 0 del; 1 mod 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec Reviewed-by: alanb, psandoz ------------- PR: https://git.openjdk.org/jdk19/pull/99 From naoto at openjdk.org Fri Jul 1 22:31:43 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 1 Jul 2022 22:31:43 GMT Subject: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 17:04:10 GMT, Joe Wang wrote: > To improve efficiency, this patch moves the limit check to within the Lexer and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole error-report block was changed, the actual change was only placing the block to within the isOverLimit statement. > > Test: java.xml tests passed. Hi Joe, In the bug report, it reads: It would be more efficient for the XSLT XPath impl to do the same as the XPath impl does and report any error earlier So now the code works as once the first error was found, it immediately reports it. Would that result in a behavioral change, if there are multiple overflows co-exist? Would there be a possibility where a different error be thrown compared to the prior implementation? ------------- PR: https://git.openjdk.org/jdk19/pull/101 From joehw at openjdk.org Fri Jul 1 23:43:42 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 1 Jul 2022 23:43:42 GMT Subject: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 17:04:10 GMT, Joe Wang wrote: > To improve efficiency, this patch moves the limit check to within the Lexer and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole error-report block was changed, the actual change was only placing the block to within the isOverLimit statement. > > Test: java.xml tests passed. Hi Naoto, Thanks for reviewing. For counting, it's mainly the way the totalOpCount was accumulated (e.g. previously it was totalOpCount += opCount and now totalOpCount++). But since the limit on total ops is usually significantly larger than that of the count for one expression, this change won't have effect on how it was reported, that is, it won't be report before individual limit is reached. In that regard, the reporting sequence hasn't changed (that is, group -> individual count -> total). The other factor is that this feature is fairly new, the change therefore will unlikely affect any real-world applications. The test cases, reporting group/individual/total errors in the order, continued passing, that's a good indicator as well. ------------- PR: https://git.openjdk.org/jdk19/pull/101 From iveresov at openjdk.org Sat Jul 2 01:13:01 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Sat, 2 Jul 2022 01:13:01 GMT Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher documentation Message-ID: Updated man pages from markdown sources. ------------- Commit messages: - Update man pages Changes: https://git.openjdk.org/jdk19/pull/103/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=103&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8245268 Stats: 495 lines in 8 files changed: 437 ins; 16 del; 42 mod Patch: https://git.openjdk.org/jdk19/pull/103.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/103/head:pull/103 PR: https://git.openjdk.org/jdk19/pull/103 From kvn at openjdk.org Sat Jul 2 02:15:46 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 2 Jul 2022 02:15:46 GMT Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher documentation In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov wrote: > Updated man pages from markdown sources. I am not sure some words changes are correct? May be we should cleanup and update all these man pages as separate issue. And apply only `-Xcomp` changes. @iklam you recently pushed changes https://github.com/openjdk/jdk/pull/9024 which included only CDS related update. Did you discuss this issue during your changes review? src/java.base/share/man/java.1 line 3682: > 3680: .RS > 3681: .PP > 3682: The following examples show how to set the mimimum size of allocated `mimimum`? src/java.base/share/man/java.1 line 5367: > 5365: \f[CB];\f[R] > 5366: .PP > 5367: (The names "static" and "dyanmic" are used for historical reasons. `dyanmic` ? ------------- PR: https://git.openjdk.org/jdk19/pull/103 From iveresov at openjdk.org Sat Jul 2 02:48:48 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Sat, 2 Jul 2022 02:48:48 GMT Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher documentation In-Reply-To: References: Message-ID: <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com> On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov wrote: > Updated man pages from markdown sources. There is also a question of which version is actually correct. Yeah, may be I should manually craft a patch just for the Xcomp part. ------------- PR: https://git.openjdk.org/jdk19/pull/103 From iveresov at openjdk.org Sat Jul 2 02:48:47 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Sat, 2 Jul 2022 02:48:47 GMT Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher documentation In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 02:12:43 GMT, Vladimir Kozlov wrote: > I am not sure some words changes are correct? > > May be we should cleanup and update all these man pages as separate issue. And apply only `-Xcomp` changes. > Then I'd have to manually craft a patch instead of actually generating them. It seems like it's all been out of sync for a long time. ------------- PR: https://git.openjdk.org/jdk19/pull/103 From iklam at openjdk.org Sat Jul 2 03:32:26 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 2 Jul 2022 03:32:26 GMT Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher documentation In-Reply-To: <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com> References: <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com> Message-ID: On Sat, 2 Jul 2022 02:45:43 GMT, Igor Veresov wrote: > There is also a question of which version is actually correct. Yeah, may be I should manually craft a patch just for the Xcomp part. @veresov please see the closed issue https://bugs.openjdk.org/browse/JDK-8287821 @vnkozlov when I did https://github.com/openjdk/jdk/pull/9024, I generated `java.1` from the `java.md` file. I then use the `meld` program on Linux to revert all changes in the `java.1` file that were unrelated to my changes in `java.md`. Yes, it was a pain. ------------- PR: https://git.openjdk.org/jdk19/pull/103 From iveresov at openjdk.org Sat Jul 2 03:48:27 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Sat, 2 Jul 2022 03:48:27 GMT Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher documentation [v2] In-Reply-To: References: Message-ID: > Updated man pages from markdown sources. Igor Veresov 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: Update java manpage ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/103/files - new: https://git.openjdk.org/jdk19/pull/103/files/37da94df..f3526e7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=103&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=103&range=00-01 Stats: 485 lines in 8 files changed: 12 ins; 427 del; 46 mod Patch: https://git.openjdk.org/jdk19/pull/103.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/103/head:pull/103 PR: https://git.openjdk.org/jdk19/pull/103 From iveresov at openjdk.org Sat Jul 2 03:48:27 2022 From: iveresov at openjdk.org (Igor Veresov) Date: Sat, 2 Jul 2022 03:48:27 GMT Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher documentation In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov wrote: > Updated man pages from markdown sources. Ok, I just hacked a patch file. ------------- PR: https://git.openjdk.org/jdk19/pull/103 From jwilhelm at openjdk.org Sat Jul 2 11:15:24 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 2 Jul 2022 11:15:24 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8245268: -Xcomp is missing from java launcher documentation - 8288703: GetThreadState returns 0 for virtual thread that has terminated - 8288854: getLocalGraphicsEnvironment() on for multi-screen setups throws exception NPE - 8280320: C2: Loop opts are missing during OSR compilation - 8289570: SegmentAllocator:allocateUtf8String(String str) default behavior mismatch to spec - 8289585: ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64 - 8289549: ISO 4217 Amendment 172 Update - 8284358: Unreachable loop is not removed from C2 IR, leading to a broken graph The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9354/files Stats: 382 lines in 14 files changed: 330 ins; 5 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/9354.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9354/head:pull/9354 PR: https://git.openjdk.org/jdk/pull/9354 From dholmes at openjdk.org Sat Jul 2 13:11:48 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 2 Jul 2022 13:11:48 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 20:01:48 GMT, Ryan Ernst wrote: > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. There is not supposed to be any spec change in relation to this issue. The behaviour should be as specified; it was the coding that was intended to be simplified. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From dholmes at openjdk.org Sat Jul 2 13:26:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 2 Jul 2022 13:26:31 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 20:01:48 GMT, Ryan Ernst wrote: > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Sorry, I did not think this issue was intended to change the specification in any way, but I see now that it actually does - whether that was the intent or not. src/java.base/share/classes/java/lang/Runtime.java line 88: > 86: *

Invocations of this method block indefinitely. It is therefore > 87: * inadvisable to invoke this method from a shutdown hook as it will > 88: * cause deadlock. This is inaccurate. The method only blocks indefinitely when shutdown has already commenced. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Sat Jul 2 14:12:39 2022 From: duke at openjdk.org (Ryan Ernst) Date: Sat, 2 Jul 2022 14:12:39 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit In-Reply-To: References: Message-ID: <49qk9yprF5VQlAd5r_BYGZfwVi2bAID-yXUXvbaasM0=.79328465-89d8-4668-8313-d764a9636523@github.com> On Sat, 2 Jul 2022 13:21:06 GMT, David Holmes wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > src/java.base/share/classes/java/lang/Runtime.java line 88: > >> 86: *

Invocations of this method block indefinitely. It is therefore >> 87: * inadvisable to invoke this method from a shutdown hook as it will >> 88: * cause deadlock. > > This is inaccurate. The method only blocks indefinitely when shutdown has already commenced. If a shutdown hook is running, then shutdown has started, right? This new wording isn?t really a change, it?s the current behavior (the ?otherwise? portion of the old wording). But the wording is meant to be more accurate for the case of running exit from shutdown hooks. The change is the removal of the first case, which is what the code portion of the PR removes. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From jwilhelm at openjdk.org Sat Jul 2 18:13:29 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 2 Jul 2022 18:13:29 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 11:03:38 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 70f56933 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/70f5693356277c0685668219a79819707d099d9f Stats: 382 lines in 14 files changed: 330 ins; 5 del; 47 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9354 From jwilhelm at openjdk.org Sat Jul 2 18:13:28 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 2 Jul 2022 18:13:28 GMT Subject: RFR: Merge jdk19 [v2] In-Reply-To: References: Message-ID: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com> > Forwardport JDK 19 -> JDK 20 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8289603: Code change for JDK-8170762 breaks all build Reviewed-by: weijun - 8170762: Document that ISO10126Padding pads with random bytes Reviewed-by: weijun - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB Reviewed-by: alanb - 8289257: Some custom loader tests failed due to symbol refcount not decremented Reviewed-by: iklam, coleenp - 8289534: Change 'uncomplicated' hotspot runtime options Reviewed-by: coleenp, dholmes - 8289512: Fix GCC 12 warnings for adlc output_c.cpp Reviewed-by: kvn, lucy - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP Reviewed-by: kvn, thartmann, chagedorn, dlong - 8288444: Remove the workaround for frame.pack() in ModalDialogTest Reviewed-by: azvegint - 8289434: x86_64: Improve comment on gen_continuation_enter() Reviewed-by: kvn - ... and 189 more: https://git.openjdk.org/jdk/compare/f5cdabad...20b15114 ------------- Changes: https://git.openjdk.org/jdk/pull/9354/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9354&range=01 Stats: 79992 lines in 1361 files changed: 50048 ins; 16523 del; 13421 mod Patch: https://git.openjdk.org/jdk/pull/9354.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9354/head:pull/9354 PR: https://git.openjdk.org/jdk/pull/9354 From duke at openjdk.org Sat Jul 2 18:42:04 2022 From: duke at openjdk.org (kristylee88) Date: Sat, 2 Jul 2022 18:42:04 GMT Subject: RFR: Merge jdk19 [v2] In-Reply-To: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com> References: <8GdyOQFu7pc4QNML59F_8hw0Wfy7v2N0-acbUtFc4x0=.b42ce0cb-009d-41d4-9a73-14765ae033a7@github.com> Message-ID: On Sat, 2 Jul 2022 18:13:28 GMT, Jesper Wilhelmsson wrote: >> Forwardport JDK 19 -> JDK 20 > > Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits: > > - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 > - 8289603: Code change for JDK-8170762 breaks all build > > Reviewed-by: weijun > - 8170762: Document that ISO10126Padding pads with random bytes > > Reviewed-by: weijun > - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB > > Reviewed-by: alanb > - 8289257: Some custom loader tests failed due to symbol refcount not decremented > > Reviewed-by: iklam, coleenp > - 8289534: Change 'uncomplicated' hotspot runtime options > > Reviewed-by: coleenp, dholmes > - 8289512: Fix GCC 12 warnings for adlc output_c.cpp > > Reviewed-by: kvn, lucy > - 8277060: EXCEPTION_INT_DIVIDE_BY_ZERO in TypeAryPtr::dump2 with -XX:+TracePhaseCCP > > Reviewed-by: kvn, thartmann, chagedorn, dlong > - 8288444: Remove the workaround for frame.pack() in ModalDialogTest > > Reviewed-by: azvegint > - 8289434: x86_64: Improve comment on gen_continuation_enter() > > Reviewed-by: kvn > - ... and 189 more: https://git.openjdk.org/jdk/compare/f5cdabad...20b15114 Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9354 From alanb at openjdk.org Sat Jul 2 19:35:41 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 2 Jul 2022 19:35:41 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit In-Reply-To: <49qk9yprF5VQlAd5r_BYGZfwVi2bAID-yXUXvbaasM0=.79328465-89d8-4668-8313-d764a9636523@github.com> References: <49qk9yprF5VQlAd5r_BYGZfwVi2bAID-yXUXvbaasM0=.79328465-89d8-4668-8313-d764a9636523@github.com> Message-ID: On Sat, 2 Jul 2022 14:07:57 GMT, Ryan Ernst wrote: >> src/java.base/share/classes/java/lang/Runtime.java line 88: >> >>> 86: *

Invocations of this method block indefinitely. It is therefore >>> 87: * inadvisable to invoke this method from a shutdown hook as it will >>> 88: * cause deadlock. >> >> This is inaccurate. The method only blocks indefinitely when shutdown has already commenced. > > If a shutdown hook is running, then shutdown has started, right? This new wording isn?t really a change, it?s the current behavior (the ?otherwise? portion of the old wording). But the wording is meant to be more accurate for the case of running exit from shutdown hooks. The change is the removal of the first case, which is what the code portion of the PR removes. The first paragraph of the method description already makes it clear that the method never returns normally. One option for the third paragraph is to just remove it, another is to replace it with wording that specifies that the first thread to call exit is the winner and the exit code provided by other threads that attempt to exit around the same time (or while exit hooks execute) will be ignored. I think there is merit with adding a warning that a shutdown hook invoking exit will deadlock. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Sat Jul 2 20:07:32 2022 From: duke at openjdk.org (kristylee88) Date: Sat, 2 Jul 2022 20:07:32 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 20:01:48 GMT, Ryan Ernst wrote: > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Sat Jul 2 21:21:37 2022 From: duke at openjdk.org (Ryan Ernst) Date: Sat, 2 Jul 2022 21:21:37 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: better clarify multiple threads behavior ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9351/files - new: https://git.openjdk.org/jdk/pull/9351/files/9d972ba6..8e7d527a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9351/head:pull/9351 PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Sat Jul 2 21:21:38 2022 From: duke at openjdk.org (Ryan Ernst) Date: Sat, 2 Jul 2022 21:21:38 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: <49qk9yprF5VQlAd5r_BYGZfwVi2bAID-yXUXvbaasM0=.79328465-89d8-4668-8313-d764a9636523@github.com> Message-ID: On Sat, 2 Jul 2022 19:32:04 GMT, Alan Bateman wrote: >> If a shutdown hook is running, then shutdown has started, right? This new wording isn?t really a change, it?s the current behavior (the ?otherwise? portion of the old wording). But the wording is meant to be more accurate for the case of running exit from shutdown hooks. The change is the removal of the first case, which is what the code portion of the PR removes. > > The first paragraph of the method description already makes it clear that the method never returns normally. One option for the third paragraph is to just remove it, another is to replace it with wording that specifies that the first thread to call exit is the winner and the exit code provided by other threads that attempt to exit around the same time (or while exit hooks execute) will be ignored. I think there is merit with adding a warning that a shutdown hook invoking exit will deadlock. Thanks for the feedback, they are all good points. I opted to make the behavior with multiple threads more clear, see [8e7d527](https://github.com/openjdk/jdk/pull/9351/commits/8e7d527a182933818bd2d7f0f1b799dac52663be). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From chegar at openjdk.org Sat Jul 2 21:35:27 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Sat, 2 Jul 2022 21:35:27 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 13:23:27 GMT, David Holmes wrote: > Sorry, I did not think this issue was intended to change the specification in any way, but I see now that it actually does - whether that was the intent or not. While, maybe, not strictly envisioned by the JIRA issue, the specification clarification is IMO a good addition. We should update the synopsis to make it clear that the simplification is to j.l.Runtime::exit. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Sun Jul 3 00:54:44 2022 From: duke at openjdk.org (kristylee88) Date: Sun, 3 Jul 2022 00:54:44 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 21:21:37 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > better clarify multiple threads behavior Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From attila at openjdk.org Sun Jul 3 19:51:22 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 19:51:22 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <4OCN70Oq_ohbWdZwrI4DjJPBOU13KGbXdz3-rhLR3_k=.25ee110e-32df-48e8-b5b3-1f65e93a9353@github.com> On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > use computeIfAbsent where lambda could be short and static Few more thoughts. src/java.base/share/classes/java/time/ZoneOffset.java line 435: > 433: result = prev; > 434: } > 435: ID_CACHE.putIfAbsent(result.getId(), result); Feel free to ignore this one, but you could still have this be a `computeIfAbsent` and put the ID_CACHE.putIfAbsent part in the lambda. Yeah, there'll be more work done inside of `computeIfAbsent` but I think it's an acceptable tradeoff for a more comprehensible code. src/java.base/share/classes/java/time/format/DecimalStyle.java line 163: > 161: public static DecimalStyle of(Locale locale) { > 162: Objects.requireNonNull(locale, "locale"); > 163: return CACHE.computeIfAbsent(locale, l -> create(l)); Suggestion: return CACHE.computeIfAbsent(locale, DecimalStyle::create); ------------- Changes requested by attila (Reviewer). PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Sun Jul 3 19:51:23 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 19:51:23 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Tue, 28 Jun 2022 07:27:30 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/time/temporal/WeekFields.java line 331: >> >>> 329: String key = firstDayOfWeek.toString() + minimalDaysInFirstWeek; >>> 330: WeekFields rules = CACHE.get(key); >>> 331: if (rules == null) { >> >> Perhaps you don't even need this `if` block and the preceding `CACHE.get(key)` and maybe it can be replaced with: >> >> >> return CACHE.computeIfAbsent(key, ignore -> new WeekFields(firstDayOfWeek, minimalDaysInFirstWeek)); > > But it will generate garbage: non-static lambda. It already generates some garbage as it does string concatenation for the key. Here's an idea: declare a record class for the key, `record CacheKey(DayOfWeek firstDayOfWeek, int minimalDaysInFirstWeek)`. It will be more efficient than using strings for keys, and then you can have a static lambda. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Sun Jul 3 20:00:33 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 20:00:33 GMT Subject: RFR: 8289484: Cleanup unnecessary null comparison before instanceof check in java.rmi In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 21:11:09 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > > For example, the following code: > > if ((obj != null) && (obj instanceof TCPEndpoint)) { > TCPEndpoint ep = (TCPEndpoint) obj; > if (port != ep.port || !host.equals(ep.host)) > > Can be simplified to: > > if (obj instanceof TCPEndpoint ep) { > if (port != ep.port || !host.equals(ep.host)) > > > See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) Very nice; I specifically like the use of pattern matching for instanceof! ------------- Marked as reviewed by attila (Reviewer). PR: https://git.openjdk.org/jdk/pull/9332 From duke at openjdk.org Sun Jul 3 20:15:27 2022 From: duke at openjdk.org (liach) Date: Sun, 3 Jul 2022 20:15:27 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> Message-ID: <1f4jQnCcAOv4ETDZS8dd06828XruSZrTTaSE5c6VLKg=.cfb76ab7-54e3-408b-a20d-675cbd01e923@github.com> On Fri, 1 Jul 2022 20:39:49 GMT, ?????? ??????? wrote: >> @Stable is only effective if the path leading to @Stable value can be constant-folded by JIT. In above test, you have an instance field Method method. This can not be constant-folded, so neither can @stable fiels in the Field object, nor array elements of a @stable array. You should replace that with "static final Method method = ..." and re-run the test. > > With `static` and without `@Stable` the benchmark yields > > Benchmark Mode Cnt Score Error Units > AccessParamsBenchmark.getParameter0 avgt 10 1,212 ? 0,083 ns/op > AccessParamsBenchmark.getParameters avgt 10 2,493 ? 0,076 ns/op > > and with `@Stable` > > Benchmark Mode Cnt Score Error Units > AccessParamsBenchmark.getParameter0 avgt 40 0,427 ? 0,007 ns/op > AccessParamsBenchmark.getParameters avgt 40 2,123 ? 0,052 ns/op > > so the annotation is useful. hmm, is the faster getParameters (without explicit index access) a result of the annotation? getParameter0 shows the documented effect but isn't quite our use case here. ------------- PR: https://git.openjdk.org/jdk/pull/9143 From attila at openjdk.org Sun Jul 3 20:22:27 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 20:22:27 GMT Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov wrote: >> There is overload method HashMap.remove(key,value) which also checks value equality. >> It's shorter and faster than pair get+remove. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem > update copyright year Marked as reviewed by attila (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9314 From duke at openjdk.org Sun Jul 3 20:49:42 2022 From: duke at openjdk.org (liach) Date: Sun, 3 Jul 2022 20:49:42 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > use computeIfAbsent where lambda could be short and static src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 312: > 310: private Object findStore(TemporalField field, Locale locale) { > 311: Entry key = createEntry(field, locale); > 312: return CACHE.computeIfAbsent(key, e -> createStore(e.getKey(), e.getValue())); If `createStore` can be static, the call site will only have to construct a constant lambda than having to pass `this` to construct a new instance on every call ------------- PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Sun Jul 3 22:10:26 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 22:10:26 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Sun, 3 Jul 2022 20:42:53 GMT, liach wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288723: Avoid redundant ConcurrentHashMap.get call in java.time >> use computeIfAbsent where lambda could be short and static > > src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 312: > >> 310: private Object findStore(TemporalField field, Locale locale) { >> 311: Entry key = createEntry(field, locale); >> 312: return CACHE.computeIfAbsent(key, e -> createStore(e.getKey(), e.getValue())); > > If `createStore` can be static, the call site will only have to construct a constant lambda than having to pass `this` to construct a new instance on every call Well, if you _really_ want to noodle this for performance, you can also store a `this`-bound lambda in a `private final` instance field, so then it's only created once too. I wouldn't put it past `javac` to do this, but I'd have to disassemble the bytecode of a little test program to see whether it's the case. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From dholmes at openjdk.org Sun Jul 3 22:25:26 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 3 Jul 2022 22:25:26 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 21:21:37 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > better clarify multiple threads behavior Changes requested by dholmes (Reviewer). src/java.base/share/classes/java/lang/Runtime.java line 89: > 87: * of the first invocation will be used; the status codes from other invocations > 88: * will be ignored. If this method is invoked from a shutdown hook the system > 89: * will deadlock. Expressing this accurately is tricky - what is "first" here? I suggest the following: > Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code. All other invocations will block indefinitely. If this method is invoked from a shutdown hook the system will deadlock. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From plevart at openjdk.org Mon Jul 4 06:22:40 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 4 Jul 2022 06:22:40 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: <1f4jQnCcAOv4ETDZS8dd06828XruSZrTTaSE5c6VLKg=.cfb76ab7-54e3-408b-a20d-675cbd01e923@github.com> References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> <1f4jQnCcAOv4ETDZS8dd06828XruSZrTTaS E5c6VLKg=.cfb76ab7-54e3-408b-a20d-675cbd01e923@github.com> Message-ID: On Sun, 3 Jul 2022 20:12:13 GMT, liach wrote: >> With `static` and without `@Stable` the benchmark yields >> >> Benchmark Mode Cnt Score Error Units >> AccessParamsBenchmark.getParameter0 avgt 10 1,212 ? 0,083 ns/op >> AccessParamsBenchmark.getParameters avgt 10 2,493 ? 0,076 ns/op >> >> and with `@Stable` >> >> Benchmark Mode Cnt Score Error Units >> AccessParamsBenchmark.getParameter0 avgt 40 0,427 ? 0,007 ns/op >> AccessParamsBenchmark.getParameters avgt 40 2,123 ? 0,052 ns/op >> >> so the annotation is useful. > > hmm, is the faster getParameters (without explicit index access) a result of the annotation? getParameter0 shows the documented effect but isn't quite our use case here. ...neither is obtaining a cloned array and passing its reference to JMH's black hole our usecase... Still, it seems that even part of that has some advantage. I would keep the @stable annotation then. ------------- PR: https://git.openjdk.org/jdk/pull/9143 From plevart at openjdk.org Mon Jul 4 06:34:29 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 4 Jul 2022 06:34:29 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> <1f4jQnCcAOv4ETDZS8dd06828XruSZrTTaS E5c6VLKg=.cfb76ab7-54e3-408b-a20d-675cbd01e923@github.com> Message-ID: On Mon, 4 Jul 2022 06:19:00 GMT, Peter Levart wrote: >> hmm, is the faster getParameters (without explicit index access) a result of the annotation? getParameter0 shows the documented effect but isn't quite our use case here. > > ...neither is obtaining a cloned array and passing its reference to JMH's black hole our usecase... Still, it seems that even part of that has some advantage. I would keep the @stable annotation then. A more realistic use case would be something in the lines of checking whether the method is an expected one: @Benchmark public boolean isFoo() { return matches(method, "foo", int.class, String.class); } private boolean matches(Method method, String name, Class ...parameterTypes) { if (method.getName().equals(name) && method.getParameterCount() == parameterTypes.length) { var params = method.getParameters(); for (int i = 0; i < parameterTypes.length; i++) { if (params[i].getType() != parameterTypes[i]) { return false; } } return true; } else { return false; } } ------------- PR: https://git.openjdk.org/jdk/pull/9143 From aturbanov at openjdk.org Mon Jul 4 06:57:00 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 06:57:00 GMT Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov wrote: >> There is overload method HashMap.remove(key,value) which also checks value equality. >> It's shorter and faster than pair get+remove. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem > update copyright year Thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/9314 From aturbanov at openjdk.org Mon Jul 4 06:57:01 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 06:57:01 GMT Subject: Integrated: 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem In-Reply-To: References: Message-ID: <0LymFuLrSfkaiN7IOjWqiVLFrO-9mt1ZQJyjBIsBQT0=.d422573a-58be-40f0-93e5-ec0c9dc8c751@github.com> On Tue, 28 Jun 2022 21:07:41 GMT, Andrey Turbanov wrote: > There is overload method HashMap.remove(key,value) which also checks value equality. > It's shorter and faster than pair get+remove. This pull request has now been integrated. Changeset: 8e7a3cb5 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/8e7a3cb5ab3852f0c367c8807d51ffbec2d0ad49 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem Reviewed-by: lancea, attila ------------- PR: https://git.openjdk.org/jdk/pull/9314 From aturbanov at openjdk.org Mon Jul 4 07:06:30 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 07:06:30 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v3] In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: > Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9208/files - new: https://git.openjdk.org/jdk/pull/9208/files/aa67cdf6..70223b4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=01-02 Stats: 22 lines in 3 files changed: 0 ins; 11 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9208.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9208/head:pull/9208 PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Mon Jul 4 07:06:30 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 07:06:30 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v3] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <2-UjojGQKHkUzJad-eZ-p0Nc_6Em8lj-Jf2sKrm-95c=.08e39048-6ef3-4b7d-9258-3870baecf803@github.com> On Tue, 21 Jun 2022 17:08:17 GMT, liach wrote: >> @liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in general block while the mapping function runs. It can block _some_ concurrent updates, namely those that [hash to the same bin](https://github.com/openjdk/jdk/blob/0f801fe6fd2fcc181121f9846f6869ca3a03e18a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L324) and it won't block concurrent reads. I'm not saying the concern you raised isn't valid, just wanted to clarify that the situation is not nearly as grave as overall blocking; after all it ain't a `Collections.synchronizedMap` :-) > > Yeah, since `putIfAbsent` may block `get` calls, the blocking of `computeIfAbsent` is minuscule as long as the creation code is efficient enough. Just be careful that when writing the lambda for `computeIfAbsent`, preferably write static lambdas (that doesn't use `this`, instances, or local variables) so that one lambda can be reused over time than having to create a new one on each invocation. Updated ------------- PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Mon Jul 4 07:06:30 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 07:06:30 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Sun, 3 Jul 2022 19:44:55 GMT, Attila Szegedi wrote: >> But it will generate garbage: non-static lambda. > > It already generates some garbage as it does string concatenation for the key. Here's an idea: declare a record class for the key, `record CacheKey(DayOfWeek firstDayOfWeek, int minimalDaysInFirstWeek)`. It will be more efficient than using strings for keys, and then you can have a static lambda. done ------------- PR: https://git.openjdk.org/jdk/pull/9208 From mbaesken at openjdk.org Mon Jul 4 07:12:20 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Jul 2022 07:12:20 GMT Subject: RFR: JDK-8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl Message-ID: Currently the ProcessBuilder/Basic.java test fails on musl. We run into >'java.io.IOException: Cannot run program "./prog": error=8, Exec format error at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143) at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073) at Basic.run(Basic.java:2771) at Basic$JavaChild.main(Basic.java:498) Caused by: java.io.IOException: error=8, Exec format error at java.base/java.lang.ProcessImpl.forkAndExec(Native Method) at java.base/java.lang.ProcessImpl.(ProcessImpl.java:319) at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:249) at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) ... 3 more This seems to be a musl/Alpine specific issue with some process execs. So adding !vm.musl to the test might make sense. ------------- Commit messages: - JDK-8289569 Changes: https://git.openjdk.org/jdk/pull/9361/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9361&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289569 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9361.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9361/head:pull/9361 PR: https://git.openjdk.org/jdk/pull/9361 From clanger at openjdk.org Mon Jul 4 07:45:47 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 4 Jul 2022 07:45:47 GMT Subject: RFR: JDK-8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote: > Currently the ProcessBuilder/Basic.java test fails on musl. > We run into >>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073) > at Basic.run(Basic.java:2771) > at Basic$JavaChild.main(Basic.java:498) > Caused by: java.io.IOException: error=8, Exec format error > at java.base/java.lang.ProcessImpl.forkAndExec(Native Method) > at java.base/java.lang.ProcessImpl.(ProcessImpl.java:319) > at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:249) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) > ... 3 more > > This seems to be a musl/Alpine specific issue with some process execs. > So adding !vm.musl to the test might make sense. Makes sense to me. Actually, since this is a test fix, I'd prefer if you could do it directly in jdk19. We see the failures in our Alpine testing there, too. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.org/jdk/pull/9361 From kbarrett at openjdk.org Mon Jul 4 07:50:47 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 4 Jul 2022 07:50:47 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 21:21:37 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > better clarify multiple threads behavior src/java.base/share/classes/java/lang/Runtime.java line 89: > 87: * of the first invocation will be used; the status codes from other invocations > 88: * will be ignored. If this method is invoked from a shutdown hook the system > 89: * will deadlock. Is "deadlock" accurate? I thought Java monitors were reentrant, with the result that a shutdown hook calling `exit` would lead to a recursive `runHooks` which would run all the hooks, including *rerunning* hooks before the one that called exit (which could be bad), and then rerunning the hook that called exit (possibly leading to infinite recursion), then running later hooks, then returning to rerun those later hooks. This situation could be made perhaps less bad by having runHooks null out each entry in the hooks table before it runs that hook, or using currentRunningHook to determine which hooks to run in runHooks. Or something else, like immediate exit in this case. (That would be spec change.) ------------- PR: https://git.openjdk.org/jdk/pull/9351 From kbarrett at openjdk.org Mon Jul 4 07:50:50 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 4 Jul 2022 07:50:50 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Sun, 3 Jul 2022 22:19:50 GMT, David Holmes wrote: >> Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> better clarify multiple threads behavior > > src/java.base/share/classes/java/lang/Runtime.java line 89: > >> 87: * of the first invocation will be used; the status codes from other invocations >> 88: * will be ignored. If this method is invoked from a shutdown hook the system >> 89: * will deadlock. > > Expressing this accurately is tricky - what is "first" here? I suggest the following: > >> Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code. All other invocations will block indefinitely. If this method is invoked from a shutdown hook the system will deadlock. +1 - except for the "deadlock" part (see other comment). I think the old paragraph is at least confusing, and perhaps even just wrong. Let's say we've run `shutdown` so run all the hooks but not halted. Then someone calls `exit(0)`. That seems to suggest the call will block indefinitely, which is neither desirable nor what was actually implemented. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From clanger at openjdk.org Mon Jul 4 07:56:43 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 4 Jul 2022 07:56:43 GMT Subject: [jdk19] Integrated: 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 09:10:07 GMT, Christoph Langer wrote: > This pull request contains a backport of [JDK-8287672](https://bugs.openjdk.org/browse/JDK-8287672), commit [7e211d7d](https://github.com/openjdk/jdk/commit/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rob McKenna on 21 Jun 2022 and was reviewed by Daniel Fuchs and Aleksei Efimov. > > It has already been brought to jdk19u but as it is a test fix I think it should still go into jdk19 as well. This pull request has now been integrated. Changeset: 5b5bc6c2 Author: Christoph Langer URL: https://git.openjdk.org/jdk19/commit/5b5bc6c26e9843e16f241b89853a3a1fa5ae61f0 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run Reviewed-by: stuefe Backport-of: 7e211d7daac32dca8f26f408d1a3b2c7805b5a2e ------------- PR: https://git.openjdk.org/jdk19/pull/97 From chegar at openjdk.org Mon Jul 4 08:11:43 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 4 Jul 2022 08:11:43 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 01:57:11 GMT, Kim Barrett wrote: > Is "deadlock" accurate? Yes. In the context of the specification, "shutdown hook" means _application_ shutdown hook - as far as the specification is concerned, application shutdown hooks are the only kind of hooks. Right? For example, the following will deadlock (when run with the changes in this PR): public class TestHook { public static void main(String... arg) { Thread hook = new Thread("my-hook") { @Override public void run() { System.exit(1); } }; Runtime.getRuntime().addShutdownHook(hook); System.exit(0); } } ------------- PR: https://git.openjdk.org/jdk/pull/9351 From stuefe at openjdk.org Mon Jul 4 08:37:39 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Jul 2022 08:37:39 GMT Subject: RFR: JDK-8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote: > Currently the ProcessBuilder/Basic.java test fails on musl. > We run into >>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073) > at Basic.run(Basic.java:2771) > at Basic$JavaChild.main(Basic.java:498) > Caused by: java.io.IOException: error=8, Exec format error > at java.base/java.lang.ProcessImpl.forkAndExec(Native Method) > at java.base/java.lang.ProcessImpl.(ProcessImpl.java:319) > at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:249) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) > ... 3 more > > This seems to be a musl/Alpine specific issue with some process execs. > So adding !vm.musl to the test might make sense. Do you want to leave the "Platform.isMusl()" parts in the code? ------------- PR: https://git.openjdk.org/jdk/pull/9361 From alanb at openjdk.org Mon Jul 4 08:45:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Jul 2022 08:45:40 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 01:59:37 GMT, Kim Barrett wrote: >> src/java.base/share/classes/java/lang/Runtime.java line 89: >> >>> 87: * of the first invocation will be used; the status codes from other invocations >>> 88: * will be ignored. If this method is invoked from a shutdown hook the system >>> 89: * will deadlock. >> >> Expressing this accurately is tricky - what is "first" here? I suggest the following: >> >>> Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code. All other invocations will block indefinitely. If this method is invoked from a shutdown hook the system will deadlock. > > +1 - except for the "deadlock" part (see other comment). I think the old paragraph is at least confusing, and perhaps even just wrong. Let's say we've run `shutdown` so run all the hooks but not halted. Then someone calls `exit(0)`. That seems to suggest the call will block indefinitely, which is neither desirable nor what was actually implemented. David's refinement looks good. The sentence on deadlock is accurate as shutdown hooks run on other threads, not the thread calling System.ext. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From alanb at openjdk.org Mon Jul 4 08:46:42 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Jul 2022 08:46:42 GMT Subject: RFR: JDK-8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote: > Currently the ProcessBuilder/Basic.java test fails on musl. > We run into >>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073) > at Basic.run(Basic.java:2771) > at Basic$JavaChild.main(Basic.java:498) > Caused by: java.io.IOException: error=8, Exec format error > at java.base/java.lang.ProcessImpl.forkAndExec(Native Method) > at java.base/java.lang.ProcessImpl.(ProcessImpl.java:319) > at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:249) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) > ... 3 more > > This seems to be a musl/Alpine specific issue with some process execs. > So adding !vm.musl to the test might make sense. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9361 From mbaesken at openjdk.org Mon Jul 4 08:46:43 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Jul 2022 08:46:43 GMT Subject: RFR: JDK-8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 08:35:35 GMT, Thomas Stuefe wrote: > Do you want to leave the "Platform.isMusl()" parts in the code? I would leave it for now if it is okay. ------------- PR: https://git.openjdk.org/jdk/pull/9361 From stuefe at openjdk.org Mon Jul 4 08:56:38 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Jul 2022 08:56:38 GMT Subject: RFR: JDK-8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl In-Reply-To: References: Message-ID: <4FJVGoe2IYMK36UOGq40qNgrrZ6OJQ2UFic0E1rfYz4=.4dc3ec31-4601-4bd6-8463-0ede486fc2bd@github.com> On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote: > Currently the ProcessBuilder/Basic.java test fails on musl. > We run into >>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073) > at Basic.run(Basic.java:2771) > at Basic$JavaChild.main(Basic.java:498) > Caused by: java.io.IOException: error=8, Exec format error > at java.base/java.lang.ProcessImpl.forkAndExec(Native Method) > at java.base/java.lang.ProcessImpl.(ProcessImpl.java:319) > at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:249) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) > ... 3 more > > This seems to be a musl/Alpine specific issue with some process execs. > So adding !vm.musl to the test might make sense. +1. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9361 From mbaesken at openjdk.org Mon Jul 4 09:00:40 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Jul 2022 09:00:40 GMT Subject: Integrated: JDK-8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote: > Currently the ProcessBuilder/Basic.java test fails on musl. > We run into >>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073) > at Basic.run(Basic.java:2771) > at Basic$JavaChild.main(Basic.java:498) > Caused by: java.io.IOException: error=8, Exec format error > at java.base/java.lang.ProcessImpl.forkAndExec(Native Method) > at java.base/java.lang.ProcessImpl.(ProcessImpl.java:319) > at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:249) > at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110) > ... 3 more > > This seems to be a musl/Alpine specific issue with some process execs. > So adding !vm.musl to the test might make sense. This pull request has now been integrated. Changeset: a8edd7a1 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/a8edd7a12f955fe843c7c9ad4273e9c653a80c5a Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl Reviewed-by: clanger, alanb, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/9361 From duke at openjdk.org Mon Jul 4 10:09:25 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 4 Jul 2022 10:09:25 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> <1f4jQnCcAOv4ETDZS8dd06828XruSZrTTaS E5c6VLKg=.cfb76ab7-54e3-408b-a20d-675cbd01e923@github.com> Message-ID: On Mon, 4 Jul 2022 06:31:15 GMT, Peter Levart wrote: >> ...neither is obtaining a cloned array and passing its reference to JMH's black hole our usecase... Still, it seems that even part of that has some advantage. I would keep the @stable annotation then. > > A more realistic use case would be something in the lines of checking whether the method is an expected one: > > > @Benchmark > public boolean isFoo() { > return matches(method, "foo", int.class, String.class); > } > > private boolean matches(Method method, String name, Class ...parameterTypes) { > if (method.getName().equals(name) && > method.getParameterCount() == parameterTypes.length) { > var params = method.getParameters(); > for (int i = 0; i < parameterTypes.length; i++) { > if (params[i].getType() != parameterTypes[i]) { > return false; > } > } > return true; > } else { > return false; > } > } Without `@Stable` your benchmark yields Benchmark Mode Cnt Score Error Units AccessParamsBenchmark.isFoo avgt 40 1,110 ? 0,062 ns/op and with `@Stable` it yields Benchmark Mode Cnt Score Error Units AccessParamsBenchmark.isFoo avgt 40 0,836 ? 0,015 ns/op Java 18: Benchmark Mode Cnt Score Error Units AccessParamsBenchmark.isFoo avgt 40 6,105 ? 0,107 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/9143 From mbaesken at openjdk.org Mon Jul 4 10:49:41 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Jul 2022 10:49:41 GMT Subject: [jdk19] RFR: 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl Message-ID: <9ArG2Q3cz0NDOiPllGmAI9x9Wnl1s2Ld8B1GDa5izt4=.0b6ace17-340f-48b4-9e17-8bbaf5f919b7@github.com> 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl ------------- Commit messages: - Backport a8edd7a12f955fe843c7c9ad4273e9c653a80c5a Changes: https://git.openjdk.org/jdk19/pull/106/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289569 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/106.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/106/head:pull/106 PR: https://git.openjdk.org/jdk19/pull/106 From jvernee at openjdk.org Mon Jul 4 11:32:13 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Jul 2022 11:32:13 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM Message-ID: This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. Testing: `jdk_foreign` test suite on all platforms that implement VaList. ------------- Commit messages: - Update Javadoc - Cleanup - Test passing Changes: https://git.openjdk.org/jdk19/pull/91/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=91&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289148 Stats: 392 lines in 7 files changed: 235 ins; 19 del; 138 mod Patch: https://git.openjdk.org/jdk19/pull/91.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/91/head:pull/91 PR: https://git.openjdk.org/jdk19/pull/91 From jvernee at openjdk.org Mon Jul 4 11:45:06 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Jul 2022 11:45:06 GMT Subject: [jdk19] RFR: 8289558: Need spec clarification of j.l.foreign.*Layout [v2] In-Reply-To: References: Message-ID: <9F6DJOvHJjZwufEjX2KdMgN_KT_Rsau_9ovdZTwHTrc=.58d8ee6f-5c32-433f-afbe-2e11b6ec70cd@github.com> On Fri, 1 Jul 2022 11:18:35 GMT, Maurizio Cimadamore wrote: >> This patch fixes few javadoc issues in the memory layout API. >> The main issues are that `SequenceLayout::flatten` and `SequenceLayout::reshape` still mention failures caused by a lack of size. But that condition is no longer possible in the new API. >> >> The javadoc of `ValueLayout::arrayElementVarHandle` is suboptimal and can be clarified - UOE is only thrown if the value layout alignment is bigger than its size. >> >> Finally, the `MemoryLayout::equals` method does not mention value layout carriers. >> >> The JBS issue associated with this PR mentions also other issues, mostly related to the overly broad visibility of some of the methods in the javadoc (e.g. isPadding). Unfortunately, given the presence of an intermediate, non-public, abstract class, this is what we get from javadoc. Fixing these issues would require a deeper restructuring of the implementation, which would be too riskt at this stage. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Use pattern match in equals implementation > Consolidate hashcode Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/98 From dholmes at openjdk.org Mon Jul 4 12:11:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Jul 2022 12:11:49 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 08:07:25 GMT, Chris Hegarty wrote: >> src/java.base/share/classes/java/lang/Runtime.java line 89: >> >>> 87: * of the first invocation will be used; the status codes from other invocations >>> 88: * will be ignored. If this method is invoked from a shutdown hook the system >>> 89: * will deadlock. >> >> Is "deadlock" accurate? I thought Java monitors were reentrant, with the result that a shutdown hook calling `exit` would lead to a recursive `runHooks` which would run all the hooks, including *rerunning* hooks before the one that called exit (which could be bad), and then rerunning the hook that called exit (possibly leading to infinite recursion), then running later hooks, then returning to rerun those later hooks. This situation could be made perhaps less bad by having runHooks null out each entry in the hooks table before it runs that hook, or using currentRunningHook to determine which hooks to run in runHooks. Or something else, like immediate exit in this case. (That would be spec change.) > >> Is "deadlock" accurate? > > Yes. > > In the context of the specification, "shutdown hook" means _application_ shutdown hook - as far as the specification is concerned, application shutdown hooks are the only kind of hooks. Right? > > For example, the following will deadlock (when run with the changes in this PR): > > > public class TestHook { > public static void main(String... arg) { > Thread hook = new Thread("my-hook") { > @Override > public void run() { > System.exit(1); > } > }; > Runtime.getRuntime().addShutdownHook(hook); > System.exit(0); > } > } It is a general deadlock, not a monitor based deadlock: the thread that called exit and holds the lock has to join() the hook thread. The hook thread blocks on the lock held by the exiting thread. Neither thread can progress. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From dholmes at openjdk.org Mon Jul 4 12:22:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Jul 2022 12:22:45 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Sat, 2 Jul 2022 21:21:37 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > better clarify multiple threads behavior > Let's say we've run shutdown so run all the hooks but not halted. Then someone calls exit(0). That seems to suggest the call will block indefinitely, which is neither desirable nor what was actually implemented. If the hook threads do not halt then the exiting thread (which holds the lock) blocks forever in the join(). Any other call to exit blocks trying to acquire the lock. That has always been the way this works - if hook threads don't terminate then the VM doesn't (unless someone calls halt() directly). That is one of the things the window you suggested be closed, allowed - a call to exit(non-zero) could force a call to halt(). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Mon Jul 4 12:50:44 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Mon, 4 Jul 2022 12:50:44 GMT Subject: RFR: 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec [v2] In-Reply-To: <6IlMf8sU-acr2ck6Ao0q211RBuc1SdCDx_pMHLkqBQ8=.c422a523-6e77-4f44-b0cd-95b4f184544a@github.com> References: <6IlMf8sU-acr2ck6Ao0q211RBuc1SdCDx_pMHLkqBQ8=.c422a523-6e77-4f44-b0cd-95b4f184544a@github.com> Message-ID: <14d-Y4wtumPhPtyvexnbgfO_pSWfQavSXYtt990O9dQ=.23724c19-48e3-42f2-951b-3abfeca4d632@github.com> On Tue, 28 Jun 2022 10:32:31 GMT, Raffaello Giulietti wrote: >> `BigDecimal.morePoint[Left|Right]()` should return the target `this` when the argument is 0 _and_ the scale is non-negative. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec CSR is ready as [JDK-8289504](https://bugs.openjdk.org/browse/JDK-8289504) ------------- PR: https://git.openjdk.org/jdk/pull/9307 From jvernee at openjdk.org Mon Jul 4 13:26:53 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 4 Jul 2022 13:26:53 GMT Subject: [jdk19] RFR: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 Message-ID: This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. Testing: local run of the `jdk_foreign` test suite. ------------- Commit messages: - Throw IAE when converting string with null byte. Changes: https://git.openjdk.org/jdk19/pull/107/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=107&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289601 Stats: 32 lines in 3 files changed: 25 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/107.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/107/head:pull/107 PR: https://git.openjdk.org/jdk19/pull/107 From clanger at openjdk.org Mon Jul 4 14:45:39 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 4 Jul 2022 14:45:39 GMT Subject: [jdk19] RFR: 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl In-Reply-To: <9ArG2Q3cz0NDOiPllGmAI9x9Wnl1s2Ld8B1GDa5izt4=.0b6ace17-340f-48b4-9e17-8bbaf5f919b7@github.com> References: <9ArG2Q3cz0NDOiPllGmAI9x9Wnl1s2Ld8B1GDa5izt4=.0b6ace17-340f-48b4-9e17-8bbaf5f919b7@github.com> Message-ID: On Mon, 4 Jul 2022 10:39:20 GMT, Matthias Baesken wrote: > 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl Thanks for bringing it to jdk19. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.org/jdk19/pull/106 From mbaesken at openjdk.org Mon Jul 4 14:49:39 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Jul 2022 14:49:39 GMT Subject: [jdk19] Integrated: 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl In-Reply-To: <9ArG2Q3cz0NDOiPllGmAI9x9Wnl1s2Ld8B1GDa5izt4=.0b6ace17-340f-48b4-9e17-8bbaf5f919b7@github.com> References: <9ArG2Q3cz0NDOiPllGmAI9x9Wnl1s2Ld8B1GDa5izt4=.0b6ace17-340f-48b4-9e17-8bbaf5f919b7@github.com> Message-ID: <-vYPIyzGE0GibLgM2qzSYEK9E3JXTF7X0YAHsHL2N5k=.53a677a6-3def-4b59-adbd-107218c91d82@github.com> On Mon, 4 Jul 2022 10:39:20 GMT, Matthias Baesken wrote: > 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl This pull request has now been integrated. Changeset: 0dff3276 Author: Matthias Baesken URL: https://git.openjdk.org/jdk19/commit/0dff3276e863fcbf496fe6decd3335cd43cab21f Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl Reviewed-by: clanger Backport-of: a8edd7a12f955fe843c7c9ad4273e9c653a80c5a ------------- PR: https://git.openjdk.org/jdk19/pull/106 From duke at openjdk.org Mon Jul 4 16:17:27 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 4 Jul 2022 16:17:27 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v3] In-Reply-To: References: Message-ID: > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: iterate on wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9351/files - new: https://git.openjdk.org/jdk/pull/9351/files/8e7d527a..2253259c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9351/head:pull/9351 PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Mon Jul 4 16:17:27 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 4 Jul 2022 16:17:27 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 08:42:02 GMT, Alan Bateman wrote: >> +1 - except for the "deadlock" part (see other comment). I think the old paragraph is at least confusing, and perhaps even just wrong. Let's say we've run `shutdown` so run all the hooks but not halted. Then someone calls `exit(0)`. That seems to suggest the call will block indefinitely, which is neither desirable nor what was actually implemented. > > David's refinement looks good. The sentence on deadlock is accurate as shutdown hooks run on other threads, not the thread calling System.ext. I reworded with the suggested text in mind. I also added another sentence referencing native signal handlers, which may also initiate shutdown. I think this clarification is important so that it is clear the status code of all invocations from Java may still be ignored. See [2253259](https://github.com/openjdk/jdk/pull/9351/commits/2253259c82b13e7b2186429a80cc42497235b035). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From alanb at openjdk.org Mon Jul 4 16:34:32 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Jul 2022 16:34:32 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 16:13:10 GMT, Ryan Ernst wrote: >> David's refinement looks good. The sentence on deadlock is accurate as shutdown hooks run on other threads, not the thread calling System.ext. > > I reworded with the suggested text in mind. I also added another sentence referencing native signal handlers, which may also initiate shutdown. I think this clarification is important so that it is clear the status code of all invocations from Java may still be ignored. See [2253259](https://github.com/openjdk/jdk/pull/9351/commits/2253259c82b13e7b2186429a80cc42497235b035). I think the wording in the latest commit (9d972b) is problematic. One reason is that you've changed it to "will run shutdown hooks" but it doesn't run the hooks, it starts them, and so conflicts with the previous paragraph. I also think "That invocation may be initiated via platform specific signal handlers" is confusing here as there is no notion of "signal handler" to reference. There may be scope for text elsewhere, maybe with an implNote for signals such as HUP, but I don't think this is the PR for this. So I think it better to try the wording that David suggested and see if it needs any improvement. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From chegar at openjdk.org Mon Jul 4 16:50:39 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 4 Jul 2022 16:50:39 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: Message-ID: <4KNDVv9fr-YXV51gm2W8KJN5mYVlF2XbVAvGiKTWH0U=.109033d5-50ba-4b03-b11e-7f38fd9b4dfe@github.com> On Mon, 4 Jul 2022 16:31:22 GMT, Alan Bateman wrote: >> I reworded with the suggested text in mind. I also added another sentence referencing native signal handlers, which may also initiate shutdown. I think this clarification is important so that it is clear the status code of all invocations from Java may still be ignored. See [2253259](https://github.com/openjdk/jdk/pull/9351/commits/2253259c82b13e7b2186429a80cc42497235b035). > > I think the wording in the latest commit (9d972b) is problematic. One reason is that you've changed it to "will run shutdown hooks" but it doesn't run the hooks, it starts them, and so conflicts with the previous paragraph. I also think "That invocation may be initiated via platform specific signal handlers" is confusing here as there is no notion of "signal handler" to reference. There may be scope for text elsewhere, maybe with an implNote for signals such as HUP, but I don't think this is the PR for this. So I think it better to try the wording that David suggested and see if it needs any improvement. YAO (Yet Another Opinion)! But I think we're actually converging. David's wording: >Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code. ... gives the impression that an invocation of this method WILL terminate the VM with the given status code - which is not actually true, given the potential for signals. This is already alluded to in `Runtime::addShutdownHook`. I agree that this could be resolved separately, but we should _allow_ for it. The original wording: > If this method is invoked after all shutdown hooks have already been run ... ... seems quite clever (and allows for signals). Maybe we could: > If this method is invoked after shutdown hooks have already been started it will block indefinitely. If this method is invoked from a shutdown hook the system will deadlock. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From lancea at openjdk.org Mon Jul 4 19:15:37 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 4 Jul 2022 19:15:37 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v5] In-Reply-To: References: Message-ID: > Hi, > > Please review the following patch which will: > > - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods > > - public boolean exists(Path path, LinkOption... options) > - public A readAttributesIfExists(Path path, Class type, LinkOption... options) > > > This change allows for providers to provide optimizations when the file's attributes are not needed. > > Mach5 tiers 1 - 3 run clean with this change > > The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) > > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Separated test cases out and added benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9249/files - new: https://git.openjdk.org/jdk/pull/9249/files/63b97ce3..a51010aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=03-04 Stats: 212 lines in 2 files changed: 198 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249 PR: https://git.openjdk.org/jdk/pull/9249 From lancea at openjdk.org Mon Jul 4 19:30:40 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 4 Jul 2022 19:30:40 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: References: Message-ID: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> > Hi, > > Please review the following patch which will: > > - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods > > - public boolean exists(Path path, LinkOption... options) > - public A readAttributesIfExists(Path path, Class type, LinkOption... options) > > > This change allows for providers to provide optimizations when the file's attributes are not needed. > > Mach5 tiers 1 - 3 run clean with this change > > The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) > > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Address whitespace issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9249/files - new: https://git.openjdk.org/jdk/pull/9249/files/a51010aa..240c38b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249 PR: https://git.openjdk.org/jdk/pull/9249 From alanb at openjdk.org Mon Jul 4 19:32:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Jul 2022 19:32:58 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> References: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> Message-ID: <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> On Mon, 4 Jul 2022 19:30:40 GMT, Lance Andersen wrote: >> Hi, >> >> Please review the following patch which will: >> >> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods >> >> - public boolean exists(Path path, LinkOption... options) >> - public A readAttributesIfExists(Path path, Class type, LinkOption... options) >> >> >> This change allows for providers to provide optimizations when the file's attributes are not needed. >> >> Mach5 tiers 1 - 3 run clean with this change >> >> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) >> >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Address whitespace issue The updated TestDelegation test is looking a bit better now but I think it would be simplified a lot more by getting rid of the data providers, just aren't needed in this test. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From aturbanov at openjdk.org Mon Jul 4 20:24:24 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 20:24:24 GMT Subject: Integrated: 8289484: Cleanup unnecessary null comparison before instanceof check in java.rmi In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 21:11:09 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > > For example, the following code: > > if ((obj != null) && (obj instanceof TCPEndpoint)) { > TCPEndpoint ep = (TCPEndpoint) obj; > if (port != ep.port || !host.equals(ep.host)) > > Can be simplified to: > > if (obj instanceof TCPEndpoint ep) { > if (port != ep.port || !host.equals(ep.host)) > > > See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) This pull request has now been integrated. Changeset: df063f7d Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/df063f7db18a40ea7325fe608b3206a6dff812c1 Stats: 9 lines in 3 files changed: 0 ins; 4 del; 5 mod 8289484: Cleanup unnecessary null comparison before instanceof check in java.rmi Reviewed-by: jpai, attila ------------- PR: https://git.openjdk.org/jdk/pull/9332 From aturbanov at openjdk.org Mon Jul 4 20:25:46 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 20:25:46 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: <4OCN70Oq_ohbWdZwrI4DjJPBOU13KGbXdz3-rhLR3_k=.25ee110e-32df-48e8-b5b3-1f65e93a9353@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> <4OCN70Oq_ohbWdZwrI4DjJPBOU13KGbXdz3-rhLR3_k=.25ee110e-32df-48e8-b5b3-1f65e93a9353@github.com> Message-ID: On Sun, 3 Jul 2022 19:47:16 GMT, Attila Szegedi wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288723: Avoid redundant ConcurrentHashMap.get call in java.time >> use computeIfAbsent where lambda could be short and static > > src/java.base/share/classes/java/time/ZoneOffset.java line 435: > >> 433: result = prev; >> 434: } >> 435: ID_CACHE.putIfAbsent(result.getId(), result); > > Feel free to ignore this one, but you could still have this be a `computeIfAbsent` and put the ID_CACHE.putIfAbsent part in the lambda. Yeah, there'll be more work done inside of `computeIfAbsent` but I think it's an acceptable tradeoff for a more comprehensible code. Implemented ------------- PR: https://git.openjdk.org/jdk/pull/9208 From plevart at openjdk.org Mon Jul 4 21:25:34 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 4 Jul 2022 21:25:34 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: <-GG5XZZ3l97GTgX6CWd1dMreb0VY8p4EOO4wEdspDy0=.300c1768-1f19-41b6-bfd0-170aa809071b@github.com> <0Vu90zROPrz4K7ktZujMKlXidZZBBy5zRzgiAyHdAi4=.6b6d359e-7f8f-4167-9880-f862e53feaf9@github.com> <1f4jQnCcAOv4ETDZS8dd06828XruSZrTTaS E5c6VLKg=.cfb76ab7-54e3-408b-a20d-675cbd01e923@github.com> Message-ID: On Mon, 4 Jul 2022 10:06:12 GMT, ?????? ??????? wrote: >> A more realistic use case would be something in the lines of checking whether the method is an expected one: >> >> >> @Benchmark >> public boolean isFoo() { >> return matches(method, "foo", int.class, String.class); >> } >> >> private boolean matches(Method method, String name, Class ...parameterTypes) { >> if (method.getName().equals(name) && >> method.getParameterCount() == parameterTypes.length) { >> var params = method.getParameters(); >> for (int i = 0; i < parameterTypes.length; i++) { >> if (params[i].getType() != parameterTypes[i]) { >> return false; >> } >> } >> return true; >> } else { >> return false; >> } >> } > > Without `@Stable` your benchmark yields > > Benchmark Mode Cnt Score Error Units > AccessParamsBenchmark.isFoo avgt 40 1,110 ? 0,062 ns/op > > and with `@Stable` it yields > > Benchmark Mode Cnt Score Error Units > AccessParamsBenchmark.isFoo avgt 40 0,836 ? 0,015 ns/op > > Java 18: > > Benchmark Mode Cnt Score Error Units > AccessParamsBenchmark.isFoo avgt 40 6,105 ? 0,107 ns/op So, it looks like @Stable should stay. ------------- PR: https://git.openjdk.org/jdk/pull/9143 From plevart at openjdk.org Mon Jul 4 21:38:22 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 4 Jul 2022 21:38:22 GMT Subject: RFR: 8288327: Executable.hasRealParameterData should not be volatile [v7] In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 12:08:19 GMT, ?????? ??????? wrote: >> If there are two threads calling `Executable.hasRealParameterData()` under race and the first one writes into volatile `Executable.parameters` field (doing _releasing store_) and the second thread reads non-null value from the same field (doing acquiring read) then it must read exactly the same value written into `hasRealParameterData` within `privateGetParameters()`. The reason for this is that we assign `hasRealParameterData` before _releasing store_. >> >> In the opposite case (_acquiring read_ reads null) the second thread writes the value itself and returns it from the method so there is no change in behavior. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8288327: Inline privateGetParameters() This looks good to me. Thanks for doing that. ------------- Marked as reviewed by plevart (Reviewer). PR: https://git.openjdk.org/jdk/pull/9143 From akasko at openjdk.org Mon Jul 4 23:38:08 2022 From: akasko at openjdk.org (Alex Kasko) Date: Mon, 4 Jul 2022 23:38:08 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v4] In-Reply-To: References: Message-ID: > jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. > > It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. > > Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: > > - option naming inside a properties file, currently `pass-all-args` is used > - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group > - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination > - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` > > Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. > > Testing: > > - [x] test to cover new logic is included > - [x] ran jtreg:jdk/tools/jpackage with no new failures Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - enable passing args, add test coverage - Added input params validation - Proposed test changes to make FA testing of jpackage more flexible ------------- Changes: https://git.openjdk.org/jdk/pull/9224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9224&range=03 Stats: 194 lines in 5 files changed: 167 ins; 9 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9224.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9224/head:pull/9224 PR: https://git.openjdk.org/jdk/pull/9224 From akasko at openjdk.org Mon Jul 4 23:43:39 2022 From: akasko at openjdk.org (Alex Kasko) Date: Mon, 4 Jul 2022 23:43:39 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v4] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 23:38:08 GMT, Alex Kasko wrote: >> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. >> >> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. >> >> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: >> >> - option naming inside a properties file, currently `pass-all-args` is used >> - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group >> - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination >> - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` >> >> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. >> >> Testing: >> >> - [x] test to cover new logic is included >> - [x] ran jtreg:jdk/tools/jpackage with no new failures > > Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - enable passing args, add test coverage > - Added input params validation > - Proposed test changes to make FA testing of jpackage more flexible I've rebased the changes on top of PR 9331 and rebased the result on top of recent master (to have JDK-8288961 to be able to run MSI test). I think the patch if ready for review now. Note on non-ASCII arguments support: I've found that Windows system locale needs to be changed to support specific language. Checked manually that such args are passed successfully with both command-line and LNK shortcut arguments. Left a note on this in test. ------------- PR: https://git.openjdk.org/jdk/pull/9224 From dholmes at openjdk.org Tue Jul 5 00:20:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Jul 2022 00:20:42 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v3] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 16:17:27 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > iterate on wording src/java.base/share/classes/java/lang/Runtime.java line 88: > 86: *

Shutdown is serialized such that only one invocation will run > 87: * shutdown hooks and terminate the VM with the given status code. That > 88: * invocation may be initiated via platform specific signal handlers. All Why are we mentioning signal handlers here? How is that relevant? ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Tue Jul 5 03:27:29 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 5 Jul 2022 03:27:29 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 00:16:50 GMT, David Holmes wrote: >> Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> iterate on wording > > src/java.base/share/classes/java/lang/Runtime.java line 88: > >> 86: *

Shutdown is serialized such that only one invocation will run >> 87: * shutdown hooks and terminate the VM with the given status code. That >> 88: * invocation may be initiated via platform specific signal handlers. All > > Why are we mentioning signal handlers here? How is that relevant? Signal handlers for eg SIGTERM invoke Shutdown.shutdown. That method holds the same lock as Shutdown.exit and runs shutdown hooks. So if a signal handler triggers shutdown, and before the system halts Runtime.exit is invoked, the status passed to Runtime.exit will be ignored. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From dholmes at openjdk.org Tue Jul 5 04:12:36 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Jul 2022 04:12:36 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 03:24:28 GMT, Ryan Ernst wrote: >> src/java.base/share/classes/java/lang/Runtime.java line 88: >> >>> 86: *

Shutdown is serialized such that only one invocation will run >>> 87: * shutdown hooks and terminate the VM with the given status code. That >>> 88: * invocation may be initiated via platform specific signal handlers. All >> >> Why are we mentioning signal handlers here? How is that relevant? > > Signal handlers for eg SIGTERM invoke Shutdown.shutdown. That method holds the same lock as Shutdown.exit and runs shutdown hooks. So if a signal handler triggers shutdown, and before the system halts Runtime.exit is invoked, the status passed to Runtime.exit will be ignored. First, the signal handlers actually invoke Shutdown.exit, not Shutdown.shutdown - see Terminator.setup(). (If they did the latter, like DestroyJavaVM, then an exit(status) call from another thread could still do the final VM halt(status) But now you are opening a can of worms. There are multiple ways for the VM to initiate termination - are you going to try and describe here how all of them potentially interact? What you are really stating here is that other parts of the JDK can invoke System.exit, but that is for them to specify where such things are specified, it isn't for exit() to try and list them all. All we have to do here is describe how multiple calls to exit() behave. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From dholmes at openjdk.org Tue Jul 5 04:12:39 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Jul 2022 04:12:39 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v3] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 16:17:27 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > iterate on wording src/java.base/share/classes/java/lang/Runtime.java line 90: > 88: * invocation may be initiated via platform specific signal handlers. All > 89: * other invocations will block indefinitely, and their supplied exit > 90: * statuses will be ignored. If this method is invoked from a shutdown hook If they block indefinitely then it is implicit that nothing happens with their exit status. I think you are trying to say too much. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Tue Jul 5 04:30:27 2022 From: duke at openjdk.org (xpbob) Date: Tue, 5 Jul 2022 04:30:27 GMT Subject: RFR: 8289711: Add container configuration data to mbeans Message-ID: Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. Results the following ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) ------------- Commit messages: - 8289711: Add container configuration data to mbeans Changes: https://git.openjdk.org/jdk/pull/9372/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289711 Stats: 248 lines in 6 files changed: 248 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Tue Jul 5 04:46:03 2022 From: duke at openjdk.org (Shruthi) Date: Tue, 5 Jul 2022 04:46:03 GMT Subject: RFR: 8289471: Issue in Initialization of keys in ErrorMsg.java and XPATHErrorResources.java Message-ID: Modifying inaccurate initialization of keys in ErrorMsg.java and XPATHErrorResources.java The bug report for the same: https://bugs.openjdk.org/browse/JDK-8289471 ------------- Commit messages: - Resolving merge conflict - Modifying inaccurate initialization of keys in ErrorMsg.java and XPATHErrorResources.java Changes: https://git.openjdk.org/jdk/pull/9369/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289471 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9369.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9369/head:pull/9369 PR: https://git.openjdk.org/jdk/pull/9369 From duke at openjdk.org Tue Jul 5 04:51:42 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 5 Jul 2022 04:51:42 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 04:06:03 GMT, David Holmes wrote: >> Signal handlers for eg SIGTERM invoke Shutdown.shutdown. That method holds the same lock as Shutdown.exit and runs shutdown hooks. So if a signal handler triggers shutdown, and before the system halts Runtime.exit is invoked, the status passed to Runtime.exit will be ignored. > > First, the signal handlers actually invoke Shutdown.exit, not Shutdown.shutdown - see Terminator.setup(). (If they did the latter, like DestroyJavaVM, then an exit(status) call from another thread could still do the final VM halt(status) > > But now you are opening a can of worms. There are multiple ways for the VM to initiate termination - are you going to try and describe here how all of them potentially interact? > > What you are really stating here is that other parts of the JDK can invoke System.exit, but that is for them to specify where such things are specified, it isn't for exit() to try and list them all. All we have to do here is describe how multiple calls to exit() behave. Aha! I think I misread the comment on Shutdown.shutdown and had it stuck in my head that signals would exit through that method. Thanks for the explanation, it makes a lot more sense now. > All we have to do here is describe how multiple calls to exit() behave. The thing that is still missing to me is that an application developer may have a single call to System.exit, yet the status code they pass to it may not be the one the jvm exits with. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Tue Jul 5 04:55:27 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 5 Jul 2022 04:55:27 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: <4KNDVv9fr-YXV51gm2W8KJN5mYVlF2XbVAvGiKTWH0U=.109033d5-50ba-4b03-b11e-7f38fd9b4dfe@github.com> References: <4KNDVv9fr-YXV51gm2W8KJN5mYVlF2XbVAvGiKTWH0U=.109033d5-50ba-4b03-b11e-7f38fd9b4dfe@github.com> Message-ID: <6J-tVs1StaX-L7Phijc6EEBgTzsjymtdKVHsXG3mXhM=.63f0dbb6-5645-417b-82b5-19f8263840a6@github.com> On Mon, 4 Jul 2022 16:47:28 GMT, Chris Hegarty wrote: >> I think the wording in the latest commit (9d972b) is problematic. One reason is that you've changed it to "will run shutdown hooks" but it doesn't run the hooks, it starts them, and so conflicts with the previous paragraph. I also think "That invocation may be initiated via platform specific signal handlers" is confusing here as there is no notion of "signal handler" to reference. There may be scope for text elsewhere, maybe with an implNote for signals such as HUP, but I don't think this is the PR for this. So I think it better to try the wording that David suggested and see if it needs any improvement. > > YAO (Yet Another Opinion)! But I think we're actually converging. > > David's wording: >>Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code. > > ... gives the impression that an invocation of this method WILL terminate the VM with the given status code - which is not actually true, given the potential for signals. This is already alluded to in `Runtime::addShutdownHook`. I agree that this could be resolved separately, but we should _allow_ for signals (even if we don't explicitly mention them). > > The original wording: >> If this method is invoked after all shutdown hooks have already been run ... > > ... seems quite clever (and allows for signals). Maybe we could keep things super simple: >> If this method is invoked after shutdown hooks have already been started, it will block indefinitely. If this method is invoked from a shutdown hook the system will deadlock. I like the new suggested wording, but I would slightly tweak it. As Alan mentioned in another comment the first paragraph makes clear the method never returns normally. How does the following sound? > If this method is invoked after shutdown hooks have already been started, the supplied status code will be ignored. If this method is invoked from a shutdown hook the system will deadlock. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From dholmes at openjdk.org Tue Jul 5 07:28:34 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Jul 2022 07:28:34 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 04:47:40 GMT, Ryan Ernst wrote: >> First, the signal handlers actually invoke Shutdown.exit, not Shutdown.shutdown - see Terminator.setup(). (If they did the latter, like DestroyJavaVM, then an exit(status) call from another thread could still do the final VM halt(status) >> >> But now you are opening a can of worms. There are multiple ways for the VM to initiate termination - are you going to try and describe here how all of them potentially interact? >> >> What you are really stating here is that other parts of the JDK can invoke System.exit, but that is for them to specify where such things are specified, it isn't for exit() to try and list them all. All we have to do here is describe how multiple calls to exit() behave. > > Aha! I think I misread the comment on Shutdown.shutdown and had it stuck in my head that signals would exit through that method. Thanks for the explanation, it makes a lot more sense now. > >> All we have to do here is describe how multiple calls to exit() behave. > > The thing that is still missing to me is that an application developer may have a single call to System.exit, yet the status code they pass to it may not be the one the jvm exits with. Yes and the problem is? If the user kills the VM by other means; or the termination of the last non-daemon thread races with a call to System.exit then the developer doesn't really have to right to expect anything in relation to that one call. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From dholmes at openjdk.org Tue Jul 5 07:28:37 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 5 Jul 2022 07:28:37 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: <6J-tVs1StaX-L7Phijc6EEBgTzsjymtdKVHsXG3mXhM=.63f0dbb6-5645-417b-82b5-19f8263840a6@github.com> References: <4KNDVv9fr-YXV51gm2W8KJN5mYVlF2XbVAvGiKTWH0U=.109033d5-50ba-4b03-b11e-7f38fd9b4dfe@github.com> <6J-tVs1StaX-L7Phijc6EEBgTzsjymtdKVHsXG3mXhM=.63f0dbb6-5645-417b-82b5-19f8263840a6@github.com> Message-ID: On Tue, 5 Jul 2022 04:51:50 GMT, Ryan Ernst wrote: >> YAO (Yet Another Opinion)! But I think we're actually converging. >> >> David's wording: >>>Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code. >> >> ... gives the impression that an invocation of this method WILL terminate the VM with the given status code - which is not actually true, given the potential for signals. This is already alluded to in `Runtime::addShutdownHook`. I agree that this could be resolved separately, but we should _allow_ for signals (even if we don't explicitly mention them). >> >> The original wording: >>> If this method is invoked after all shutdown hooks have already been run ... >> >> ... seems quite clever (and allows for signals). Maybe we could keep things super simple: >>> If this method is invoked after shutdown hooks have already been started, it will block indefinitely. If this method is invoked from a shutdown hook the system will deadlock. > > I like the new suggested wording, but I would slightly tweak it. As Alan mentioned in another comment the first paragraph makes clear the method never returns normally. How does the following sound? > >> If this method is invoked after shutdown hooks have already been started, the supplied status code will be ignored. If this method is invoked from a shutdown hook the system will deadlock. > gives the impression that an invocation of this method WILL terminate the VM with the given status code - which is not actually true, given the potential for signals. The subtle distinction being calling Runtime.exit versus Shutdown.exit. The actual serialization takes places in Shutdown.exit and serializes with signals too. But discussion of signals has no place here - I'm not even sure we document those ways of terminating the VM anywhere? ------------- PR: https://git.openjdk.org/jdk/pull/9351 From chegar at openjdk.org Tue Jul 5 08:07:27 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Tue, 5 Jul 2022 08:07:27 GMT Subject: RFR: 8288984: Simplification in Shutdown.exit [v2] In-Reply-To: References: <4KNDVv9fr-YXV51gm2W8KJN5mYVlF2XbVAvGiKTWH0U=.109033d5-50ba-4b03-b11e-7f38fd9b4dfe@github.com> <6J-tVs1StaX-L7Phijc6EEBgTzsjymtdKVHsXG3mXhM=.63f0dbb6-5645-417b-82b5-19f8263840a6@github.com> Message-ID: On Tue, 5 Jul 2022 07:23:49 GMT, David Holmes wrote: >> I like the new suggested wording, but I would slightly tweak it. As Alan mentioned in another comment the first paragraph makes clear the method never returns normally. How does the following sound? >> >>> If this method is invoked after shutdown hooks have already been started, the supplied status code will be ignored. If this method is invoked from a shutdown hook the system will deadlock. > >> gives the impression that an invocation of this method WILL terminate the VM with the given status code - which is not actually true, given the potential for signals. > > The subtle distinction being calling Runtime.exit versus Shutdown.exit. The actual serialization takes places in Shutdown.exit and serializes with signals too. But discussion of signals has no place here - I'm not even sure we document those ways of terminating the VM anywhere? @dholmes-ora Agreed - this paragraph should not explicitly mention signals or any _other_ means of termination. There is some shutdown hook specific verbiage relating to termination in `Runtime::addShutdownHook` : In rare circumstances the virtual machine may abort, that is, stop running without shutting down cleanly. This occurs when the virtual machine is terminated externally, for example with the SIGKILL signal on Unix or the TerminateProcess call on Microsoft Windows. The virtual machine may also abort if a native method goes awry by, for example, corrupting internal data structures or attempting to access nonexistent memory. If the virtual machine aborts then no guarantee can be made about whether or not any shutdown hooks will be run. ... but we do not need to go there, and it's not really enough to leverage anyway. >The subtle distinction being calling Runtime.exit versus Shutdown.exit. The actual serialization takes places in Shutdown.exit and serializes with signals too. Exactly. On further reading of the proposed "Invocations of this method are serialized such that only one invocation will actually proceed with the shutdown sequence and terminate the VM with the given status code.", I think that it is fine (given its position and context in Runtime::exit). My reason for suggesting an alternative ("If this method is invoked after shutdown hooks have already been started, it will block indefinitely") was mainly to try to find something a little simpler while retaining correctness. Given the discussion so far, either is fine with me. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From lancea at openjdk.org Tue Jul 5 09:57:47 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 09:57:47 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> References: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> Message-ID: On Mon, 4 Jul 2022 19:30:50 GMT, Alan Bateman wrote: > The updated TestDelegation test is looking a bit better now but I think it would be simplified a lot more by getting rid of the data providers, just aren't needed in this test. Unless you feel this is a must, I would prefer to keep the DataProviders. The benefit I see is the test code does not need to be duplicated per parameter, each test scenario can be run as an individual test so that you do not need extra plumbing to run each test scenario in the unlikely event of a failure. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From duke at openjdk.org Tue Jul 5 10:50:02 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 10:50:02 GMT Subject: RFR: JDK-8289730 : Deprecated code in src/java.base/share/classes/java/lang/ClassCastException.java Message-ID: - Correct a deprecated code. - Update Copyright. - More wide question : How are you dealing with deprecated codes in snippets ? ``` @deprecated(since="9") public Integer?(int value) ``` ------------- Commit messages: - Merge branch 'openjdk:master' into patch-2 - Merge branch 'openjdk:master' into patch-2 - Merge branch 'openjdk:master' into patch-2 - Merge branch 'openjdk:master' into patch-2 - Update Copyright date. - Merge branch 'openjdk:master' into patch-2 - Use deprecated Constructor. Changes: https://git.openjdk.org/jdk/pull/9359/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9359&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289730 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9359.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9359/head:pull/9359 PR: https://git.openjdk.org/jdk/pull/9359 From alanb at openjdk.org Tue Jul 5 11:00:43 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Jul 2022 11:00:43 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: References: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> Message-ID: On Tue, 5 Jul 2022 09:54:15 GMT, Lance Andersen wrote: > Unless you feel this is a must, I would prefer to keep the DataProviders. The benefit I see is the test code does not need to be duplicated per parameter, each test scenario can be run as an individual test so that you do not need extra plumbing to run each test scenario in the unlikely event of a failure. Okay, but there are a few other things to mention: One issue is the reset method is called at the end of each test. I think it needs to be at the beginning of the method, moved to a finally block of a try-finally, or maybe @BeforeMethod to reset before each test. The reason is that one test failing will cause the tests that follow to fail too. The fields aren't constants so looks a bit strange (to me anyway) to be in uppercase. If you rename them then I think the tests would be a bit more readable. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From mcimadamore at openjdk.org Tue Jul 5 11:30:53 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 5 Jul 2022 11:30:53 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 13:40:01 GMT, Jorn Vernee wrote: > This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. > > For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. > > Testing: `jdk_foreign` test suite on all platforms that implement VaList. Looks good - I've added some comments, esp. in the javadoc src/java.base/share/classes/java/lang/foreign/VaList.java line 61: > 59: * Particularly, variable argument lists created using {@link #make(Consumer, MemorySession)} are able to detect out-of-bounds reads, > 60: * while variable argument lists crearted using {@link #ofAddress(MemoryAddress, MemorySession)} are not. > 61: *

Suggestion: *

Safety considerations

* A variable argument list can be thought of as a cursor into a memory segment which stores one or * more elements, with given layouts. The {@linkplain #nextVarg(ValueLayout.OfInt) methods} used to retrieve elements from * a variable argument list update the cursor position; as such it is possible for clients to access elements * outside the spatial bounds of the variable argument list. *

* A variable argument list attempts to detect out-of-bounds access on a best-effort basis. * Whether this detection succeeds depends on the factory method used to create the variable argument list: *

    *
  • Variable argument lists created safely, using {@link #make(Consumer, MemorySession)} are built on top of * native memory segments that are sized correctly. As such, they are capable of detecting out-of-bounds reads;
  • *
  • Variable argument lists created unsafely, using {@link #ofAddress(MemoryAddress, MemorySession)} are built on top * of segments whose size is unknown. As such they cannot detect out-of-bounds reads
  • *

    ``` src/java.base/share/classes/java/lang/foreign/VaList.java line 99: > 97: * @throws WrongThreadException if this method is called from a thread other than the thread owning > 98: * the {@linkplain #session() session} associated with this variable argument list. > 99: * @throws NoSuchElementException if an out-of-bounds read is detected. I'd insert a link to the safety section, where the link text is "out-of-bounds". src/java.base/share/classes/java/lang/foreign/VaList.java line 202: > 200: * restricted methods, and use safe and supported functionalities, where possible. > 201: * > 202: * @implNote variable argument lists created using this method can not detect out-of-bound reads. Links here too src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java line 291: > 289: } > 290: > 291: private void checkRegAreaElement(MemoryLayout layout, TypeClass typeClass) { should this be `checkRegSaveAreaElement` ? test/jdk/java/foreign/valist/VaListTest.java line 827: > 825: > 826: @DataProvider > 827: public static Object[][] overflow() { nice test! ------------- PR: https://git.openjdk.org/jdk19/pull/91 From duke at openjdk.org Tue Jul 5 12:19:17 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 12:19:17 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java Message-ID: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> This is tracked in JBS as [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) > **Remove unused imports from DTDBuilder.java** Some imports are no more used. - java.io.FileNotFoundException; - java.io.BufferedInputStream; - java.io.OutputStream; - java.util.BitSet; - java.util.StringTokenizer; - java.util.Properties; - java.util.zip.DeflaterOutputStream; - java.util.zip.Deflater; - java.net.URL; ------------- Commit messages: - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Remove unused imports. Changes: https://git.openjdk.org/jdk/pull/9360/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9360&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289741 Stats: 11 lines in 1 file changed: 0 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9360.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9360/head:pull/9360 PR: https://git.openjdk.org/jdk/pull/9360 From jwaters at openjdk.org Tue Jul 5 12:19:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 5 Jul 2022 12:19:18 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java In-Reply-To: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> Message-ID: <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> On Mon, 4 Jul 2022 07:04:40 GMT, ScientificWare wrote: > This is tracked in JBS as > > [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) > >> **Remove unused imports from DTDBuilder.java** > Some imports are no more used. > > - java.io.FileNotFoundException; > - java.io.BufferedInputStream; > - java.io.OutputStream; > - java.util.BitSet; > - java.util.StringTokenizer; > - java.util.Properties; > - java.util.zip.DeflaterOutputStream; > - java.util.zip.Deflater; > - java.net.URL; @scientificware Do you need an entry in the JBS for this PR? Alright, was asking since I can help create one for you, but it seems that others already have it covered ------------- PR: https://git.openjdk.org/jdk/pull/9360 From duke at openjdk.org Tue Jul 5 12:19:18 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 12:19:18 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java In-Reply-To: <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> Message-ID: On Tue, 5 Jul 2022 01:53:33 GMT, Julian Waters wrote: >> This is tracked in JBS as >> >> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) >> >>> **Remove unused imports from DTDBuilder.java** >> Some imports are no more used. >> >> - java.io.FileNotFoundException; >> - java.io.BufferedInputStream; >> - java.io.OutputStream; >> - java.util.BitSet; >> - java.util.StringTokenizer; >> - java.util.Properties; >> - java.util.zip.DeflaterOutputStream; >> - java.util.zip.Deflater; >> - java.net.URL; > > @scientificware Do you need an entry in the JBS for this PR? Hi @TheShermanTanker, Yes I need it. I'm waiting for the Issue Id. Regards > Alright, was asking since I can help create one for you, but it seems that others already have it covered @TheShermanTanker , thank you for asking and helping. > it seems that others already have it covered In fact, I don't known. Yesterday, I posted 3 reports in the Java Bug Database and I have no feedback at this moment. ------------- PR: https://git.openjdk.org/jdk/pull/9360 From jwaters at openjdk.org Tue Jul 5 12:19:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 5 Jul 2022 12:19:18 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java In-Reply-To: <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> Message-ID: On Tue, 5 Jul 2022 03:40:51 GMT, Julian Waters wrote: >> This is tracked in JBS as >> >> [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) >> >>> **Remove unused imports from DTDBuilder.java** >> Some imports are no more used. >> >> - java.io.FileNotFoundException; >> - java.io.BufferedInputStream; >> - java.io.OutputStream; >> - java.util.BitSet; >> - java.util.StringTokenizer; >> - java.util.Properties; >> - java.util.zip.DeflaterOutputStream; >> - java.util.zip.Deflater; >> - java.net.URL; > > Alright, was asking since I can help create one for you, but it seems that others already have it covered > @TheShermanTanker , thank you for asking and helping. > > > it seems that others already have it covered > > In fact, I dont known. Yesterday, I posted 3 reports in the Java Bug Database and I have no feedback at this moment. Well, in that case, wait no longer! Your issue ID is [8289741](https://bugs.openjdk.org/browse/JDK-8289741), just change your title to "8289741" and the automated tooling should take care of the rest and send this PR to the appropriate teams for review. All the best! ------------- PR: https://git.openjdk.org/jdk/pull/9360 From duke at openjdk.org Tue Jul 5 12:37:38 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 12:37:38 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java In-Reply-To: References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> <6EzP1J6Wql9_M9ek2JNDk5UneiH2a5ilaf-BssTXa-E=.15e32eab-3b8c-444e-a085-c40465f0754d@github.com> Message-ID: On Tue, 5 Jul 2022 11:34:05 GMT, Julian Waters wrote: >> Alright, was asking since I can help create one for you, but it seems that others already have it covered > >> @TheShermanTanker , thank you for asking and helping. >> >> > it seems that others already have it covered >> >> In fact, I dont known. Yesterday, I posted 3 reports in the Java Bug Database and I have no feedback at this moment. > > Well, in that case, wait no longer! > Your issue ID is [8289741](https://bugs.openjdk.org/browse/JDK-8289741), just change your title to "8289741" and the automated tooling should take care of the rest and send this PR to the appropriate teams for review. > > All the best! @TheShermanTanker Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9360 From duke at openjdk.org Tue Jul 5 13:30:40 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 5 Jul 2022 13:30:40 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v4] In-Reply-To: References: Message-ID: > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: iter text ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9351/files - new: https://git.openjdk.org/jdk/pull/9351/files/2253259c..fccd85ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9351/head:pull/9351 PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Tue Jul 5 13:55:46 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 5 Jul 2022 13:55:46 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 12:19:27 GMT, David Holmes wrote: >> Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> better clarify multiple threads behavior > >> Let's say we've run shutdown so run all the hooks but not halted. Then someone calls exit(0). That seems to suggest the call will block indefinitely, which is neither desirable nor what was actually implemented. > > If the hook threads do not halt then the exiting thread (which holds the lock) blocks forever in the join(). Any other call to exit blocks trying to acquire the lock. That has always been the way this works - if hook threads don't terminate then the VM doesn't (unless someone calls halt() directly). That is one of the things the window you suggested be closed, allowed - a call to exit(non-zero) could force a call to halt(). I appreciate all the feedback and the many opinions expressed here! This has been a learning exercise for me in finding a balance between implementation and specification. While I still think mentioning the possibility of signals is beneficial to a developer trying to understand that the passed status code could be ignored, the text suggested by @dholmes-ora is better than was previously there, so I have updated this PR with that. See [fccd85b](https://github.com/openjdk/jdk/pull/9351/commits/fccd85ba106ff651c00479446ac3207ed60698e8). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From chegar at openjdk.org Tue Jul 5 14:05:44 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Tue, 5 Jul 2022 14:05:44 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v4] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 13:30:40 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > iter text Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From jvernee at openjdk.org Tue Jul 5 15:10:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 5 Jul 2022 15:10:50 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 11:03:30 GMT, Maurizio Cimadamore wrote: >> This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. >> >> For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. >> >> Testing: `jdk_foreign` test suite on all platforms that implement VaList. > > src/java.base/share/classes/java/lang/foreign/VaList.java line 61: > >> 59: * Particularly, variable argument lists created using {@link #make(Consumer, MemorySession)} are able to detect out-of-bounds reads, >> 60: * while variable argument lists crearted using {@link #ofAddress(MemoryAddress, MemorySession)} are not. >> 61: *

    > > Suggestion: > > *

    Safety considerations

    > * A variable argument list can be thought of as a cursor into a memory segment which stores one or > * more elements, with given layouts. The {@linkplain #nextVarg(ValueLayout.OfInt) methods} used to retrieve elements from > * a variable argument list update the cursor position; as such it is possible for clients to access elements > * outside the spatial bounds of the variable argument list. > *

    > * A variable argument list attempts to detect out-of-bounds access on a best-effort basis. > * Whether this detection succeeds depends on the factory method used to create the variable argument list: > *

      > *
    • Variable argument lists created safely, using {@link #make(Consumer, MemorySession)} are built on top of > * native memory segments that are sized correctly. As such, they are capable of detecting out-of-bounds reads;
    • > *
    • Variable argument lists created unsafely, using {@link #ofAddress(MemoryAddress, MemorySession)} are built on top > * of segments whose size is unknown. As such they cannot detect out-of-bounds reads
    • > *

      ``` This seems a bit too much. The class javadoc further up already describes a va list as "a stateful cursor used to iterate over a set of arguments". If that description is insufficient, I think it should be amended at that point. Also, I don't think we have to go into describing how va lists returned by different factories are implemented (in fact, I think we should avoid that in order not to make accidental false promises when things change). It seems like noise next to the safety concerns (if someone really wants to know how the specified semantics are implemented, they can look at the code, or ask on the mailing list). I'd suggest something simpler like this: Suggestion: * It is possible for clients to access elements outside the spatial bounds of a variable argument list. Variable argument list * implementations will try to detect out-of-bounds reads on a best-effort basis. *

      * Whether this detection succeeds depends on the factory method used to create the variable argument list: *

        *
      • Variable argument lists created safely, using {@link #make(Consumer, MemorySession)} are capable of detecting out-of-bounds reads;
      • *
      • Variable argument lists created unsafely, using {@link #ofAddress(MemoryAddress, MemorySession)} are not capable of detecting out-of-bounds reads
      • *
      *

      I'm also fine with changing the section title to "Safety considerations". ------------- PR: https://git.openjdk.org/jdk19/pull/91 From jvernee at openjdk.org Tue Jul 5 15:18:41 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 5 Jul 2022 15:18:41 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 15:07:32 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/foreign/VaList.java line 61: >> >>> 59: * Particularly, variable argument lists created using {@link #make(Consumer, MemorySession)} are able to detect out-of-bounds reads, >>> 60: * while variable argument lists crearted using {@link #ofAddress(MemoryAddress, MemorySession)} are not. >>> 61: *

      >> >> Suggestion: >> >> *

      Safety considerations

      >> * A variable argument list can be thought of as a cursor into a memory segment which stores one or >> * more elements, with given layouts. The {@linkplain #nextVarg(ValueLayout.OfInt) methods} used to retrieve elements from >> * a variable argument list update the cursor position; as such it is possible for clients to access elements >> * outside the spatial bounds of the variable argument list. >> *

      >> * A variable argument list attempts to detect out-of-bounds access on a best-effort basis. >> * Whether this detection succeeds depends on the factory method used to create the variable argument list: >> *

        >> *
      • Variable argument lists created safely, using {@link #make(Consumer, MemorySession)} are built on top of >> * native memory segments that are sized correctly. As such, they are capable of detecting out-of-bounds reads;
      • >> *
      • Variable argument lists created unsafely, using {@link #ofAddress(MemoryAddress, MemorySession)} are built on top >> * of segments whose size is unknown. As such they cannot detect out-of-bounds reads
      • >> *

        ``` > > This seems a bit too much. > > The class javadoc further up already describes a va list as "a stateful cursor used to iterate over a set of arguments". If that description is insufficient, I think it should be amended at that point. > > Also, I don't think we have to go into describing how va lists returned by different factories are implemented (in fact, I think we should avoid that in order not to make accidental false promises when things change). It seems like noise next to the safety concerns (if someone really wants to know how the specified semantics are implemented, they can look at the code, or ask on the mailing list). > > I'd suggest something simpler like this: > > Suggestion: > > * It is possible for clients to access elements outside the spatial bounds of a variable argument list. Variable argument list > * implementations will try to detect out-of-bounds reads on a best-effort basis. > *

        > * Whether this detection succeeds depends on the factory method used to create the variable argument list: > *

          > *
        • Variable argument lists created safely, using {@link #make(Consumer, MemorySession)} are capable of detecting out-of-bounds reads;
        • > *
        • Variable argument lists created unsafely, using {@link #ofAddress(MemoryAddress, MemorySession)} are not capable of detecting out-of-bounds reads
        • > *
        > *

        > > > I'm also fine with changing the section title to "Safety considerations". i.e. I'd like to just specify the behavior, and avoid explaining why we have that behavior. ------------- PR: https://git.openjdk.org/jdk19/pull/91 From jvernee at openjdk.org Tue Jul 5 15:18:45 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 5 Jul 2022 15:18:45 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 11:13:15 GMT, Maurizio Cimadamore wrote: >> This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. >> >> For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. >> >> Testing: `jdk_foreign` test suite on all platforms that implement VaList. > > src/java.base/share/classes/java/lang/foreign/VaList.java line 99: > >> 97: * @throws WrongThreadException if this method is called from a thread other than the thread owning >> 98: * the {@linkplain #session() session} associated with this variable argument list. >> 99: * @throws NoSuchElementException if an out-of-bounds read is detected. > > I'd insert a link to the safety section, where the link text is "out-of-bounds". Good idea, I'll add links > src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java line 291: > >> 289: } >> 290: >> 291: private void checkRegAreaElement(MemoryLayout layout, TypeClass typeClass) { > > should this be `checkRegSaveAreaElement` ? Okay, I can rename it. ------------- PR: https://git.openjdk.org/jdk19/pull/91 From rriggs at openjdk.org Tue Jul 5 15:29:42 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 5 Jul 2022 15:29:42 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Sun, 3 Jul 2022 22:06:58 GMT, Attila Szegedi wrote: >> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 312: >> >>> 310: private Object findStore(TemporalField field, Locale locale) { >>> 311: Entry key = createEntry(field, locale); >>> 312: return CACHE.computeIfAbsent(key, e -> createStore(e.getKey(), e.getValue())); >> >> If `createStore` can be static, the call site will only have to construct a constant lambda than having to pass `this` to construct a new instance on every call > > Well, if you _really_ want to noodle this for performance, you can also store a `this`-bound lambda in a `private final` instance field, so then it's only created once too. I wouldn't put it past `javac` to do this, but I'd have to disassemble the bytecode of a little test program to see whether it's the case. Can there be some JMH tests to confirm the performance? The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure that the combination of creating a new record and the hashcode and equals methods would be faster than string concat of a constant and a single digit integer. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From asemenyuk at openjdk.org Tue Jul 5 15:55:31 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 5 Jul 2022 15:55:31 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v4] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 23:38:08 GMT, Alex Kasko wrote: >> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. >> >> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. >> >> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: >> >> - option naming inside a properties file, currently `pass-all-args` is used >> - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group >> - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination >> - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` >> >> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. >> >> Testing: >> >> - [x] test to cover new logic is included >> - [x] ran jtreg:jdk/tools/jpackage with no new failures > > Alex Kasko 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: > > - enable passing args, add test coverage > - Added input params validation > - Proposed test changes to make FA testing of jpackage more flexible Looks good! I'll try the patch locally and get back to you. Please provide a detailed test scenario for non-ASCII args. We can add this scenario to manual test runs done by SQE. ------------- PR: https://git.openjdk.org/jdk/pull/9224 From jvernee at openjdk.org Tue Jul 5 17:21:09 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 5 Jul 2022 17:21:09 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 15:14:20 GMT, Jorn Vernee wrote: >> This seems a bit too much. >> >> The class javadoc further up already describes a va list as "a stateful cursor used to iterate over a set of arguments". If that description is insufficient, I think it should be amended at that point. >> >> Also, I don't think we have to go into describing how va lists returned by different factories are implemented (in fact, I think we should avoid that in order not to make accidental false promises when things change). It seems like noise next to the safety concerns (if someone really wants to know how the specified semantics are implemented, they can look at the code, or ask on the mailing list). >> >> I'd suggest something simpler like this: >> >> Suggestion: >> >> * It is possible for clients to access elements outside the spatial bounds of a variable argument list. Variable argument list >> * implementations will try to detect out-of-bounds reads on a best-effort basis. >> *

        >> * Whether this detection succeeds depends on the factory method used to create the variable argument list: >> *

          >> *
        • Variable argument lists created safely, using {@link #make(Consumer, MemorySession)} are capable of detecting out-of-bounds reads;
        • >> *
        • Variable argument lists created unsafely, using {@link #ofAddress(MemoryAddress, MemorySession)} are not capable of detecting out-of-bounds reads
        • >> *
        >> *

        >> >> >> I'm also fine with changing the section title to "Safety considerations". > > i.e. I'd like to just specify the behavior, and avoid explaining why we have that behavior. I've updated the PR with this suggestion for now. Please let me know if it looks OK to you as well. ------------- PR: https://git.openjdk.org/jdk19/pull/91 From jvernee at openjdk.org Tue Jul 5 17:21:08 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 5 Jul 2022 17:21:08 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM [v2] In-Reply-To: References: Message-ID: > This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. > > For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. > > Testing: `jdk_foreign` test suite on all platforms that implement VaList. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/91/files - new: https://git.openjdk.org/jdk19/pull/91/files/e1c757c6..e7d7b367 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=91&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=91&range=00-01 Stats: 19 lines in 2 files changed: 2 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk19/pull/91.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/91/head:pull/91 PR: https://git.openjdk.org/jdk19/pull/91 From naoto at openjdk.org Tue Jul 5 17:57:31 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 5 Jul 2022 17:57:31 GMT Subject: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 17:04:10 GMT, Joe Wang wrote: > To improve efficiency, this patch moves the limit check to within the Lexer and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole error-report block was changed, the actual change was only placing the block to within the isOverLimit statement. > > Test: java.xml tests passed. Thanks for the explanation. Looks good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk19/pull/101 From duke at openjdk.org Tue Jul 5 18:12:51 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 18:12:51 GMT Subject: RFR: JDK-8289730 : Deprecated code in src/java.base/share/classes/java/lang/ClassCastException.java In-Reply-To: <_1Z82RcvMPw8WVmgWRF-2OoAk9ZLtLqA4yh2I7I1KSU=.21574c2d-9c73-4526-8800-8774509c68a7@github.com> References: <_1Z82RcvMPw8WVmgWRF-2OoAk9ZLtLqA4yh2I7I1KSU=.21574c2d-9c73-4526-8800-8774509c68a7@github.com> Message-ID: On Tue, 5 Jul 2022 17:27:03 GMT, Joe Darcy wrote: >> - Correct a deprecated code. >> - Update Copyright. >> - More wide question : How are you dealing with deprecated codes in snippets ? >> ``` >> @deprecated(since="9") >> public Integer?(int value) >> ``` > > Looks fine. > > There is as of yet no systemic way of dealing with compiler warnings with formal or informal snippet samples, but JEP 413: "Code Snippets in Java API Documentation" is meant to enable that. @jddarcy Thanks. In fact this Issue is related to JEP 413, I had a short informal exchange about this with Jonathan Giles one year ago. It seems that Microsoft already validates snippets in its AzureSDK : https://twitter.com/JonathanGiles/status/1387550356524081154 How JEP 413 process will react with this kind of code ? /** * Thrown to indicate that the code has attempted to cast an object * to a subclass of which it is not an instance. For example, the * following code generates a {@code ClassCastException}: *

         *     Object x = Integer.valueOf(0);
         *     System.out.println((String)x);
         * 
        * * @since 1.0 */ In another word, is there a way to specifiy witch result the author expected. ------------- PR: https://git.openjdk.org/jdk/pull/9359 From darcy at openjdk.org Tue Jul 5 17:29:48 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 5 Jul 2022 17:29:48 GMT Subject: RFR: JDK-8289730 : Deprecated code in src/java.base/share/classes/java/lang/ClassCastException.java In-Reply-To: References: Message-ID: <_1Z82RcvMPw8WVmgWRF-2OoAk9ZLtLqA4yh2I7I1KSU=.21574c2d-9c73-4526-8800-8774509c68a7@github.com> On Mon, 4 Jul 2022 06:57:12 GMT, ScientificWare wrote: > - Correct a deprecated code. > - Update Copyright. > - More wide question : How are you dealing with deprecated codes in snippets ? > ``` > @deprecated(since="9") > public Integer?(int value) > ``` Looks fine. There is as of yet no systemic way of dealing with compiler warnings with formal or informal snippet samples, but JEP 413: "Code Snippets in Java API Documentation" is meant to enable that. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/9359 From lancea at openjdk.org Tue Jul 5 18:47:56 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 18:47:56 GMT Subject: RFR: 8288706: Unused parameter 'boolean newln' in method java.lang.VersionProps#print(boolean, boolean) Message-ID: Hi all, This PR cleans up `VersionProps::print` removing the unused parameter `newln`. Mach5 tiers1-3 are currently running. Best, Lance ------------- Commit messages: - Address unused parameter in VersionProps::print Changes: https://git.openjdk.org/jdk/pull/9382/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288706 Stats: 19 lines in 2 files changed: 1 ins; 13 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9382.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9382/head:pull/9382 PR: https://git.openjdk.org/jdk/pull/9382 From lancea at openjdk.org Tue Jul 5 19:48:02 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 19:48:02 GMT Subject: Integrated: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen wrote: > Hi, > > Please review the following patch which will: > > - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods > > - public boolean exists(Path path, LinkOption... options) > - public
        A readAttributesIfExists(Path path, Class type, LinkOption... options) > > > This change allows for providers to provide optimizations when the file's attributes are not needed. > > Mach5 tiers 1 - 3 run clean with this change > > The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) > > > Best, > Lance This pull request has now been integrated. Changeset: d48694d0 Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/d48694d0f3865c1b205acdfa2e6c6d032a39959d Stats: 712 lines in 13 files changed: 537 ins; 135 del; 40 mod 8283335: Add exists and readAttributesIfExists methods to FileSystemProvider Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/9249 From duke at openjdk.org Tue Jul 5 18:39:30 2022 From: duke at openjdk.org (ScientificWare) Date: Tue, 5 Jul 2022 18:39:30 GMT Subject: RFR: JDK-8289730 : Deprecated code sample in java.lang.ClassCastException In-Reply-To: <_1Z82RcvMPw8WVmgWRF-2OoAk9ZLtLqA4yh2I7I1KSU=.21574c2d-9c73-4526-8800-8774509c68a7@github.com> References: <_1Z82RcvMPw8WVmgWRF-2OoAk9ZLtLqA4yh2I7I1KSU=.21574c2d-9c73-4526-8800-8774509c68a7@github.com> Message-ID: On Tue, 5 Jul 2022 17:27:03 GMT, Joe Darcy wrote: >> - Correct a deprecated code. >> - Update Copyright. >> - More wide question : How are you dealing with deprecated codes in snippets ? >> ``` >> @deprecated(since="9") >> public Integer?(int value) >> ``` > > Looks fine. > > There is as of yet no systemic way of dealing with compiler warnings with formal or informal snippet samples, but JEP 413: "Code Snippets in Java API Documentation" is meant to enable that. @jddarcy, please could you sponsor this PR ? ------------- PR: https://git.openjdk.org/jdk/pull/9359 From jvernee at openjdk.org Tue Jul 5 17:27:34 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 5 Jul 2022 17:27:34 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM [v3] In-Reply-To: References: Message-ID: > This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. > > For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. > > Testing: `jdk_foreign` test suite on all platforms that implement VaList. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: hmtl -> html ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/91/files - new: https://git.openjdk.org/jdk19/pull/91/files/e7d7b367..ba132af5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=91&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=91&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk19/pull/91.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/91/head:pull/91 PR: https://git.openjdk.org/jdk19/pull/91 From duke at openjdk.org Tue Jul 5 18:43:26 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 5 Jul 2022 18:43:26 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v5] In-Reply-To: References: Message-ID: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Ryan Ernst 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 branch 'master' into shutdown_cleanup - iter text - iterate on wording - better clarify multiple threads behavior - 8288984: Simplification in Shutdown.exit This is a followup to simplify Shutdown.exit after the removal of finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement on the approach has been reached in this PR, a CSR will be filed to propose the spec change to Runtime.exit. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9351/files - new: https://git.openjdk.org/jdk/pull/9351/files/fccd85ba..75a2651e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9351&range=03-04 Stats: 2278 lines in 110 files changed: 1285 ins; 604 del; 389 mod Patch: https://git.openjdk.org/jdk/pull/9351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9351/head:pull/9351 PR: https://git.openjdk.org/jdk/pull/9351 From psandoz at openjdk.org Tue Jul 5 17:45:32 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 5 Jul 2022 17:45:32 GMT Subject: [jdk19] RFR: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 13:01:34 GMT, Jorn Vernee wrote: > This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. > > Testing: local run of the `jdk_foreign` test suite. It's tempting to allow null/0 characters to pass through, truncating the string, given the rarity of such characters, but it could hide a nasty bug. If performance becomes a really important issue we can make intrinsic and vectorize. I think it is better to refer to the characters in the String, rather than refer to bytes of the UTF-8 encoding of that String e.g. throws if the string contains a null character (same for the exception message). We can explain in an API note why. ------------- PR: https://git.openjdk.org/jdk19/pull/107 From lancea at openjdk.org Tue Jul 5 19:20:25 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 19:20:25 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v7] In-Reply-To: References: Message-ID: > Hi, > > Please review the following patch which will: > > - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods > > - public boolean exists(Path path, LinkOption... options) > - public A readAttributesIfExists(Path path, Class type, LinkOption... options) > > > This change allows for providers to provide optimizations when the file's attributes are not needed. > > Mach5 tiers 1 - 3 run clean with this change > > The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) > > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Add @BeforeMethod and rename fields ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9249/files - new: https://git.openjdk.org/jdk/pull/9249/files/240c38b8..74436951 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=05-06 Stats: 36 lines in 1 file changed: 9 ins; 3 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/9249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249 PR: https://git.openjdk.org/jdk/pull/9249 From lancea at openjdk.org Tue Jul 5 19:20:25 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 19:20:25 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: References: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> Message-ID: On Tue, 5 Jul 2022 10:56:45 GMT, Alan Bateman wrote: > > Unless you feel this is a must, I would prefer to keep the DataProviders. The benefit I see is the test code does not need to be duplicated per parameter, each test scenario can be run as an individual test so that you do not need extra plumbing to run each test scenario in the unlikely event of a failure. > > Okay, but there are a few other things to mention: > > One issue is the reset method is called at the end of each test. I think it needs to be at the beginning of the method, moved to a finally block of a try-finally, or maybe @BeforeMethod to reset before each test. The reason is that one test failing will cause the tests that follow to fail too. Good catch, added `@BeforeMethod` > > The fields aren't constants so looks a bit strange (to me anyway) to be in uppercase. If you rename them then I think the tests would be a bit more readable. Ah, sometimes you see what you want. I must have had fields on my mind when I did that as I completely agree with you. Both of the above are addressed in the latest update to the PR. Thank you for the feedback. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From alanb at openjdk.org Tue Jul 5 18:59:45 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Jul 2022 18:59:45 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v5] In-Reply-To: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> References: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> Message-ID: On Tue, 5 Jul 2022 18:43:26 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst 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 branch 'master' into shutdown_cleanup > - iter text > - iterate on wording > - better clarify multiple threads behavior > - 8288984: Simplification in Shutdown.exit > > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Version 75a2651e looks fine. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9351 From alanb at openjdk.org Tue Jul 5 19:20:25 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Jul 2022 19:20:25 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v7] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 19:17:27 GMT, Lance Andersen wrote: >> Hi, >> >> Please review the following patch which will: >> >> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods >> >> - public boolean exists(Path path, LinkOption... options) >> - public A readAttributesIfExists(Path path, Class type, LinkOption... options) >> >> >> This change allows for providers to provide optimizations when the file's attributes are not needed. >> >> Mach5 tiers 1 - 3 run clean with this change >> >> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) >> >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Add @BeforeMethod and rename fields I think all my comments have been addressed so I think this is good to go. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9249 From mcimadamore at openjdk.org Tue Jul 5 20:53:58 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 5 Jul 2022 20:53:58 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM [v3] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 17:27:34 GMT, Jorn Vernee wrote: >> This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. >> >> For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. >> >> Testing: `jdk_foreign` test suite on all platforms that implement VaList. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > hmtl -> html Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk19/pull/91 From aturbanov at openjdk.org Tue Jul 5 20:53:42 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 5 Jul 2022 20:53:42 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Tue, 5 Jul 2022 15:26:06 GMT, Roger Riggs wrote: >> Well, if you _really_ want to noodle this for performance, you can also store a `this`-bound lambda in a `private final` instance field, so then it's only created once too. I wouldn't put it past `javac` to do this, but I'd have to disassemble the bytecode of a little test program to see whether it's the case. > > Can there be some JMH tests to confirm the performance? > The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure that the combination of creating a new record and the hashcode and equals methods would be faster than string concat of a constant and a single digit integer. @RogerRiggs is you comment about `DateTimeTextProvider.findStore` or `WeekFields.of`? There is no record creation here, in `DateTimeTextProvider.findStore`. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From djelinski at openjdk.org Tue Jul 5 21:06:58 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 5 Jul 2022 21:06:58 GMT Subject: RFR: 8289768: Clean up unused code Message-ID: This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. ------------- Commit messages: - Remove unused variables (windows) - Remove unused variables (macos) - Remove unused variables (linux) Changes: https://git.openjdk.org/jdk/pull/9383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289768 Stats: 69 lines in 45 files changed: 0 ins; 65 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From kbarrett at openjdk.org Tue Jul 5 21:55:41 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Jul 2022 21:55:41 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 12:09:46 GMT, David Holmes wrote: >>> Is "deadlock" accurate? >> >> Yes. >> >> In the context of the specification, "shutdown hook" means _application_ shutdown hook - as far as the specification is concerned, application shutdown hooks are the only kind of hooks. Right? >> >> For example, the following will deadlock (when run with the changes in this PR): >> >> >> public class TestHook { >> public static void main(String... arg) { >> Thread hook = new Thread("my-hook") { >> @Override >> public void run() { >> System.exit(1); >> } >> }; >> Runtime.getRuntime().addShutdownHook(hook); >> System.exit(0); >> } >> } > > It is a general deadlock, not a monitor based deadlock: the thread that called exit and holds the lock has to join() the hook thread. The hook thread blocks on the lock held by the exiting thread. Neither thread can progress. You folks are correct. I hadn't noticed the ApplicationShutdownHooks thing. Sorry for the noise. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From attila at openjdk.org Tue Jul 5 21:30:30 2022 From: attila at openjdk.org (Attila Szegedi) Date: Tue, 5 Jul 2022 21:30:30 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> On Tue, 5 Jul 2022 15:26:06 GMT, Roger Riggs wrote: >> Well, if you _really_ want to noodle this for performance, you can also store a `this`-bound lambda in a `private final` instance field, so then it's only created once too. I wouldn't put it past `javac` to do this, but I'd have to disassemble the bytecode of a little test program to see whether it's the case. > > Can there be some JMH tests to confirm the performance? > The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure that the combination of creating a new record and the hashcode and equals methods would be faster than string concat of a constant and a single digit integer. @RogerRiggs in my view, it's not about performance per se??I'll sometimes help along these kinds of small fix PRs (that are more likely than not driven by IntelliJ code refactoring suggestions) if I think they lead to more idiomatic code in the JDK with no drawbacks. I think there's value in periodically revisiting existing code and improve it to use new language and library construct that have become available since ? people study JDK source code, and I think it's important they see as good examples in there as possible. I do like seeing an old example of hand-rolled compute-if-absent being replaced by an actual `computeIfAbsent` call. Similarly, I think using records as composite keys is in general a better practice over simulating a composite key by creating a string representation of it. Yeah, it'll load additional code at runtime for that record's class, and yes, I'm aware records' `hashCode`/`equals`/`toString` are implemented by delegating to factory methods that heavily use method handle combinators. If records are meant as lightweight value-semantics composites, it should be okay to use them like this and if there are performance concerns with their use, then those concerns should be addressed by improving their performance. OTOH, MH combinators installed into constant call sites are well optimized by HotSpot these days??anyhow, a discussion for another day. In this specific instance, the value domain of the keys is limited, but the number of method calls to `WeekFields.of` isn't. It could be benchmarked but if there's concerns, it's also okay to de-scope the record-as-key from this PR. I don't have strong feelings either way. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From duke at openjdk.org Wed Jul 6 00:13:42 2022 From: duke at openjdk.org (liach) Date: Wed, 6 Jul 2022 00:13:42 GMT Subject: RFR: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets In-Reply-To: References: Message-ID: <6N5NFb_1R5x4IxrbVaDQ9EHZE-y30d6RyM3YsGr-ntg=.5f4decee-9e6e-4fab-b848-a5dd6ff1f627@github.com> On Tue, 5 Jul 2022 22:22:46 GMT, Joe Darcy wrote: > Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles} to use snippets rather than the older markup idiom. In addition, I believe we can add link in many examples, but I am not sure if this is part of this issue or if it will be addressed separately. src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 272: > 270: * Here are some examples of usage: > 271: * {@snippet lang="java" : > 272: Object x, y; String s; int i; These lines can now be properly indented, and they should be. ------------- PR: https://git.openjdk.org/jdk/pull/9385 From akasko at openjdk.org Tue Jul 5 21:54:38 2022 From: akasko at openjdk.org (Alex Kasko) Date: Tue, 5 Jul 2022 21:54:38 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v4] In-Reply-To: References: Message-ID: <41WXKm--MiKEJ1hDjCphryXNmJ3D7zE6T3d93kZRqOI=.fb5f9ffa-544e-41f3-986a-009ee82a1471@github.com> On Mon, 4 Jul 2022 23:38:08 GMT, Alex Kasko wrote: >> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. >> >> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. >> >> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: >> >> - option naming inside a properties file, currently `pass-all-args` is used >> - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group >> - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination >> - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` >> >> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. >> >> Testing: >> >> - [x] test to cover new logic is included >> - [x] ran jtreg:jdk/tools/jpackage with no new failures > > Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - enable passing args, add test coverage > - Added input params validation > - Proposed test changes to make FA testing of jpackage more flexible About the non-ASCII args: in `FileAssociations.TestRun::openFiles` non-ASCII argument can be supplied along with other arguments (in `WinCommandLine` and `WinDesktopOpenShortcut` runs). The arguments passing and the check in the output file works correctly for such arguments, but only when the `Language for non-Unicode programs` system setting in Windows is set to the corresponding language. Otherwise the argument is received by java app in `?????????` form and the test expectedly fails. I've checked that this behaviour of jpackage launcher is the same as in the main `java.exe` launcher. I've added the note comment and the concrete example of an arg to `FileAssociations.TestRun::openFiles`. If it is desired to be able to run such non-ASCII test manually (without changing the test code), I assume this can be done by making the test to read arguments from filesystem, or to add some kind of a test option to run the branch with predefined non-ASCII arguments only when requested. ------------- PR: https://git.openjdk.org/jdk/pull/9224 From jlaskey at openjdk.org Tue Jul 5 23:22:59 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 5 Jul 2022 23:22:59 GMT Subject: [jdk19] RFR: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 13:01:34 GMT, Jorn Vernee wrote: > This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. > > Testing: local run of the `jdk_foreign` test suite. Is UTF-8 E0 C0 reasonable in this case? Or at least an option? ------------- PR: https://git.openjdk.org/jdk19/pull/107 From smarks at openjdk.org Wed Jul 6 00:42:14 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 6 Jul 2022 00:42:14 GMT Subject: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses Message-ID: Simple javadoc fix of an editorial nature. ------------- Commit messages: - 8289779: Map::replaceAll javadoc has redundant @throws clauses Changes: https://git.openjdk.org/jdk19/pull/111/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289779 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk19/pull/111.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/111/head:pull/111 PR: https://git.openjdk.org/jdk19/pull/111 From kbarrett at openjdk.org Tue Jul 5 21:59:40 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Jul 2022 21:59:40 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v2] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 12:19:27 GMT, David Holmes wrote: > > Let's say we've run shutdown so run all the hooks but not halted. Then someone calls exit(0). That seems to suggest the call will block indefinitely, which is neither desirable nor what was actually implemented. > > If the hook threads do not halt then the exiting thread (which holds the lock) blocks forever in the join(). Any other call to exit blocks trying to acquire the lock. That has always been the way this works - if hook threads don't terminate then the VM doesn't (unless someone calls halt() directly). That is one of the things the window you suggested be closed, allowed - a call to exit(non-zero) could force a call to halt(). I think that isn't true. If a hook doesn't terminate then VM.shutdown doesn't get called, so the window never gets cracked opened to call halt directly. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From darcy at openjdk.org Tue Jul 5 22:29:06 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 5 Jul 2022 22:29:06 GMT Subject: RFR: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets Message-ID: Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles} to use snippets rather than the older markup idiom. ------------- Commit messages: - JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets Changes: https://git.openjdk.org/jdk/pull/9385/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9385&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289775 Stats: 123 lines in 2 files changed: 0 ins; 1 del; 122 mod Patch: https://git.openjdk.org/jdk/pull/9385.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9385/head:pull/9385 PR: https://git.openjdk.org/jdk/pull/9385 From iris at openjdk.org Wed Jul 6 00:06:38 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 6 Jul 2022 00:06:38 GMT Subject: RFR: 8288706: Unused parameter 'boolean newln' in method java.lang.VersionProps#print(boolean, boolean) In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 18:38:57 GMT, Lance Andersen wrote: > Hi all, > > This PR cleans up `VersionProps::print` removing the unused parameter `newln`. > > Mach5 tiers1-3 are currently running. > > Best, > Lance Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9382 From alanb at openjdk.org Wed Jul 6 09:44:28 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Jul 2022 09:44:28 GMT Subject: RFR: 8288706: Unused parameter 'boolean newln' in method java.lang.VersionProps#print(boolean, boolean) In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 18:38:57 GMT, Lance Andersen wrote: > Hi all, > > This PR cleans up `VersionProps::print` removing the unused parameter `newln`. > > Mach5 tiers1-3 are currently running. > > Best, > Lance Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9382 From duke at openjdk.org Wed Jul 6 08:23:30 2022 From: duke at openjdk.org (ScientificWare) Date: Wed, 6 Jul 2022 08:23:30 GMT Subject: Integrated: JDK-8289730 : Deprecated code sample in java.lang.ClassCastException In-Reply-To: References: Message-ID: <7arb4SHjZ1vt-z0NYg7LL0XpcqaQSiSWD8UZPBRT5Oo=.7c394908-0faf-47c7-b14f-4da15b04d8b4@github.com> On Mon, 4 Jul 2022 06:57:12 GMT, ScientificWare wrote: > - Correct a deprecated code. > - Update Copyright. > - More wide question : How are you dealing with deprecated codes in snippets ? > ``` > @deprecated(since="9") > public Integer?(int value) > ``` This pull request has now been integrated. Changeset: 4ad18cf0 Author: ScientificWare Committer: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/4ad18cf088e12f3582b8f6117a44ae4607f69839 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8289730: Deprecated code sample in java.lang.ClassCastException Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/9359 From jwilhelm at openjdk.org Wed Jul 6 13:11:34 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 6 Jul 2022 13:11:34 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge - 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc - 8289439: Clarify relationship between ThreadStart/ThreadEnd and can_support_virtual_threads capability - 8288128: S390X: Fix crashes after JDK-8284161 (Virtual Threads) - 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() - 8287847: Fatal Error when suspending virtual thread after it has terminated - 8067757: Incorrect HTML generation for copied javadoc with multiple @throws tags - 8289569: [test] java/lang/ProcessBuilder/Basic.java fails on Alpine/musl - 8287851: C2 crash: assert(t->meet(t0) == t) failed: Not monotonic - 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run - ... and 2 more: https://git.openjdk.org/jdk/compare/83a5d599...fbbc3300 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9397&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9397&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9397/files Stats: 888 lines in 24 files changed: 705 ins; 64 del; 119 mod Patch: https://git.openjdk.org/jdk/pull/9397.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9397/head:pull/9397 PR: https://git.openjdk.org/jdk/pull/9397 From dholmes at openjdk.org Wed Jul 6 12:09:50 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Jul 2022 12:09:50 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v5] In-Reply-To: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> References: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> Message-ID: <4E_bY1mIkc1DXXQTv-2Fj-8BeFOlVhxMrZ698TtV6uA=.e2e9b2b2-d87e-4c0a-9b82-8993e58a7702@github.com> On Tue, 5 Jul 2022 18:43:26 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst 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 branch 'master' into shutdown_cleanup > - iter text > - iterate on wording > - better clarify multiple threads behavior > - 8288984: Simplification in Shutdown.exit > > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Thanks for the updates ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9351 From jvernee at openjdk.org Wed Jul 6 11:09:33 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Jul 2022 11:09:33 GMT Subject: [jdk19] RFR: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 [v2] In-Reply-To: References: Message-ID: > This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. > > Testing: local run of the `jdk_foreign` test suite. Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Add javadoc - Revert "Throw IAE when converting string with null byte." This reverts commit 70f83902a38e863b96fedb312982f7ac683ed068. ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/107/files - new: https://git.openjdk.org/jdk19/pull/107/files/70f83902..7234fd72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=107&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=107&range=00-01 Stats: 43 lines in 4 files changed: 17 ins; 25 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/107.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/107/head:pull/107 PR: https://git.openjdk.org/jdk19/pull/107 From xuelei at openjdk.org Wed Jul 6 14:28:36 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 6 Jul 2022 14:28:36 GMT Subject: Integrated: 8287596: Reorg jdk.test.lib.util.ForceGC In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 19:08:03 GMT, Xue-Lei Andrew Fan wrote: > This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in open part looks good to me. Please help to run Mach5 just case the closed test cases are impacted. This pull request has now been integrated. Changeset: 82a8bd7e Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/82a8bd7e92a1867b0c82f051361938be8610428d Stats: 92 lines in 10 files changed: 13 ins; 38 del; 41 mod 8287596: Reorg jdk.test.lib.util.ForceGC Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/8979 From jiefu at openjdk.org Wed Jul 6 03:17:28 2022 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 6 Jul 2022 03:17:28 GMT Subject: RFR: 8289711: Add container configuration data to mbeans In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 04:21:55 GMT, xpbob wrote: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) src/java.base/share/classes/module-info.java line 233: > 231: exports jdk.internal.platform to > 232: jdk.management, > 233: java.management, Maybe, we'd better put `jdk.management,` before `jdk.management,`. src/java.management/share/classes/java/lang/management/ContainerMXBean.java line 1: > 1: package java.lang.management; Shall we add a copyright header for this new file? ------------- PR: https://git.openjdk.org/jdk/pull/9372 From prappo at openjdk.org Wed Jul 6 08:43:41 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 6 Jul 2022 08:43:41 GMT Subject: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 00:32:00 GMT, Stuart Marks wrote: > Simple javadoc fix of an editorial nature. Thanks for doing this, Stuart. Not only does this PR remove duplication from the `Map` documentation, but it also ensures that when JDK-6509045 is integrated, that duplication won't spread to `ConcurrentMap`. A bonus of this fix is that the irrelevant mention of "keys" is gone from the description of `NullPointerException`. Also, consider closing 8255426 as a duplicate. ------------- Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.org/jdk19/pull/111 From duke at openjdk.org Wed Jul 6 03:52:30 2022 From: duke at openjdk.org (xpbob) Date: Wed, 6 Jul 2022 03:52:30 GMT Subject: RFR: 8289711: Add container configuration data to mbeans In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 04:21:55 GMT, xpbob wrote: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) @DamonFool Thanks for review. The code has been updated ------------- PR: https://git.openjdk.org/jdk/pull/9372 From chegar at openjdk.org Wed Jul 6 12:50:30 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 6 Jul 2022 12:50:30 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v5] In-Reply-To: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> References: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> Message-ID: On Tue, 5 Jul 2022 18:43:26 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst 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 branch 'master' into shutdown_cleanup > - iter text > - iterate on wording > - better clarify multiple threads behavior > - 8288984: Simplification in Shutdown.exit > > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From mcimadamore at openjdk.org Wed Jul 6 09:43:38 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 09:43:38 GMT Subject: [jdk19] RFR: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 In-Reply-To: References: Message-ID: <9-xTlctIXpIc-FJrfk1_m25bL95lInpqt8kydXZreq4=.ffa5efe2-76ab-4ed3-86bf-2f0b3f699af3@github.com> On Mon, 4 Jul 2022 13:01:34 GMT, Jorn Vernee wrote: > This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. > > Testing: local run of the `jdk_foreign` test suite. After some offline discussions Jorn and I have decided to leave things as they are and document the behavior. After all, there's no unsafety - and in some cases (e.g. concatenating multiple strings into a "flat" array whose elements are separated by terminators) it might even be desirable. The performance impact of checking all bytes and throwing is just too much: from 1.5 slower (with 100 chars) when using a standard allocator, up to 2.5x slower when using an optimized allocator. As a fallback, users could always resort to manual bulk copy, but the trade off would not be super obvious. ------------- PR: https://git.openjdk.org/jdk19/pull/107 From duke at openjdk.org Wed Jul 6 09:03:31 2022 From: duke at openjdk.org (ScientificWare) Date: Wed, 6 Jul 2022 09:03:31 GMT Subject: RFR: JDK-8289730 : Deprecated code sample in java.lang.ClassCastException In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 06:57:12 GMT, ScientificWare wrote: > - Correct a deprecated code. > - Update Copyright. > - More wide question : How are you dealing with deprecated codes in snippets ? > ``` > @deprecated(since="9") > public Integer?(int value) > ``` @turbanoff Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9359 From chegar at openjdk.org Wed Jul 6 10:51:34 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 6 Jul 2022 10:51:34 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v2] In-Reply-To: References: Message-ID: <3UWokVnmW_QaiIErk3-kwLYFdLeP778WmVl-UrRMXss=.7d7c770f-b299-483a-8529-95e41d9e2b60@github.com> On Mon, 4 Jul 2022 12:19:27 GMT, David Holmes wrote: >> Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> better clarify multiple threads behavior > >> Let's say we've run shutdown so run all the hooks but not halted. Then someone calls exit(0). That seems to suggest the call will block indefinitely, which is neither desirable nor what was actually implemented. > > If the hook threads do not halt then the exiting thread (which holds the lock) blocks forever in the join(). Any other call to exit blocks trying to acquire the lock. That has always been the way this works - if hook threads don't terminate then the VM doesn't (unless someone calls halt() directly). That is one of the things the window you suggested be closed, allowed - a call to exit(non-zero) could force a call to halt(). @dholmes-ora @AlanBateman @kimbarrett The following [CSR](https://bugs.openjdk.org/browse/JDK-8289824) has been filed to cover the specification related changes in this PR - please review as appropriate. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From rriggs at openjdk.org Wed Jul 6 14:32:39 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Jul 2022 14:32:39 GMT Subject: RFR: 8288706: Unused parameter 'boolean newln' in method java.lang.VersionProps#print(boolean, boolean) In-Reply-To: References: Message-ID: <7Ogp-03R6UaPHubcxty4Av0z_hBjrktu4CCZxBO7Hi8=.ceb6f7ec-4ad4-4d3a-b8e4-ebb99882adac@github.com> On Tue, 5 Jul 2022 18:38:57 GMT, Lance Andersen wrote: > Hi all, > > This PR cleans up `VersionProps::print` removing the unused parameter `newln`. > > Mach5 tiers1-3 are currently running. > > Best, > Lance Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9382 From duke at openjdk.org Wed Jul 6 09:05:25 2022 From: duke at openjdk.org (iaroslavski) Date: Wed, 6 Jul 2022 09:05:25 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v14] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Thu, 30 Jun 2022 16:41:36 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Fix @since version Sure, will do it, thank you for pointing to this. ------------- PR: https://git.openjdk.org/jdk/pull/3938 From jvernee at openjdk.org Wed Jul 6 11:09:33 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Jul 2022 11:09:33 GMT Subject: [jdk19] RFR: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 13:01:34 GMT, Jorn Vernee wrote: > This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. > > Testing: local run of the `jdk_foreign` test suite. I've tweaked the Javadoc. I realized it should also be tweaked for `MemorySegment::setUtf8String`. ------------- PR: https://git.openjdk.org/jdk19/pull/107 From lancea at openjdk.org Wed Jul 6 15:41:27 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 6 Jul 2022 15:41:27 GMT Subject: Integrated: 8288706: Unused parameter 'boolean newln' in method java.lang.VersionProps#print(boolean, boolean) In-Reply-To: References: Message-ID: <3MiGeNTCqTHwMnh7IUM8AxXMAmvs3AuWPy215wXCJoQ=.1ac3e68c-9944-412f-889f-7bf1bb23b1e8@github.com> On Tue, 5 Jul 2022 18:38:57 GMT, Lance Andersen wrote: > Hi all, > > This PR cleans up `VersionProps::print` removing the unused parameter `newln`. > > Mach5 tiers1-3 are currently running. > > Best, > Lance This pull request has now been integrated. Changeset: 9f37ba44 Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/9f37ba44b8a6dfb635f39b6950fd5a7ae8894902 Stats: 19 lines in 2 files changed: 1 ins; 13 del; 5 mod 8288706: Unused parameter 'boolean newln' in method java.lang.VersionProps#print(boolean, boolean) Reviewed-by: iris, alanb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/9382 From dfuchs at openjdk.org Wed Jul 6 09:39:28 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 6 Jul 2022 09:39:28 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Changes to libnet look good. Please wait until you have obtained approvals from maintainers of the other areas to integrate, ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Wed Jul 6 08:39:42 2022 From: duke at openjdk.org (iaroslavski) Date: Wed, 6 Jul 2022 08:39:42 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v14] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Thu, 30 Jun 2022 16:41:36 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Fix @since version The latest benchmark performed by Laurent https://github.com/bourgesl/nearly-optimal-mergesort-code/tree/master/sort-bench/results/202205_final ------------- PR: https://git.openjdk.org/jdk/pull/3938 From duke at openjdk.org Wed Jul 6 08:53:55 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 6 Jul 2022 08:53:55 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v14] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Thu, 30 Jun 2022 16:41:36 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Fix @since version I mean adding benchmarks into `micro.org.openjdk.bench` ------------- PR: https://git.openjdk.org/jdk/pull/3938 From sgehwolf at openjdk.org Wed Jul 6 10:03:39 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 6 Jul 2022 10:03:39 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 03:52:30 GMT, xpbob wrote: >> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. >> Results the following >> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > update header I do think this could be useful. Having said that, some of this has been discussed in https://bugs.openjdk.org/browse/JDK-8199944 (and been considered as won't fix at the time). I tend to agree that it should be a JDK (and even an OS) specific bean. The relevant information is only available on Linux. +1 on making this JDK specific. First step is probably to get consensus on a CSR. ------------- PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Wed Jul 6 08:23:29 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 6 Jul 2022 08:23:29 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v14] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Thu, 30 Jun 2022 16:41:36 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Fix @since version Should we add a benchmark for this? ------------- PR: https://git.openjdk.org/jdk/pull/3938 From djelinski at openjdk.org Wed Jul 6 08:57:23 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Jul 2022 08:57:23 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) test failure is unrelated, caused by [JDK-8289619](https://bugs.openjdk.org/browse/JDK-8289619) ------------- PR: https://git.openjdk.org/jdk/pull/9383 From rriggs at openjdk.org Wed Jul 6 14:15:39 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Jul 2022 14:15:39 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> Message-ID: On Tue, 5 Jul 2022 21:27:16 GMT, Attila Szegedi wrote: >> Can there be some JMH tests to confirm the performance? >> The value domain of the keys is pretty limited (7 * 7) max; and I'm not sure that the combination of creating a new record and the hashcode and equals methods would be faster than string concat of a constant and a single digit integer. > > @RogerRiggs in my view, it's not about performance per se??I'll sometimes help along these kinds of small fix PRs (that are more likely than not driven by IntelliJ code refactoring suggestions) if I think they lead to more idiomatic code in the JDK with no drawbacks. I think there's value in periodically revisiting existing code and improve it to use new language and library construct that have become available since ? people study JDK source code, and I think it's important they see as good examples in there as possible. I do like seeing an old example of hand-rolled compute-if-absent being replaced by an actual `computeIfAbsent` call. Similarly, I think using records as composite keys is in general a better practice over simulating a composite key by creating a string representation of it. > > Yeah, it'll load additional code at runtime for that record's class, and yes, I'm aware records' `hashCode`/`equals`/`toString` are implemented by delegating to factory methods that heavily use method handle combinators. If records are meant as lightweight value-semantics composites, it should be okay to use them like this and if there are performance concerns with their use, then those concerns should be addressed by improving their performance. OTOH, MH combinators installed into constant call sites are well optimized by HotSpot these days??anyhow, a discussion for another day. > > In this specific instance, the value domain of the keys is limited, but the number of method calls to `WeekFields.of` isn't. It could be benchmarked but if there's concerns, it's also okay to de-scope the record-as-key from this PR. I don't have strong feelings either way. The comment was about WeekFields.of(), I misplaced the comment. @szegedi All good points about modernizing code... One of the reasons to ask about specific performance data is to validate the general performance impact of using lambdas. In the case of WeekFields.of(), the lambda is passed on every call to `computeIfAbsent` even if the key is present and the lambda won't be used. `WeekFields` is way-way down the long tail of frequency of use and I expect that 99% of calls are for the same one or two combinations. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From djelinski at openjdk.org Wed Jul 6 05:32:29 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Jul 2022 05:32:29 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables - Remove unused variables (windows) - Remove unused variables (macos) - Remove unused variables (linux) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9383/files - new: https://git.openjdk.org/jdk/pull/9383/files/915680c0..b4cd5374 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00-01 Stats: 491 lines in 22 files changed: 458 ins; 5 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From alanb at openjdk.org Wed Jul 6 06:02:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Jul 2022 06:02:39 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: References: Message-ID: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> On Wed, 6 Jul 2022 03:52:30 GMT, xpbob wrote: >> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. >> Results the following >> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > update header It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API? I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting locked in. A possible standard point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management). ------------- PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Wed Jul 6 03:52:30 2022 From: duke at openjdk.org (xpbob) Date: Wed, 6 Jul 2022 03:52:30 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: References: Message-ID: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with one additional commit since the last revision: update header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/0f262911..8f63af82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=00-01 Stats: 52 lines in 4 files changed: 47 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Wed Jul 6 16:26:47 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Wed, 6 Jul 2022 16:26:47 GMT Subject: Integrated: 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 10:09:36 GMT, Raffaello Giulietti wrote: > `BigDecimal.morePoint[Left|Right]()` should return the target `this` when the argument is 0 _and_ the scale is non-negative. This pull request has now been integrated. Changeset: 35387d5c Author: Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.org/jdk/commit/35387d5cb6aa9e59d62b8e1b137b53ec88521310 Stats: 108 lines in 2 files changed: 106 ins; 0 del; 2 mod 8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/9307 From itakiguchi at openjdk.org Wed Jul 6 16:23:22 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Wed, 6 Jul 2022 16:23:22 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets Message-ID: OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. |Charset|Mix|SBCS|DBCS| | -- | -- | -- | -- | | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | | Korean | Cp933 | Cp833 | Cp834 | But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency |Charset|Mix|SBCS|DBCS| | ------------- | ------------- | ------------- | ------------- | | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | *1: Cp037 compatible ------------- Commit messages: - 8289834: Missing SBCS and DBCS Only EBCDIC charsets Changes: https://git.openjdk.org/jdk/pull/9399/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9399&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289834 Stats: 369 lines in 6 files changed: 367 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9399.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9399/head:pull/9399 PR: https://git.openjdk.org/jdk/pull/9399 From jvernee at openjdk.org Wed Jul 6 17:11:54 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Jul 2022 17:11:54 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v4] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore wrote: >> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Revert implicit vs. heap session changes src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 131: > 129: AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, true); > 130: #if[floatingPoint] > 131: $rawType$ rawValue = SCOPED_MEMORY_ACCESS.get$RawType$Unaligned(bb.session(), For instance, it's not clear to me why `baseSession()` is not called here. src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java line 172: > 170: > 171: public Builder(MemorySession session) { > 172: ((MemorySessionImpl)session).checkValidState(); Or here, if the memory session is a non-closeable view. ------------- PR: https://git.openjdk.org/jdk19/pull/22 From jvernee at openjdk.org Wed Jul 6 17:11:55 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Jul 2022 17:11:55 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v4] In-Reply-To: References: Message-ID: <37B_wovfu8uoaM0hq4X1PG3xccVavpwYiZcJ9uNpqTM=.e417015c-9cef-4125-88cb-346b0a80471e@github.com> On Wed, 6 Jul 2022 17:05:51 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert implicit vs. heap session changes > > src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 131: > >> 129: AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, true); >> 130: #if[floatingPoint] >> 131: $rawType$ rawValue = SCOPED_MEMORY_ACCESS.get$RawType$Unaligned(bb.session(), > > For instance, it's not clear to me why `baseSession()` is not called here. It seems that, if `get$RawType$Unaligned` calls `checkValidStateRaw()` this will end up throwing an exception ------------- PR: https://git.openjdk.org/jdk19/pull/22 From psandoz at openjdk.org Wed Jul 6 17:43:54 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 6 Jul 2022 17:43:54 GMT Subject: [jdk19] RFR: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 [v2] In-Reply-To: References: Message-ID: <6QOLWRPfubGqK-TKLntajCXGtdnX71_heOL8ppSBknM=.fa7ef907-2452-4b8a-bbc7-5a2c48876464@github.com> On Wed, 6 Jul 2022 11:09:33 GMT, Jorn Vernee wrote: >> This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. >> >> Testing: local run of the `jdk_foreign` test suite. > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Add javadoc > - Revert "Throw IAE when converting string with null byte." > > This reverts commit 70f83902a38e863b96fedb312982f7ac683ed068. That is indeed the simplest option, and the more preferable one given the performance cost of checking. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.org/jdk19/pull/107 From mcimadamore at openjdk.org Wed Jul 6 18:01:28 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 18:01:28 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v5] In-Reply-To: References: Message-ID: > This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into memory_session_cleanup - Fix ambiguity between session vs. base session - Revert implicit vs. heap session changes - Unify heap vs. implicit scopes - Merge branch 'master' into memory_session_cleanup - Fix issue in Direct-X-Buffer template - Simplify and drop the state class - Add missing files - Initial push ------------- Changes: https://git.openjdk.org/jdk19/pull/22/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=04 Stats: 484 lines in 24 files changed: 56 ins; 107 del; 321 mod Patch: https://git.openjdk.org/jdk19/pull/22.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22 PR: https://git.openjdk.org/jdk19/pull/22 From duke at openjdk.org Wed Jul 6 17:07:02 2022 From: duke at openjdk.org (Markus KARG) Date: Wed, 6 Jul 2022 17:07:02 GMT Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5] In-Reply-To: References: Message-ID: <0_UCVYNLvy1g96gjleo_1GiVW92wPGJWzTLmY6hpAjw=.18672270-2f22-4f44-a3a2-d189ece7daff@github.com> On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote: >> Implementation of JDK-8279283 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed missing BufferedInputStream Please keep this PR open; I will continune work on it soon. ------------- PR: https://git.openjdk.org/jdk/pull/6935 From jvernee at openjdk.org Wed Jul 6 17:00:47 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Jul 2022 17:00:47 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v4] In-Reply-To: References: Message-ID: <9ZEADSzSlDzVxEDuF3KT1bgynXFLLtLmXZi1XszM0D0=.ff3a84ef-d38b-4daa-920e-acee3ee97e6c@github.com> On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore wrote: >> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Revert implicit vs. heap session changes Am I understanding correctly that, before calling `checkValidState` we also need to always call `baseSession()`? `checkValidState()` just calls `checkValidStateRaw` in a try/catch, and for non-closeable views this always throws. There seem to be many cases where `baseSession()` is not called... ------------- PR: https://git.openjdk.org/jdk19/pull/22 From weijun at openjdk.org Wed Jul 6 16:44:53 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 6 Jul 2022 16:44:53 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Changes in security (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`) look fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From lancea at openjdk.org Wed Jul 6 15:35:39 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 6 Jul 2022 15:35:39 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) zlib looks fine given it is openjdk and not an upstream needed change ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From itakiguchi at openjdk.org Wed Jul 6 16:23:22 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Wed, 6 Jul 2022 16:23:22 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi wrote: > OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. > |Charset|Mix|SBCS|DBCS| > | -- | -- | -- | -- | > | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | > | Korean | Cp933 | Cp833 | Cp834 | > > But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. > > I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency > |Charset|Mix|SBCS|DBCS| > | ------------- | ------------- | ------------- | ------------- | > | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | > | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | > | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | > > *1: Cp037 compatible Discussions are available on : [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets ------------- PR: https://git.openjdk.org/jdk/pull/9399 From darcy at openjdk.org Wed Jul 6 21:31:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 6 Jul 2022 21:31:20 GMT Subject: Integrated: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets In-Reply-To: References: Message-ID: <8Kne8z124WTS43u3vUMOhi-njDqEei7wExyFzrf3x2M=.7f71b5ad-da2d-4d6f-9189-c8a0f0d66d76@github.com> On Tue, 5 Jul 2022 22:22:46 GMT, Joe Darcy wrote: > Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles} to use snippets rather than the older markup idiom. This pull request has now been integrated. Changeset: a40c17b7 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/a40c17b730257919f18066dbce4fc92ed3c4f10e Stats: 123 lines in 2 files changed: 0 ins; 1 del; 122 mod 8289775: Update java.lang.invoke.MethodHandle[s] to use snippets Reviewed-by: jrose ------------- PR: https://git.openjdk.org/jdk/pull/9385 From jwilhelm at openjdk.org Wed Jul 6 21:03:47 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 6 Jul 2022 21:03:47 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 13:01:02 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 2a6ec88c Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/2a6ec88cd09adec43df3da1b22653271517b14a8 Stats: 888 lines in 24 files changed: 705 ins; 64 del; 119 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9397 From smarks at openjdk.org Wed Jul 6 23:09:07 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 6 Jul 2022 23:09:07 GMT Subject: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 23:03:42 GMT, Stuart Marks wrote: >> Simple javadoc fix of an editorial nature. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Reflow and adjust whitespace per Alan's & Iris' comments. Reflowed and adjusted whitespace. Also, Pavel wrote: > Also, consider closing 8255426 as a duplicate. Ha! Thanks, I had forgotten about that one. Easier to file a new bug than to dig out an old one. Oh well, closed as duplicate. ------------- PR: https://git.openjdk.org/jdk19/pull/111 From asemenyuk at openjdk.org Thu Jul 7 00:01:46 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 7 Jul 2022 00:01:46 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v4] In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 23:38:08 GMT, Alex Kasko wrote: >> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. >> >> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. >> >> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: >> >> - option naming inside a properties file, currently `pass-all-args` is used >> - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group >> - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination >> - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` >> >> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. >> >> Testing: >> >> - [x] test to cover new logic is included >> - [x] ran jtreg:jdk/tools/jpackage with no new failures > > Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - enable passing args, add test coverage > - Added input params validation > - Proposed test changes to make FA testing of jpackage more flexible Marked as reviewed by asemenyuk (Reviewer). I confirm the patch works and there are no regressions. SQE uses only the part of jpackage jtreg tests that create test packages, so there is no point in customizing tests with reading args from the file system. I think I have enough information to help SQE update test spec and cover Unicode args. ------------- PR: https://git.openjdk.org/jdk/pull/9224 From duke at openjdk.org Wed Jul 6 23:56:33 2022 From: duke at openjdk.org (ScientificWare) Date: Wed, 6 Jul 2022 23:56:33 GMT Subject: RFR: JDK-8289741 : Remove unused imports from DTDBuilder.java [v2] In-Reply-To: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> References: <_NwZVv_R3J3rji4AQYptjRFrewWjITtqvSuFsfk0JuM=.17e9f97e-076a-4b5e-ac6f-0cd100aa0f60@github.com> Message-ID: > This is tracked in JBS as > > [JDK-8289741](https://bugs.openjdk.org/browse/JDK-8289741) > >> **Remove unused imports from DTDBuilder.java** > > Some imports are no more used. > > - java.io.FileNotFoundException; > - java.io.BufferedInputStream; > - java.io.OutputStream; > - java.util.BitSet; > - java.util.StringTokenizer; > - java.util.Properties; > - java.util.zip.DeflaterOutputStream; > - java.util.zip.Deflater; > - java.net.URL; > > https://github.com/scientificware/jdk/issues/4 ScientificWare 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 scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Merge branch 'openjdk:master' into scientificware-patch-001-DTDBuilder - Remove unused imports. Some imports are no more used. - java.io.FileNotFoundException; - java.io.BufferedInputStream; - java.io.OutputStream; - java.util.BitSet; - java.util.StringTokenizer; - java.util.Properties; - java.util.zip.DeflaterOutputStream; - java.util.zip.Deflater; - java.net.URL; ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9360/files - new: https://git.openjdk.org/jdk/pull/9360/files/2bf79718..6d097e77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9360&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9360&range=00-01 Stats: 3364 lines in 138 files changed: 2399 ins; 468 del; 497 mod Patch: https://git.openjdk.org/jdk/pull/9360.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9360/head:pull/9360 PR: https://git.openjdk.org/jdk/pull/9360 From almatvee at openjdk.org Thu Jul 7 07:27:57 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 7 Jul 2022 07:27:57 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 03:03:15 GMT, Alexander Matveev wrote: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be signed. > - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. > > Added additional test to validate signature when DMG or PKG is generated from predefined app image. 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] - Fixed as suggested by Alexey. If app image already signed we will not add `.package` file. ------------- PR: https://git.openjdk.org/jdk19/pull/89 From almatvee at openjdk.org Thu Jul 7 07:27:57 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 7 Jul 2022 07:27:57 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 03:03:15 GMT, Alexander Matveev wrote: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be signed. > - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. > > Added additional test to validate signature when DMG or PKG is generated from predefined app image. 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] - Fixed as suggested by Alexey. If app image already signed we will not add `.package` file. ------------- PR: https://git.openjdk.org/jdk19/pull/89 From dholmes at openjdk.org Thu Jul 7 08:07:29 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Jul 2022 08:07:29 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v2] In-Reply-To: References: Message-ID: <8PqtiVU2RlQqVGzDQogGefiTnfuELS_5oaIf4j8ccaQ=.fcdafb60-55e0-4c76-b3ab-b0fb4a663a88@github.com> On Tue, 5 Jul 2022 21:56:27 GMT, Kim Barrett wrote: > I think that isn't true. If a hook doesn't terminate then VM.shutdown doesn't get called, so the window never gets cracked opened to call halt directly. @kimbarrett Any thread can call halt() directly while the attempted shutdown is in progress. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From smarks at openjdk.org Thu Jul 7 06:14:55 2022 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 7 Jul 2022 06:14:55 GMT Subject: [jdk19] RFR: 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. Message-ID: Minor doc wording changes, to be consistent with HashSet.newHashSet et. al. ------------- Commit messages: - 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. Changes: https://git.openjdk.org/jdk19/pull/118/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=118&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289872 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk19/pull/118.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/118/head:pull/118 PR: https://git.openjdk.org/jdk19/pull/118 From akasko at openjdk.org Thu Jul 7 05:45:29 2022 From: akasko at openjdk.org (Alex Kasko) Date: Thu, 7 Jul 2022 05:45:29 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v4] In-Reply-To: References: Message-ID: <3B1BT5cTlmVdZvm18FFA0HUx57t3MZRniECVM-9p-Eg=.ea34e9bd-16c3-4e8d-97e3-d7603d1afad8@github.com> On Mon, 4 Jul 2022 23:38:08 GMT, Alex Kasko wrote: >> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. >> >> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. >> >> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: >> >> - option naming inside a properties file, currently `pass-all-args` is used >> - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group >> - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination >> - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` >> >> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. >> >> Testing: >> >> - [x] test to cover new logic is included >> - [x] ran jtreg:jdk/tools/jpackage with no new failures > > Alex Kasko 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: > > - enable passing args, add test coverage > - Added input params validation > - Proposed test changes to make FA testing of jpackage more flexible Thanks for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9224 From iris at openjdk.org Wed Jul 6 19:12:43 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 6 Jul 2022 19:12:43 GMT Subject: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 00:32:00 GMT, Stuart Marks wrote: > Simple javadoc fix of an editorial nature. Marked as reviewed by iris (Reviewer). src/java.base/share/classes/java/util/Map.java line 740: > 738: * @param function the function to apply to each entry > 739: * @throws UnsupportedOperationException if the {@code set} operation > 740: * is not supported by this map's entry set iterator. Maybe fix indentation here and at line 742 for the CCE for consistency? ------------- PR: https://git.openjdk.org/jdk19/pull/111 From asemenyuk at openjdk.org Thu Jul 7 00:01:51 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 7 Jul 2022 00:01:51 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v3] In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 12:29:33 GMT, Alex Kasko wrote: >> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. >> >> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. >> >> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: >> >> - option naming inside a properties file, currently `pass-all-args` is used >> - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group >> - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination >> - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` >> >> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. >> >> Testing: >> >> - [x] test to cover new logic is included >> - [x] ran jtreg:jdk/tools/jpackage with no new failures > > Alex Kasko has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. test/jdk/tools/jpackage/share/FileAssociationsTest.java line 108: > 106: .applyTo(packageTest); > 107: > 108: packageTest.run(RunnablePackageTest.Action.CREATE, RunnablePackageTest.Action.INSTALL, FYI: the default test steps can be overridden with the value of `jpackage.test.action` system property. Its value would be `create,install,verify_install,uninstall` for this case. UPD: Nevermind this comment. It applied to the old version of the PR. ------------- PR: https://git.openjdk.org/jdk/pull/9224 From mcimadamore at openjdk.org Wed Jul 6 21:50:36 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 21:50:36 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v6] In-Reply-To: References: Message-ID: > This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Turn non-closeable view back into MemorySession impl ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/22/files - new: https://git.openjdk.org/jdk19/pull/22/files/09bb7cf3..809a0a2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=04-05 Stats: 79 lines in 14 files changed: 7 ins; 11 del; 61 mod Patch: https://git.openjdk.org/jdk19/pull/22.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22 PR: https://git.openjdk.org/jdk19/pull/22 From duke at openjdk.org Thu Jul 7 10:32:17 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 7 Jul 2022 10:32:17 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] Message-ID: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. Benchmark results: before Benchmark Mode Cnt Score Error Units StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op after Benchmark Mode Cnt Score Error Units StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op ------------- Commit messages: - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] Changes: https://git.openjdk.org/jdk/pull/9407/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289908 Stats: 90 lines in 5 files changed: 77 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9407.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407 PR: https://git.openjdk.org/jdk/pull/9407 From akasko at openjdk.org Thu Jul 7 05:45:30 2022 From: akasko at openjdk.org (Alex Kasko) Date: Thu, 7 Jul 2022 05:45:30 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v3] In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 18:50:23 GMT, Alexey Semenyuk wrote: >> Alex Kasko has updated the pull request incrementally with one additional commit since the last revision: >> >> drop pass-all-args property > > test/jdk/tools/jpackage/share/FileAssociationsTest.java line 108: > >> 106: .applyTo(packageTest); >> 107: >> 108: packageTest.run(RunnablePackageTest.Action.CREATE, RunnablePackageTest.Action.INSTALL, > > FYI: the default test steps can be overridden with the value of `jpackage.test.action` system property. > Its value would be `create,install,verify_install,uninstall` for this case. > > UPD: Nevermind this comment. It applied to the old version of the PR. Thanks for the info! I've seen `jpackage.test.action` property in `run_tests.sh`, but never used it. ------------- PR: https://git.openjdk.org/jdk/pull/9224 From chegar at openjdk.org Thu Jul 7 07:10:51 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Thu, 7 Jul 2022 07:10:51 GMT Subject: [jdk19] RFR: 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. In-Reply-To: References: Message-ID: <45-toZcCdABR0DjhUnuEMMgwI3GEi-tjOWV20Wh9bsI=.6fdc6c75-9cd9-4ef3-87d5-7ee330031e61@github.com> On Thu, 7 Jul 2022 06:06:42 GMT, Stuart Marks wrote: > Minor doc wording changes, to be consistent with HashSet.newHashSet et. al. LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk19/pull/118 From darcy at openjdk.org Wed Jul 6 21:28:54 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 6 Jul 2022 21:28:54 GMT Subject: RFR: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 20:49:25 GMT, John R Rose wrote: > The code examples in these files were exdented to make it easier to extract example code and test it, and to maintain equivalence during active development of the APIs. > > The examples in runnable form are in test/jdk/java/lang/invoke/JavaDocExamplesTest.java in the same repo. > > It would be nice if some day we could tie together the two copies into one using a link. I don't recall whether snippets can do this or not, given that the two copies are far apart in the repo structure. > > I agree that just the bracket changes are valuable by themselves. I also have no objection to fixing the exdentation. Thanks John; I'll push the update to use the snippet tag as-is and leave further refinements to future work. ------------- PR: https://git.openjdk.org/jdk/pull/9385 From almatvee at openjdk.org Thu Jul 7 07:27:56 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 7 Jul 2022 07:27:56 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] In-Reply-To: References: Message-ID: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be signed. > - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. > > Added additional test to validate signature when DMG or PKG is generated from predefined app image. Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8289030 - 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] - 8289030: [macos] app image signature invalid when creating DMG or PKG ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/89/files - new: https://git.openjdk.org/jdk19/pull/89/files/5e47a1e3..4d5d4bce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=00-01 Stats: 1986 lines in 64 files changed: 1671 ins; 95 del; 220 mod Patch: https://git.openjdk.org/jdk19/pull/89.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/89/head:pull/89 PR: https://git.openjdk.org/jdk19/pull/89 From duke at openjdk.org Wed Jul 6 21:28:07 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 6 Jul 2022 21:28:07 GMT Subject: RFR: 8249834: Marked Bug8146568 and Bug8148174 as manual tests. Message-ID: Tests Bug8146568 and Bug8148174 were disabled for high memory consumption, over 17G. This is a task to re-enable these two tests by marking them as manual tests. ------------- Commit messages: - Marked Bug8146568 and Bug8148174 as manual tests. Changes: https://git.openjdk.org/jdk/pull/9404/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9404&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8249834 Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9404.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9404/head:pull/9404 PR: https://git.openjdk.org/jdk/pull/9404 From duke at openjdk.org Thu Jul 7 07:37:44 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 7 Jul 2022 07:37:44 GMT Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5] In-Reply-To: References: Message-ID: On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote: >> Implementation of JDK-8279283 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed missing BufferedInputStream src/java.base/share/classes/java/io/BufferedInputStream.java line 495: > 493: int avail = count - pos; > 494: if (avail > 0) { > 495: out.write(buf, pos, avail); I think `buf` should not be accessed directly but via `getBufIfOpen()` because we need to throw IOE in case `this` is closed. ------------- PR: https://git.openjdk.org/jdk/pull/6935 From mcimadamore at openjdk.org Wed Jul 6 21:50:39 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 21:50:39 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v5] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 18:01:28 GMT, Maurizio Cimadamore wrote: >> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' into memory_session_cleanup > - Fix ambiguity between session vs. base session > - Revert implicit vs. heap session changes > - Unify heap vs. implicit scopes > - Merge branch 'master' into memory_session_cleanup > - Fix issue in Direct-X-Buffer template > - Simplify and drop the state class > - Add missing files > - Initial push I've fixed the issues in the review comments, and further reduced the differences between the contents of this patch and mainline (while retaining the improvements). ------------- PR: https://git.openjdk.org/jdk19/pull/22 From smarks at openjdk.org Wed Jul 6 23:03:42 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 6 Jul 2022 23:03:42 GMT Subject: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses [v2] In-Reply-To: References: Message-ID: > Simple javadoc fix of an editorial nature. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Reflow and adjust whitespace per Alan's & Iris' comments. ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/111/files - new: https://git.openjdk.org/jdk19/pull/111/files/8902f466..a3fbdb5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=111&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=111&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk19/pull/111.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/111/head:pull/111 PR: https://git.openjdk.org/jdk19/pull/111 From almatvee at openjdk.org Thu Jul 7 00:16:43 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 7 Jul 2022 00:16:43 GMT Subject: RFR: 8288838: jpackage: file association additional arguments [v4] In-Reply-To: References: Message-ID: <2vFSmdz9mmLtzjmgJd1-VO5NI54PyPpMWmnWN9H_D5w=.6fc775d5-b8c2-43cd-8a4d-57e744b24a37@github.com> On Mon, 4 Jul 2022 23:38:08 GMT, Alex Kasko wrote: >> jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. >> >> It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. >> >> Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: >> >> - option naming inside a properties file, currently `pass-all-args` is used >> - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group >> - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination >> - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` >> >> Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. >> >> Testing: >> >> - [x] test to cover new logic is included >> - [x] ran jtreg:jdk/tools/jpackage with no new failures > > Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - enable passing args, add test coverage > - Added input params validation > - Proposed test changes to make FA testing of jpackage more flexible Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9224 From smarks at openjdk.org Thu Jul 7 00:34:45 2022 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 7 Jul 2022 00:34:45 GMT Subject: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17] In-Reply-To: References: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com> Message-ID: On Wed, 1 Jun 2022 16:45:35 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> do it as naotoj said > > 'the new' fix should be applied to newHashMap etc. too. @liach > 'the new' fix should be applied to newHashMap etc. too. I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it. ------------- PR: https://git.openjdk.org/jdk/pull/8302 From alanb at openjdk.org Thu Jul 7 09:50:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Jul 2022 09:50:39 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com> On Wed, 6 Jul 2022 16:18:08 GMT, Ichiroh Takiguchi wrote: > Discussions are available on : > [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets Yes, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets. I understand they can be useful for someone using JDBC to connect to a database on z/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path. Do you know if the icu4j project is still alive? I've often wondered why there wasn't more use of the provider mechanism. ------------- PR: https://git.openjdk.org/jdk/pull/9399 From mcimadamore at openjdk.org Wed Jul 6 17:16:56 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 17:16:56 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v4] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 17:07:37 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert implicit vs. heap session changes > > src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java line 172: > >> 170: >> 171: public Builder(MemorySession session) { >> 172: ((MemorySessionImpl)session).checkValidState(); > > Or here, if the memory session is a non-closeable view. I believe there was a wrong renaming with the IDE here, I will fix this ------------- PR: https://git.openjdk.org/jdk19/pull/22 From alanb at openjdk.org Wed Jul 6 06:26:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Jul 2022 06:26:40 GMT Subject: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 00:32:00 GMT, Stuart Marks wrote: > Simple javadoc fix of an editorial nature. src/java.base/share/classes/java/util/Map.java line 745: > 743: * (optional) > 744: * @throws NullPointerException if the specified function is null, or if a replacement value is null > 745: * and this map does not permit null values This looks okay although I'd probably reflow L744-745 to avoid to keep the line lengths somewhat consistent with the other exceptions. ------------- PR: https://git.openjdk.org/jdk19/pull/111 From duke at openjdk.org Wed Jul 6 06:49:16 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Wed, 6 Jul 2022 06:49:16 GMT Subject: RFR: 8289797: [TESTBUG]tools/launcher/I18NArgTest.java fails on Japanese Windows enviromnent Message-ID: I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification. This behavior is added in JDK-8170832, which add JAVA_OPTIONS?environment variable. At this time, this test is mismatch with the specification. I tried to test and get Passed on Japanese Windows environment. Could you review this fix, please? ------------- Commit messages: - 8289797: [TESTBUG]tools/launcher/I18NArgTest.java fails on Japanese Windows enviromnent Changes: https://git.openjdk.org/jdk/pull/9389/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9389&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289797 Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9389.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9389/head:pull/9389 PR: https://git.openjdk.org/jdk/pull/9389 From jrose at openjdk.org Wed Jul 6 20:52:31 2022 From: jrose at openjdk.org (John R Rose) Date: Wed, 6 Jul 2022 20:52:31 GMT Subject: RFR: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 22:22:46 GMT, Joe Darcy wrote: > Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles} to use snippets rather than the older markup idiom. The code examples in these files were exdented to make it easier to extract example code and test it, and to maintain equivalence during active development of the APIs. The examples in runnable form are in test/jdk/java/lang/invoke/JavaDocExamplesTest.java in the same repo. It would be nice if some day we could tie together the two copies into one using a link. I don't recall whether snippets can do this or not, given that the two copies are far apart in the repo structure. I agree that just the bracket changes are valuable by themselves. I also have no objection to fixing the exdentation. ------------- Marked as reviewed by jrose (Reviewer). PR: https://git.openjdk.org/jdk/pull/9385 From mcimadamore at openjdk.org Wed Jul 6 17:11:44 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 17:11:44 GMT Subject: [jdk19] RFR: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 11:09:33 GMT, Jorn Vernee wrote: >> This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. >> >> Testing: local run of the `jdk_foreign` test suite. > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Add javadoc > - Revert "Throw IAE when converting string with null byte." > > This reverts commit 70f83902a38e863b96fedb312982f7ac683ed068. Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk19/pull/107 From naoto at openjdk.org Wed Jul 6 19:46:33 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 6 Jul 2022 19:46:33 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From iris at openjdk.org Wed Jul 6 23:38:29 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 6 Jul 2022 23:38:29 GMT Subject: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 23:03:42 GMT, Stuart Marks wrote: >> Simple javadoc fix of an editorial nature. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Reflow and adjust whitespace per Alan's & Iris' comments. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/111 From darcy at openjdk.org Wed Jul 6 17:03:43 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 6 Jul 2022 17:03:43 GMT Subject: RFR: JDK-8289775: Update java.lang.invoke.MethodHandle[s] to use snippets In-Reply-To: <6N5NFb_1R5x4IxrbVaDQ9EHZE-y30d6RyM3YsGr-ntg=.5f4decee-9e6e-4fab-b848-a5dd6ff1f627@github.com> References: <6N5NFb_1R5x4IxrbVaDQ9EHZE-y30d6RyM3YsGr-ntg=.5f4decee-9e6e-4fab-b848-a5dd6ff1f627@github.com> Message-ID: On Wed, 6 Jul 2022 00:08:04 GMT, liach wrote: >> Update existing examples in java.lang.invoke.{MethodHandle, MethodHandles} to use snippets rather than the older markup idiom. > > src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 272: > >> 270: * Here are some examples of usage: >> 271: * {@snippet lang="java" : >> 272: Object x, y; String s; int i; > > These lines can now be properly indented, and they should be. That isn't an unreasonable suggestion. However, I wanted to present this change in an easy-to-review fashion so limited the diffs to the bracketing tags. ------------- PR: https://git.openjdk.org/jdk/pull/9385 From asotona at openjdk.org Thu Jul 7 09:11:43 2022 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 7 Jul 2022 09:11:43 GMT Subject: RFR: JDK-8289106: Add model of class file versions to core reflection [v2] In-Reply-To: References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> Message-ID: <-JsUDOucs32gCWW3ijKYxe6WZ8ofpfPxmxkW0B8hbeY=.91d4d5b2-7a9d-45ed-a81c-7fe29fad4252@github.com> On Wed, 29 Jun 2022 21:32:29 GMT, Joe Darcy wrote: >> JDK-8289106: Add model of class file versions to core reflection > > Joe Darcy 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 10 additional commits since the last revision: > > - Add method to map from major class file version. > - Merge branch 'master' into JDK-8289106 > - Update phrasing. > - Augment and correct docs. > - Correct major versions; RELEASE_0 and RELEASE_1 are both 45. > - Make major method public. > - Add AccessFlag.locations(ClassFileFormatVersion) > - Add ClassFileFormatVersion <-> Runtime.Version conversions. > - Merge branch 'master' into JDK-8289106 > - JDK-8289106: Add model of class file versions to core reflection I like the proposed concept and Classfile Processing API is definitely one of the potential consumers. ------------- PR: https://git.openjdk.org/jdk/pull/9299 From mcimadamore at openjdk.org Thu Jul 7 09:04:49 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 7 Jul 2022 09:04:49 GMT Subject: [jdk19] RFR: 8289223: Canonicalize header ids in foreign API javadocs In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 16:44:17 GMT, Jorn Vernee wrote: > https://github.com/openjdk/jdk/pull/8817 added a button to copy a link to a section of javadoc to the clipboard. For the copy button to appear, the header needs to have an `id`. > > This cleanup PR canonicalizes all header ids in the java.lang.foreign package to the preferred (non-legacy) style, and adds ids in places where they are missing as well. > > In accordance with the Late-Enhancement Request Process [1], this is a `noreg-doc` documentation only change, which does not require an enhancement request. > > [1]: https://openjdk.org/jeps/3#Late-Enhancement-Request-Process Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk19/pull/75 From mcimadamore at openjdk.org Thu Jul 7 09:12:41 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 7 Jul 2022 09:12:41 GMT Subject: [jdk19] Integrated: 8289558: Need spec clarification of j.l.foreign.*Layout In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 11:03:23 GMT, Maurizio Cimadamore wrote: > This patch fixes few javadoc issues in the memory layout API. > The main issues are that `SequenceLayout::flatten` and `SequenceLayout::reshape` still mention failures caused by a lack of size. But that condition is no longer possible in the new API. > > The javadoc of `ValueLayout::arrayElementVarHandle` is suboptimal and can be clarified - UOE is only thrown if the value layout alignment is bigger than its size. > > Finally, the `MemoryLayout::equals` method does not mention value layout carriers. > > The JBS issue associated with this PR mentions also other issues, mostly related to the overly broad visibility of some of the methods in the javadoc (e.g. isPadding). Unfortunately, given the presence of an intermediate, non-public, abstract class, this is what we get from javadoc. Fixing these issues would require a deeper restructuring of the implementation, which would be too riskt at this stage. This pull request has now been integrated. Changeset: 889150b4 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk19/commit/889150b47a7a33d302c1883320d2cfbb915c52e7 Stats: 48 lines in 5 files changed: 14 ins; 11 del; 23 mod 8289558: Need spec clarification of j.l.foreign.*Layout Reviewed-by: psandoz, jvernee ------------- PR: https://git.openjdk.org/jdk19/pull/98 From prappo at openjdk.org Thu Jul 7 12:06:51 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 7 Jul 2022 12:06:51 GMT Subject: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 23:03:42 GMT, Stuart Marks wrote: >> Simple javadoc fix of an editorial nature. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Reflow and adjust whitespace per Alan's & Iris' comments. Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/111 From alanb at openjdk.org Thu Jul 7 13:44:55 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Jul 2022 13:44:55 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v14] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Thu, 30 Jun 2022 16:41:36 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Fix @since version This PR has been open and in development for a long time. One question is whether Arrays.sort has reached its "complexity budget". Right now, and before the addition of radix sort, there are cases where it will do insertion, counting, or heap sorts. Laurent has provided a good set of results to support the case for using radix for random data but it does beg the question on whether Array.sort really needs to try to be optimal for all cases, esp. as there are 4 implementations of each for int, long, float and double elements. Another question is whether the space/performance of tradeoff of using radix sort is too much of a change for Arrays.sort. If I read it correctly then it may allocate up to 1/128 of the heap but I can't immediately see the implications for parallel sort and whether the % of the heap used may be several allocations to up this size (it looks like it is only done on the non-left parts but I'm not 100% sure yet). I see the OOME handling so it can continue when it's not possible to allocate but it may be that allocating big arrays during sort will cause something else in the system to OOME. So before going any further, I think it would be useful to get input on whether this large change has support or whether there are suggestions for other avenues of exploration before committing to the proposal here. ------------- PR: https://git.openjdk.org/jdk/pull/3938 From duke at openjdk.org Thu Jul 7 15:30:30 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Thu, 7 Jul 2022 15:30:30 GMT Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti wrote: > A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path. These are the improvements over the current implementation: - Much more cases are processed by the fast path. - Most values that will either produce 0 or infinity are detected early in a fast way to avoid expensive computations. - If neither of the above applies, the conversion to `String` and subsequent parsing, as currently done, is replaced by `BigInteger` arithmetic. There's at most one division between `BigInteger`s. Of course, no need for `toString()` nor parsing. - Extensive comments explain all the details. JMH benchmarks show that, on the fast path, the new implementation is on par or way better (>200x for the cases not currently covered). Cases where 0 or infinity are detected early contribute with speedup factors of >200x. `BigInteger` arithmetic contributes with speed factors of 2x-8x on "typical" `BigDecimal`s of precision 18 to 24 and scale 2 to 6. ------------- PR: https://git.openjdk.org/jdk/pull/9410 From duke at openjdk.org Thu Jul 7 15:30:30 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Thu, 7 Jul 2022 15:30:30 GMT Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow Message-ID: A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path. ------------- Commit messages: - 8205592: BigDecimal.doubleValue() is depressingly slow Changes: https://git.openjdk.org/jdk/pull/9410/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9410&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8205592 Stats: 585 lines in 2 files changed: 545 ins; 8 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/9410.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9410/head:pull/9410 PR: https://git.openjdk.org/jdk/pull/9410 From joehw at openjdk.org Thu Jul 7 19:10:45 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 7 Jul 2022 19:10:45 GMT Subject: [jdk19] Integrated: 8289486: Improve XSLT XPath operators count efficiency In-Reply-To: References: Message-ID: <3JLCyhroHQAFVxKc7S5pspCpVK3Dfe2GXz1X8vhOnUw=.f3712aa4-dcc4-435f-babc-5d0ff279399a@github.com> On Fri, 1 Jul 2022 17:04:10 GMT, Joe Wang wrote: > To improve efficiency, this patch moves the limit check to within the Lexer and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole error-report block was changed, the actual change was only placing the block to within the isOverLimit statement. > > Test: java.xml tests passed. This pull request has now been integrated. Changeset: 3212dc9c Author: Joe Wang URL: https://git.openjdk.org/jdk19/commit/3212dc9c6f3538e1d0bd1809efd5f33ad8b47701 Stats: 59 lines in 2 files changed: 31 ins; 4 del; 24 mod 8289486: Improve XSLT XPath operators count efficiency Reviewed-by: naoto, lancea ------------- PR: https://git.openjdk.org/jdk19/pull/101 From naoto at openjdk.org Thu Jul 7 16:49:45 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 7 Jul 2022 16:49:45 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: <9GfdBeeI_GmXrZrgMxQBnPvPNK09f2E7XhgtrqT6b4I=.6eefa839-68be-4941-8d84-e7c4d81218b0@github.com> On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi wrote: > OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. > |Charset|Mix|SBCS|DBCS| > | -- | -- | -- | -- | > | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | > | Korean | Cp933 | Cp833 | Cp834 | > > But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. > > I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency > |Charset|Mix|SBCS|DBCS| > | ------------- | ------------- | ------------- | ------------- | > | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | > | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | > | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | > > *1: Cp037 compatible I second Alan's comment here. I am not sure we could justify those legacy less common EBCDIC charsets making into the `jdk.charsets` module. Instead, utilizing the charset provider mechanism will better fit here to me. ------------- PR: https://git.openjdk.org/jdk/pull/9399 From akasko at openjdk.org Thu Jul 7 16:48:41 2022 From: akasko at openjdk.org (Alex Kasko) Date: Thu, 7 Jul 2022 16:48:41 GMT Subject: Integrated: 8288838: jpackage: file association additional arguments In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 09:30:30 GMT, Alex Kasko wrote: > jpackage implementation of file association on Windows currently passes a selected filename as an only argument to associated executable. > > It is proposed to introduce additional option in file association property file to allow optionally support additional arguments using `%*` batch wildcard. > > Note, current implementation, while fully functional, is only a **DRAFT** one, it is not ready for integration in this form. I would appreciate any guidance on the following points: > > - option naming inside a properties file, currently `pass-all-args` is used > - option naming in a bundler parameter implementation, it is not clear if it should introduce a new group of "file association windows specific options" next to the existing "file association mac specific options" group > - test organization to cover the new option: currently it is included inside `FileAssociationTest` and piggybacks on the existing (and unrelated) `includeDescription` parameter; it is not clear whether it should be done in a separate test and whether to include runs for every parameter combination > - test run implementation: currently arguments are checked when a file with associated extension is invoked from command line; it is not clear whether it would be more appropriate instead to create a desktop shortcut with the same command as a target and to invoke it with `java.awt.Desktop` > > Also please note, that full install/uninstall run is currently enabled in `FileAssociationTest`, it is intended to be used only in a draft code during the development and to be removed (to use the same "install or unpack" logic as other tests) in a final version. > > Testing: > > - [x] test to cover new logic is included > - [x] ran jtreg:jdk/tools/jpackage with no new failures This pull request has now been integrated. Changeset: a694e9e3 Author: Alex Kasko Committer: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/a694e9e34d1e4388df200d11b168ca5265cea4ac Stats: 194 lines in 5 files changed: 167 ins; 9 del; 18 mod 8288838: jpackage: file association additional arguments Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/9224 From cjplummer at openjdk.org Thu Jul 7 19:16:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 7 Jul 2022 19:16:48 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Are you going to update copyrights? I reviewed src/jdk.hotspot.agent, src/jdk.jdi/, src/jdk.jdwp.agent, and src/jdk.management. Looks good other than copyrights and the suggestion I made for additional cleanup in symtab.c. src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308: > 306: ELF_SHDR* shbuf = NULL; > 307: ELF_SHDR* cursct = NULL; > 308: ELF_PHDR* phbuf = NULL; phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From asemenyuk at openjdk.org Thu Jul 7 17:17:09 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 7 Jul 2022 17:17:09 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 07:27:56 GMT, Alexander Matveev wrote: >> Fixed 3 issues which made signature invalid: >> - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. >> - .package should be created when app image is generated, so this file can be signed. >> - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. >> >> Added additional test to validate signature when DMG or PKG is generated from predefined app image. > > Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8289030 > - 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] > - 8289030: [macos] app image signature invalid when creating DMG or PKG Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 171: > 169: Files.deleteIfExists(AppImageFile.getPathInAppImage(appDir)); > 170: } > 171: I think there is no need to modify AbstractAppImageBuilder.java, and AppImageBundler.java. It is sufficient to modify the condition controlling the creation of `.package` file: if (predefinedImage == null || (!StandardBundlerParam.isRuntimeInstaller(params) && !AppImageFile.load(predefinedImage).isSigned())) { new PackageFile(APP_NAME.fetchFrom(params)).save( ApplicationLayout.macAppImage().resolveAt(appDir)); Files.deleteIfExists(AppImageFile.getPathInAppImage(appDir)); } Besides `.package` file logically doesn't belong to app image, it belongs to the installed application, so it must not be referenced from the classes creating app images. test/jdk/tools/jpackage/macosx/SigningPackageTwoStepTest.java line 87: > 85: private static void verifyAppImageInDMG(JPackageCommand cmd) { > 86: MacHelper.withExplodedDmg(cmd, dmgImage -> { > 87: Path launcherPath = dmgImage.resolve(Path.of("Contents", "MacOS", cmd.name())); I'd replace it with `ApplicationLayout.macAppImage().resolveAt(dmgImage).launchersDirectory(cmd.name())` ------------- PR: https://git.openjdk.org/jdk19/pull/89 From asemenyuk at openjdk.org Thu Jul 7 19:56:46 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 7 Jul 2022 19:56:46 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 19:30:07 GMT, Alexander Matveev wrote: >> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 171: >> >>> 169: Files.deleteIfExists(AppImageFile.getPathInAppImage(appDir)); >>> 170: } >>> 171: >> >> I think there is no need to modify AbstractAppImageBuilder.java, and AppImageBundler.java. >> It is sufficient to modify the condition controlling the creation of `.package` file: >> >> if (predefinedImage == null || (!StandardBundlerParam.isRuntimeInstaller(params) && !AppImageFile.load(predefinedImage).isSigned())) { >> new PackageFile(APP_NAME.fetchFrom(params)).save( >> ApplicationLayout.macAppImage().resolveAt(appDir)); >> Files.deleteIfExists(AppImageFile.getPathInAppImage(appDir)); >> } >> >> Besides `.package` file logically doesn't belong to app image, it belongs to the installed application, so it must not be referenced from the classes creating app images. > > We need to add `.package` file during app image creation, since we need to sign it. With your proposed change we will add `.package` file to already signed app image. Oh, right. Anyways let's keep `.package`-related stuff away from AbstractAppImageBuilder.java, and AppImageBundler.java. I'd move `.package`-related logic from AbstractAppImageBuilder to MacAppImageBuilder and change public MacAppBundler() { setAppImageSupplier(MacAppImageBuilder::new); setParamsValidator(MacAppBundler::doValidate); } to something like this public MacAppBundler() { public MacAppBundler() { setAppImageSupplier(imageOutDir -> { return new MacAppImageBuilder(imageOutDir, isDependentTask()); }); setParamsValidator(MacAppBundler::doValidate); } Need to add `AppImageBundler.sDependentTask()` method and change signature if MacAppImageBuilder ctor from `MacAppImageBuilder(Path imageOutDir)` to `MacAppImageBuilder(Path imageOutDir, boolean withPackageFile)` ------------- PR: https://git.openjdk.org/jdk19/pull/89 From joehw at openjdk.org Thu Jul 7 17:37:48 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 7 Jul 2022 17:37:48 GMT Subject: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency [v2] In-Reply-To: References: Message-ID: > To improve efficiency, this patch moves the limit check to within the Lexer and reports any overlimit situation as soon as it happens. > > Note the change in XPathParser: diff (and also webrevs) showed the whole error-report block was changed, the actual change was only placing the block to within the isOverLimit statement. > > Test: java.xml tests passed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: add comments ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/101/files - new: https://git.openjdk.org/jdk19/pull/101/files/330f86ce..ef9cf7d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=101&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=101&range=00-01 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/101.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/101/head:pull/101 PR: https://git.openjdk.org/jdk19/pull/101 From rriggs at openjdk.org Thu Jul 7 18:48:40 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 7 Jul 2022 18:48:40 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Thu, 7 Jul 2022 10:21:06 GMT, ?????? ??????? wrote: > We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. > > Benchmark results: > > before > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op > StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op > > after > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op > StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op src/java.base/share/classes/java/lang/String.java line 1429: > 1427: */ > 1428: public String(byte[] bytes, int offset, int length) { > 1429: this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length)); Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset. this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset()); or call `Preconditions.checkFromIndexSize` directly. ------------- PR: https://git.openjdk.org/jdk/pull/9407 From smarks at openjdk.org Thu Jul 7 16:57:16 2022 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 7 Jul 2022 16:57:16 GMT Subject: [jdk19] Integrated: 8289779: Map::replaceAll javadoc has redundant @throws clauses In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 00:32:00 GMT, Stuart Marks wrote: > Simple javadoc fix of an editorial nature. This pull request has now been integrated. Changeset: a8eb7286 Author: Stuart Marks URL: https://git.openjdk.org/jdk19/commit/a8eb728680529e81bea0584912dead394c35b040 Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod 8289779: Map::replaceAll javadoc has redundant @throws clauses Reviewed-by: prappo, iris ------------- PR: https://git.openjdk.org/jdk19/pull/111 From duke at openjdk.org Thu Jul 7 15:48:52 2022 From: duke at openjdk.org (iaroslavski) Date: Thu, 7 Jul 2022 15:48:52 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v14] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Thu, 7 Jul 2022 13:41:17 GMT, Alan Bateman wrote: >> iaroslavski has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) >> >> * Fix @since version > > This PR has been open and in development for a long time. > > One question is whether Arrays.sort has reached its "complexity budget". Right now, and before the addition of radix sort, there are cases where it will do insertion, counting, or heap sorts. Laurent has provided a good set of results to support the case for using radix for random data but it does beg the question on whether Arrays.sort really needs to try to be optimal for all cases, esp. as there are 4 implementations of each for int, long, float and double elements. > > Another question is whether the space/performance tradeoff of using radix sort is too much of a change for Arrays.sort. If I read it correctly then it may allocate up to 1/128 of the heap but I can't immediately see the implications for parallel sort and whether the % of the heap used may be several allocations to up this size (it looks like it is only done on the non-left parts but I'm not 100% sure yet). I see the OOME handling so it can continue when it's not possible to allocate but it may be that allocating big arrays during sort will cause something else in the system to OOME. > > So before going any further, I think it would be useful to get input on whether this large change has support or whether there are suggestions for other avenues of exploration before committing to the proposal here. @AlanBateman, I agree that current Arrays.sort() is not simple as it was in JDK 6 with classical Quicksort and insertion sort only. Quicksort (Dual-Pivot Quicksort) works faster than other algorithms but, unfortunately, not on all types of data. For example, if we process sorted or almost sorted data, the winner is merging sort which takes into account already sorted sub-sequences. It is 2-5 times faster, and this advantage can't be ignored. We have heap sort in our "zoo". Many years ago I had discussion with one of the participants of an programming competition. The goal of such competition is to write code which solves given tasks as quickly as possible. The problem was that their code on specific data showed quadratic time because of Quicksort from Arrays.sort(). Therefore, heap sort was added to guarantee n*log(n) complexity on any data. For small-ranged values, like char, short and byte, counting sort works much faster, and it was added also. Another case is computers with many processors, where parallel merge sort is much faster. Of course, we can stay with few algorithms only, but JDK, as world class software, must have perfect implementation. Last step is to add Radix sort which works 5-8 times faster than Quicksort (on 1m elements), and this fact can't be ignored as well. There were several suggestions to introduce Radix sort as a good algorithm for digits here. I can say that each algorithm is on own place and plays key role. Need to add that this PR contains not Radix sort only, but significant improvements of parallel sorting, insertion sorts and merging sort. The fastest implementation of Radix sort is LSD (Least Significant Digit) variant with additional buffer. Our current implementation of sorting also uses additional buffer for merging sort and parallel sort. So, additional buffer is not new. If we try to sort huge array with limited memory now, we get OOME and sorting will not be completed correctly. Suggested PR solves this problem: we switch to in-place algorithms and sorting will not fail. We set max limit for additional buffer, it is applied for all sorts (parallel, merging, radix). Also additional buffer will be reused by merging and radix sort in case of parallel sorting. It means we don't request multiple buffers (#threads * size) at the same time. In few words, current PR doesn't make Arrays.sort() more complicated, but improves performance and memory allocation. ------------- PR: https://git.openjdk.org/jdk/pull/3938 From rriggs at openjdk.org Thu Jul 7 19:17:29 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 7 Jul 2022 19:17:29 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline Message-ID: The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. The process calling `pipelineStart()` is creating the pipes between the stages. As each process is launched, the file descriptor is inherited by the child process and the child process `dup`s them to the respective stdin/stdout/stderr fd. These copies of inherited file descriptors are handled correctly. Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. The fix is to close the fd after it has been used as the input of the next process. A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. ------------- Commit messages: - 8289643: File descriptor leak with ProcessBuilder.startPipeline Changes: https://git.openjdk.org/jdk/pull/9414/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289643 Stats: 144 lines in 2 files changed: 144 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9414/head:pull/9414 PR: https://git.openjdk.org/jdk/pull/9414 From duke at openjdk.org Thu Jul 7 15:58:33 2022 From: duke at openjdk.org (iaroslavski) Date: Thu, 7 Jul 2022 15:58:33 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v15] In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort iaroslavski has updated the pull request incrementally with one additional commit since the last revision: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) * Added JMH ------------- Changes: - all: https://git.openjdk.org/jdk/pull/3938/files - new: https://git.openjdk.org/jdk/pull/3938/files/1cb6fd7a..618bdb5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=13-14 Stats: 584 lines in 3 files changed: 583 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.org/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.org/jdk/pull/3938 From lbourges at openjdk.org Thu Jul 7 17:52:54 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Thu, 7 Jul 2022 17:52:54 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v15] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Thu, 7 Jul 2022 15:58:33 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Added JMH Thanks vladimir, your comment and test look good , even if I would not trust results for size < 200... @AlanBateman If needed, a new system.property or flag could be added to disable heap-allocation or adjust the max heap ratio (1/128) as it may depend on use cases. To insist, current jdk's Array.sort() does not have any heap limit (merge sort only) so this PR is a great achievement to reduce memory footprint compared to the current situation. 1/128th seemed to me a good upper limit as my compromise on speed vs memory, please propose any more conservative or appropriate threshold. Laurent ------------- PR: https://git.openjdk.org/jdk/pull/3938 From duke at openjdk.org Thu Jul 7 16:04:47 2022 From: duke at openjdk.org (iaroslavski) Date: Thu, 7 Jul 2022 16:04:47 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v14] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: On Wed, 6 Jul 2022 08:49:45 GMT, ?????? ??????? wrote: >> iaroslavski has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) >> >> * Fix @since version > > I mean adding benchmarks into `micro.org.openjdk.bench` @stsypanov I added JMH test, see class org.openjdk.bench.java.util,ArraysSort.java I performed benchmarking and compared current version from JDK and new implementation, results as well as sources can be found here https://github.com/iaroslavski/sorting/tree/master/micro/result New version shows better performance. Please, let me know if you have questions / comments. ------------- PR: https://git.openjdk.org/jdk/pull/3938 From lancea at openjdk.org Thu Jul 7 17:37:49 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 7 Jul 2022 17:37:49 GMT Subject: [jdk19] RFR: 8289486: Improve XSLT XPath operators count efficiency [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 17:32:45 GMT, Joe Wang wrote: >> To improve efficiency, this patch moves the limit check to within the Lexer and reports any overlimit situation as soon as it happens. >> >> Note the change in XPathParser: diff (and also webrevs) showed the whole error-report block was changed, the actual change was only placing the block to within the isOverLimit statement. >> >> Test: java.xml tests passed. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > add comments Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/101 From almatvee at openjdk.org Thu Jul 7 19:33:55 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 7 Jul 2022 19:33:55 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 17:07:51 GMT, Alexey Semenyuk wrote: >> Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8289030 >> - 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] >> - 8289030: [macos] app image signature invalid when creating DMG or PKG > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 171: > >> 169: Files.deleteIfExists(AppImageFile.getPathInAppImage(appDir)); >> 170: } >> 171: > > I think there is no need to modify AbstractAppImageBuilder.java, and AppImageBundler.java. > It is sufficient to modify the condition controlling the creation of `.package` file: > > if (predefinedImage == null || (!StandardBundlerParam.isRuntimeInstaller(params) && !AppImageFile.load(predefinedImage).isSigned())) { > new PackageFile(APP_NAME.fetchFrom(params)).save( > ApplicationLayout.macAppImage().resolveAt(appDir)); > Files.deleteIfExists(AppImageFile.getPathInAppImage(appDir)); > } > > Besides `.package` file logically doesn't belong to app image, it belongs to the installed application, so it must not be referenced from the classes creating app images. We need to add `.package` file during app image creation, since we need to sign it. With your proposed change we will add `.package` file to already signed app image. ------------- PR: https://git.openjdk.org/jdk19/pull/89 From jwilhelm at openjdk.org Fri Jul 8 02:11:29 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Fri, 8 Jul 2022 02:11:29 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:31:27 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 01b9f95c Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/01b9f95c62953e7f9ca10eafd42d21c634413827 Stats: 807 lines in 28 files changed: 669 ins; 52 del; 86 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9419 From ecki at zusammenkunft.net Thu Jul 7 23:16:10 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 7 Jul 2022 23:16:10 +0000 Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com> References: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com> Message-ID: And also there is no reason why db drivers or host connectors should not ship their own charset support (Oracle JDBC for example had nls_charset addons. My employer also ship a custom EBCDIC encoding which includes some compatibility hacks, and that took some effort to adopt it to the missing ext mechanism). Having said that, with JPMS a ?legacy ebcdic? encoding module would be possible while still being optional. Maybe in the future a mechanism for modules which can be added (instead of removed) from standard distribution would make that nicer? Is there a performance restriction for charset if they are not part of a platform module (optimized string access)? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Alan Bateman Gesendet: Thursday, July 7, 2022 11:50:39 AM An: build-dev at openjdk.org ; core-libs-dev at openjdk.org ; i18n-dev at openjdk.org Betreff: Re: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets On Wed, 6 Jul 2022 16:18:08 GMT, Ichiroh Takiguchi wrote: > Discussions are available on : > [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets Yes, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets. I understand they can be useful for someone using JDBC to connect to a database on z/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path. Do you know if the icu4j project is still alive? I've often wondered why there wasn't more use of the provider mechanism. ------------- PR: https://git.openjdk.org/jdk/pull/9399 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Thu Jul 7 22:39:13 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:39:13 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:25:10 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. > > Redirected from https://github.com/openjdk/jdk/pull/9416. This pull request has now been integrated. Changeset: 11319c2a Author: Brian Burkhalter URL: https://git.openjdk.org/jdk19/commit/11319c2aeb16ef2feb0ecab0e2811a52e845739d Stats: 2 lines in 3 files changed: 1 ins; 0 del; 1 mod 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out 8289526: java/nio/channels/FileChannel/MapTest.java times out Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk19/pull/122 From iris at openjdk.org Thu Jul 7 23:34:43 2022 From: iris at openjdk.org (Iris Clark) Date: Thu, 7 Jul 2022 23:34:43 GMT Subject: [jdk19] RFR: 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 06:06:42 GMT, Stuart Marks wrote: > Minor doc wording changes, to be consistent with HashSet.newHashSet et. al. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/118 From dcubed at openjdk.org Thu Jul 7 22:39:12 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 7 Jul 2022 22:39:12 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:25:10 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. > > Redirected from https://github.com/openjdk/jdk/pull/9416. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk19/pull/122 From bpb at openjdk.org Thu Jul 7 20:46:07 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 20:46:07 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. It is conjectured that several tests with large memory demands such as these could be failing due to insufficient memory per core on the test node when the tests are run simultaneously. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From almatvee at openjdk.org Fri Jul 8 00:14:27 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 8 Jul 2022 00:14:27 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3] In-Reply-To: References: Message-ID: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be signed. > - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. > > Added additional test to validate signature when DMG or PKG is generated from predefined app image. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3] ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/89/files - new: https://git.openjdk.org/jdk19/pull/89/files/4d5d4bce..a84c725d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=89&range=01-02 Stats: 37 lines in 7 files changed: 15 ins; 14 del; 8 mod Patch: https://git.openjdk.org/jdk19/pull/89.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/89/head:pull/89 PR: https://git.openjdk.org/jdk19/pull/89 From jwilhelm at openjdk.org Thu Jul 7 22:29:42 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 7 Jul 2022 22:29:42 GMT Subject: Withdrawn: Merge jdk19 In-Reply-To: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com> References: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com> Message-ID: On Thu, 7 Jul 2022 20:14:12 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9415 From bpb at openjdk.org Thu Jul 7 22:39:12 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:39:12 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out Message-ID: Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. Redirected from https://github.com/openjdk/jdk/pull/9416. ------------- Commit messages: - 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out Changes: https://git.openjdk.org/jdk19/pull/122/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=122&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278469 Stats: 2 lines in 3 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/122.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/122/head:pull/122 PR: https://git.openjdk.org/jdk19/pull/122 From bpb at openjdk.org Thu Jul 7 20:46:06 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 20:46:06 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out Message-ID: Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. ------------- Commit messages: - 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out Changes: https://git.openjdk.org/jdk/pull/9416/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9416&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278469 Stats: 2 lines in 3 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9416.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9416/head:pull/9416 PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Thu Jul 7 22:29:38 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:29:38 GMT Subject: Withdrawn: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From coleenp at openjdk.org Thu Jul 7 23:30:25 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 7 Jul 2022 23:30:25 GMT Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox Message-ID: This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at. The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version. Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit. Tested with tiers1-6. ------------- Commit messages: - 8271707: migrate tests to use jdk.test.whitebox.WhiteBox Changes: https://git.openjdk.org/jdk/pull/9417/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9417&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8271707 Stats: 2995 lines in 984 files changed: 6 ins; 0 del; 2989 mod Patch: https://git.openjdk.org/jdk/pull/9417.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9417/head:pull/9417 PR: https://git.openjdk.org/jdk/pull/9417 From almatvee at openjdk.org Fri Jul 8 00:14:29 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 8 Jul 2022 00:14:29 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 17:11:23 GMT, Alexey Semenyuk wrote: >> Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8289030 >> - 8289030: [macos] app image signature invalid when creating DMG or PKG [v2] >> - 8289030: [macos] app image signature invalid when creating DMG or PKG > > test/jdk/tools/jpackage/macosx/SigningPackageTwoStepTest.java line 87: > >> 85: private static void verifyAppImageInDMG(JPackageCommand cmd) { >> 86: MacHelper.withExplodedDmg(cmd, dmgImage -> { >> 87: Path launcherPath = dmgImage.resolve(Path.of("Contents", "MacOS", cmd.name())); > > I'd replace it with `ApplicationLayout.macAppImage().resolveAt(dmgImage).launchersDirectory(cmd.name())` Fixed. ------------- PR: https://git.openjdk.org/jdk19/pull/89 From asemenyuk at openjdk.org Fri Jul 8 00:17:11 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 8 Jul 2022 00:17:11 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 00:14:27 GMT, Alexander Matveev wrote: >> Fixed 3 issues which made signature invalid: >> - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. >> - .package should be created when app image is generated, so this file can be signed. >> - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. >> >> Added additional test to validate signature when DMG or PKG is generated from predefined app image. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8289030: [macos] app image signature invalid when creating DMG or PKG [v3] Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/89 From dcubed at openjdk.org Thu Jul 7 22:07:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 7 Jul 2022 22:07:45 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: <0gPmAVZXUW0z72hLHK55ww6D6WMw_g7EZrhpCmgQZqo=.ae89ee63-1884-400b-9cbc-9b264749ab2f@github.com> On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. Thumbs up. I didn't realize that other test dirs already had the mechanism in place to isolate the resource hogs. I'm looking forward to seeing this in action. I just realized this is targeted at jdk/jdk (JDK20). Can you please close this PR and create a new one for JDK19? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9416 From jwilhelm at openjdk.org Thu Jul 7 22:27:22 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 7 Jul 2022 22:27:22 GMT Subject: RFR: Merge jdk19 [v2] In-Reply-To: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com> References: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com> Message-ID: <2HegrqiJuBLT64CHm3G3bNnBtYc0U07ECeoRV1pKbWA=.3c35644c-6a60-48fe-b0cc-d0e41c0c9ee1@github.com> > Forwardport JDK 19 -> JDK 20 Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision: Fix merge error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9415/files - new: https://git.openjdk.org/jdk/pull/9415/files/0f86db4f..c6949b8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9415&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9415&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9415.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9415/head:pull/9415 PR: https://git.openjdk.org/jdk/pull/9415 From almatvee at openjdk.org Fri Jul 8 00:14:28 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 8 Jul 2022 00:14:28 GMT Subject: [jdk19] RFR: 8289030: [macos] app image signature invalid when creating DMG or PKG [v3] In-Reply-To: References: Message-ID: <9axHDeWNBF32BKzR9hti1LCgKVP4pM3si6wJh-1DnW8=.8609c5d3-f8cb-4bdd-95cc-e8b070216f82@github.com> On Thu, 7 Jul 2022 19:52:57 GMT, Alexey Semenyuk wrote: >> We need to add `.package` file during app image creation, since we need to sign it. With your proposed change we will add `.package` file to already signed app image. > > Oh, right. > Anyways let's keep `.package`-related stuff away from AbstractAppImageBuilder.java, and AppImageBundler.java. > > I'd move `.package`-related logic from AbstractAppImageBuilder to MacAppImageBuilder and change > > public MacAppBundler() { > setAppImageSupplier(MacAppImageBuilder::new); > setParamsValidator(MacAppBundler::doValidate); > } > > to something like this > > public MacAppBundler() { > public MacAppBundler() { > setAppImageSupplier(imageOutDir -> { > return new MacAppImageBuilder(imageOutDir, isDependentTask()); > }); > setParamsValidator(MacAppBundler::doValidate); > } > > > Need to add `AppImageBundler.sDependentTask()` method and change signature if MacAppImageBuilder ctor from `MacAppImageBuilder(Path imageOutDir)` to `MacAppImageBuilder(Path imageOutDir, boolean withPackageFile)` Fixed. ------------- PR: https://git.openjdk.org/jdk19/pull/89 From naoto at openjdk.org Thu Jul 7 23:03:47 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 7 Jul 2022 23:03:47 GMT Subject: [jdk19] RFR: 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 06:06:42 GMT, Stuart Marks wrote: > Minor doc wording changes, to be consistent with HashSet.newHashSet et. al. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/118 From jwilhelm at openjdk.org Thu Jul 7 20:22:53 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 7 Jul 2022 20:22:53 GMT Subject: RFR: Merge jdk19 Message-ID: <-KkCuVSAMiTg4BocRz3OwWxTQ7_0TIjXqqGQ4OicoOg=.c4255a3a-29b0-4fb5-9334-fe694249ad44@github.com> Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge - 8289486: Improve XSLT XPath operators count efficiency - 8289779: Map::replaceAll javadoc has redundant @throws clauses - 8289558: Need spec clarification of j.l.foreign.*Layout - 8289196: Pattern domination not working properly for record patterns - 6509045: {@inheritDoc} only copies one instance of the specified exception - 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing - 8289857: ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java - 8289840: ProblemList vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java when run with vthread wrapper - 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9415&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9415&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9415/files Stats: 803 lines in 28 files changed: 669 ins; 48 del; 86 mod Patch: https://git.openjdk.org/jdk/pull/9415.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9415/head:pull/9415 PR: https://git.openjdk.org/jdk/pull/9415 From jwilhelm at openjdk.org Thu Jul 7 22:40:28 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 7 Jul 2022 22:40:28 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge - 8289486: Improve XSLT XPath operators count efficiency - 8289779: Map::replaceAll javadoc has redundant @throws clauses - 8289558: Need spec clarification of j.l.foreign.*Layout - 8289196: Pattern domination not working properly for record patterns - 6509045: {@inheritDoc} only copies one instance of the specified exception - 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing - 8289857: ProblemList jdk/jfr/event/runtime/TestActiveSettingEvent.java - 8289840: ProblemList vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java when run with vthread wrapper - 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9419&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9419&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9419/files Stats: 807 lines in 28 files changed: 669 ins; 52 del; 86 mod Patch: https://git.openjdk.org/jdk/pull/9419.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9419/head:pull/9419 PR: https://git.openjdk.org/jdk/pull/9419 From bpb at openjdk.org Thu Jul 7 22:39:12 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:39:12 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:25:10 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. > > Redirected from https://github.com/openjdk/jdk/pull/9416. It is conjectured that several tests with large memory demands such as these could be failing due to insufficient memory per core on the test node when the tests are run simultaneously. ------------- PR: https://git.openjdk.org/jdk19/pull/122 From lmesnik at openjdk.org Fri Jul 8 00:53:43 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 8 Jul 2022 00:53:43 GMT Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore wrote: > This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at. > The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version. > Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit. > Tested with tiers1-6. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9417 From bpb at openjdk.org Thu Jul 7 22:29:35 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:29:35 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. Superseded by https://github.com/openjdk/jdk19/pull/122 ------------- PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Thu Jul 7 22:29:37 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:29:37 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: <0gPmAVZXUW0z72hLHK55ww6D6WMw_g7EZrhpCmgQZqo=.ae89ee63-1884-400b-9cbc-9b264749ab2f@github.com> References: <0gPmAVZXUW0z72hLHK55ww6D6WMw_g7EZrhpCmgQZqo=.ae89ee63-1884-400b-9cbc-9b264749ab2f@github.com> Message-ID: <7mygwAjMURF-MohcFrd-sViGCDTgy01k6uxAWPt8uQM=.ff301290-c7d6-47cd-b95b-33d1304900c1@github.com> On Thu, 7 Jul 2022 22:04:09 GMT, Daniel D. Daugherty wrote: > I just realized this is targeted at jdk/jdk (JDK20). Can you please close this PR and create a new one for JDK19? Done. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From almatvee at openjdk.org Fri Jul 8 00:20:51 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 8 Jul 2022 00:20:51 GMT Subject: [jdk19] Integrated: 8289030: [macos] app image signature invalid when creating DMG or PKG In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 03:03:15 GMT, Alexander Matveev wrote: > Fixed 3 issues which made signature invalid: > - We should not remove .jpackage.xml from signed app image when creating DMG or PKG otherwise it invalidates signature. > - .package should be created when app image is generated, so this file can be signed. > - Copying predefine app image for DMG and PKG should not follow symbolic links, otherwise several files from runtime (COPYRIGHT and LICENSE) will be copied instead of symbolic links being created, since it invalidates signature as well. > > Added additional test to validate signature when DMG or PKG is generated from predefined app image. This pull request has now been integrated. Changeset: 64286074 Author: Alexander Matveev URL: https://git.openjdk.org/jdk19/commit/64286074ba763d4a1e8879d8af69eee34d32cfa6 Stats: 221 lines in 14 files changed: 194 ins; 6 del; 21 mod 8289030: [macos] app image signature invalid when creating DMG or PKG Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk19/pull/89 From alanb at openjdk.org Fri Jul 8 06:35:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 06:35:40 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. Are you sure MapTest needs a lot of memory? It's a unit test and doesn't have anything in its jtreg test description to require a lot of resources. I wonder if it's just the victim. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From cjplummer at openjdk.org Fri Jul 8 07:20:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 8 Jul 2022 07:20:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Fri Jul 8 07:39:46 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 8 Jul 2022 07:39:46 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Thu, 7 Jul 2022 18:45:03 GMT, Roger Riggs wrote: >> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. >> >> Benchmark results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op >> >> after >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op > > src/java.base/share/classes/java/lang/String.java line 1429: > >> 1427: */ >> 1428: public String(byte[] bytes, int offset, int length) { >> 1429: this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length)); > > Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset. > > this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset()); > > or call `Preconditions.checkFromIndexSize` directly. But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I? ------------- PR: https://git.openjdk.org/jdk/pull/9407 From djelinski at openjdk.org Fri Jul 8 07:08:46 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:08:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: - Update copyright - Remove more unused variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9383/files - new: https://git.openjdk.org/jdk/pull/9383/files/b4cd5374..da30ef90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01-02 Stats: 30 lines in 26 files changed: 0 ins; 4 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From alanb at openjdk.org Fri Jul 8 08:03:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 08:03:39 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by alanb (Reviewer). src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 686: > 684: LPCWSTR lpFileName = jlong_to_ptr(pathAddress); > 685: PSECURITY_DESCRIPTOR pSecurityDescriptor = jlong_to_ptr(descAddress); > 686: DWORD lengthNeeded = 0; lengthNeeded, it seems not :-) ------------- PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Fri Jul 8 07:12:44 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:12:44 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: <2_Xy-WrhqelW5xoQnKgSrnb1WSEENT6zlJ4ZRbnJDvo=.0e7b8752-9def-459a-ac6a-1172dbd3d5f7@github.com> On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Copyrights updated. ------------- PR: https://git.openjdk.org/jdk/pull/9383 From alanb at openjdk.org Fri Jul 8 07:35:13 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 07:35:13 GMT Subject: [jdk19] RFR: 8289930: Improve Thread description of inherited AccessControlContext Message-ID: This is javadoc only change. The "Inheritance when creating threads" section in the Thread description lists the things that are inherited when creating a Thread. This includes the somewhat obscure "inherited AccessControlContext" where the first sentence looks like it wants to be a heading. The proposal change is tiny, it stops the first sentence/prefix "Inherited Access Control Context:" and replaces it with the sentence "The captured caller context is the new thread's inherited AccessControlContext". When the legacy SecurityManager is degraded further then I expect this paragraph will be removed. No semantic changes and I think below the radar for needing a csr. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk19/pull/121/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=121&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289930 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk19/pull/121.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/121/head:pull/121 PR: https://git.openjdk.org/jdk19/pull/121 From jpai at openjdk.org Fri Jul 8 11:15:41 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 8 Jul 2022 11:15:41 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:25:10 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. > > Redirected from https://github.com/openjdk/jdk/pull/9416. Hello Brian, should `java/nio/channels/Channels/ReadXBytes.java` be treated similarly to prevent https://bugs.openjdk.org/browse/JDK-8289470? That test uses `-Xmx12G`, so probably would need to be running exclusively? ------------- PR: https://git.openjdk.org/jdk19/pull/122 From duke at openjdk.org Fri Jul 8 13:55:47 2022 From: duke at openjdk.org (XenoAmess) Date: Fri, 8 Jul 2022 13:55:47 GMT Subject: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17] In-Reply-To: References: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com> Message-ID: On Wed, 1 Jun 2022 16:45:35 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> do it as naotoj said > > 'the new' fix should be applied to newHashMap etc. too. > @liach > > > 'the new' fix should be applied to newHashMap etc. too. > > I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it. Sorry for I already forgotten it. ------------- PR: https://git.openjdk.org/jdk/pull/8302 From alanb at openjdk.org Fri Jul 8 13:34:55 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 13:34:55 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 19:08:35 GMT, Roger Riggs wrote: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. src/java.base/share/classes/java/lang/ProcessBuilder.java line 1301: > 1299: if (prevOutput instanceof RedirectPipeImpl redir) { > 1300: // Wrap the fd so it can be closed > 1301: new Process.PipeInputStream(redir.getFd()).close(); It looks unusual to need to create a new input stream to invoke close but I think this is okay here. test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 59: > 57: * @requires (os.family == "linux" & !vm.musl) > 58: * @summary file descriptor leak with ProcessBuilder.startPipeline > 59: * @run testng PipelineLeaksFD I wonder if this test should be /othervm, just in case there are pipes left over from previous tests that could interfere with the list found in /proc. ------------- PR: https://git.openjdk.org/jdk/pull/9414 From jvernee at openjdk.org Fri Jul 8 11:25:56 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 8 Jul 2022 11:25:56 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v6] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 21:50:36 GMT, Maurizio Cimadamore wrote: >> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Turn non-closeable view back into MemorySession impl Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/22 From bpb at openjdk.org Fri Jul 8 15:20:44 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Jul 2022 15:20:44 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: <3cfOXUr2YS6mzQkZLwJhMOb5HStzTbSRxwnch04R8kA=.a8439f5f-c986-4696-9436-bb4cf9edba86@github.com> On Fri, 8 Jul 2022 11:12:26 GMT, Jaikiran Pai wrote: > Hello Brian, should `java/nio/channels/Channels/ReadXBytes.java` be treated similarly to prevent https://bugs.openjdk.org/browse/JDK-8289470? That test uses `-Xmx12G`, so probably would need to be running exclusively? Probably. I had been considering because of this [prior comment](https://github.com/openjdk/jdk19/pull/122#issuecomment-1178864972). ------------- PR: https://git.openjdk.org/jdk19/pull/122 From bpb at openjdk.org Fri Jul 8 15:18:53 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Jul 2022 15:18:53 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> References: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> Message-ID: On Fri, 8 Jul 2022 06:30:53 GMT, Alan Bateman wrote: > Are you sure MapTest needs a lot of memory? It's a unit test and doesn't have anything in its jtreg test description to require a lot of resources. I wonder if it's just the victim. We can see whether they both stop failing regularly after this change and if so move `MapTest` out of the large memory list. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From jpai at openjdk.org Fri Jul 8 13:34:53 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 8 Jul 2022 13:34:53 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline In-Reply-To: References: Message-ID: <-zow6jtPRp6kV5ITtRp0vhXTfR0zH2-4SSkEnQnoueA=.2b7a7512-4fc2-4352-9abe-e9138d36ca7a@github.com> On Thu, 7 Jul 2022 19:08:35 GMT, Roger Riggs wrote: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. Hello Roger, the change looks OK to me. The `ProcessBuilder` file will need a copyright year update. test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 59: > 57: * @requires (os.family == "linux" & !vm.musl) > 58: * @summary file descriptor leak with ProcessBuilder.startPipeline > 59: * @run testng PipelineLeaksFD Should this use `othervm` to avoid any kind of interference while we are counting the file descriptors in this test? test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 101: > 99: > 100: Set pipesAfter = myPipes(); > 101: if (!pipesBefore.equals(pipesAfter)) { Since `myPipes()` can return null, should there be a null check here for `pipesBefore`? ------------- PR: https://git.openjdk.org/jdk/pull/9414 From jpai at openjdk.org Fri Jul 8 12:13:29 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 8 Jul 2022 12:13:29 GMT Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows enviromnent In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 06:40:32 GMT, KIRIYAMA Takuya wrote: > I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification. > This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification. > I tried to test and get Passed on Japanese Windows environment. > Could you review this fix, please? The change looks fine to me since in its current form the usage of `JDK_JAVA_OPTIONS` is incorrect. Having said that and looking at the history of this file, I think, this part of the test was added to check if the `java` launcher would be able to read an environment variable (specifically the `JDK_JAVA_OPTIONS`) whose value was in `MS932` encoding, and pass it along as a correctly encoded String, all the way to the main method of the application. If we remove this section of the test, then we would be skipping that code path completely. Perhaps this part of the test could be modified a bit to let it pass the `JDK_JAVA_OPTIONS` environment variable with a `MS932` encoded value that acts some option to the java launcher, instead of being the argument to the main method? That way, you won't have to specify the main class name in the value of the environment variable. Specifically, something like: diff --git a/test/jdk/tools/launcher/I18NArgTest.java b/test/jdk/tools/launcher/I18NArgTest.java index fa09736da2f..2ba724d6f1d 100644 --- a/test/jdk/tools/launcher/I18NArgTest.java +++ b/test/jdk/tools/launcher/I18NArgTest.java @@ -97,12 +97,17 @@ public class I18NArgTest extends TestHelper { // Test via JDK_JAVA_OPTIONS Map env = new HashMap<>(); - String cmd = "-Dtest.src=" + TEST_SOURCES_DIR.getAbsolutePath() + - " -Dtest.classes=" + TEST_CLASSES_DIR.getAbsolutePath() + - " -cp " + TEST_CLASSES_DIR.getAbsolutePath() + - " I18NArgTest " + unicodeStr + " " + hexValue; - env.put("JDK_JAVA_OPTIONS", cmd); - tr = doExec(env, javaCmd); + String sysPropName = "foo.bar"; + // pass "-Dfoo.bar=" through the JDK_JAVA_OPTIONS environment variable. + // we expect that system property value to be passed along to the main method with the + // correct encoding + String jdkJavaOpts = "-D" + sysPropName + "=" + unicodeStr; + env.put("JDK_JAVA_OPTIONS", jdkJavaOpts); + tr = doExec(env,javaCmd, + "-Dtest.src=" + TEST_SOURCES_DIR.getAbsolutePath(), + "-Dtest.classes=" + TEST_CLASSES_DIR.getAbsolutePath(), + "-cp", TEST_CLASSES_DIR.getAbsolutePath(), + "I18NArgTest", unicodeStr, hexValue, sysPropName); System.out.println(tr.testOutput); if (!tr.isOK()) { System.err.println(tr); @@ -125,5 +130,23 @@ public class I18NArgTest extends TestHelper { "expected:" + expected + " obtained:" + hexValue; throw new RuntimeException(message); } + if (args.length == 3) { + // verify the value of the system property matches the expected value + String sysPropName = args[2]; + String sysPropVal = System.getProperty(sysPropName); + if (sysPropVal == null) { + throw new RuntimeException("Missing system property " + sysPropName); + } + String sysPropHexVal = ""; + for (int i = 0; i < sysPropVal.length(); i++) { + sysPropHexVal = sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i))); + } + System.out.println("System property " + sysPropName + " computed hex value: " + + sysPropHexVal); + if (!sysPropHexVal.equals(expected)) { + throw new RuntimeException("Unexpected value in system property, expected " + + expected + ", but got " + sysPropHexVal); + } + } } } I haven't tested this change, so you might have to experiment with it a bit. What do you think? ------------- PR: https://git.openjdk.org/jdk/pull/9389 From rriggs at openjdk.org Fri Jul 8 14:21:39 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Jul 2022 14:21:39 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 13:27:42 GMT, Alan Bateman wrote: >> The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. >> >> The process calling `pipelineStart()` is creating the pipes between the stages. >> As each process is launched, the file descriptor is inherited by the child process and >> the child process `dup`s them to the respective stdin/stdout/stderr fd. >> These copies of inherited file descriptors are handled correctly. >> >> Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. >> >> However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. >> The fix is to close the fd after it has been used as the input of the next process. >> >> A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. >> The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. >> >> The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. > > test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 59: > >> 57: * @requires (os.family == "linux" & !vm.musl) >> 58: * @summary file descriptor leak with ProcessBuilder.startPipeline >> 59: * @run testng PipelineLeaksFD > > I wonder if this test should be /othervm, just in case there are pipes left over from previous tests that could interfere with the list found in /proc. Agreed ------------- PR: https://git.openjdk.org/jdk/pull/9414 From jvernee at openjdk.org Fri Jul 8 11:21:54 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 8 Jul 2022 11:21:54 GMT Subject: [jdk19] Integrated: 8289223: Canonicalize header ids in foreign API javadocs In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 16:44:17 GMT, Jorn Vernee wrote: > https://github.com/openjdk/jdk/pull/8817 added a button to copy a link to a section of javadoc to the clipboard. For the copy button to appear, the header needs to have an `id`. > > This cleanup PR canonicalizes all header ids in the java.lang.foreign package to the preferred (non-legacy) style, and adds ids in places where they are missing as well. > > In accordance with the Late-Enhancement Request Process [1], this is a `noreg-doc` documentation only change, which does not require an enhancement request. > > [1]: https://openjdk.org/jeps/3#Late-Enhancement-Request-Process This pull request has now been integrated. Changeset: 732f1065 Author: Jorn Vernee URL: https://git.openjdk.org/jdk19/commit/732f1065fe05ae737a716bea92536cb8edc2b6a0 Stats: 22 lines in 7 files changed: 0 ins; 1 del; 21 mod 8289223: Canonicalize header ids in foreign API javadocs Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk19/pull/75 From rriggs at openjdk.org Fri Jul 8 14:07:32 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Jul 2022 14:07:32 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Fri, 8 Jul 2022 07:37:36 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/lang/String.java line 1429: >> >>> 1427: */ >>> 1428: public String(byte[] bytes, int offset, int length) { >>> 1429: this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length)); >> >> Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset. >> >> this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset()); >> >> or call `Preconditions.checkFromIndexSize` directly. > > But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I? The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it. Is there a better way than adding a non-functional argument? The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg. The constructor should be private, it has a very narrow scope of use given the lack of checking its args. It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks; it would have broader applicability then this point fix. I would be interesting to ask the compiler folks if that's a future optimization. These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement. ------------- PR: https://git.openjdk.org/jdk/pull/9407 From dholmes at openjdk.org Fri Jul 8 06:15:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Jul 2022 06:15:42 GMT Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox In-Reply-To: References: Message-ID: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com> On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore wrote: > This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at. > The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version. > Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit. > Tested with tiers1-6. I skimmed the diff and this seems fine. Are we not going to remove the old WhiteBox at the same time? Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9417 From coleenp at openjdk.org Fri Jul 8 12:51:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 8 Jul 2022 12:51:42 GMT Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox In-Reply-To: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com> References: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com> Message-ID: On Fri, 8 Jul 2022 06:12:18 GMT, David Holmes wrote: >> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at. >> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version. >> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit. >> Tested with tiers1-6. > > I skimmed the diff and this seems fine. > > Are we not going to remove the old WhiteBox at the same time? > > Thanks. @dholmes-ora We'll remove it with this patch JDK-8275662 and the other obsolete sun.hotspot test classes which will be easier to look at. Thanks for reviewing. ------------- PR: https://git.openjdk.org/jdk/pull/9417 From djelinski at openjdk.org Fri Jul 8 07:08:50 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:08:50 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> References: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> Message-ID: <5lYmVui3caVoMyThlWMlQP1etBfuLQan6v6OUIBYh_o=.e1d33b03-8791-4462-a9e7-b13287df2aa8@github.com> On Thu, 7 Jul 2022 19:06:52 GMT, Chris Plummer wrote: >> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables >> - Remove unused variables (windows) >> - Remove unused variables (macos) >> - Remove unused variables (linux) > > src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308: > >> 306: ELF_SHDR* shbuf = NULL; >> 307: ELF_SHDR* cursct = NULL; >> 308: ELF_PHDR* phbuf = NULL; > > phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too. Good catch! Also removed similar code from macOS version. ------------- PR: https://git.openjdk.org/jdk/pull/9383 From jvernee at openjdk.org Fri Jul 8 15:24:15 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 8 Jul 2022 15:24:15 GMT Subject: [jdk19] Integrated: 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 In-Reply-To: References: Message-ID: <9Y8mFEfV8NAJlublUi2DvMqSe3i3-M0VdZAbC4M8iBE=.9ba2c805-54c8-4ff0-8b9f-56b585b5f70e@github.com> On Mon, 4 Jul 2022 13:01:34 GMT, Jorn Vernee wrote: > This PR updates the spec and implementation to throw an `IllegalArgumentException` when an attempt is made to convert a Java string containing null characters to a C string. > > Testing: local run of the `jdk_foreign` test suite. This pull request has now been integrated. Changeset: 460d879a Author: Jorn Vernee URL: https://git.openjdk.org/jdk19/commit/460d879a75133fc071802bbc2c742b4232db604e Stats: 11 lines in 2 files changed: 11 ins; 0 del; 0 mod 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 Reviewed-by: psandoz, mcimadamore ------------- PR: https://git.openjdk.org/jdk19/pull/107 From coleenp at openjdk.org Fri Jul 8 15:58:32 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 8 Jul 2022 15:58:32 GMT Subject: Integrated: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox In-Reply-To: References: Message-ID: <7OYMQYFZ2rIDV87GtSdBA2jbeOcjjsCVQq_GWOPfEoU=.846e9278-06ec-4428-83e9-d2a883a04e5f@github.com> On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore wrote: > This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at. > The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version. > Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit. > Tested with tiers1-6. This pull request has now been integrated. Changeset: e7795851 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/e7795851d2e02389e63950fef939084b18ec4bfb Stats: 2994 lines in 984 files changed: 6 ins; 0 del; 2988 mod 8271707: migrate tests to use jdk.test.whitebox.WhiteBox Reviewed-by: lmesnik, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9417 From coleenp at openjdk.org Fri Jul 8 15:58:31 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 8 Jul 2022 15:58:31 GMT Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox In-Reply-To: References: Message-ID: <2mTLTyDQH8b2csvKDlgLMlfVhSm7JJXvFcuNMeqnYO0=.ab170919-9813-40be-a097-43671975d984@github.com> On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore wrote: > This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at. > The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version. > Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit. > Tested with tiers1-6. Thanks Leonid! ------------- PR: https://git.openjdk.org/jdk/pull/9417 From rriggs at openjdk.org Fri Jul 8 16:24:16 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 8 Jul 2022 16:24:16 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v2] In-Reply-To: References: Message-ID: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Cleanup of PipelineLeaksFD test improving error messages and source cleanup. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9414/files - new: https://git.openjdk.org/jdk/pull/9414/files/3b154680..0d628d66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=00-01 Stats: 70 lines in 2 files changed: 16 ins; 21 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/9414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9414/head:pull/9414 PR: https://git.openjdk.org/jdk/pull/9414 From smarks at openjdk.org Fri Jul 8 17:07:45 2022 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 8 Jul 2022 17:07:45 GMT Subject: [jdk19] Integrated: 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 06:06:42 GMT, Stuart Marks wrote: > Minor doc wording changes, to be consistent with HashSet.newHashSet et. al. This pull request has now been integrated. Changeset: eeaf0bba Author: Stuart Marks URL: https://git.openjdk.org/jdk19/commit/eeaf0bbabc6632c181b191854678e72a333ec0a5 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. Reviewed-by: chegar, naoto, iris ------------- PR: https://git.openjdk.org/jdk19/pull/118 From alanb at openjdk.org Fri Jul 8 16:58:29 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 16:58:29 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> Message-ID: On Fri, 8 Jul 2022 15:15:03 GMT, Brian Burkhalter wrote: > We can see whether they both stop failing regularly after this change and if so move `MapTest` out of the large memory list. I suspect it's a victim and shouldn't in the largeMemory directory but let's see if there are issues in the coming days. My preference is to keep the unit tests in the original location and the only tests in largeMemory are the tests that really need a lot of memory. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Fri Jul 8 18:17:44 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Jul 2022 18:17:44 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> Message-ID: On Fri, 8 Jul 2022 16:55:28 GMT, Alan Bateman wrote: > My preference is to keep the unit tests in the original location and the only tests in largeMemory are the tests that really need a lot of memory. Likewise. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From joehw at openjdk.org Fri Jul 8 18:33:10 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 8 Jul 2022 18:33:10 GMT Subject: [jdk19] RFR: 8282071: Update java.xml module-info Message-ID: Update module-info ------------- Commit messages: - 8282071: Update java.xml module-info Changes: https://git.openjdk.org/jdk19/pull/126/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282071 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk19/pull/126.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/126/head:pull/126 PR: https://git.openjdk.org/jdk19/pull/126 From lancea at openjdk.org Fri Jul 8 18:37:49 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 8 Jul 2022 18:37:49 GMT Subject: [jdk19] RFR: 8282071: Update java.xml module-info In-Reply-To: References: Message-ID: <-KO_lvz1bzCYlbovuUDKfwBbOvfJeq-Bop8gavMBCs4=.0314ce18-793a-4103-8e58-8a890bd3ab32@github.com> On Fri, 8 Jul 2022 18:23:05 GMT, Joe Wang wrote: > Update module-info Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/126 From naoto at openjdk.org Fri Jul 8 18:44:51 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 8 Jul 2022 18:44:51 GMT Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows enviromnent In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 06:40:32 GMT, KIRIYAMA Takuya wrote: > I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification. > This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification. > I tried to test and get Passed on Japanese Windows environment. > Could you review this fix, please? I agree with Jai here. It would be desirable to convert the incorrect test to something originally intended, ie., tests whether `JDK_JAVA_OPTIONS` env can correctly handle non-ASCII variables. ------------- PR: https://git.openjdk.org/jdk/pull/9389 From iris at openjdk.org Fri Jul 8 18:45:59 2022 From: iris at openjdk.org (Iris Clark) Date: Fri, 8 Jul 2022 18:45:59 GMT Subject: [jdk19] RFR: 8282071: Update java.xml module-info In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:23:05 GMT, Joe Wang wrote: > Update module-info Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/126 From naoto at openjdk.org Fri Jul 8 18:57:41 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 8 Jul 2022 18:57:41 GMT Subject: [jdk19] RFR: 8282071: Update java.xml module-info In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:23:05 GMT, Joe Wang wrote: > Update module-info Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/126 From duke at openjdk.org Fri Jul 8 19:43:49 2022 From: duke at openjdk.org (Markus KARG) Date: Fri, 8 Jul 2022 19:43:49 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. >> >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. >> >> I encourage everybody to discuss this draft: >> * Are there valid arguments for *not* doing this change? >> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? >> * How to go on from here: What is missing to get this ready for an actual review? > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel Please keep this PR open; I will continune work on it soon. ------------- PR: https://git.openjdk.org/jdk/pull/4263 From joehw at openjdk.org Fri Jul 8 21:38:46 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 8 Jul 2022 21:38:46 GMT Subject: [jdk19] Integrated: 8282071: Update java.xml module-info In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:23:05 GMT, Joe Wang wrote: > Update module-info This pull request has now been integrated. Changeset: c86c51cc Author: Joe Wang URL: https://git.openjdk.org/jdk19/commit/c86c51cc72e3457756434b9150b0c5ef2f5d496d Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8282071: Update java.xml module-info Reviewed-by: lancea, iris, naoto ------------- PR: https://git.openjdk.org/jdk19/pull/126 From coleenp at openjdk.org Fri Jul 8 21:50:12 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 8 Jul 2022 21:50:12 GMT Subject: RFR: 8275662: remove test/lib/sun/hotspot Message-ID: This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox. I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot. Tested with tier1-4. ------------- Commit messages: - 8275662: remove test/lib/sun/hotspot Changes: https://git.openjdk.org/jdk/pull/9434/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9434&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8275662 Stats: 1484 lines in 99 files changed: 0 ins; 1367 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/9434.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9434/head:pull/9434 PR: https://git.openjdk.org/jdk/pull/9434 From mseledtsov at openjdk.org Fri Jul 8 21:50:12 2022 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Fri, 8 Jul 2022 21:50:12 GMT Subject: RFR: 8275662: remove test/lib/sun/hotspot In-Reply-To: References: Message-ID: <-s197KfRIxYZ-QIqR_c48nZlUjed9kTjHTOGOqlVHWg=.a11735f0-9e5b-44f4-907a-c11230540a87@github.com> On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote: > This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox. > I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot. > Tested with tier1-4. Changes look good to me. Thank you. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.org/jdk/pull/9434 From coleenp at openjdk.org Fri Jul 8 21:50:13 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 8 Jul 2022 21:50:13 GMT Subject: RFR: 8275662: remove test/lib/sun/hotspot In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote: > This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox. > I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot. > Tested with tier1-4. Thanks Misha! ------------- PR: https://git.openjdk.org/jdk/pull/9434 From duke at openjdk.org Fri Jul 8 21:53:45 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 8 Jul 2022 21:53:45 GMT Subject: RFR: 8249834: java/util/ArrayList/Bug8146568.java and j/u/Vector/Bug8148174.java use @ignore w/o bug-id [v2] In-Reply-To: References: Message-ID: > Tests Bug8146568 and Bug8148174 were disabled for high memory consumption, over 17G. This is a task to re-enable these two tests by marking them as manual tests. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Added missing backslash in jdk/TEST.groups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9404/files - new: https://git.openjdk.org/jdk/pull/9404/files/d37b084d..fc2d6bb0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9404&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9404&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9404.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9404/head:pull/9404 PR: https://git.openjdk.org/jdk/pull/9404 From duke at openjdk.org Fri Jul 8 21:53:46 2022 From: duke at openjdk.org (crazybones) Date: Fri, 8 Jul 2022 21:53:46 GMT Subject: RFR: 8249834: java/util/ArrayList/Bug8146568.java and j/u/Vector/Bug8148174.java use @ignore w/o bug-id [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:50:40 GMT, Bill Huang wrote: >> Tests Bug8146568 and Bug8148174 were disabled for high memory consumption, over 17G. This is a task to re-enable these two tests by marking them as manual tests. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Added missing backslash in jdk/TEST.groups test/jdk/TEST.groups line 587: > 585: javax/net/ssl/compatibility/HrrTest.java \ > 586: javax/net/ssl/compatibility/SniTest.java \ > 587: jdk/nio/zipfs/TestLocOffsetFromZip64EF.java Shouldn't we add here a backslash at the end of the line? ------------- PR: https://git.openjdk.org/jdk/pull/9404 From duke at openjdk.org Fri Jul 8 21:53:47 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 8 Jul 2022 21:53:47 GMT Subject: RFR: 8249834: java/util/ArrayList/Bug8146568.java and j/u/Vector/Bug8148174.java use @ignore w/o bug-id [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:34:44 GMT, crazybones wrote: >> Bill Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> Added missing backslash in jdk/TEST.groups > > test/jdk/TEST.groups line 587: > >> 585: javax/net/ssl/compatibility/HrrTest.java \ >> 586: javax/net/ssl/compatibility/SniTest.java \ >> 587: jdk/nio/zipfs/TestLocOffsetFromZip64EF.java > > Shouldn't we add here a backslash at the end of the line? Good catch! I will add it back. Thank you for pointing out. ------------- PR: https://git.openjdk.org/jdk/pull/9404 From kbarrett at openjdk.org Fri Jul 8 22:34:39 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Jul 2022 22:34:39 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v2] In-Reply-To: <8PqtiVU2RlQqVGzDQogGefiTnfuELS_5oaIf4j8ccaQ=.fcdafb60-55e0-4c76-b3ab-b0fb4a663a88@github.com> References: <8PqtiVU2RlQqVGzDQogGefiTnfuELS_5oaIf4j8ccaQ=.fcdafb60-55e0-4c76-b3ab-b0fb4a663a88@github.com> Message-ID: <_DTEM2afRyh5tOCzz5N0rI1Hyq_bb5KHkY9XWDN-UMc=.39859518-f4bf-40b9-a27b-93d8dd543064@github.com> On Thu, 7 Jul 2022 08:03:52 GMT, David Holmes wrote: > > I think that isn't true. If a hook doesn't terminate then VM.shutdown doesn't get called, so the window never gets cracked opened to call halt directly. > > @kimbarrett Any thread can call halt() directly while the attempted shutdown is in progress. The "that" I was referring to / disagreeing with is about the window for exit(non-zero), which I think won't ever open if any hook doesn't terminate. ------------- PR: https://git.openjdk.org/jdk/pull/9351 From sspitsyn at openjdk.org Fri Jul 8 22:47:40 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 8 Jul 2022 22:47:40 GMT Subject: RFR: 8275662: remove test/lib/sun/hotspot In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote: > This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox. > I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot. > Tested with tier1-4. This looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9434 From kbarrett at openjdk.org Fri Jul 8 23:18:47 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Jul 2022 23:18:47 GMT Subject: RFR: 8288984: Simplification in java.lang.Runtime::exit [v5] In-Reply-To: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> References: <7isrvwtGBXGFMqHmO8eUXPA5WOJmQU438YXLZLIEkao=.e3145ba3-4140-4697-8c09-9b007c3f9bec@github.com> Message-ID: On Tue, 5 Jul 2022 18:43:26 GMT, Ryan Ernst wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change to Runtime.exit. > > Ryan Ernst 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 branch 'master' into shutdown_cleanup > - iter text > - iterate on wording > - better clarify multiple threads behavior > - 8288984: Simplification in Shutdown.exit > > This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9351 From duke at openjdk.org Sat Jul 9 02:49:40 2022 From: duke at openjdk.org (David Schlosnagle) Date: Sat, 9 Jul 2022 02:49:40 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 16:24:16 GMT, Roger Riggs wrote: >> The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. >> >> The process calling `pipelineStart()` is creating the pipes between the stages. >> As each process is launched, the file descriptor is inherited by the child process and >> the child process `dup`s them to the respective stdin/stdout/stderr fd. >> These copies of inherited file descriptors are handled correctly. >> >> Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. >> >> However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. >> The fix is to close the fd after it has been used as the input of the next process. >> >> A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. >> The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. >> >> The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup of PipelineLeaksFD test improving error messages and source cleanup. test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 130: > 128: }) > 129: .filter(p1 -> p1.link().toString().startsWith("pipe:")) > 130: .collect(Collectors.toSet()); Is this intentionally leaking the returned `DirectoryStream` from `Files.walk` to trigger the previous failure mode or should this be auto-closed (i.e. https://errorprone.info/bugpattern/StreamResourceLeak )? Suggestion: try (Stream s = Files.walk(path)) { return s.filter(Files::isSymbolicLink) .map(p -> { try { return new PipeRecord(p, Files.readSymbolicLink(p)); } catch (IOException ioe) { } return new PipeRecord(p, null); }) .filter(p1 -> p1.link().toString().startsWith("pipe:")) .collect(Collectors.toSet()); } ------------- PR: https://git.openjdk.org/jdk/pull/9414 From lmesnik at openjdk.org Sat Jul 9 03:46:42 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 9 Jul 2022 03:46:42 GMT Subject: RFR: 8275662: remove test/lib/sun/hotspot In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote: > This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox. > I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot. > Tested with tier1-4. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9434 From coderodd3 at gmail.com Sat Jul 9 05:17:00 2022 From: coderodd3 at gmail.com (Rodion Efremov) Date: Sat, 9 Jul 2022 08:17:00 +0300 Subject: JMH results for IndexedLinkedList Message-ID: Data structure repo: https://github.com/coderodde/IndexedLinkedList Benchmark repo: https://github.com/coderodde/IndexedLinkedListBenchmark I have profiled my data structure and it seems it?s more performant than java.util.LinkedList or TreeList, if nothing else. So, is there any chance of including IndexedLinkedList to JDK? Best regards, rodde -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Sat Jul 9 08:19:02 2022 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 9 Jul 2022 10:19:02 +0200 Subject: JMH results for IndexedLinkedList In-Reply-To: References: Message-ID: Hello! Are there real world problems/use cases where IndexedLinkedList would be preferred in terms of CPU/memory usage over ArrayList? ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : > Data structure repo: > https://github.com/coderodde/IndexedLinkedList > > Benchmark repo: > https://github.com/coderodde/IndexedLinkedListBenchmark > > I have profiled my data structure and it seems it?s more performant than > java.util.LinkedList or TreeList, if nothing else. > > So, is there any chance of including IndexedLinkedList to JDK? > > Best regards, > rodde > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coderodd3 at gmail.com Sat Jul 9 09:21:11 2022 From: coderodd3 at gmail.com (Rodion Efremov) Date: Sat, 9 Jul 2022 12:21:11 +0300 Subject: JMH results for IndexedLinkedList In-Reply-To: References: Message-ID: Hello, My benchmarking suggests, that, if nothing else, my IndexedLinkedList outperforms gracefully the java.util.LinkedList, so the use case should be the same (List + Deque -interfaces) for both of the aforementioned data structures. Best regards, rodde On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev wrote: > Hello! > > Are there real world problems/use cases where IndexedLinkedList would be > preferred in terms of CPU/memory usage over ArrayList? > > ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : > >> Data structure repo: >> https://github.com/coderodde/IndexedLinkedList >> >> Benchmark repo: >> https://github.com/coderodde/IndexedLinkedListBenchmark >> >> I have profiled my data structure and it seems it?s more performant than >> java.util.LinkedList or TreeList, if nothing else. >> >> So, is there any chance of including IndexedLinkedList to JDK? >> >> Best regards, >> rodde >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Sat Jul 9 19:33:32 2022 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 9 Jul 2022 21:33:32 +0200 Subject: JMH results for IndexedLinkedList In-Reply-To: References: Message-ID: Note that nobody these days cares about LinkedList. Use-cases where LinkedList outperforms careful use of ArrayList or ArrayDeque are next to none. So saying that your data structure is better than LinkedList is totally not a reason to add it to JDK. It should be better than ArrayList and ArrayDeque. Having a single data structure that provides list and deque interface is a reasonable idea. However it would be much simpler to retrofit existing data structure like ArrayDeque, rather than create a new data structure. Here's an issue for this: https://bugs.openjdk.org/browse/JDK-8143850 There were also discussions to enhance collections in general, adding more useful methods like getFirst() or removeLast() to ArrayList, etc. See for details: https://bugs.openjdk.org/browse/JDK-8266572 To conclude, the idea of adding one more collection implementation looks questionable to me. It will add more confusion when people need to select which collection fits their needs better. It will require more learning. This could be justified if there are clear benefits in using it in real world problems, compared to existing collections. But so far I don't see the examples of such problems. With best regards, Tagir Valeev ??, 9 ???. 2022 ?., 11:22 Rodion Efremov : > Hello, > > My benchmarking suggests, that, if nothing else, my IndexedLinkedList > outperforms gracefully the java.util.LinkedList, so the use case should be > the same (List + Deque -interfaces) for both of the aforementioned > data structures. > > Best regards, > rodde > > > On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev wrote: > >> Hello! >> >> Are there real world problems/use cases where IndexedLinkedList would be >> preferred in terms of CPU/memory usage over ArrayList? >> >> ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : >> >>> Data structure repo: >>> https://github.com/coderodde/IndexedLinkedList >>> >>> Benchmark repo: >>> https://github.com/coderodde/IndexedLinkedListBenchmark >>> >>> I have profiled my data structure and it seems it?s more performant than >>> java.util.LinkedList or TreeList, if nothing else. >>> >>> So, is there any chance of including IndexedLinkedList to JDK? >>> >>> Best regards, >>> rodde >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Sat Jul 9 21:58:49 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 9 Jul 2022 23:58:49 +0200 Subject: JMH results for IndexedLinkedList In-Reply-To: References: Message-ID: <899a1dc6-5326-e2bb-715a-70d7fcda0469@gmail.com> I think there might be room for another List implementation in the JDK, one that fits in between ArrayList and LinkedHashMap. I've been looking for something to manage lists of listeners (which allow arbitrary removal), must be called in order, and should handle duplicates (at their respective positions).? Both ArrayList and LinkedHashMap are close.? LinkedHashMap has quite some overhead (Entry instance per element) and poor cache locality while iterating and doesn't allow duplicates.? ArrayList has poor remove performance. It should offer O(1) performance for add(Last), contains, remove(T) and near O(1) performance for operations that operate near the head/tail of the list (like getFirst, getLast, removeFirst, removeLast).? Iteration performance would be similar to ArrayList.? Basically an ArrayDeque, but with fast contains/remove(T).? The sacrifice made is poor index based access (with the exception of the head/tail). It should be useful as a queue as well that allows quick removal (in order to cancel tasks for example, or to move a task up/down the queue). --John On 09/07/2022 21:33, Tagir Valeev wrote: > Note that nobody these days cares about LinkedList. Use-cases where > LinkedList outperforms careful use of ArrayList or ArrayDeque are next > to none. So saying that your data structure is better than LinkedList > is totally not a reason to add it to JDK. It should be better than > ArrayList and ArrayDeque. > > Having a single data structure that provides list and deque interface > is a reasonable idea. However it would be much simpler to retrofit > existing data structure like ArrayDeque, rather than create a new data > structure. Here's an issue for this: > https://bugs.openjdk.org/browse/JDK-8143850 > > There were also discussions to enhance collections in general, adding > more useful methods like getFirst() or removeLast() to ArrayList, etc. > See for details: > https://bugs.openjdk.org/browse/JDK-8266572 > > To conclude, the idea of adding one more collection implementation > looks questionable to me. It will add more confusion when people need > to select which collection fits their needs better. It will require > more learning. This could be justified if there are clear benefits in > using it in real world problems, compared to existing collections. But > so far I don't see the examples of such problems. > > With best regards, > Tagir Valeev > > ??, 9 ???. 2022 ?., 11:22 Rodion Efremov : > > Hello, > > My benchmarking suggests, that, if nothing else, my > IndexedLinkedList outperforms gracefully the java.util.LinkedList, > so the use case should be the same (List + Deque > -interfaces) for both of the aforementioned data structures. > > Best regards, > rodde > > > On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev > wrote: > > Hello! > > Are there real world problems/use cases where > IndexedLinkedList would be preferred in terms of CPU/memory > usage over ArrayList? > > ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : > > Data structure repo: > https://github.com/coderodde/IndexedLinkedList > > Benchmark repo: > https://github.com/coderodde/IndexedLinkedListBenchmark > > I have profiled my data structure and it seems it?s more > performant than java.util.LinkedList or TreeList, if > nothing else. > > So, is there any chance of including IndexedLinkedList to JDK? > > Best regards, > rodde > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coderodd3 at gmail.com Sun Jul 10 04:31:32 2022 From: coderodd3 at gmail.com (Rodion Efremov) Date: Sun, 10 Jul 2022 07:31:32 +0300 Subject: JMH results for IndexedLinkedList In-Reply-To: References: Message-ID: Hello, I am interested in https://bugs.openjdk.org/browse/JDK-8143850 Is there a way for becoming an assignee for the above issue? If yes, how do I proceed and what is the schedule? Best regards, rodde la 9.7.2022 klo 22.33 Tagir Valeev kirjoitti: > Note that nobody these days cares about LinkedList. Use-cases where > LinkedList outperforms careful use of ArrayList or ArrayDeque are next to > none. So saying that your data structure is better than LinkedList is > totally not a reason to add it to JDK. It should be better than ArrayList > and ArrayDeque. > > Having a single data structure that provides list and deque interface is a > reasonable idea. However it would be much simpler to retrofit existing data > structure like ArrayDeque, rather than create a new data structure. Here's > an issue for this: > https://bugs.openjdk.org/browse/JDK-8143850 > > There were also discussions to enhance collections in general, adding more > useful methods like getFirst() or removeLast() to ArrayList, etc. See for > details: > https://bugs.openjdk.org/browse/JDK-8266572 > > To conclude, the idea of adding one more collection implementation looks > questionable to me. It will add more confusion when people need to select > which collection fits their needs better. It will require more learning. > This could be justified if there are clear benefits in using it in real > world problems, compared to existing collections. But so far I don't see > the examples of such problems. > > With best regards, > Tagir Valeev > > ??, 9 ???. 2022 ?., 11:22 Rodion Efremov : > >> Hello, >> >> My benchmarking suggests, that, if nothing else, my IndexedLinkedList >> outperforms gracefully the java.util.LinkedList, so the use case should be >> the same (List + Deque -interfaces) for both of the aforementioned >> data structures. >> >> Best regards, >> rodde >> >> >> On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev wrote: >> >>> Hello! >>> >>> Are there real world problems/use cases where IndexedLinkedList would be >>> preferred in terms of CPU/memory usage over ArrayList? >>> >>> ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : >>> >>>> Data structure repo: >>>> https://github.com/coderodde/IndexedLinkedList >>>> >>>> Benchmark repo: >>>> https://github.com/coderodde/IndexedLinkedListBenchmark >>>> >>>> I have profiled my data structure and it seems it?s more performant >>>> than java.util.LinkedList or TreeList, if nothing else. >>>> >>>> So, is there any chance of including IndexedLinkedList to JDK? >>>> >>>> Best regards, >>>> rodde >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Sun Jul 10 07:49:50 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 10 Jul 2022 07:49:50 GMT Subject: [jdk19] RFR: 8289930: Improve Thread description of inherited AccessControlContext [v2] In-Reply-To: References: Message-ID: > This is a javadoc only change. The "Inheritance when creating threads" section in the Thread description lists the things that are inherited when creating a Thread. This includes the somewhat obscure "inherited AccessControlContext" where the first sentence looks like it wants to be a heading. The proposed change is tiny: drop the the first sentence/prefix "Inherited Access Control Context:" and adds the sentence "The captured caller context is the new thread's inherited AccessControlContext" later in the paragraph. When the legacy SecurityManager is degraded further then I expect this paragraph will be removed. > > No semantic changes and I think below the radar for needing a csr. 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: - Merge - Tweak javadoc - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/121/files - new: https://git.openjdk.org/jdk19/pull/121/files/68ffdc5b..73045566 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=121&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=121&range=00-01 Stats: 356 lines in 37 files changed: 254 ins; 16 del; 86 mod Patch: https://git.openjdk.org/jdk19/pull/121.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/121/head:pull/121 PR: https://git.openjdk.org/jdk19/pull/121 From lbourges at openjdk.org Sun Jul 10 10:23:09 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 10 Jul 2022 10:23:09 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v15] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: <5_6Tfzs75GqnzF4jscfhvvILa0JGNBfjMCAOfXn6VP8=.6393d760-fe4a-4080-ade0-3139e3123af5@github.com> On Thu, 7 Jul 2022 15:58:33 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Added JMH Here are JMH test results on my stable perf laptop (cpu fixed: 4 real cpu cores at 2ghz, HT disabled, i7 6820k): https://github.com/bourgesl/bourgesl.github.io/blob/master/bench-220709-summary-2.log It confirms Vladimir results: 50% gain in average in parallelSort(), huge gains (x5) on large random arrays... As DPQS relies on ForkJoinPool.getCommonParallelism = 3 on my machine, MT speedup is only x3 ! I observed max 300%/400% cpu load when parallelSort() runs on large arrays... Why does it return NCpuCore - 1 ? ------------- PR: https://git.openjdk.org/jdk/pull/3938 From attila at openjdk.org Sun Jul 10 13:33:51 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 10 Jul 2022 13:33:51 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v3] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Mon, 4 Jul 2022 07:06:30 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time Marked as reviewed by attila (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9208 From duke at openjdk.org Sun Jul 10 14:38:43 2022 From: duke at openjdk.org (xpbob) Date: Sun, 10 Jul 2022 14:38:43 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> References: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> Message-ID: On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman wrote: >> xpbob has updated the pull request incrementally with one additional commit since the last revision: >> >> update header > > It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API? I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management). @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR ------------- PR: https://git.openjdk.org/jdk/pull/9372 From amaembo at gmail.com Sun Jul 10 15:25:55 2022 From: amaembo at gmail.com (Tagir Valeev) Date: Sun, 10 Jul 2022 17:25:55 +0200 Subject: JMH results for IndexedLinkedList In-Reply-To: References: Message-ID: Hello! On Sun, Jul 10, 2022 at 6:33 AM Rodion Efremov wrote: > I am interested in > https://bugs.openjdk.org/browse/JDK-8143850 > > Is there a way for becoming an assignee for the above issue? If yes, how do I proceed and what is the schedule? Stuart Marks might be the right person to ask. Adding to CC. With best regards, Tagir Valeev. > > Best regards, > rodde > > la 9.7.2022 klo 22.33 Tagir Valeev kirjoitti: >> >> Note that nobody these days cares about LinkedList. Use-cases where LinkedList outperforms careful use of ArrayList or ArrayDeque are next to none. So saying that your data structure is better than LinkedList is totally not a reason to add it to JDK. It should be better than ArrayList and ArrayDeque. >> >> Having a single data structure that provides list and deque interface is a reasonable idea. However it would be much simpler to retrofit existing data structure like ArrayDeque, rather than create a new data structure. Here's an issue for this: >> https://bugs.openjdk.org/browse/JDK-8143850 >> >> There were also discussions to enhance collections in general, adding more useful methods like getFirst() or removeLast() to ArrayList, etc. See for details: >> https://bugs.openjdk.org/browse/JDK-8266572 >> >> To conclude, the idea of adding one more collection implementation looks questionable to me. It will add more confusion when people need to select which collection fits their needs better. It will require more learning. This could be justified if there are clear benefits in using it in real world problems, compared to existing collections. But so far I don't see the examples of such problems. >> >> With best regards, >> Tagir Valeev >> >> ??, 9 ???. 2022 ?., 11:22 Rodion Efremov : >>> >>> Hello, >>> >>> My benchmarking suggests, that, if nothing else, my IndexedLinkedList outperforms gracefully the java.util.LinkedList, so the use case should be the same (List + Deque -interfaces) for both of the aforementioned data structures. >>> >>> Best regards, >>> rodde >>> >>> >>> On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev wrote: >>>> >>>> Hello! >>>> >>>> Are there real world problems/use cases where IndexedLinkedList would be preferred in terms of CPU/memory usage over ArrayList? >>>> >>>> ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : >>>>> >>>>> Data structure repo: >>>>> https://github.com/coderodde/IndexedLinkedList >>>>> >>>>> Benchmark repo: >>>>> https://github.com/coderodde/IndexedLinkedListBenchmark >>>>> >>>>> I have profiled my data structure and it seems it?s more performant than java.util.LinkedList or TreeList, if nothing else. >>>>> >>>>> So, is there any chance of including IndexedLinkedList to JDK? >>>>> >>>>> Best regards, >>>>> rodde From pntanasis at gmail.com Sun Jul 10 22:20:27 2022 From: pntanasis at gmail.com (Periklis Ntanasis) Date: Mon, 11 Jul 2022 01:20:27 +0300 Subject: ArrayList grow method optimization and documentation improvement Message-ID: Hi all, I was reading the ArrayList source code and I think that the "private Object[] grow(int minCapacity)" method does not work as it was intended by the author. Currently the method looks like this ( https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ArrayList.java#L224-L241 ): /** * Increases the capacity to ensure that it can hold at least the * number of elements specified by the minimum capacity argument. * * @param minCapacity the desired minimum capacity * @throws OutOfMemoryError if minCapacity is less than zero */ private Object[] grow(int minCapacity) { int oldCapacity = elementData.length; if (oldCapacity > 0 || elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { int newCapacity = ArraysSupport.newLength(oldCapacity, minCapacity - oldCapacity, /* minimum growth */ oldCapacity >> 1 /* preferred growth */); return elementData = Arrays.copyOf(elementData, newCapacity); } else { return elementData = new Object[Math.max(DEFAULT_CAPACITY, minCapacity)]; } } As far as I understand, the else part performs an optimization for cases where there are no elements in elementData to be copied to the new array. Simply an empty array which ensures the requested minCapacity is created. The problem lies with the if condition "if (oldCapacity > 0 || elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)". This is going to be executed for any elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA regardless of the oldCapacity value. So, I believe that the original intention was the else part to also include cases where the oldCapacity is zero. This means that the condition should use && instead of || and be written like that: if (oldCapacity > 0 && elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { What do you think? Does this make sense? While we are at it I would also like to point out that the javadoc comment regarding the "OutOfMemoryError" seems a bit misleading to me. It says that the OutOfMemoryError will be thrown "if minCapacity is less than zero". However, this seems true only before 218204b1a330 ( https://github.com/openjdk/jdk/commit/218204b1a330) which performed this change, with the previous implementation ( https://github.com/openjdk/jdk/blob/9ffe7e1205ea42ffccc9622b3e1c5436cc9898f5/src/java.base/share/classes/java/util/ArrayList.java#L261-L262 and https://github.com/openjdk/jdk/blob/9ffe7e1205ea42ffccc9622b3e1c5436cc9898f5/src/java.base/share/classes/java/util/ArrayList.java#L271-L272 ). Now, an OutOfMemoryError is still possible. "ArraysSupport.newLength()" method may throw it "if the new length would exceed Integer.MAX_VALUE". This may depend implicitly on the "minCapacity" value. However, the condition for the appearance of the error seems not to be exactly the one described in the comment. So, I think the javadoc should be updated to reflect the current situation, probably by using the same comment which exists in the "ArraysSupport.newLength()" method. Thank you, Periklis -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sun Jul 10 22:30:47 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 10 Jul 2022 22:30:47 +0000 Subject: ArrayList grow method optimization and documentation improvement In-Reply-To: References: Message-ID: I think it means for the zero case it should not use the else part if it has not the default sizing, since somebody might have created it with a specific size. Not sure if it matters much either way. -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Periklis Ntanasis Gesendet: Monday, July 11, 2022 12:20:27 AM An: core-libs-dev at openjdk.org Betreff: ArrayList grow method optimization and documentation improvement Hi all, I was reading the ArrayList source code and I think that the "private Object[] grow(int minCapacity)" method does not work as it was intended by the author. Currently the method looks like this (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ArrayList.java#L224-L241): /** * Increases the capacity to ensure that it can hold at least the * number of elements specified by the minimum capacity argument. * * @param minCapacity the desired minimum capacity * @throws OutOfMemoryError if minCapacity is less than zero */ private Object[] grow(int minCapacity) { int oldCapacity = elementData.length; if (oldCapacity > 0 || elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { int newCapacity = ArraysSupport.newLength(oldCapacity, minCapacity - oldCapacity, /* minimum growth */ oldCapacity >> 1 /* preferred growth */); return elementData = Arrays.copyOf(elementData, newCapacity); } else { return elementData = new Object[Math.max(DEFAULT_CAPACITY, minCapacity)]; } } As far as I understand, the else part performs an optimization for cases where there are no elements in elementData to be copied to the new array. Simply an empty array which ensures the requested minCapacity is created. The problem lies with the if condition "if (oldCapacity > 0 || elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)". This is going to be executed for any elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA regardless of the oldCapacity value. So, I believe that the original intention was the else part to also include cases where the oldCapacity is zero. This means that the condition should use && instead of || and be written like that: if (oldCapacity > 0 && elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { What do you think? Does this make sense? While we are at it I would also like to point out that the javadoc comment regarding the "OutOfMemoryError" seems a bit misleading to me. It says that the OutOfMemoryError will be thrown "if minCapacity is less than zero". However, this seems true only before 218204b1a330 (https://github.com/openjdk/jdk/commit/218204b1a330) which performed this change, with the previous implementation (https://github.com/openjdk/jdk/blob/9ffe7e1205ea42ffccc9622b3e1c5436cc9898f5/src/java.base/share/classes/java/util/ArrayList.java#L261-L262 and https://github.com/openjdk/jdk/blob/9ffe7e1205ea42ffccc9622b3e1c5436cc9898f5/src/java.base/share/classes/java/util/ArrayList.java#L271-L272). Now, an OutOfMemoryError is still possible. "ArraysSupport.newLength()" method may throw it "if the new length would exceed Integer.MAX_VALUE". This may depend implicitly on the "minCapacity" value. However, the condition for the appearance of the error seems not to be exactly the one described in the comment. So, I think the javadoc should be updated to reflect the current situation, probably by using the same comment which exists in the "ArraysSupport.newLength()" method. Thank you, Periklis -------------- next part -------------- An HTML attachment was scrubbed... URL: From pntanasis at gmail.com Sun Jul 10 23:02:49 2022 From: pntanasis at gmail.com (Periklis Ntanasis) Date: Mon, 11 Jul 2022 02:02:49 +0300 Subject: ArrayList grow method optimization and documentation improvement In-Reply-To: References: Message-ID: Thanks for your response. Sure, maybe it doesn't really matter because it is about micro-optimization. The code is correct in any case. However, as I see it the else part could be executed for the following two cases which currently does not: 1. If the ArrayList is initialized as empty and the shared EMPTY_ELEMENTDATA is used. 2. If the current capacity of the elementData is zero because of removals (actually in that case if trimToSize() is used again elementData points to EMPTY_ELEMENTDATA). So, I agree that it is not really important but if for some reason the optimization was originally placed there I would expect it to work for all the cases where the optimization may be performed. Currently, the "if (oldCapacity > 0 || elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)" is equivalent to "if (elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)" (DEFAULTCAPACITY_EMPTY_ELEMENTDATA has always oldCapacity equals to zero) which seems weird to me. By the way for the same reason my previous suggestion to change it to "if (oldCapacity > 0 && elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)" is actually equivalent to "if (oldCapacity > 0)". Anyway, maybe I am missing something but this seemed strange to me and I wanted to bring it to the attention of the mailing list. Feel free to ignore my comment in case you think that it isn't worth the effort. Best regards, Periklis On Mon, Jul 11, 2022 at 1:31 AM Bernd Eckenfels wrote: > I think it means for the zero case it should not use the else part if it > has not the default sizing, since somebody might have created it with a > specific size. Not sure if it matters much either way. > > > -- > http://bernd.eckenfels.net > ------------------------------ > *Von:* core-libs-dev im Auftrag von > Periklis Ntanasis > *Gesendet:* Monday, July 11, 2022 12:20:27 AM > *An:* core-libs-dev at openjdk.org > *Betreff:* ArrayList grow method optimization and documentation > improvement > > Hi all, > > I was reading the ArrayList source code and I think that the "private > Object[] grow(int minCapacity)" method does not work as it was intended by > the author. > > Currently the method looks like this ( > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ArrayList.java#L224-L241 > ): > > /** > * Increases the capacity to ensure that it can hold at least the > * number of elements specified by the minimum capacity argument. > * > * @param minCapacity the desired minimum capacity > * @throws OutOfMemoryError if minCapacity is less than zero > */ > private Object[] grow(int minCapacity) { > int oldCapacity = elementData.length; > if (oldCapacity > 0 || elementData != > DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { > int newCapacity = ArraysSupport.newLength(oldCapacity, > minCapacity - oldCapacity, /* minimum growth */ > oldCapacity >> 1 /* preferred growth */); > return elementData = Arrays.copyOf(elementData, newCapacity); > } else { > return elementData = new Object[Math.max(DEFAULT_CAPACITY, > minCapacity)]; > } > } > > As far as I understand, the else part performs an optimization for cases > where there are no elements in elementData to be copied to the new array. > Simply an empty array which ensures the requested minCapacity is created. > > The problem lies with the if condition "if (oldCapacity > 0 || elementData > != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)". > This is going to be executed for any elementData != > DEFAULTCAPACITY_EMPTY_ELEMENTDATA regardless of the oldCapacity value. > > So, I believe that the original intention was the else part to also > include cases where the oldCapacity is zero. > This means that the condition should use && instead of || and be written > like that: > > if (oldCapacity > 0 && elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA) { > > What do you think? Does this make sense? > > While we are at it I would also like to point out that the javadoc comment > regarding the "OutOfMemoryError" seems a bit misleading to me. > > It says that the OutOfMemoryError will be thrown "if minCapacity is less > than zero". > However, this seems true only before 218204b1a330 ( > https://github.com/openjdk/jdk/commit/218204b1a330) which performed this > change, with the previous implementation ( > https://github.com/openjdk/jdk/blob/9ffe7e1205ea42ffccc9622b3e1c5436cc9898f5/src/java.base/share/classes/java/util/ArrayList.java#L261-L262 > and > https://github.com/openjdk/jdk/blob/9ffe7e1205ea42ffccc9622b3e1c5436cc9898f5/src/java.base/share/classes/java/util/ArrayList.java#L271-L272 > ). > > Now, an OutOfMemoryError is still possible. "ArraysSupport.newLength()" > method may throw it "if the new length would exceed Integer.MAX_VALUE". > This may depend implicitly on the "minCapacity" value. > However, the condition for the appearance of the error seems not to be > exactly the one described in the comment. > > So, I think the javadoc should be updated to reflect the current > situation, probably by using the same comment which exists in the > "ArraysSupport.newLength()" method. > > Thank you, > Periklis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelm at openjdk.org Mon Jul 11 07:00:45 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 11 Jul 2022 07:00:45 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables libnet changes look fine to me ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Mon Jul 11 08:07:28 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 11 Jul 2022 08:07:28 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v2] In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: > We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. > > Benchmark results: > > before > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op > StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op > > after > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op > StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op ?????? ??????? 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 8289908 - 8289908: Make constructor private and use trailing Void instead of int - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9407/files - new: https://git.openjdk.org/jdk/pull/9407/files/567727e9..294e91f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=00-01 Stats: 11699 lines in 1295 files changed: 3911 ins; 1617 del; 6171 mod Patch: https://git.openjdk.org/jdk/pull/9407.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407 PR: https://git.openjdk.org/jdk/pull/9407 From duke at openjdk.org Mon Jul 11 08:07:28 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 11 Jul 2022 08:07:28 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v2] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Fri, 8 Jul 2022 14:04:14 GMT, Roger Riggs wrote: >> But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I? > > The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it. Is there a better way than adding a non-functional argument? > The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg. > > The constructor should be private, it has a very narrow scope of use given the lack of checking its args. > > It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks; > it would have broader applicability then this point fix. > I would be interesting to ask the compiler folks if that's a future optimization. > These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement. Well, we already have e.g. `String(char[], int, int, Void)` and `String(AbstractStringBuilder asb, Void sig)` where trailing argument is for disambiguation against private constructors. I did the same for mine and applied the same naming as in other trailing `Void` params. ------------- PR: https://git.openjdk.org/jdk/pull/9407 From chegar at openjdk.org Mon Jul 11 08:13:45 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 11 Jul 2022 08:13:45 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: <0LufT1j0Gvkv3sFYqCQUR7aBmIU9lHIdOWBHVJyDc-M=.ee7f2980-e54f-4507-9ce3-73378faad4b8@github.com> On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From sgehwolf at openjdk.org Mon Jul 11 08:40:46 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 11 Jul 2022 08:40:46 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> References: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> Message-ID: On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman wrote: >> xpbob has updated the pull request incrementally with one additional commit since the last revision: >> >> update header > > It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API? I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management). > @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR See https://wiki.openjdk.org/display/csr/CSR+FAQs ------------- PR: https://git.openjdk.org/jdk/pull/9372 From alanb at openjdk.org Mon Jul 11 09:34:31 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 11 Jul 2022 09:34:31 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> References: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> Message-ID: On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman wrote: >> xpbob has updated the pull request incrementally with one additional commit since the last revision: >> >> update header > > It's not clear that introducing this as a standard API is the right thing to do. Are you 100% confident that the concepts of "CPU quota", "CPU shares", "CPU period", "soft limit" etc. will last the test of time and that we don't be back here next year with another PR to deprecate or replace this API? I don't disagree that exposing a MXBean could be useful for monitoring/management purposes but I think we have to be cautious getting getting locked in. A possible starting point for prototyping purposes and getting feedback is a JDK-specific MXBean (module jdk.management). > @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR It's too early to think about a CSR, probably a bit premature to create a PR too because it will take a few iterations to come to agreement on what API to expose, if any. I don't think this should be a standard API, meaning java.management/java.lang.management.ContainerMXBean is not the right place for this. A JDK-specific MXBean is an option but it would only be usable on Linux and maybe only usable when running in a container environment. Working down, it's not clear to me how stable the attributes are and the mapping to both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which already defines the "TotalSwapSpaceSize" attribute. There's another level of detail beyond that with unusual value -2 to distinguish "not available" from "not supported". So I think there are a few things to think about there. Another direction to think about is not exposing an API that you can compile against but instead just register a MBean that provides access to the attributes that are interesting for the container environment. By this I mean ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be enough to browse the MBean and its attributes in any JMX console and may give you a bit more flexibility to expose attributes that are specific to the cgroup version. I'm not saying this is the right direction, I'm just listing here is something that you could be explored. If the main use case is JMX consoles rather than programmatic access then it may not be too bad. ------------- PR: https://git.openjdk.org/jdk/pull/9372 From mcimadamore at openjdk.org Mon Jul 11 09:55:05 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 09:55:05 GMT Subject: [jdk19] RFR: 8290071: Javadoc for MemorySegment/MemoryAddress getter/setters contains some typos Message-ID: Some of the accessors in `MemorySegment` and `MemoryAddress` (esp. setters) have typos - e.g. they use `from` instead of `into`. I've tried to simplify the text and made it more regular. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk19/pull/131/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=131&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290071 Stats: 50 lines in 2 files changed: 0 ins; 0 del; 50 mod Patch: https://git.openjdk.org/jdk19/pull/131.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/131/head:pull/131 PR: https://git.openjdk.org/jdk19/pull/131 From maurizio.cimadamore at oracle.com Mon Jul 11 09:58:52 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 10:58:52 +0100 Subject: JMH results for IndexedLinkedList In-Reply-To: References: Message-ID: <56a19568-2adc-7f38-3ff0-13b069ff09a3@oracle.com> The implementation of the Foreign Function & Memory API uses an internal custom linked list to add native resources to a "memory session" abstraction (things that need to be cleaned up at a later point). Linked list is quite critical in our use case because we need something that has a very fast insertion (in the head), and can scale gracefully to handle multiple threads. In our case LinkedList is not good enough (because we want to deal with concurrent writes ourselves) - but aside from that, note that, at least looking at the numbers posted in your benchmarks, it seems that prepending an element to a classic LinkedList is 10x faster than ArrayList and 5x faster IndexList. Perhaps that's a case where IndexList has not been fully optimized - but for prepend-heavy code (and the javac compiler is another one of those), I think performance of addFirst is the number to look at. As Tagir said, of course these use cases are very "niche" - and, at least in my experience, deevelopers in this "niche" tend to come up with ad-hoc specialized data structures anyways. So the return of investment for adding another collection type in this space seems relatively low. Maurizio On 09/07/2022 20:33, Tagir Valeev wrote: > Note that nobody these days cares about LinkedList. Use-cases where > LinkedList outperforms careful use of ArrayList or ArrayDeque are next > to none. So saying that your data structure is better than LinkedList > is totally not a reason to add it to JDK. It should be better than > ArrayList and ArrayDeque. > > Having a single data structure that provides list and deque interface > is a reasonable idea. However it would be much simpler to retrofit > existing data structure like ArrayDeque, rather than create a new data > structure. Here's an issue for this: > https://bugs.openjdk.org/browse/JDK-8143850 > > There were also discussions to enhance collections in general, adding > more useful methods like getFirst() or removeLast() to ArrayList, etc. > See for details: > https://bugs.openjdk.org/browse/JDK-8266572 > > To conclude, the idea of adding one more collection implementation > looks questionable to me. It will add more confusion when people need > to select which collection fits their needs better. It will require > more learning. This could be justified if there are clear benefits in > using it in real world problems, compared to existing collections. But > so far I don't see the examples of such problems. > > With best regards, > Tagir Valeev > > ??, 9 ???. 2022 ?., 11:22 Rodion Efremov : > > Hello, > > My benchmarking suggests, that, if nothing else, my > IndexedLinkedList outperforms gracefully the java.util.LinkedList, > so the use case should be the same (List + Deque > -interfaces) for both of the aforementioned data structures. > > Best regards, > rodde > > > On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev > wrote: > > Hello! > > Are there real world problems/use cases where > IndexedLinkedList would be preferred in terms of CPU/memory > usage over ArrayList? > > ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : > > Data structure repo: > https://github.com/coderodde/IndexedLinkedList > > Benchmark repo: > https://github.com/coderodde/IndexedLinkedListBenchmark > > I have profiled my data structure and it seems it?s more > performant than java.util.LinkedList or TreeList, if > nothing else. > > So, is there any chance of including IndexedLinkedList to JDK? > > Best regards, > rodde > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uschindler at openjdk.org Mon Jul 11 10:12:56 2022 From: uschindler at openjdk.org (Uwe Schindler) Date: Mon, 11 Jul 2022 10:12:56 GMT Subject: [jdk19] RFR: 8290071: Javadoc for MemorySegment/MemoryAddress getter/setters contains some typos In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 09:46:11 GMT, Maurizio Cimadamore wrote: > Some of the accessors in `MemorySegment` and `MemoryAddress` (esp. setters) have typos - e.g. they use `from` instead of `into`. > > I've tried to simplify the text and made it more regular. Marked as reviewed by uschindler (Author). ------------- PR: https://git.openjdk.org/jdk19/pull/131 From john.hendrikx at gmail.com Mon Jul 11 10:22:16 2022 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 11 Jul 2022 12:22:16 +0200 Subject: JMH results for IndexedLinkedList In-Reply-To: <56a19568-2adc-7f38-3ff0-13b069ff09a3@oracle.com> References: <56a19568-2adc-7f38-3ff0-13b069ff09a3@oracle.com> Message-ID: <11b988e7-82fe-2835-37b4-106b58e1efb4@gmail.com> I'm curious, why isn't ArrayDeque or ConcurrentLinkedDeque used instead? Or is there another requirement? ArrayDeque has amortized O(1) for inserts at head and tail (and faster and more memory efficient than LinkedList as it doesn't use nodes). ConcurrentLinkedDeque would be useful in the face of multiple threads (it uses nodes though, so won't be as fast as ArrayDeque). --John On 11/07/2022 11:58, Maurizio Cimadamore wrote: > > The implementation of the Foreign Function & Memory API uses an > internal custom linked list to add native resources to a "memory > session" abstraction (things that need to be cleaned up at a later point). > > Linked list is quite critical in our use case because we need > something that has a very fast insertion (in the head), and can scale > gracefully to handle multiple threads. > > In our case LinkedList is not good enough (because we want to deal > with concurrent writes ourselves) - but aside from that, note that, at > least looking at the numbers posted in your benchmarks, it seems that > prepending an element to a classic LinkedList is 10x faster than > ArrayList and 5x faster IndexList. Perhaps that's a case where > IndexList has not been fully optimized - but for prepend-heavy code > (and the javac compiler is another one of those), I think performance > of addFirst is the number to look at. > > As Tagir said, of course these use cases are very "niche" - and, at > least in my experience, deevelopers in this "niche" tend to come up > with ad-hoc specialized data structures anyways. So the return of > investment for adding another collection type in this space seems > relatively low. > > Maurizio > > On 09/07/2022 20:33, Tagir Valeev wrote: >> Note that nobody these days cares about LinkedList. Use-cases where >> LinkedList outperforms careful use of ArrayList or ArrayDeque are >> next to none. So saying that your data structure is better than >> LinkedList is totally not a reason to add it to JDK. It should be >> better than ArrayList and ArrayDeque. >> >> Having a single data structure that provides list and deque interface >> is a reasonable idea. However it would be much simpler to retrofit >> existing data structure like ArrayDeque, rather than create a new >> data structure. Here's an issue for this: >> https://bugs.openjdk.org/browse/JDK-8143850 >> >> There were also discussions to enhance collections in general, adding >> more useful methods like getFirst() or removeLast() to ArrayList, >> etc. See for details: >> https://bugs.openjdk.org/browse/JDK-8266572 >> >> To conclude, the idea of adding one more collection implementation >> looks questionable to me. It will add more confusion when people need >> to select which collection fits their needs better. It will require >> more learning. This could be justified if there are clear benefits in >> using it in real world problems, compared to existing collections. >> But so far I don't see the examples of such problems. >> >> With best regards, >> Tagir Valeev >> >> ??, 9 ???. 2022 ?., 11:22 Rodion Efremov : >> >> Hello, >> >> My benchmarking suggests, that, if nothing else, my >> IndexedLinkedList outperforms gracefully the >> java.util.LinkedList, so the use case should be the same (List >> + Deque -interfaces) for both of the aforementioned data >> structures. >> >> Best regards, >> rodde >> >> >> On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev >> wrote: >> >> Hello! >> >> Are there real world problems/use cases where >> IndexedLinkedList would be preferred in terms of CPU/memory >> usage over ArrayList? >> >> ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : >> >> Data structure repo: >> https://github.com/coderodde/IndexedLinkedList >> >> Benchmark repo: >> https://github.com/coderodde/IndexedLinkedListBenchmark >> >> I have profiled my data structure and it seems it?s more >> performant than java.util.LinkedList or TreeList, if >> nothing else. >> >> So, is there any chance of including IndexedLinkedList to >> JDK? >> >> Best regards, >> rodde >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Jul 11 10:27:54 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 11:27:54 +0100 Subject: JMH results for IndexedLinkedList In-Reply-To: <11b988e7-82fe-2835-37b4-106b58e1efb4@gmail.com> References: <56a19568-2adc-7f38-3ff0-13b069ff09a3@oracle.com> <11b988e7-82fe-2835-37b4-106b58e1efb4@gmail.com> Message-ID: <62ae0217-bf23-0af6-77d3-7f8adddb0c43@oracle.com> ConcurrentLinkedDeque was tested and it has similar thoughput to what we use, slightly higher memory footprint per element added, so we opted against it (but might re-eval in the future). In the specific case of the FFM API, it is not uncommon to have a session with just 1-2 resources attached to it. So having a data structure backed by an array becomes a bit problematic, while data structures where you pay for what you use are instead preferrable. We only scan the contents of the data strtucture once (when we bring down the session), to call the various cleanup actions, so we're absolutely not interested in random access. Maurizio On 11/07/2022 11:22, John Hendrikx wrote: > > I'm curious, why isn't ArrayDeque or ConcurrentLinkedDeque used > instead? Or is there another requirement? > > ArrayDeque has amortized O(1) for inserts at head and tail (and faster > and more memory efficient than LinkedList as it doesn't use nodes). > > ConcurrentLinkedDeque would be useful in the face of multiple threads > (it uses nodes though, so won't be as fast as ArrayDeque). > > --John > > On 11/07/2022 11:58, Maurizio Cimadamore wrote: >> >> The implementation of the Foreign Function & Memory API uses an >> internal custom linked list to add native resources to a "memory >> session" abstraction (things that need to be cleaned up at a later >> point). >> >> Linked list is quite critical in our use case because we need >> something that has a very fast insertion (in the head), and can scale >> gracefully to handle multiple threads. >> >> In our case LinkedList is not good enough (because we want to deal >> with concurrent writes ourselves) - but aside from that, note that, >> at least looking at the numbers posted in your benchmarks, it seems >> that prepending an element to a classic LinkedList is 10x faster than >> ArrayList and 5x faster IndexList. Perhaps that's a case where >> IndexList has not been fully optimized - but for prepend-heavy code >> (and the javac compiler is another one of those), I think performance >> of addFirst is the number to look at. >> >> As Tagir said, of course these use cases are very "niche" - and, at >> least in my experience, deevelopers in this "niche" tend to come up >> with ad-hoc specialized data structures anyways. So the return of >> investment for adding another collection type in this space seems >> relatively low. >> >> Maurizio >> >> On 09/07/2022 20:33, Tagir Valeev wrote: >>> Note that nobody these days cares about LinkedList. Use-cases where >>> LinkedList outperforms careful use of ArrayList or ArrayDeque are >>> next to none. So saying that your data structure is better than >>> LinkedList is totally not a reason to add it to JDK. It should be >>> better than ArrayList and ArrayDeque. >>> >>> Having a single data structure that provides list and deque >>> interface is a reasonable idea. However it would be much simpler to >>> retrofit existing data structure like ArrayDeque, rather than create >>> a new data structure. Here's an issue for this: >>> https://bugs.openjdk.org/browse/JDK-8143850 >>> >>> There were also discussions to enhance collections in general, >>> adding more useful methods like getFirst() or removeLast() to >>> ArrayList, etc. See for details: >>> https://bugs.openjdk.org/browse/JDK-8266572 >>> >>> To conclude, the idea of adding one more collection implementation >>> looks questionable to me. It will add more confusion when people >>> need to select which collection fits their needs better. It will >>> require more learning. This could be justified if there are clear >>> benefits in using it in real world problems, compared to existing >>> collections. But so far I don't see the examples of such problems. >>> >>> With best regards, >>> Tagir Valeev >>> >>> ??, 9 ???. 2022 ?., 11:22 Rodion Efremov : >>> >>> Hello, >>> >>> My benchmarking suggests, that, if nothing else, my >>> IndexedLinkedList outperforms gracefully the >>> java.util.LinkedList, so the use case should be the same >>> (List + Deque -interfaces) for both of the aforementioned >>> data structures. >>> >>> Best regards, >>> rodde >>> >>> >>> On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev >>> wrote: >>> >>> Hello! >>> >>> Are there real world problems/use cases where >>> IndexedLinkedList would be preferred in terms of CPU/memory >>> usage over ArrayList? >>> >>> ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : >>> >>> Data structure repo: >>> https://github.com/coderodde/IndexedLinkedList >>> >>> Benchmark repo: >>> https://github.com/coderodde/IndexedLinkedListBenchmark >>> >>> I have profiled my data structure and it seems it?s more >>> performant than java.util.LinkedList or TreeList, if >>> nothing else. >>> >>> So, is there any chance of including IndexedLinkedList >>> to JDK? >>> >>> Best regards, >>> rodde >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jul 11 11:46:21 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 11 Jul 2022 11:46:21 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v3] In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: > We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. > > Benchmark results: > > before > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op > StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op > > after > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op > StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8289908: Fixed tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9407/files - new: https://git.openjdk.org/jdk/pull/9407/files/294e91f7..b7375cd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=01-02 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9407.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407 PR: https://git.openjdk.org/jdk/pull/9407 From duke at openjdk.org Mon Jul 11 12:25:39 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 11 Jul 2022 12:25:39 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v3] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Mon, 11 Jul 2022 08:02:43 GMT, ?????? ??????? wrote: >> The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it. Is there a better way than adding a non-functional argument? >> The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg. >> >> The constructor should be private, it has a very narrow scope of use given the lack of checking its args. >> >> It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks; >> it would have broader applicability then this point fix. >> I would be interesting to ask the compiler folks if that's a future optimization. >> These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement. > > Well, we already have e.g. `String(char[], int, int, Void)` and `String(AbstractStringBuilder asb, Void sig)` where trailing argument is for disambiguation against private constructors. I did the same for mine and applied the same naming as in other trailing `Void` params. Benchmark results after: Benchmark Mode Cnt Score Error Units StringConstructor.newStringFromArray avgt 50 4,354 ? 0,195 ns/op StringConstructor.newStringFromArrayWithCharset avgt 50 4,035 ? 0,088 ns/op StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,166 ? 0,062 ns/op StringConstructor.newStringFromRangedArray avgt 50 4,132 ? 0,054 ns/op StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,416 ? 0,206 ns/op StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,421 ? 0,041 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/9407 From jwilhelm at openjdk.org Mon Jul 11 12:46:47 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 11 Jul 2022 12:46:47 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge - 8290004: [PPC64] JfrGetCallTrace: assert(_pc != nullptr) failed: must have PC - 8289692: JFR: Thread checkpoint no longer enforce mutual exclusion post Loom integration - 8289894: A NullPointerException thrown from guard expression - 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap - 8282071: Update java.xml module-info - 8290033: ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on windows-x64 in -Xcomp mode - 8289697: buffer overflow in MTLVertexCache.m: MTLVertexCache_AddGlyphQuad - 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. - 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 - ... and 5 more: https://git.openjdk.org/jdk/compare/46251bc6...0b0d186f The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9450&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9450&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9450/files Stats: 411 lines in 43 files changed: 284 ins; 26 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/9450.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9450/head:pull/9450 PR: https://git.openjdk.org/jdk/pull/9450 From duke at openjdk.org Mon Jul 11 12:49:17 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 11 Jul 2022 12:49:17 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger Message-ID: `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. ------------- Commit messages: - 8290079: Reduce interaction with volatile in static initializer of BigInteger Changes: https://git.openjdk.org/jdk/pull/9451/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290079 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9451.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9451/head:pull/9451 PR: https://git.openjdk.org/jdk/pull/9451 From mcimadamore at openjdk.org Mon Jul 11 14:33:12 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 14:33:12 GMT Subject: [jdk19] Integrated: 8287809: Revisit implementation of memory session In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 18:06:44 GMT, Maurizio Cimadamore wrote: > This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 This pull request has now been integrated. Changeset: fed3af8a Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk19/commit/fed3af8ae069fc760a24e750292acbb468b14ce5 Stats: 429 lines in 21 files changed: 47 ins; 102 del; 280 mod 8287809: Revisit implementation of memory session Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk19/pull/22 From mcimadamore at openjdk.org Mon Jul 11 14:41:40 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 14:41:40 GMT Subject: [jdk19] RFR: 8288697: Clarify lifecycle of buffer segments and loader lookup [v2] In-Reply-To: References: Message-ID: > This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases: > > * when a buffer segment is created, to keep the original buffer instance reachable > * when a loader symbol lookup is created, to keep the classloader instance reachable > > Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model. > > This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments. > > This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Initial push - Revert implicit vs. heap session changes - Unify heap vs. implicit scopes - Merge branch 'master' into memory_session_cleanup - Fix issue in Direct-X-Buffer template - Simplify and drop the state class - Add missing files - Initial push ------------- Changes: https://git.openjdk.org/jdk19/pull/39/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=39&range=01 Stats: 577 lines in 28 files changed: 53 ins; 125 del; 399 mod Patch: https://git.openjdk.org/jdk19/pull/39.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/39/head:pull/39 PR: https://git.openjdk.org/jdk19/pull/39 From mcimadamore at openjdk.org Mon Jul 11 14:53:18 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 14:53:18 GMT Subject: [jdk19] RFR: 8289365: SegmentAllocator:allocateArray(MemoryLayout, count) does not throw IAEx when count is -1 Message-ID: The default implementation for `SegmentAllocator:allocateArray(MemoryLayout, count)` is missing a check for negative array size. In the past this used to be caught in the `SequenceLayout` factory, but not anymore, as now `SequenceLayout` accepts `-1` as special size where the sequence element count is inferred. So, an explicit check is needed. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk19/pull/132/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=132&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289365 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/132.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/132/head:pull/132 PR: https://git.openjdk.org/jdk19/pull/132 From dl at openjdk.org Mon Jul 11 15:02:05 2022 From: dl at openjdk.org (Doug Lea) Date: Mon, 11 Jul 2022 15:02:05 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died Message-ID: 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died ------------- Commit messages: - Also update Xcomp problem list - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8066859 - Address review comments - Disable filling in stack trace for preallocated exceptions - Merge branch 'master' into JDK-8066859 - Test synch under OOME - Avoid sync failures when encountering OutOfMemoryErrors - Accommodate OutOfMemoryErrors while locking Changes: https://git.openjdk.org/jdk/pull/9427/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9427&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8066859 Stats: 418 lines in 6 files changed: 322 ins; 12 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/9427.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9427/head:pull/9427 PR: https://git.openjdk.org/jdk/pull/9427 From dl at openjdk.org Mon Jul 11 15:02:06 2022 From: dl at openjdk.org (Doug Lea) Date: Mon, 11 Jul 2022 15:02:06 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 11:44:53 GMT, Doug Lea
        wrote: > 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died Thanks to @AlanBateman for suggesting to disable possibly misleading stack traces in pre-allocated exceptions; now updated I keep trying but failing to change commit message to something jcheck likes? The idea here is that a non-OOME-throwing condition wait might be required for (some) memory to be reclaimed. This is not too farfetched for InterruptedException (if serving as a cancellation), so we allow it to be thrown (instead of OOME) in hopes that a catch of IE will free memory. It IS farfetched to think this might be the case for IllegalMonitorStateException, but I did it the same way for consistency. ------------- PR: https://git.openjdk.org/jdk/pull/9427 From rriggs at openjdk.org Mon Jul 11 15:02:44 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 11 Jul 2022 15:02:44 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v3] In-Reply-To: References: Message-ID: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add TWR for Files.walk of /proc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9414/files - new: https://git.openjdk.org/jdk/pull/9414/files/0d628d66..845695d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=01-02 Stats: 13 lines in 1 file changed: 1 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9414/head:pull/9414 PR: https://git.openjdk.org/jdk/pull/9414 From alanb at openjdk.org Mon Jul 11 15:02:08 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 11 Jul 2022 15:02:08 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 22:42:28 GMT, Doug Lea
        wrote: > I keep trying but failing to change commit message to something jcheck likes? There should be an "Edit" button in the top right that allows you to edit the title and change it to "8066859 : java/lang/ref/OOMEInReferenceHandler.java failed ...". There are two Skara commands that may be useful here. Adding a comment "/issue JDK-8066859" will link the PR to this JBS issue. There is also a "/summary" command to edit the commit message. ------------- PR: https://git.openjdk.org/jdk/pull/9427 From dl at openjdk.org Mon Jul 11 15:02:11 2022 From: dl at openjdk.org (Doug Lea) Date: Mon, 11 Jul 2022 15:02:11 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 04:10:49 GMT, David Holmes wrote: >> 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 296: > >> 294: byte spins = 0, postSpins = 0; // retries upon unpark of first thread >> 295: boolean interrupted = false, first = false; >> 296: Node pred = null, t; // predecessor of node when enqueued > > Nit: please don't use this style of multi-variable declaration as they are very easy to mis-read. Also the comment only applies to one of the variables. OK, changed. > src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java line 1626: > >> 1624: } >> 1625: if (!isHeldExclusively() || !release(savedState = getState())) >> 1626: throw LockSupport.staticIllegalMonitorStateException; // OOM > > How is it possible to get IMSE this deep into the code? And the comment is confusing - OOM? Clarified to: // fall through if encountered OutOfMemoryError if (!isHeldExclusively() || !release(savedState = getState())) throw LockSupport.staticIllegalMonitorStateException; ------------- PR: https://git.openjdk.org/jdk/pull/9427 From dholmes at openjdk.org Mon Jul 11 15:02:10 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Jul 2022 15:02:10 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 11:44:53 GMT, Doug Lea
        wrote: > 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 296: > 294: byte spins = 0, postSpins = 0; // retries upon unpark of first thread > 295: boolean interrupted = false, first = false; > 296: Node pred = null, t; // predecessor of node when enqueued Nit: please don't use this style of multi-variable declaration as they are very easy to mis-read. Also the comment only applies to one of the variables. src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java line 1626: > 1624: } > 1625: if (!isHeldExclusively() || !release(savedState = getState())) > 1626: throw LockSupport.staticIllegalMonitorStateException; // OOM How is it possible to get IMSE this deep into the code? And the comment is confusing - OOM? src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java line 463: > 461: * Preallocated exceptions thrown if acquiring or releasing locks > 462: * when OutOfMemory. > 463: */ I don't see why this should be necessary. IMSE is thrown before any state changes occur and so it is is fine if the IMSE is replaced by OOME. Even IE should be safe at the points it is thrown. Also in both cases you want to see a full and proper stacktrace. ------------- PR: https://git.openjdk.org/jdk/pull/9427 From dholmes at openjdk.org Mon Jul 11 15:02:12 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Jul 2022 15:02:12 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 04:16:44 GMT, David Holmes wrote: >> 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java line 463: > >> 461: * Preallocated exceptions thrown if acquiring or releasing locks >> 462: * when OutOfMemory. >> 463: */ > > I don't see why this should be necessary. IMSE is thrown before any state changes occur and so it is is fine if the IMSE is replaced by OOME. > > Even IE should be safe at the points it is thrown. > > Also in both cases you want to see a full and proper stacktrace. Consider this another way, any place you have a `throw x` it must be safe to propagate that exception. It doesn't matter if that is actually `x` or an OOME caused by creating `x`. ------------- PR: https://git.openjdk.org/jdk/pull/9427 From rriggs at openjdk.org Mon Jul 11 15:02:47 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 11 Jul 2022 15:02:47 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v2] In-Reply-To: References: Message-ID: On Sat, 9 Jul 2022 02:43:55 GMT, David Schlosnagle wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup of PipelineLeaksFD test improving error messages and source cleanup. > > test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 130: > >> 128: }) >> 129: .filter(p1 -> p1.link().toString().startsWith("pipe:")) >> 130: .collect(Collectors.toSet()); > > Is this intentionally leaking the returned `DirectoryStream` from `Files.walk` to trigger the previous failure mode or should this be auto-closed (i.e. https://errorprone.info/bugpattern/StreamResourceLeak )? > > Suggestion: > > try (Stream s = Files.walk(path)) { > return s.filter(Files::isSymbolicLink) > .map(p -> { > try { > return new PipeRecord(p, Files.readSymbolicLink(p)); > } catch (IOException ioe) { > } > return new PipeRecord(p, null); > }) > .filter(p1 -> p1.link().toString().startsWith("pipe:")) > .collect(Collectors.toSet()); > } @schlosna An oversight, thanks for the reminder. ------------- PR: https://git.openjdk.org/jdk/pull/9414 From jens at lidestrom.se Mon Jul 11 15:10:43 2022 From: jens at lidestrom.se (=?UTF-8?Q?Jens_Lidestr=c3=b6m?=) Date: Mon, 11 Jul 2022 17:10:43 +0200 Subject: [JMH results for IndexedLinkedList] In-Reply-To: References: Message-ID: <2cfa6e41-d8c0-4267-d16d-1e38af4f90bf@lidestrom.se> I think you are coming at this in the wrong way, Rodion. I am not a JDK contributor, but these are my thoughts on how this works. The people that are responsible for the Java collections framework are well aware of the existence of alternative data structures such as finger trees. There are also a lot of various implementations of them available on the internet. The code for these data structures is not the reason that they have not been added to Java. The reason is that adding more data structures makes the standard library harder to learn for users and increases the maintenance burden for JDK developers. The benefits of the new data structure must outweigh these costs. If you want to move forward with this I think you should create a JEP-style document with the following content: * A description of the problem you think should be solved and why the current collection framework does not solve it. * A list of concrete use cases for your contribution. * An overview of the existing collection framework where you demonstrate how your collection would fill a hole. * An overview of alternative data structures and implementations, where you argue that your collection solves the problem in the best way. Adding a new data structure the the collections framework is a major change. There is a very small change that it will be done and it will not be done without careful evaluation. The code and the benchmarks is only a small part of that work. BR, Jens Lidestr?m On 2022-06-21 13:20, Rodion Efremov wrote: > Hi, > > Data structure: IndexedLinkedList > Benchmark: IndexedLinkedListBenchmark > > Benchmark output: https://github.com/coderodde/indexedLinkedList/#benchmark-output > > From the benchmark output, we can judge that IndexedLinkedList outperforms both java.util.LinkedList and the Apache Commons Collections TreeList. It, however, does not seem to supersede the java.util.ArrayList. > > Basically, I would expect the IndexedLinkedList to beat the ArrayList where we have a lot of following?operations: > > * addFirst(E) > * add(int, E) > * remove(int) > > So, what do you think? I am getting anywhere with that? > > Best regards, > rodde From mcimadamore at openjdk.org Mon Jul 11 15:12:21 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 15:12:21 GMT Subject: [jdk19] RFR: 8288850: SegmentAllocator:allocate() can return null some cases Message-ID: This patch fixes an issue where the arena allocator does not detect an overflow when attempting to allocate a new slice. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jdk19/pull/133/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288850 Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/133.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/133/head:pull/133 PR: https://git.openjdk.org/jdk19/pull/133 From jvernee at openjdk.org Mon Jul 11 15:14:33 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 11 Jul 2022 15:14:33 GMT Subject: [jdk19] RFR: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM [v4] In-Reply-To: References: Message-ID: > This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. > > For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. > > Testing: `jdk_foreign` test suite on all platforms that implement VaList. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into VaList - hmtl -> html - Review comments - Update Javadoc - Cleanup - Test passing ------------- Changes: https://git.openjdk.org/jdk19/pull/91/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=91&range=03 Stats: 394 lines in 7 files changed: 237 ins; 19 del; 138 mod Patch: https://git.openjdk.org/jdk19/pull/91.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/91/head:pull/91 PR: https://git.openjdk.org/jdk19/pull/91 From mcimadamore at openjdk.org Mon Jul 11 15:15:56 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 15:15:56 GMT Subject: [jdk19] Withdrawn: 8288697: Clarify lifecycle of buffer segments and loader lookup In-Reply-To: References: Message-ID: <5LRXjtqv5kfiVtlsihxBScnttPrbSIMvNRRfrF2jwj4=.e9e9f559-7bb7-47a6-a6c4-91b1097d9bbe@github.com> On Fri, 17 Jun 2022 21:39:16 GMT, Maurizio Cimadamore wrote: > This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases: > > * when a buffer segment is created, to keep the original buffer instance reachable > * when a loader symbol lookup is created, to keep the classloader instance reachable > > Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model. > > This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments. > > This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk19/pull/39 From clanger at openjdk.org Mon Jul 11 15:18:04 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 11 Jul 2022 15:18:04 GMT Subject: [jdk19] RFR: 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows Message-ID: Hi all, This pull request contains a backport of [JDK-8287902](https://bugs.openjdk.org/browse/JDK-8287902), commit [975316e3](https://github.com/openjdk/jdk/commit/975316e3e5f1208e4e15eadc2493d25c15554647) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Magnus Ihse Bursie on 10 Jun 2022 and was reviewed by Naoto Sato. It fixes an issue that shows up in the new GHA workflow. Thanks! ------------- Commit messages: - Backport 975316e3e5f1208e4e15eadc2493d25c15554647 Changes: https://git.openjdk.org/jdk19/pull/134/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=134&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287902 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/134.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/134/head:pull/134 PR: https://git.openjdk.org/jdk19/pull/134 From rriggs at openjdk.org Mon Jul 11 15:31:46 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 11 Jul 2022 15:31:46 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v4] In-Reply-To: References: Message-ID: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: remove debug output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9414/files - new: https://git.openjdk.org/jdk/pull/9414/files/845695d8..f34a3a09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9414/head:pull/9414 PR: https://git.openjdk.org/jdk/pull/9414 From jwilhelm at openjdk.org Mon Jul 11 16:19:55 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 11 Jul 2022 16:19:55 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 12:38:11 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: c79baaa8 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/c79baaa811971c43fbdbc251482d0e40903588cc Stats: 411 lines in 43 files changed: 284 ins; 26 del; 101 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9450 From alanb at openjdk.org Mon Jul 11 17:40:49 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 11 Jul 2022 17:40:49 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v4] In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 15:31:46 GMT, Roger Riggs wrote: >> The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. >> >> The process calling `pipelineStart()` is creating the pipes between the stages. >> As each process is launched, the file descriptor is inherited by the child process and >> the child process `dup`s them to the respective stdin/stdout/stderr fd. >> These copies of inherited file descriptors are handled correctly. >> >> Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. >> >> However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. >> The fix is to close the fd after it has been used as the input of the next process. >> >> A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. >> The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. >> >> The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > remove debug output Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9414 From clanger at openjdk.org Mon Jul 11 17:49:56 2022 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 11 Jul 2022 17:49:56 GMT Subject: [jdk19] Integrated: 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 15:07:28 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of [JDK-8287902](https://bugs.openjdk.org/browse/JDK-8287902), commit [975316e3](https://github.com/openjdk/jdk/commit/975316e3e5f1208e4e15eadc2493d25c15554647) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Magnus Ihse Bursie on 10 Jun 2022 and was reviewed by Naoto Sato. > > It fixes an issue that shows up in the new GHA workflow. > > Thanks! This pull request has now been integrated. Changeset: 39715f3d Author: Christoph Langer URL: https://git.openjdk.org/jdk19/commit/39715f3da7e8749bf477b818ae06f4dd99c223c4 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows Backport-of: 975316e3e5f1208e4e15eadc2493d25c15554647 ------------- PR: https://git.openjdk.org/jdk19/pull/134 From mchung at openjdk.org Mon Jul 11 20:34:43 2022 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 11 Jul 2022 20:34:43 GMT Subject: RFR: JDK-8289106: Add model of class file versions to core reflection [v2] In-Reply-To: References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> Message-ID: On Wed, 29 Jun 2022 21:32:29 GMT, Joe Darcy wrote: >> JDK-8289106: Add model of class file versions to core reflection > > Joe Darcy 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 10 additional commits since the last revision: > > - Add method to map from major class file version. > - Merge branch 'master' into JDK-8289106 > - Update phrasing. > - Augment and correct docs. > - Correct major versions; RELEASE_0 and RELEASE_1 are both 45. > - Make major method public. > - Add AccessFlag.locations(ClassFileFormatVersion) > - Add ClassFileFormatVersion <-> Runtime.Version conversions. > - Merge branch 'master' into JDK-8289106 > - JDK-8289106: Add model of class file versions to core reflection This `ClassFileFormatVersion` API is a good proposal. It can also reference `java.class.version` system property to map to the latest class file format version. ------------- PR: https://git.openjdk.org/jdk/pull/9299 From psandoz at openjdk.org Mon Jul 11 22:11:05 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 11 Jul 2022 22:11:05 GMT Subject: [jdk19] RFR: 8290071: Javadoc for MemorySegment/MemoryAddress getter/setters contains some typos In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 09:46:11 GMT, Maurizio Cimadamore wrote: > Some of the accessors in `MemorySegment` and `MemoryAddress` (esp. setters) have typos - e.g. they use `from` instead of `into`. > > I've tried to simplify the text and made it more regular. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/131 From psandoz at openjdk.org Mon Jul 11 22:13:43 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 11 Jul 2022 22:13:43 GMT Subject: [jdk19] RFR: 8289365: SegmentAllocator:allocateArray(MemoryLayout, count) does not throw IAEx when count is -1 In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 14:45:42 GMT, Maurizio Cimadamore wrote: > The default implementation for `SegmentAllocator:allocateArray(MemoryLayout, count)` is missing a check for negative array size. > In the past this used to be caught in the `SequenceLayout` factory, but not anymore, as now `SequenceLayout` accepts `-1` as special size where the sequence element count is inferred. So, an explicit check is needed. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/132 From psandoz at openjdk.org Mon Jul 11 22:19:33 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 11 Jul 2022 22:19:33 GMT Subject: [jdk19] RFR: 8288850: SegmentAllocator:allocate() can return null some cases In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 15:05:34 GMT, Maurizio Cimadamore wrote: > This patch fixes an issue where the arena allocator does not detect an overflow when attempting to allocate a new slice. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/133 From jpai at openjdk.org Tue Jul 12 02:29:50 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 02:29:50 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v4] In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 15:31:46 GMT, Roger Riggs wrote: >> The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. >> >> The process calling `pipelineStart()` is creating the pipes between the stages. >> As each process is launched, the file descriptor is inherited by the child process and >> the child process `dup`s them to the respective stdin/stdout/stderr fd. >> These copies of inherited file descriptors are handled correctly. >> >> Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. >> >> However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. >> The fix is to close the fd after it has been used as the input of the next process. >> >> A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. >> The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. >> >> The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > remove debug output Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9414 From jpai at openjdk.org Tue Jul 12 02:33:23 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 02:33:23 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v4] In-Reply-To: References: Message-ID: <8sc3pA2MRwWfVBcbKSipxEYKaBa23KrKuPGmmXW0hC8=.eb41bb2f-d048-4eb3-8290-8887574db12a@github.com> On Mon, 11 Jul 2022 15:31:46 GMT, Roger Riggs wrote: >> The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. >> >> The process calling `pipelineStart()` is creating the pipes between the stages. >> As each process is launched, the file descriptor is inherited by the child process and >> the child process `dup`s them to the respective stdin/stdout/stderr fd. >> These copies of inherited file descriptors are handled correctly. >> >> Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. >> >> However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. >> The fix is to close the fd after it has been used as the input of the next process. >> >> A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. >> The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. >> >> The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > remove debug output Hello Roger, I just noticed that the failures reported in the GitHub actions job are genuine and related to this new test. 2 separate failures: test PipelineLeaksFD.checkForLeaks(java.util.ImmutableCollections$List12 at 73c167a8): failure java.lang.AssertionError: More or fewer pipes than expected at org.testng.Assert.fail(Assert.java:99) at PipelineLeaksFD.checkForLeaks(PipelineLeaksFD.java:94) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at org.testng.TestRunner.privateRun(TestRunner.java:764) at org.testng.TestRunner.run(TestRunner.java:585) at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) at org.testng.SuiteRunner.run(SuiteRunner.java:286) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) at org.testng.TestNG.runSuites(TestNG.java:1069) at org.testng.TestNG.run(TestNG.java:1037) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1589) and test PipelineLeaksFD.checkForLeaks(java.util.ImmutableCollections$ListN at 13c9b949): failure java.io.UncheckedIOException: java.nio.file.NoSuchFileException: /proc/18459/fd/20 at java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:87) at java.base/java.nio.file.FileTreeIterator.hasNext(FileTreeIterator.java:103) at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132) at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1921) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) at PipelineLeaksFD.myPipes(PipelineLeaksFD.java:130) at PipelineLeaksFD.checkForLeaks(PipelineLeaksFD.java:86) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at org.testng.TestRunner.privateRun(TestRunner.java:764) at org.testng.TestRunner.run(TestRunner.java:585) at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) at org.testng.SuiteRunner.run(SuiteRunner.java:286) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) at org.testng.TestNG.runSuites(TestNG.java:1069) at org.testng.TestNG.run(TestNG.java:1037) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1589) Caused by: java.nio.file.NoSuchFileException: /proc/18459/fd/20 at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55) at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:148) at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99) at java.base/java.nio.file.Files.readAttributes(Files.java:1848) at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:220) at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:277) at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:374) at java.base/java.nio.file.FileTreeIterator.fetchNextIfNeeded(FileTreeIterator.java:83) ... 39 more ------------- PR: https://git.openjdk.org/jdk/pull/9414 From jpai at openjdk.org Tue Jul 12 06:26:47 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 06:26:47 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 12:41:48 GMT, ?????? ??????? wrote: > `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. The change looks fine to me. Please wait for at least another review from someone more familiar with this area, before merging. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9451 From jpai at openjdk.org Tue Jul 12 07:25:40 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 07:25:40 GMT Subject: RFR: 8289284: jdk.tracePinnedThreads output confusing when pinned due to native frame In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 10:44:01 GMT, Alan Bateman wrote: > The system property jdk.tracePinnedThreads triggers a stack trace to be printed when a virtual thread parks while pinned. If a virtual thread is pinned due to a native frame there is a spurious " <== monitors:0" added to line for the native method. > > A secondary issue is that there is no stack trace when there is Panama downcall as there isn't a native method in the stack trace. A future change may annotate the downcalls, for now the entire stack trace is printed (no filtering) so there is at least some output when pinned due to a call through native code Marked as reviewed by jpai (Reviewer). Hello Alan, The changes looks fine to me. I'm not too familiar with the build files, so I can't comment about the changes to the `JtregNativeJdk.gmk` file. On a slightly related note, while reviewing this change, I noticed the code in `VirtualThread` here https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/VirtualThread.java#L177. Is it intentional that we don't print/use the `reason` while printing out the stacktrace? The reason appears to be one of: /** Native frame on stack */ NATIVE, /** Monitor held */ MONITOR, /** In critical section */ CRITICAL_SECTION Would printing this reason be useful for easily understanding why the thread was considered pinned? I guess the same could be inferred from the stacktraces right now? test/jdk/java/lang/Thread/virtual/TracePinnedThreads.java line 95: > 93: System.setOut(new PrintStream(baos)); > 94: try { > 95: VThreadRunner.run(task::run); The change here removes the previous call to flush the `System.out`. I believe that's fine because the `PrintStream` here is backed by a `ByteArrayOutputStream` so the flush isn't necessary. ------------- PR: https://git.openjdk.org/jdk/pull/9308 From duke at openjdk.org Tue Jul 12 08:39:39 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Tue, 12 Jul 2022 08:39:39 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 12:41:48 GMT, ?????? ??????? wrote: > `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. (Not a reviewer) While the change doesn't hurt, I doubt that access to a (static) volatile in a static initializer is ever contended. ------------- PR: https://git.openjdk.org/jdk/pull/9451 From duke at openjdk.org Tue Jul 12 09:02:46 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 12 Jul 2022 09:02:46 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 08:35:50 GMT, Raffaello Giulietti wrote: >> `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. > > (Not a reviewer) While the change doesn't hurt, I doubt that access to a (static) volatile in a static initializer is ever contended. @rgiulietti AFAIK volatile access is more expensive than plain one regardless contention ------------- PR: https://git.openjdk.org/jdk/pull/9451 From duke at openjdk.org Tue Jul 12 09:21:43 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Tue, 12 Jul 2022 09:21:43 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 12:41:48 GMT, ?????? ??????? wrote: > `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. Usually yes, but since a static initializer is executed by at most one thread by using a locking protocol before any other static code is ever executed, the runtime _could_ (but I'm not sure it it really does) treat the volatile in the for loop as a local. But I would approve your change because it makes this more explicit. ------------- PR: https://git.openjdk.org/jdk/pull/9451 From jpai at openjdk.org Tue Jul 12 11:20:53 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 11:20:53 GMT Subject: [jdk19] RFR: 8289930: Improve Thread description of inherited AccessControlContext [v2] In-Reply-To: References: Message-ID: On Sun, 10 Jul 2022 07:49:50 GMT, Alan Bateman wrote: >> This is a javadoc only change. The "Inheritance when creating threads" section in the Thread description lists the things that are inherited when creating a Thread. This includes the somewhat obscure "inherited AccessControlContext" where the first sentence looks like it wants to be a heading. The proposed change is tiny: drop the the first sentence/prefix "Inherited Access Control Context:" and adds the sentence "The captured caller context is the new thread's inherited AccessControlContext" later in the paragraph. When the legacy SecurityManager is degraded further then I expect this paragraph will be removed. >> >> No semantic changes and I think below the radar for needing a csr. > > 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: > > - Merge > - Tweak javadoc > - Initial commit The change looks fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk19/pull/121 From jvernee at openjdk.org Tue Jul 12 11:29:53 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 12 Jul 2022 11:29:53 GMT Subject: [jdk19] Integrated: 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM In-Reply-To: References: Message-ID: <4r3JvJLBIeMlRLsxZ1RhYvnqmT1WvyXeEfv33glRhPE=.0fb9b62f-2f8c-45af-b433-e356c4783dc1@github.com> On Wed, 29 Jun 2022 13:40:01 GMT, Jorn Vernee wrote: > This patch changes all VaList implementations to throw `NoSuchElementException` when out of bounds reads occur on a VaList that is created using the Java builder API. The docs are updated accordingly. > > For VaLists that are created from native addresses, we don't know their bounds, so we can not throw exceptions in that case. > > Testing: `jdk_foreign` test suite on all platforms that implement VaList. This pull request has now been integrated. Changeset: 3164c98f Author: Jorn Vernee URL: https://git.openjdk.org/jdk19/commit/3164c98f4c02a48cad62dd4f9b6cc55d64ac6d83 Stats: 394 lines in 7 files changed: 237 ins; 19 del; 138 mod 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM 8289333: Specification of method j.l.foreign.VaList::skip deserves clarification 8289156: j.l.foreign.VaList::skip call could throw java.lang.IndexOutOfBoundsException: Out of bound access on segment Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk19/pull/91 From djelinski at openjdk.org Tue Jul 12 11:34:43 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Jul 2022 11:34:43 GMT Subject: Integrated: 8289768: Clean up unused code In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 20:19:10 GMT, Daniel Jeli?ski wrote: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. This pull request has now been integrated. Changeset: 04c47da1 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4 Stats: 98 lines in 46 files changed: 0 ins; 69 del; 29 mod 8289768: Clean up unused code Reviewed-by: dfuchs, lancea, weijun, naoto, cjplummer, alanb, michaelm, chegar ------------- PR: https://git.openjdk.org/jdk/pull/9383 From duke at openjdk.org Tue Jul 12 21:31:46 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 12 Jul 2022 21:31:46 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 09:18:19 GMT, Raffaello Giulietti wrote: >> `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. > > Usually yes, but since a static initializer is executed by at most one thread by using a locking protocol before any other static code is ever executed, the runtime _could_ (but I'm not sure it it really does) treat the volatile in the for loop as a local. > But I would approve your change because it makes this more explicit. @rgiulietti I've copy-pasted class-loading benchmark from JMH samples @State(Scope.Thread) @Warmup(iterations = 10, time = 1) @Measurement(iterations = 10, time = 5) @Fork(value = 5, jvmArgsAppend = {"-Xms1g", "-Xmx1g"}) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class Classy { @Benchmark public Class load() throws ClassNotFoundException { return Class.forName("com.tsypanov.slp.Sample", true, new XLoader()); } public static class XLoader extends URLClassLoader { private static final byte[] X_BYTECODE = new byte[]{ /*..*/}; public XLoader() { super(new URL[0], ClassLoader.getSystemClassLoader()); } @Override protected Class findClass(final String name) { return defineClass(name, X_BYTECODE, 0, X_BYTECODE.length); } } } and used it to measure loading a class from `byte[]` copied from the following class compiled: class Sample { static volatile int[] items = new int[100]; static { for (int i = 0; i < items.length; i++) { items[i] = ThreadLocalRandom.current().nextInt(); } } } I ran the benchmark with `java -jar target/sleep-benchmarks.jar Classy -prof cl` and for the version above got these results (Java 17): Benchmark Mode Cnt Score Error Units Classy.load avgt 50 96247.202 ? 548.137 ns/op Classy.load:?class.load avgt 50 259912.089 ? 1485.314 classes/sec Classy.load:?class.load.norm avgt 50 1.000 ? 0.001 classes/op Classy.load:?class.unload avgt 50 260243.318 ? 3673.515 classes/sec Classy.load:?class.unload.norm avgt 50 1.001 ? 0.014 classes/op Then I've modified the class in the same way I did in this PR: class Sample { static volatile int[] items; static { int[] items = new int[100]; for (int i = 0; i < items.length; i++) { items[i] = ThreadLocalRandom.current().nextInt(); } Sample.items = items; } } and for modified code got Benchmark Mode Cnt Score Error Units Classy.load avgt 50 63955.673 ? 147.470 ns/op Classy.load:?class.load avgt 50 391101.854 ? 925.013 classes/sec Classy.load:?class.load.norm avgt 50 1.000 ? 0.001 classes/op Classy.load:?class.unload avgt 50 390800.851 ? 2307.589 classes/sec Classy.load:?class.unload.norm avgt 50 0.999 ? 0.006 classes/op >From this I conclude that volatile costs are still there no matter whether we deal with static or non-static initializers. ------------- PR: https://git.openjdk.org/jdk/pull/9451 From prr at openjdk.org Tue Jul 12 22:32:53 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 12 Jul 2022 22:32:53 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v3] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: <-ieBZH9T_kfEdWWQPOAijkh7qx8gCm_OspehCdbfTPo=.c749524e-ac7f-4b04-8d82-5b50da62fd55@github.com> On Mon, 11 Jul 2022 11:46:21 GMT, ?????? ??????? wrote: >> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. >> >> Benchmark results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op >> >> after >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8289908: Fixed tests Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9407 From rriggs at openjdk.org Tue Jul 12 23:58:44 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Jul 2022 23:58:44 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v6] In-Reply-To: References: Message-ID: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add DEBUG diagnostics to determine cause of GitHub Action test failures due to unexpected pipes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9414/files - new: https://git.openjdk.org/jdk/pull/9414/files/e40207b6..ffddeed9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=04-05 Stats: 26 lines in 2 files changed: 25 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9414/head:pull/9414 PR: https://git.openjdk.org/jdk/pull/9414 From joehw at openjdk.org Wed Jul 13 00:39:08 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 13 Jul 2022 00:39:08 GMT Subject: [jdk19] RFR: 8290207: Missing notice in dom.md Message-ID: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> Update dom.md, adding notice. ------------- Commit messages: - 8290207: Missing notice in dom.md Changes: https://git.openjdk.org/jdk19/pull/138/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290207 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/138.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/138/head:pull/138 PR: https://git.openjdk.org/jdk19/pull/138 From naoto at openjdk.org Wed Jul 13 02:03:59 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 13 Jul 2022 02:03:59 GMT Subject: [jdk19] RFR: 8290207: Missing notice in dom.md In-Reply-To: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> Message-ID: <1qukQUNCv6HrOS-jFjeK8ehllE9iXz5wTEAUxSl7UfY=.0f0276d3-97f7-4baf-8aca-75324b77b687@github.com> On Wed, 13 Jul 2022 00:04:24 GMT, Joe Wang wrote: > Update dom.md, adding notice. src/java.xml/share/legal/dom.md line 4: > 2: > 3: ### W3C Software Notice > 4:
        
        Since this is a markdown, should this be three back-ticks "```" instead of "pre" HTML tag?
        
        -------------
        
        PR: https://git.openjdk.org/jdk19/pull/138
        
        From iris at openjdk.org  Wed Jul 13 03:50:39 2022
        From: iris at openjdk.org (Iris Clark)
        Date: Wed, 13 Jul 2022 03:50:39 GMT
        Subject: [jdk19] RFR: 8290207: Missing notice in dom.md
        In-Reply-To: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com>
        References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com>
        Message-ID: 
        
        On Wed, 13 Jul 2022 00:04:24 GMT, Joe Wang  wrote:
        
        > Update dom.md, adding notice.
        
        Marked as reviewed by iris (Reviewer).
        
        -------------
        
        PR: https://git.openjdk.org/jdk19/pull/138
        
        From duke at openjdk.org  Wed Jul 13 05:23:49 2022
        From: duke at openjdk.org (Shruthi)
        Date: Wed, 13 Jul 2022 05:23:49 GMT
        Subject: RFR: 8289471: Issue in Initialization of keys in ErrorMsg.java and
         XPATHErrorResources.java
        In-Reply-To: 
        References: 
        Message-ID: 
        
        On Mon, 4 Jul 2022 17:21:14 GMT, Shruthi  wrote:
        
        > Modifying inaccurate initialization of keys in ErrorMsg.java and XPATHErrorResources.java
        > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8289471
        
        Hi @JoeWang-Java,  could we please review this  PR
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9369
        
        From joehw at openjdk.org  Wed Jul 13 05:51:42 2022
        From: joehw at openjdk.org (Joe Wang)
        Date: Wed, 13 Jul 2022 05:51:42 GMT
        Subject: [jdk19] RFR: 8290207: Missing notice in dom.md
        In-Reply-To: <1qukQUNCv6HrOS-jFjeK8ehllE9iXz5wTEAUxSl7UfY=.0f0276d3-97f7-4baf-8aca-75324b77b687@github.com>
        References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com>
         <1qukQUNCv6HrOS-jFjeK8ehllE9iXz5wTEAUxSl7UfY=.0f0276d3-97f7-4baf-8aca-75324b77b687@github.com>
        Message-ID: 
        
        On Wed, 13 Jul 2022 01:57:43 GMT, Naoto Sato  wrote:
        
        >> Update dom.md, adding notice.
        >
        > src/java.xml/share/legal/dom.md line 4:
        > 
        >> 2: 
        >> 3: ### W3C Software Notice
        >> 4: 
        > 
        > Since this is a markdown, should this be three back-ticks "```" instead of "pre" HTML tag?
        
        Iris can probably comment on this. It's been the pre tag across the existing md files.
        
        -------------
        
        PR: https://git.openjdk.org/jdk19/pull/138
        
        From jpai at openjdk.org  Wed Jul 13 06:04:42 2022
        From: jpai at openjdk.org (Jaikiran Pai)
        Date: Wed, 13 Jul 2022 06:04:42 GMT
        Subject: RFR: 8290178: failure_handler: run netstat without name lookups
        In-Reply-To: 
        References: 
        Message-ID: 
        
        On Tue, 12 Jul 2022 13:16:12 GMT, Daniel Jeli?ski  wrote:
        
        > `netstat -av` in Mac OS X failure handler is frequently running into the 20 second timeout, leaving us with no socket information. This PR proposes running `netstat -anv` along with the existing `netstat -av`, so that we have at least some socket information if the original command times out.
        > 
        > `netstat -anv` does not perform reverse DNS lookups on the socket IP addresses. The output contains IP addresses instead of DNS names. The command usually finishes in a few milliseconds.
        
        Looks fine to me.
        
        @lmesnik, could you also please take a look at this change?
        
        -------------
        
        Marked as reviewed by jpai (Reviewer).
        
        PR: https://git.openjdk.org/jdk/pull/9469
        
        From darcy at openjdk.org  Wed Jul 13 06:06:24 2022
        From: darcy at openjdk.org (Joe Darcy)
        Date: Wed, 13 Jul 2022 06:06:24 GMT
        Subject: RFR: JDK-8289551: Conversions between bit representations of half
         precision values and floats
        Message-ID: 
        
        Initial implementation.
        
        -------------
        
        Commit messages:
         - Further refine spec.
         - Refine spec and tests.
         - Fix implementation thresholds; refine tests.
         - Initial implementation of float -> binary16 round-to-nearest with tests.
         - Implement review feedback from John Rose.
         - Merge branch 'master' into JDK-8289551
         - Merge branch 'master' into JDK-8289551
         - Appease jcheck.
         - Add cardinal value tests.
         - JDK-8289551: Conversions between bit representations of half precision values and floats
        
        Changes: https://git.openjdk.org/jdk/pull/9422/files
         Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=00
          Issue: https://bugs.openjdk.org/browse/JDK-8289551
          Stats: 464 lines in 2 files changed: 464 ins; 0 del; 0 mod
          Patch: https://git.openjdk.org/jdk/pull/9422.diff
          Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422
        
        PR: https://git.openjdk.org/jdk/pull/9422
        
        From darcy at openjdk.org  Wed Jul 13 06:06:24 2022
        From: darcy at openjdk.org (Joe Darcy)
        Date: Wed, 13 Jul 2022 06:06:24 GMT
        Subject: RFR: JDK-8289551: Conversions between bit representations of half
         precision values and floats
        In-Reply-To: 
        References: 
        Message-ID: 
        
        On Fri, 8 Jul 2022 06:11:22 GMT, Joe Darcy  wrote:
        
        > Initial implementation.
        
        Some notes in the current implementation in the PR: the impetus for the change is to provide a minimal level of platform support for the binary16 floating-point format defined in IEEE 754. This is done by added two methods to Float, one for binary16 -> float conversion and the other for float -> binary16 conversion. In the absence of the ability to define primitive types, short is used as a carrier for the bits of a binary16 value.
        
        The conversion code in its current form favors readability over speed; a more performant software implementation may be possible even without intrinsification.
        
        A different 16-bit floating-point format, bfloat, is popular in some circles. Any similar support for bfloat will be left for future work.
        
        Please also review the companion CSR: https://bugs.openjdk.org/browse/JDK-8290216
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9422
        
        From jrose at openjdk.org  Wed Jul 13 06:06:25 2022
        From: jrose at openjdk.org (John R Rose)
        Date: Wed, 13 Jul 2022 06:06:25 GMT
        Subject: RFR: JDK-8289551: Conversions between bit representations of half
         precision values and floats
        In-Reply-To: 
        References: 
        Message-ID: 
        
        On Fri, 8 Jul 2022 06:11:22 GMT, Joe Darcy  wrote:
        
        > Initial implementation.
        
        src/java.base/share/classes/java/lang/Float.java line 1003:
        
        > 1001:         float abs_f = Math.abs(f);
        > 1002:         int doppel = Float.floatToRawIntBits(f);
        > 1003:         int f_sign = 0x8000_0000 & doppel;
        
        The code would be a bit less branchy if sign were computed like this:
        
        short sign_bit = (short)((doppel >> 16) & 0x8000);
        
        and get rid of `f_sign`; instead of conditionals in various places use bitwise or of `sign_bit`, such as:
        
        
        if (abs_f > 65504.0f ) {
          return (short)(sign_bit | 0x7c00);  // Positive or negative infinity
        }
        
        
        I'm mainly looking forward to what the JIT produces, but I also think handling the sign in this way makes the code at least as easy to understand as the current branch-based exposition.
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9422
        
        From jpai at openjdk.org  Wed Jul 13 06:08:39 2022
        From: jpai at openjdk.org (Jaikiran Pai)
        Date: Wed, 13 Jul 2022 06:08:39 GMT
        Subject: RFR: 8249834: java/util/ArrayList/Bug8146568.java and
         j/u/Vector/Bug8148174.java use @ignore w/o bug-id [v2]
        In-Reply-To: 
        References: 
         
        Message-ID: 
        
        On Fri, 8 Jul 2022 21:53:45 GMT, Bill Huang  wrote:
        
        >> Tests Bug8146568 and Bug8148174 were disabled for high memory consumption, over 17G. This is a task to re-enable these two tests by marking them as manual tests.
        >
        > Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
        > 
        >   Added missing backslash in jdk/TEST.groups
        
        Hello Bill,
        The change looks fine to me.
        
        I wasn't aware that a `jdk_core_manual` test group existed. Before merging, please do run a test which exercises either `jdk_core_manual` or `jdk_core_manual_no_input` test group, to make sure this change works fine.
        
        -------------
        
        Marked as reviewed by jpai (Reviewer).
        
        PR: https://git.openjdk.org/jdk/pull/9404
        
        From duke at openjdk.org  Wed Jul 13 07:41:52 2022
        From: duke at openjdk.org (Raffaello Giulietti)
        Date: Wed, 13 Jul 2022 07:41:52 GMT
        Subject: RFR: 8290079: Reduce interaction with volatile in static
         initializer of BigInteger
        In-Reply-To: 
        References: 
         
         
        Message-ID: 
        
        On Tue, 12 Jul 2022 21:16:23 GMT, ?????? ???????  wrote:
        
        >> Usually yes, but since a static initializer is executed by at most one thread by using a locking protocol before any other static code is ever executed, the runtime _could_ (but I'm not sure it it really does) treat the volatile in the for loop as a local.
        >> But I would approve your change because it makes this more explicit.
        >
        > @rgiulietti I've copy-pasted class-loading benchmark from JMH samples
        > 
        > @State(Scope.Thread)
        > @Warmup(iterations = 10, time = 1)
        > @Measurement(iterations = 10, time = 5)
        > @Fork(value = 5, jvmArgsAppend = {"-Xms1g", "-Xmx1g"})
        > @BenchmarkMode(Mode.AverageTime)
        > @OutputTimeUnit(TimeUnit.NANOSECONDS)
        > public class Classy {
        > 
        >     @Benchmark
        >     public Class load() throws ClassNotFoundException {
        >         return Class.forName("com.tsypanov.slp.Sample", true, new XLoader());
        >     }
        > 
        >     public static class XLoader extends URLClassLoader {
        > 
        >         private static final byte[] X_BYTECODE = new byte[]{ /*..*/};
        > 
        >         public XLoader() {
        >             super(new URL[0], ClassLoader.getSystemClassLoader());
        >         }
        > 
        >         @Override
        >         protected Class findClass(final String name) {
        >             return defineClass(name, X_BYTECODE, 0, X_BYTECODE.length);
        >         }
        >     }
        > }
        > 
        > and used it to measure loading a class from `byte[]` copied from the following class compiled:
        > 
        > class Sample {
        >   static volatile int[] items = new int[100];
        >   static {
        >     for (int i = 0; i < items.length; i++) {
        >       items[i] = ThreadLocalRandom.current().nextInt();
        >     }
        >   }
        > }
        > 
        > I ran the benchmark with `java -jar target/sleep-benchmarks.jar Classy -prof cl` and for the version above got these results (Java 17):
        > 
        > Benchmark                       Mode  Cnt       Score      Error        Units
        > Classy.load                     avgt   50   96247.202 ?  548.137        ns/op
        > Classy.load:?class.load         avgt   50  259912.089 ? 1485.314  classes/sec
        > Classy.load:?class.load.norm    avgt   50       1.000 ?    0.001   classes/op
        > Classy.load:?class.unload       avgt   50  260243.318 ? 3673.515  classes/sec
        > Classy.load:?class.unload.norm  avgt   50       1.001 ?    0.014   classes/op
        > 
        > Then I've modified the class in the same way I did in this PR:
        > 
        > class Sample {
        >   static volatile int[] items;
        >   static {
        >     int[] items = new int[100];
        >     for (int i = 0; i < items.length; i++) {
        >       items[i] = ThreadLocalRandom.current().nextInt();
        >     }
        >     Sample.items = items;
        >   }
        > }
        > 
        > and for modified code got
        > 
        > 
        > Benchmark                       Mode  Cnt       Score      Error        Units
        > Classy.load                     avgt   50   63955.673 ?  147.470        ns/op
        > Classy.load:?class.load         avgt   50  391101.854 ?  925.013  classes/sec
        > Classy.load:?class.load.norm    avgt   50       1.000 ?    0.001   classes/op
        > Classy.load:?class.unload       avgt   50  390800.851 ? 2307.589  classes/sec
        > Classy.load:?class.unload.norm  avgt   50       0.999 ?    0.006   classes/op
        > 
        > From this I conclude that volatile costs are still there no matter whether we deal with static or non-static initializers.
        
        @stsypanov Hi ??????, thanks for the convincing measurements!
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9451
        
        From duke at openjdk.org  Wed Jul 13 07:46:42 2022
        From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
        Date: Wed, 13 Jul 2022 07:46:42 GMT
        Subject: RFR: 8287908: Use non-cloning reflection methods where acceptable
         [v3]
        In-Reply-To: 
        References: 
         
        Message-ID: <5Pk9HAxkmR87eEniqfPkeaYNjJb3LWDbyqtkUYBqqWE=.8e6c8cf1-6939-4cf2-becd-649a26e0ecfa@github.com>
        
        On Tue, 14 Jun 2022 19:36:51 GMT, ?????? ???????  wrote:
        
        >> Instead of `Executable.getParameterTypes()` we could use `Executable.getSharedParameterTypes()` in trusted code. Same is applicable for `Executable.getExceptionTypes()`.
        >
        > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
        > 
        >   8287908: Make Executable.getAllGenericParameterTypes() safe
        
        Let's wait
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9064
        
        From dfuchs at openjdk.org  Wed Jul 13 08:39:43 2022
        From: dfuchs at openjdk.org (Daniel Fuchs)
        Date: Wed, 13 Jul 2022 08:39:43 GMT
        Subject: RFR: 8290178: failure_handler: run netstat without name lookups
        In-Reply-To: 
        References: 
        Message-ID: 
        
        On Tue, 12 Jul 2022 13:16:12 GMT, Daniel Jeli?ski  wrote:
        
        > `netstat -av` in Mac OS X failure handler is frequently running into the 20 second timeout, leaving us with no socket information. This PR proposes running `netstat -anv` along with the existing `netstat -av`, so that we have at least some socket information if the original command times out.
        > 
        > `netstat -anv` does not perform reverse DNS lookups on the socket IP addresses. The output contains IP addresses instead of DNS names. The command usually finishes in a few milliseconds.
        
        Marked as reviewed by dfuchs (Reviewer).
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9469
        
        From msheppar at openjdk.org  Wed Jul 13 08:57:43 2022
        From: msheppar at openjdk.org (Mark Sheppard)
        Date: Wed, 13 Jul 2022 08:57:43 GMT
        Subject: RFR: 8290178: failure_handler: run netstat without name lookups
        In-Reply-To: 
        References: 
        Message-ID: <5Thff6ZJLToBbOq7-zqYStR0wB5zneV_IG5YbLtHOBk=.a582a8ef-aebd-4903-9690-6e2b22e2525f@github.com>
        
        On Tue, 12 Jul 2022 13:16:12 GMT, Daniel Jeli?ski  wrote:
        
        > `netstat -av` in Mac OS X failure handler is frequently running into the 20 second timeout, leaving us with no socket information. This PR proposes running `netstat -anv` along with the existing `netstat -av`, so that we have at least some socket information if the original command times out.
        > 
        > `netstat -anv` does not perform reverse DNS lookups on the socket IP addresses. The output contains IP addresses instead of DNS names. The command usually finishes in a few milliseconds.
        
        Marked as reviewed by msheppar (Reviewer).
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9469
        
        From alanb at openjdk.org  Wed Jul 13 09:47:50 2022
        From: alanb at openjdk.org (Alan Bateman)
        Date: Wed, 13 Jul 2022 09:47:50 GMT
        Subject: RFR: 8289284: jdk.tracePinnedThreads output confusing when pinned
         due to native frame [v2]
        In-Reply-To: 
        References: 
        Message-ID: 
        
        > The system property jdk.tracePinnedThreads triggers a stack trace to be printed when a virtual thread parks while pinned. If a virtual thread is pinned due to a native frame there is a spurious " <== monitors:0" added to line for the native method.
        > 
        > A secondary issue is that there is no stack trace when there is Panama downcall as there isn't a native method in the stack trace. A future change may annotate the downcalls, for now the entire stack trace is printed (no filtering) so there is at least some output when pinned due to a call through native code
        
        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:
        
         - PrintStream can auto flush
         - Merge
         - Initial commit
        
        -------------
        
        Changes:
          - all: https://git.openjdk.org/jdk/pull/9308/files
          - new: https://git.openjdk.org/jdk/pull/9308/files/305b8541..ebbbd985
        
        Webrevs:
         - full: https://webrevs.openjdk.org/?repo=jdk&pr=9308&range=01
         - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9308&range=00-01
        
          Stats: 116667 lines in 2199 files changed: 70705 ins; 29043 del; 16919 mod
          Patch: https://git.openjdk.org/jdk/pull/9308.diff
          Fetch: git fetch https://git.openjdk.org/jdk pull/9308/head:pull/9308
        
        PR: https://git.openjdk.org/jdk/pull/9308
        
        From alanb at openjdk.org  Wed Jul 13 09:47:52 2022
        From: alanb at openjdk.org (Alan Bateman)
        Date: Wed, 13 Jul 2022 09:47:52 GMT
        Subject: RFR: 8289284: jdk.tracePinnedThreads output confusing when pinned
         due to native frame
        In-Reply-To: 
        References: 
         
        Message-ID: <49KS1rd5AumzlIhVRN47Nw4ZIVB0Z21yyLY_FBoBjWU=.ee091757-a750-4f0d-9fb2-040d0e6a9a4d@github.com>
        
        On Tue, 12 Jul 2022 07:20:24 GMT, Jaikiran Pai  wrote:
        
        > Would printing this reason be useful for easily understanding why the thread was considered pinned? I guess the same could be inferred from the stacktraces right now?
        
        The stack trace shows the native frames and highlights any frames with monitors. So the "reason" isn't currently needed.
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9308
        
        From alanb at openjdk.org  Wed Jul 13 09:47:52 2022
        From: alanb at openjdk.org (Alan Bateman)
        Date: Wed, 13 Jul 2022 09:47:52 GMT
        Subject: RFR: 8289284: jdk.tracePinnedThreads output confusing when pinned
         due to native frame [v2]
        In-Reply-To: 
        References: 
         
        Message-ID: 
        
        On Tue, 12 Jul 2022 07:22:14 GMT, Jaikiran Pai  wrote:
        
        > The change here removes the previous call to flush the `System.out`. I believe that's fine because the `PrintStream` here is backed by a `ByteArrayOutputStream` so the flush isn't necessary.
        
        That's a good observation, it would be more robust for the test to create the PrintStream with "auto flush" or use an explicit flush. It works now because there is sufficient output to trigger flushing. So I'll change this to auto flush - thanks!
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9308
        
        From hannesw at openjdk.org  Wed Jul 13 09:55:14 2022
        From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
        Date: Wed, 13 Jul 2022 09:55:14 GMT
        Subject: RFR: JDK-8288624: Cleanup CommentHelper.getText0 [v5]
        In-Reply-To: 
        References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com>
         
        Message-ID: <7LAD-__aVhDd0t_4wpoMKw61flNmwCg0ebSLZrTsm1g=.275117e0-ff8d-4460-a93c-2a4779fc2ac3@github.com>
        
        On Tue, 12 Jul 2022 17:04:40 GMT, Jonathan Gibbons  wrote:
        
        >> Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads.
        >> 
        >> This is moderately simple, because most of the heavy lifting was done in 
        >> [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`.
        >> 
        >> The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`.
        >> 
        >> Two bugs were uncovered as a result of the cleanup.  These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488)  
        >> 
        >> Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language.
        >> 
        >> Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored.  However, one tweak was necessary.
        >> The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type.
        >> This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `...` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`.
        >> 
        >> Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored.  All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work.
        >
        > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
        > 
        >   fix regex for entities
        
        Looks good!
        
        -------------
        
        Marked as reviewed by hannesw (Reviewer).
        
        PR: https://git.openjdk.org/jdk/pull/9438
        
        From lancea at openjdk.org  Wed Jul 13 10:15:20 2022
        From: lancea at openjdk.org (Lance Andersen)
        Date: Wed, 13 Jul 2022 10:15:20 GMT
        Subject: [jdk19] RFR: 8290207: Missing notice in dom.md
        In-Reply-To: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com>
        References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com>
        Message-ID: 
        
        On Wed, 13 Jul 2022 00:04:24 GMT, Joe Wang  wrote:
        
        > Update dom.md, adding notice.
        
        Marked as reviewed by lancea (Reviewer).
        
        -------------
        
        PR: https://git.openjdk.org/jdk19/pull/138
        
        From lancea at openjdk.org  Wed Jul 13 10:15:23 2022
        From: lancea at openjdk.org (Lance Andersen)
        Date: Wed, 13 Jul 2022 10:15:23 GMT
        Subject: [jdk19] RFR: 8290207: Missing notice in dom.md
        In-Reply-To: 
        References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com>
         <1qukQUNCv6HrOS-jFjeK8ehllE9iXz5wTEAUxSl7UfY=.0f0276d3-97f7-4baf-8aca-75324b77b687@github.com>
         
        Message-ID: 
        
        On Wed, 13 Jul 2022 05:31:27 GMT, Joe Wang  wrote:
        
        >> src/java.xml/share/legal/dom.md line 4:
        >> 
        >>> 2: 
        >>> 3: ### W3C Software Notice
        >>> 4: 
        >> 
        >> Since this is a markdown, should this be three back-ticks "```" instead of "pre" HTML tag?
        >
        > Iris can probably comment on this. It's been the pre tag across the existing md files.
        
        The pre tag is supported for code blocks by most markdown implementations so this should be OK and as Joe mentions has been there for ages in this file.
        
        -------------
        
        PR: https://git.openjdk.org/jdk19/pull/138
        
        From jpai at openjdk.org  Wed Jul 13 10:46:05 2022
        From: jpai at openjdk.org (Jaikiran Pai)
        Date: Wed, 13 Jul 2022 10:46:05 GMT
        Subject: RFR: 8289284: jdk.tracePinnedThreads output confusing when pinned
         due to native frame [v2]
        In-Reply-To: 
        References: 
         
        Message-ID: 
        
        On Wed, 13 Jul 2022 09:47:50 GMT, Alan Bateman  wrote:
        
        >> The system property jdk.tracePinnedThreads triggers a stack trace to be printed when a virtual thread parks while pinned. If a virtual thread is pinned due to a native frame there is a spurious " <== monitors:0" added to line for the native method.
        >> 
        >> A secondary issue is that there is no stack trace when there is Panama downcall as there isn't a native method in the stack trace. A future change may annotate the downcalls, for now the entire stack trace is printed (no filtering) so there is at least some output when pinned due to a call through native code
        >
        > 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:
        > 
        >  - PrintStream can auto flush
        >  - Merge
        >  - Initial commit
        
        Thank you for the update. This looks fine to me.
        
        -------------
        
        Marked as reviewed by jpai (Reviewer).
        
        PR: https://git.openjdk.org/jdk/pull/9308
        
        From dl at openjdk.org  Wed Jul 13 11:22:29 2022
        From: dl at openjdk.org (Doug Lea)
        Date: Wed, 13 Jul 2022 11:22:29 GMT
        Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed
         with java.lang.Exception: Reference Handler thread died [v2]
        In-Reply-To: 
        References: 
        Message-ID: 
        
        > 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died
        
        Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
        
          Don't bother creating static exceptions
        
        -------------
        
        Changes:
          - all: https://git.openjdk.org/jdk/pull/9427/files
          - new: https://git.openjdk.org/jdk/pull/9427/files/4fcabd00..1aa540ca
        
        Webrevs:
         - full: https://webrevs.openjdk.org/?repo=jdk&pr=9427&range=01
         - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9427&range=00-01
        
          Stats: 87 lines in 4 files changed: 0 ins; 41 del; 46 mod
          Patch: https://git.openjdk.org/jdk/pull/9427.diff
          Fetch: git fetch https://git.openjdk.org/jdk pull/9427/head:pull/9427
        
        PR: https://git.openjdk.org/jdk/pull/9427
        
        From dl at openjdk.org  Wed Jul 13 11:22:31 2022
        From: dl at openjdk.org (Doug Lea)
        Date: Wed, 13 Jul 2022 11:22:31 GMT
        Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed
         with java.lang.Exception: Reference Handler thread died [v2]
        In-Reply-To: 
        References: 
         
         
        Message-ID: 
        
        On Mon, 11 Jul 2022 04:18:20 GMT, David Holmes  wrote:
        
        >> src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java line 463:
        >> 
        >>> 461:      *  Preallocated exceptions thrown if acquiring or releasing locks
        >>> 462:      *  when OutOfMemory.
        >>> 463:      */
        >> 
        >> I don't see why this should be necessary. IMSE is thrown before any state changes occur and so it is is fine if the IMSE is replaced by OOME.
        >> 
        >> Even IE should be safe at the points it is thrown.
        >> 
        >> Also in both cases you want to see a full and proper stacktrace.
        >
        > Consider this another way, any place you have a `throw x` it must be safe to propagate that exception. It doesn't matter if that is actually `x` or an OOME caused by creating `x`.
        
        On further consideration, I agree. The very low probability that an IE or IMSE would enable further handling is not worth the extra startup cost of establishing static exceptions. Updated.
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9427
        
        From dl at openjdk.org  Wed Jul 13 11:22:32 2022
        From: dl at openjdk.org (Doug Lea)
        Date: Wed, 13 Jul 2022 11:22:32 GMT
        Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed
         with java.lang.Exception: Reference Handler thread died [v2]
        In-Reply-To: 
        References: 
         
        Message-ID: <4wvDO8xRhnIocKU9TwCgs2ZHetPIbHM5RYDbwABxuf8=.a7f2a85a-7d3a-458b-9d97-c315a08afd70@github.com>
        
        On Tue, 12 Jul 2022 15:03:46 GMT, Alan Bateman  wrote:
        
        >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
        >> 
        >>   Don't bother creating static exceptions
        >
        > test/jdk/ProblemList.txt line 498:
        > 
        >> 496: java/lang/invoke/lambda/LambdaFileEncodingSerialization.java    8249079 linux-x64
        >> 497: java/lang/invoke/RicochetTest.java                              8251969 generic-all
        >> 498: java/lang/CompressExpandTest.java                               8287851 generic-all
        > 
        > There may be merge issue here. JDK-8287851 was fixed last week and the CompressExpandTest.java removed from the exclude list at the same time.
        
        Thanks. fixed.
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9427
        
        From jwilhelm at openjdk.org  Wed Jul 13 12:22:55 2022
        From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
        Date: Wed, 13 Jul 2022 12:22:55 GMT
        Subject: RFR: Merge jdk19
        Message-ID: <0kV4AZaoLszVYbNjgtP-POvZBo8IlSUi1DhF5G6YYrc=.b18a6389-52ff-4d1a-95de-f537f506fef4@github.com>
        
        Forwardport JDK 19 -> JDK 20
        
        -------------
        
        Commit messages:
         - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
         - 8290203: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java on linux-all
         - 8290201: ProblemList com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode
         - 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out
         - 8289930: Improve Thread description of inherited AccessControlContext
         - 8289365: SegmentAllocator:allocateArray(MemoryLayout, count) does not throw IAEx when count is -1
         - 8290071: Javadoc for MemorySegment/MemoryAddress getter/setters contains some typos
         - 8288850: SegmentAllocator:allocate() can return null some cases
        
        The webrevs contain the adjustments done while merging with regards to each parent branch:
         - master: https://webrevs.openjdk.org/?repo=jdk&pr=9479&range=00.0
         - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9479&range=00.1
        
        Changes: https://git.openjdk.org/jdk/pull/9479/files
          Stats: 120 lines in 9 files changed: 59 ins; 3 del; 58 mod
          Patch: https://git.openjdk.org/jdk/pull/9479.diff
          Fetch: git fetch https://git.openjdk.org/jdk pull/9479/head:pull/9479
        
        PR: https://git.openjdk.org/jdk/pull/9479
        
        From rriggs at openjdk.org  Wed Jul 13 13:17:41 2022
        From: rriggs at openjdk.org (Roger Riggs)
        Date: Wed, 13 Jul 2022 13:17:41 GMT
        Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with
         "Failed to unload native library"
        Message-ID: 
        
        The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java`
        Fails intermittently when expected output from a subprocess is not found.
        
        I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced.
        
        The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded.
        The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released.
        When released the child process exits and the driver test will find all of the output it expects.
        
        -------------
        
        Commit messages:
         - 8289919: Failed to unload native library
        
        Changes: https://git.openjdk.org/jdk/pull/9474/files
         Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9474&range=00
          Issue: https://bugs.openjdk.org/browse/JDK-8289919
          Stats: 58 lines in 4 files changed: 45 ins; 0 del; 13 mod
          Patch: https://git.openjdk.org/jdk/pull/9474.diff
          Fetch: git fetch https://git.openjdk.org/jdk pull/9474/head:pull/9474
        
        PR: https://git.openjdk.org/jdk/pull/9474
        
        From jpai at openjdk.org  Wed Jul 13 13:17:41 2022
        From: jpai at openjdk.org (Jaikiran Pai)
        Date: Wed, 13 Jul 2022 13:17:41 GMT
        Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with
         "Failed to unload native library"
        In-Reply-To: 
        References: 
        Message-ID: 
        
        On Tue, 12 Jul 2022 20:00:22 GMT, Roger Riggs  wrote:
        
        > The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java`
        > Fails intermittently when expected output from a subprocess is not found.
        > 
        > I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced.
        > 
        > The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded.
        > The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released.
        > When released the child process exits and the driver test will find all of the output it expects.
        
        Hello Roger,
        
        > and the test code that exits as soon as it detects that the p.Class1 is no longer referenced.
        
        Looking at the `LoadLibraryUnload` test, the `clazz` against which the `WeakReference` is being made in that test, gets updated in a loop https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java#L113 and thus the `WeakReference` happens to be against the last loop iteration's `clazz` https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java#L149
        
        >From what I understand of that test code, this `clazz` instance against which the `WeakReference` is being created, may not be the right one, since it isn't guaranteed that the classloader of this `clazz` is the one which "won" the attempt to load the native library. Do you think this (too) might be playing a role in this intermittent failure?
        
        
        (It looks like a RFR mail didn't get generated for this one due to the missing issue description in the title of this PR)
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9474
        
        From rriggs at openjdk.org  Wed Jul 13 13:30:03 2022
        From: rriggs at openjdk.org (Roger Riggs)
        Date: Wed, 13 Jul 2022 13:30:03 GMT
        Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with
         "Failed to unload native library"
        In-Reply-To: 
        References: 
        Message-ID: 
        
        On Tue, 12 Jul 2022 20:00:22 GMT, Roger Riggs  wrote:
        
        > The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java`
        > Fails intermittently when expected output from a subprocess is not found.
        > 
        > I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced.
        > 
        > The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded.
        > The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released.
        > When released the child process exits and the driver test will find all of the output it expects.
        
        Yes, waiting for only the final Class1 loaded from the class loaders is suspect.
        There is no deterministic order to the clearing/queuing of the WeakReferences/PhantomReferences to the classes or the respective class loaders.  The test is looking for the call to the library's "_OnUnload" function to be printed to the output.
        That happens sometime after the (successful) class loader is reclaimed; waiting on that reclamation isn't sufficient.
        I'll remove the waiting on the Class1.
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9474
        
        From dl at openjdk.org  Wed Jul 13 14:00:09 2022
        From: dl at openjdk.org (Doug Lea)
        Date: Wed, 13 Jul 2022 14:00:09 GMT
        Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed
         with java.lang.Exception: Reference Handler thread died [v3]
        In-Reply-To: 
        References: 
        Message-ID: 
        
        > 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died
        
        Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
        
          Unspecialize catch to allow OOME
        
        -------------
        
        Changes:
          - all: https://git.openjdk.org/jdk/pull/9427/files
          - new: https://git.openjdk.org/jdk/pull/9427/files/1aa540ca..59ede960
        
        Webrevs:
         - full: https://webrevs.openjdk.org/?repo=jdk&pr=9427&range=02
         - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9427&range=01-02
        
          Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
          Patch: https://git.openjdk.org/jdk/pull/9427.diff
          Fetch: git fetch https://git.openjdk.org/jdk pull/9427/head:pull/9427
        
        PR: https://git.openjdk.org/jdk/pull/9427
        
        From rriggs at openjdk.org  Wed Jul 13 14:06:00 2022
        From: rriggs at openjdk.org (Roger Riggs)
        Date: Wed, 13 Jul 2022 14:06:00 GMT
        Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with
         "Failed to unload native library" [v2]
        In-Reply-To: 
        References: 
        Message-ID: 
        
        > The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java`
        > Fails intermittently when expected output from a subprocess is not found.
        > 
        > I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced.
        > 
        > The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded.
        > The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released.
        > When released the child process exits and the driver test will find all of the output it expects.
        
        Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
        
          Cleanup waiting for library unload
        
        -------------
        
        Changes:
          - all: https://git.openjdk.org/jdk/pull/9474/files
          - new: https://git.openjdk.org/jdk/pull/9474/files/ce2425fd..68532938
        
        Webrevs:
         - full: https://webrevs.openjdk.org/?repo=jdk&pr=9474&range=01
         - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9474&range=00-01
        
          Stats: 16 lines in 1 file changed: 4 ins; 4 del; 8 mod
          Patch: https://git.openjdk.org/jdk/pull/9474.diff
          Fetch: git fetch https://git.openjdk.org/jdk pull/9474/head:pull/9474
        
        PR: https://git.openjdk.org/jdk/pull/9474
        
        From duke at openjdk.org  Wed Jul 13 14:18:12 2022
        From: duke at openjdk.org (Raffaello Giulietti)
        Date: Wed, 13 Jul 2022 14:18:12 GMT
        Subject: RFR: JDK-8289551: Conversions between bit representations of half
         precision values and floats
        In-Reply-To: 
        References: 
        Message-ID: 
        
        On Fri, 8 Jul 2022 06:11:22 GMT, Joe Darcy  wrote:
        
        > Initial implementation.
        
        src/java.base/share/classes/java/lang/Float.java line 1044:
        
        > 1042:         }
        > 1043: 
        > 1044:         assert -14 <= bin16Exp  && bin16Exp <= 15;
        
        assert -15 < bin16Exp  && bin16Exp < 16;
        
        is perhaps more readable because the code above uses -15 and 16: less mental calculation at no runtime costs ;-)
        
        src/java.base/share/classes/java/lang/Float.java line 1056:
        
        > 1054:                    // formats
        > 1055:                    (bin16SignifBits << (FloatConsts.SIGNIFICAND_WIDTH - 11)));
        > 1056:         return sign * Float.intBitsToFloat(result);
        
        int result = (floatExpBits |
                           // Shift left difference in the number of
                           // significand bits in the float and binary16
                           // formats
                           (bin16SignifBits << (FloatConsts.SIGNIFICAND_WIDTH - 11)));
        
        
        avoids a useless `|` operation
        
        src/java.base/share/classes/java/lang/Float.java line 1090:
        
        > 1088:     public static short floatToBinary16AsShortBits(float f) {
        > 1089:         if (Float.isNaN(f)) {
        > 1090:             // Arbitrary binary16 NaN value; could try to preserve the
        
        // Arbitrary binary16 quiet NaN value; could try to preserve the
        
        src/java.base/share/classes/java/lang/Float.java line 1100:
        
        > 1098: 
        > 1099:         // The overflow threshold is binary16 MAX_VALUE + 1/2 ulp
        > 1100:         if (abs_f > (65504.0f + 16.0f) ) {
        
        if (abs_f >= (65504.0f + 16.0f) ) {
        
        Value exactly halfway must round to infinity.
        
        src/java.base/share/classes/java/lang/Float.java line 1124:
        
        > 1122:                 // 2^(-125) -- since (-125 = -149 - (-24)) -- so that
        > 1123:                 // the trailing bits of a subnormal float represent
        > 1124:                 // the correct trailing bits of a binary16 subnormal.
        
        I would write intervals (ranges) in the form `[low, high]`, so `[-24, -15]` and `[-149, -140]`.
        
        src/java.base/share/classes/java/lang/Float.java line 1127:
        
        > 1125:                 exp = -15; // Subnormal encoding using -E_max.
        > 1126:                 float f_adjust = abs_f * 0x1.0p-125f;
        > 1127:                 signif_bits = (short)(Float.floatToRawIntBits(f_adjust) & 0x03ff);
        
        I think the `if` and the `exp++` can be avoided if the `& 0x03ff` is dropped altogether.
        
                       signif_bits = (short)Float.floatToRawIntBits(f_adjust);
        
        The reason is the same as for the normalized case below: a carry will eventually flow into the representation for the exponent.
        
        src/java.base/share/classes/java/lang/Float.java line 1141:
        
        > 1139: 
        > 1140:                 // Significand bits as if using rounding to zero (truncation).
        > 1141:                 signif_bits = (short)((doppel & 0x0007f_e000) >>
        
        signif_bits = (short)((doppel & 0x007f_e000) >>
        
        or even
        
                       signif_bits = (short)((doppel & 0x007f_ffff) >>
        
        32 bit hex are more readable when they have 8 hex digits
        
        src/java.base/share/classes/java/lang/Float.java line 1163:
        
        > 1161:                 int round =  doppel & 0x00000_1000;
        > 1162:                 int sticky = doppel & 0x00000_0fff;
        > 1163: 
        
        int lsb    = doppel & 0x0000_2000;
                        int round  = doppel & 0x0000_1000;
                        int sticky = doppel & 0x0000_0fff;
        
        As above, these are 32 bit hex constants and should have at most 8 hex digits.
        
        src/java.base/share/classes/java/lang/Float.java line 1166:
        
        > 1164:                 if (((lsb == 0) && (round != 0) && (sticky != 0)) ||
        > 1165:                     ( lsb != 0  &&  round != 0 ) ) { // sticky not needed
        > 1166:                     // Due to the representational properties, an
        
        if (round != 0 && (sticky != 0 || lsb != 0)) {
        
        is more succinct.
        
        src/java.base/share/classes/java/lang/Float.java line 1174:
        
        > 1172: 
        > 1173:             short result = 0;
        > 1174:             result = (short)(((exp + 15) << 10) | signif_bits);
        
        result = (short)(((exp + 15) << 10) + signif_bits);
        
        The final exponent needs to be incremented when `signif_bits == 0x400`. The `|` is not enough for this to happen.
        
        src/java.base/share/classes/java/lang/Float.java line 1175:
        
        > 1173:             short result = 0;
        > 1174:             result = (short)(((exp + 15) << 10) | signif_bits);
        > 1175:             return (short)(sign_bit | (0x7fff & result));
        
        return (short)(sign_bit | result);
        
        because `result <= 0x7fff`.
        
        -------------
        
        PR: https://git.openjdk.org/jdk/pull/9422
        
        From alanb at openjdk.org  Wed Jul 13 14:36:04 2022
        From: alanb at openjdk.org (Alan Bateman)
        Date: Wed, 13 Jul 2022 14:36:04 GMT
        Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed
         with java.lang.Exception: Reference Handler thread died [v3]
        In-Reply-To: 
        References: 
         
        Message-ID: 
        
        On Wed, 13 Jul 2022 14:00:09 GMT, Doug Lea 
        wrote: >> 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Unspecialize catch to allow OOME test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java line 1: > 1: //package concurrent; Do you mind adding a copyright header to the test? ------------- PR: https://git.openjdk.org/jdk/pull/9427 From jjg at openjdk.org Wed Jul 13 14:49:12 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 13 Jul 2022 14:49:12 GMT Subject: Integrated: JDK-8288624: Cleanup CommentHelper.getText0 In-Reply-To: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com> References: <9uN7bfC5s3czzTIv0_8KWn-xB2Cl6jbGayoMK4ro0Y0=.f9615fd9-d903-47bf-8a93-02129afd0209@github.com> Message-ID: On Sat, 9 Jul 2022 01:55:32 GMT, Jonathan Gibbons wrote: > Please review a moderately simple fix to clean up (as in _remove_!) `CommentHelper.getText` and friends/overloads. > > This is moderately simple, because most of the heavy lifting was done in > [JDK-8288699](https://bugs.openjdk.org/browse/JDK-8288624), to clean up `commentTagsToContent`. > > The uses of `CommentHelper.getText` can generally be replaced by either `commentTagsToContent` or just `DocTree.toString()`. > > Two bugs were uncovered as a result of the cleanup. These are described in detail in a comment with screenshots in the [bug report](https://bugs.openjdk.org/browse/JDK-8288624?focusedCommentId=14508488&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508488) > > Fixing the `see-list-long` bug was a direct reason to cleanup `commentTagsToContent`. The fix here could maybe be further improved by writing a simple visitor or (preferably) a pattern-switch when that is a standard feature of the language. > > Fixing the other bug was mostly an accidental side-effect of just using `commentTagsToContent` instead of `CommentHelper.getText`, since the tags now get interpreted instead of ignored. However, one tweak was necessary. > The doc comments for serialization info end up in `serialized-form.html` and not in the primary file for the enclosing type. > This means they should not undergo the standard `redirectRelativeLinks` treatment. Links using `{@link...}` are not affected, but links using explicit `...` are affected. Ideally, we should not be using such relative links in the JDK API documentation, but there are too many to change/fix as part of this work. The fix, for now, is to add a new overload to `commentTagsToContent` that provides the ability to disable the call to `redirectRelativeLinks` when needed ... that is, when generating `serialized-form.html`. > > Initially, the goal was just a cleanup fix with no change to tests. The work has been tested by comparing generated docs before and after this work. There are a number of instances of differences in the generated docs, but all are instances of the bugs described above ... either the `see-list-long` bug, or the change that inline doc comment tags are now interpretedin places where they were previously ignored. All existing tests continue to work without modification; new tests have been added for the fixes for the bugs that were discovered in the course of this work. This pull request has now been integrated. Changeset: 572c14ef Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/572c14efc67860e75edaa50608b4c61aec5997da Stats: 406 lines in 12 files changed: 209 ins; 169 del; 28 mod 8288624: Cleanup CommentHelper.getText0 Reviewed-by: hannesw ------------- PR: https://git.openjdk.org/jdk/pull/9438 From rriggs at openjdk.org Wed Jul 13 15:04:05 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 13 Jul 2022 15:04:05 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger In-Reply-To: References: Message-ID: <5qhIzkwCQ5O0ITz-YcYPdh6f998BZ_5YVLHbfNKZa98=.4bba1b02-cb2d-448a-a5c4-4a23abb586f0@github.com> On Mon, 11 Jul 2022 12:41:48 GMT, ?????? ??????? wrote: > `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. src/java.base/share/classes/java/math/BigInteger.java line 1276: > 1274: * on demand. > 1275: */ > 1276: BigInteger[][] powerCache = new BigInteger[Character.MAX_RADIX+1][]; Using a different local name will avoid the shadowing and make it more obvious that the initialization is being deliberately being done before the assignment to a volatile. ------------- PR: https://git.openjdk.org/jdk/pull/9451 From alanb at openjdk.org Wed Jul 13 15:06:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Jul 2022 15:06:11 GMT Subject: Integrated: 8289284: jdk.tracePinnedThreads output confusing when pinned due to native frame In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 10:44:01 GMT, Alan Bateman wrote: > The system property jdk.tracePinnedThreads triggers a stack trace to be printed when a virtual thread parks while pinned. If a virtual thread is pinned due to a native frame there is a spurious " <== monitors:0" added to line for the native method. > > A secondary issue is that there is no stack trace when there is Panama downcall as there isn't a native method in the stack trace. A future change may annotate the downcalls, for now the entire stack trace is printed (no filtering) so there is at least some output when pinned due to a call through native code This pull request has now been integrated. Changeset: f528124f Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/f528124f571a29da49defbef30eeca04ab4a00ce Stats: 115 lines in 4 files changed: 91 ins; 7 del; 17 mod 8289284: jdk.tracePinnedThreads output confusing when pinned due to native frame Reviewed-by: jpai, mchung ------------- PR: https://git.openjdk.org/jdk/pull/9308 From duke at openjdk.org Wed Jul 13 15:11:25 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 13 Jul 2022 15:11:25 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v4] In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: > We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. > > Benchmark results: > > before > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op > StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op > > after > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op > StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op ?????? ??????? 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: - 8289908: Rework constructor - Merge branch 'master' into 8289908 - 8289908: Fixed tests - Merge branch 'master' into 8289908 - 8289908: Make constructor private and use trailing Void instead of int - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9407/files - new: https://git.openjdk.org/jdk/pull/9407/files/b7375cd3..f653a67b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=02-03 Stats: 62100 lines in 564 files changed: 33281 ins; 20833 del; 7986 mod Patch: https://git.openjdk.org/jdk/pull/9407.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407 PR: https://git.openjdk.org/jdk/pull/9407 From duke at openjdk.org Wed Jul 13 15:11:26 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 13 Jul 2022 15:11:26 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v4] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Tue, 12 Jul 2022 15:57:12 GMT, Roger Riggs wrote: >> Benchmark results after: >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,354 ? 0,195 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,035 ? 0,088 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,166 ? 0,062 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 4,132 ? 0,054 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,416 ? 0,206 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,421 ? 0,041 ns/op > > Matching the existing Void argument looks better. > The new private method should have a comment saying that it does not do any precondition checks on the arguments. > > (Reordering the arguments is an alternative to adding an argument, for example, (Charset, byte[], int, int). > But it is less readable and can raise questions due to the different order of arguments.) Updated PR. With newer version I get these results: Benchmark Mode Cnt Score Error Units StringConstructor.newStringFromArray avgt 50 4,831 ? 0,205 ns/op StringConstructor.newStringFromArrayWithCharset avgt 50 3,940 ? 0,008 ns/op StringConstructor.newStringFromArrayWithCharsetName avgt 50 7,662 ? 0,112 ns/op StringConstructor.newStringFromRangedArray avgt 50 4,175 ? 0,065 ns/op StringConstructor.newStringFromRangedArrayWithCharset avgt 50 3,970 ? 0,037 ns/op StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,480 ? 0,014 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/9407 From duke at openjdk.org Wed Jul 13 15:21:15 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Wed, 13 Jul 2022 15:21:15 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 06:11:22 GMT, Joe Darcy wrote: > Initial implementation. test/jdk/java/lang/Float/SixteenBitFormats.java line 239: > 237: public static boolean isNaN(short binary16) { > 238: return ((binary16 & 0x7c00) == 0x7c00) // Max exponent and... > 239: && ((binary16 & 0x03ff) != 0 ); // significand nonzero. return (binary16 & 0x7fff) > 0x7c00; is more concise test/jdk/java/lang/Float/SixteenBitFormats.java line 244: > 242: public static short negate(short binary16) { > 243: return (short)(((binary16 & 0x8000) ^ 0x8000) | // Isolate and flip sign bit > 244: (binary16 & 0x7fff)); return (short)(binary16 ^ 0x8000); is shorter test/jdk/java/lang/Float/SixteenBitFormats.java line 263: > 261: } > 262: } > 263: } The last invocation to `Integer.compare()` is not correct. For example, if `bin16_1 = -1 `and `bin16_2 = 1`, the invocation returns 1, which is incorrect. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From duke at openjdk.org Wed Jul 13 15:32:18 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 13 Jul 2022 15:32:18 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger [v2] In-Reply-To: References: Message-ID: > `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290079: Rename local var ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9451/files - new: https://git.openjdk.org/jdk/pull/9451/files/15971c4c..1f51992b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9451&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9451&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9451.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9451/head:pull/9451 PR: https://git.openjdk.org/jdk/pull/9451 From duke at openjdk.org Wed Jul 13 15:32:21 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 13 Jul 2022 15:32:21 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger [v2] In-Reply-To: <5qhIzkwCQ5O0ITz-YcYPdh6f998BZ_5YVLHbfNKZa98=.4bba1b02-cb2d-448a-a5c4-4a23abb586f0@github.com> References: <5qhIzkwCQ5O0ITz-YcYPdh6f998BZ_5YVLHbfNKZa98=.4bba1b02-cb2d-448a-a5c4-4a23abb586f0@github.com> Message-ID: <0Zous2I2RHsSl0q2Z-MDYJF9QEGKmNVHZkKy3mHgIN8=.cf972688-ad98-4c63-8fd8-427724a2bc8b@github.com> On Wed, 13 Jul 2022 15:00:07 GMT, Roger Riggs wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290079: Rename local var > > src/java.base/share/classes/java/math/BigInteger.java line 1276: > >> 1274: * on demand. >> 1275: */ >> 1276: BigInteger[][] powerCache = new BigInteger[Character.MAX_RADIX+1][]; > > Using a different local name will avoid the shadowing and make it more obvious that the initialization is being deliberately being done before the assignment to a volatile. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9451 From rriggs at openjdk.org Wed Jul 13 15:47:12 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 13 Jul 2022 15:47:12 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v4] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Wed, 13 Jul 2022 15:11:25 GMT, ?????? ??????? wrote: >> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. >> >> Benchmark results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op >> >> after >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op > > ?????? ??????? 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: > > - 8289908: Rework constructor > - Merge branch 'master' into 8289908 > - 8289908: Fixed tests > - Merge branch 'master' into 8289908 > - 8289908: Make constructor private and use trailing Void instead of int > - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] Looks good, thanks for the updates. src/java.base/share/classes/java/lang/String.java line 528: > 526: *

        > 527: * Important: parameter order of this method is deliberately changed in order to > 528: * disambiguate it against other similar methods ot this class. typo? "ot this". ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9407 From rriggs at openjdk.org Wed Jul 13 15:50:10 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 13 Jul 2022 15:50:10 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger [v2] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 15:32:18 GMT, ?????? ??????? wrote: >> `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290079: Rename local var LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9451 From naoto at openjdk.org Wed Jul 13 16:26:12 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 13 Jul 2022 16:26:12 GMT Subject: [jdk19] RFR: 8290207: Missing notice in dom.md In-Reply-To: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> Message-ID: On Wed, 13 Jul 2022 00:04:24 GMT, Joe Wang wrote: > Update dom.md, adding notice. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/138 From iris at openjdk.org Wed Jul 13 16:31:04 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 13 Jul 2022 16:31:04 GMT Subject: [jdk19] RFR: 8290207: Missing notice in dom.md In-Reply-To: References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> <1qukQUNCv6HrOS-jFjeK8ehllE9iXz5wTEAUxSl7UfY=.0f0276d3-97f7-4baf-8aca-75324b77b687@github.com> Message-ID: On Wed, 13 Jul 2022 10:13:09 GMT, Lance Andersen wrote: >> Iris can probably comment on this. It's been the pre tag across the existing md files. > > The pre tag is supported for code blocks by most markdown implementations so this should be OK and as Joe mentions has been there for ages in this file. Agree. I think the `pre` tag will be fine in this instance. ------------- PR: https://git.openjdk.org/jdk19/pull/138 From joehw at openjdk.org Wed Jul 13 16:34:14 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 13 Jul 2022 16:34:14 GMT Subject: [jdk19] RFR: 8290207: Missing notice in dom.md In-Reply-To: References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> <1qukQUNCv6HrOS-jFjeK8ehllE9iXz5wTEAUxSl7UfY=.0f0276d3-97f7-4baf-8aca-75324b77b687@github.com> Message-ID: On Wed, 13 Jul 2022 16:28:10 GMT, Iris Clark wrote: >> The pre tag is supported for code blocks by most markdown implementations so this should be OK and as Joe mentions has been there for ages in this file. > > Agree. I think the `pre` tag will be fine in this instance. Thanks! ------------- PR: https://git.openjdk.org/jdk19/pull/138 From darcy at openjdk.org Wed Jul 13 16:55:19 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 13 Jul 2022 16:55:19 GMT Subject: RFR: 8290079: Reduce interaction with volatile in static initializer of BigInteger [v2] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 15:32:18 GMT, ?????? ??????? wrote: >> `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290079: Rename local var Version with renamed local variable looks fine. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/9451 From dl at openjdk.org Wed Jul 13 16:58:21 2022 From: dl at openjdk.org (Doug Lea) Date: Wed, 13 Jul 2022 16:58:21 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died [v4] In-Reply-To: References: Message-ID: > 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died Doug Lea has updated the pull request incrementally with one additional commit since the last revision: copyright header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9427/files - new: https://git.openjdk.org/jdk/pull/9427/files/59ede960..ca096801 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9427&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9427&range=02-03 Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9427.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9427/head:pull/9427 PR: https://git.openjdk.org/jdk/pull/9427 From dl at openjdk.org Wed Jul 13 17:02:08 2022 From: dl at openjdk.org (Doug Lea) Date: Wed, 13 Jul 2022 17:02:08 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died [v3] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 14:32:35 GMT, Alan Bateman wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Unspecialize catch to allow OOME > > test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java line 1: > >> 1: //package concurrent; > > Do you mind adding a copyright header to the test? OK, done. ------------- PR: https://git.openjdk.org/jdk/pull/9427 From joehw at openjdk.org Wed Jul 13 17:35:20 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 13 Jul 2022 17:35:20 GMT Subject: [jdk19] Integrated: 8290207: Missing notice in dom.md In-Reply-To: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> References: <2qLvQw9Qhg52dEboY7EE-_oQY1L4FC_KPb8SJbuD8Vw=.0cd9f78a-cab0-49fc-8468-8d46f56fa4c7@github.com> Message-ID: <1-0PbbY46g8vRlrjWVNySQgEHmXk_vnIdP69AnU4jps=.5eab9678-e7c1-4abd-82ad-f36b2206986b@github.com> On Wed, 13 Jul 2022 00:04:24 GMT, Joe Wang wrote: > Update dom.md, adding notice. This pull request has now been integrated. Changeset: 73b83e01 Author: Joe Wang URL: https://git.openjdk.org/jdk19/commit/73b83e018838d3870733970b2bb22a8394b53330 Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod 8290207: Missing notice in dom.md Reviewed-by: iris, lancea, naoto ------------- PR: https://git.openjdk.org/jdk19/pull/138 From duke at openjdk.org Wed Jul 13 17:42:18 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 13 Jul 2022 17:42:18 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v5] In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: > We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. > > Benchmark results: > > before > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op > StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op > > after > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op > StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: - 8289908: Fix typo - 8289908: Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9407/files - new: https://git.openjdk.org/jdk/pull/9407/files/f653a67b..72146f7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9407.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407 PR: https://git.openjdk.org/jdk/pull/9407 From duke at openjdk.org Wed Jul 13 17:42:23 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 13 Jul 2022 17:42:23 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v4] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Wed, 13 Jul 2022 15:44:04 GMT, Roger Riggs wrote: >> ?????? ??????? 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: >> >> - 8289908: Rework constructor >> - Merge branch 'master' into 8289908 >> - 8289908: Fixed tests >> - Merge branch 'master' into 8289908 >> - 8289908: Make constructor private and use trailing Void instead of int >> - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] > > src/java.base/share/classes/java/lang/String.java line 528: > >> 526: *

        >> 527: * Important: parameter order of this method is deliberately changed in order to >> 528: * disambiguate it against other similar methods ot this class. > > typo? "ot this". Changed to "of this" ------------- PR: https://git.openjdk.org/jdk/pull/9407 From alanb at openjdk.org Wed Jul 13 17:44:01 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Jul 2022 17:44:01 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died [v4] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 16:58:21 GMT, Doug Lea

        wrote: >> 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > copyright header Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9427 From dl at openjdk.org Wed Jul 13 18:10:09 2022 From: dl at openjdk.org (Doug Lea) Date: Wed, 13 Jul 2022 18:10:09 GMT Subject: Integrated: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died In-Reply-To: References: Message-ID: <6K_lIqCBQUf0gvoXSGn0Dzgk5IPhlLS69PJ0pPra9Sg=.c91190e2-e596-4cb8-818a-18ff24b60d8e@github.com> On Fri, 8 Jul 2022 11:44:53 GMT, Doug Lea
        wrote: > 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died This pull request has now been integrated. Changeset: 53580455 Author: Doug Lea
        URL: https://git.openjdk.org/jdk/commit/535804554deef213d056cbd6bce14aeff04c32fb Stats: 364 lines in 5 files changed: 303 ins; 13 del; 48 mod 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/9427 From duke at openjdk.org Wed Jul 13 18:22:05 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 13 Jul 2022 18:22:05 GMT Subject: RFR: 8249834: java/util/ArrayList/Bug8146568.java and j/u/Vector/Bug8148174.java use @ignore w/o bug-id [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:53:45 GMT, Bill Huang wrote: >> Tests Bug8146568 and Bug8148174 were disabled for high memory consumption, over 17G. This is a task to re-enable these two tests by marking them as manual tests. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Added missing backslash in jdk/TEST.groups Test group jdk_core_manual_no_input was run with no issues. Both two newly added tests were run and passed. The only one failed test in this group is a remote test and failure is expected on a local machine. Screen Shot 2022-07-13 at 11 07 37 AM ------------- PR: https://git.openjdk.org/jdk/pull/9404 From duke at openjdk.org Wed Jul 13 19:41:08 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 13 Jul 2022 19:41:08 GMT Subject: Integrated: 8290079: Reduce interaction with volatile in static initializer of BigInteger In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 12:41:48 GMT, ?????? ??????? wrote: > `BigInteger.powerCache` is volatile and should be assigned only once in static initializer. This pull request has now been integrated. Changeset: c83fcbd1 Author: Sergey Tsypanov Committer: Joe Darcy URL: https://git.openjdk.org/jdk/commit/c83fcbd18fff4d10c4162c43ddcdf3a51ce2c8e6 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8290079: Reduce interaction with volatile in static initializer of BigInteger Reviewed-by: jpai, rriggs, darcy ------------- PR: https://git.openjdk.org/jdk/pull/9451 From joehw at openjdk.org Wed Jul 13 19:41:43 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 13 Jul 2022 19:41:43 GMT Subject: [jdk19] RFR: 8290209: jcup.md missing additional text Message-ID: Update jcup.md with additional text at the end. Refer to http://www2.cs.tum.edu/projects/cup/licence.php. ------------- Commit messages: - 8290209: jcup.md missing additional text Changes: https://git.openjdk.org/jdk19/pull/141/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290209 Stats: 11 lines in 1 file changed: 9 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/141.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/141/head:pull/141 PR: https://git.openjdk.org/jdk19/pull/141 From iris at openjdk.org Wed Jul 13 20:01:00 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 13 Jul 2022 20:01:00 GMT Subject: [jdk19] RFR: 8290209: jcup.md missing additional text In-Reply-To: References: Message-ID: <_FmnOLpnk0yXB5e7NCR4suZzpH332wgNwJ_X98qE9QQ=.7c7e9ef8-d38b-4e8d-a59b-231f89dbfa11@github.com> On Wed, 13 Jul 2022 19:34:30 GMT, Joe Wang wrote: > Update jcup.md with additional text at the end. Refer to http://www2.cs.tum.edu/projects/cup/licence.php. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/141 From naoto at openjdk.org Wed Jul 13 20:07:59 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 13 Jul 2022 20:07:59 GMT Subject: [jdk19] RFR: 8290209: jcup.md missing additional text In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 19:34:30 GMT, Joe Wang wrote: > Update jcup.md with additional text at the end. Refer to http://www2.cs.tum.edu/projects/cup/licence.php. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/141 From lancea at openjdk.org Wed Jul 13 20:14:03 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 13 Jul 2022 20:14:03 GMT Subject: [jdk19] RFR: 8290209: jcup.md missing additional text In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 19:34:30 GMT, Joe Wang wrote: > Update jcup.md with additional text at the end. Refer to http://www2.cs.tum.edu/projects/cup/licence.php. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/141 From mchung at openjdk.org Wed Jul 13 20:49:05 2022 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 13 Jul 2022 20:49:05 GMT Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" [v2] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 14:06:00 GMT, Roger Riggs wrote: >> The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java` >> Fails intermittently when expected output from a subprocess is not found. >> >> I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced. >> >> The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded. >> The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released. >> When released the child process exits and the driver test will find all of the output it expects. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup waiting for library unload Looks good. The solution is a good way to fix this race. Thanks for fixing this. test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 168: > 166: for (int i = 0; i < LOADER_COUNT; i++) { > 167: System.gc(); > 168: var res = refQueue.remove(); This should block until one becomes available or `InterruptedException` gets thrown. So `res` would never be null? ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/9474 From joehw at openjdk.org Wed Jul 13 21:06:02 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 13 Jul 2022 21:06:02 GMT Subject: [jdk19] Integrated: 8290209: jcup.md missing additional text In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 19:34:30 GMT, Joe Wang wrote: > Update jcup.md with additional text at the end. Refer to http://www2.cs.tum.edu/projects/cup/licence.php. This pull request has now been integrated. Changeset: 2bf6285c Author: Joe Wang URL: https://git.openjdk.org/jdk19/commit/2bf6285c80f078d8451afb5682ee307bb13be179 Stats: 11 lines in 1 file changed: 9 ins; 2 del; 0 mod 8290209: jcup.md missing additional text Reviewed-by: iris, naoto, lancea ------------- PR: https://git.openjdk.org/jdk19/pull/141 From duke at openjdk.org Wed Jul 13 21:13:40 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 13 Jul 2022 21:13:40 GMT Subject: RFR: 8289511: Axes: child Message-ID: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. ------------- Commit messages: - Added more XPath expression test cases and created negative tests for invalid expressions. - Created XPathChildTest.java Changes: https://git.openjdk.org/jdk/pull/9484/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9484&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289511 Stats: 217 lines in 1 file changed: 217 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9484.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9484/head:pull/9484 PR: https://git.openjdk.org/jdk/pull/9484 From dholmes at openjdk.org Wed Jul 13 21:48:05 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 13 Jul 2022 21:48:05 GMT Subject: RFR: 8066859: java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died [v4] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 16:58:21 GMT, Doug Lea
        wrote: >> 8066859 : java/lang/ref/OOMEInReferenceHandler.java failed with java.lang.Exception: Reference Handler thread died > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > copyright header src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 1249: > 1247: // fall through if encountered OutOfMemoryError > 1248: if (!isHeldExclusively() || !release(savedState = getState())) > 1249: throw new IllegalMonitorStateException(); I still don't see how an OOME can possibly indicate we might somehow be in a state where we need to throw IMSE! ------------- PR: https://git.openjdk.org/jdk/pull/9427 From lmesnik at openjdk.org Wed Jul 13 22:49:14 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 13 Jul 2022 22:49:14 GMT Subject: RFR: 8290178: failure_handler: run netstat without name lookups In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 13:16:12 GMT, Daniel Jeli?ski wrote: > `netstat -av` in Mac OS X failure handler is frequently running into the 20 second timeout, leaving us with no socket information. This PR proposes running `netstat -anv` along with the existing `netstat -av`, so that we have at least some socket information if the original command times out. > > `netstat -anv` does not perform reverse DNS lookups on the socket IP addresses. The output contains IP addresses instead of DNS names. The command usually finishes in a few milliseconds. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9469 From stuart.marks at oracle.com Thu Jul 14 00:52:52 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 13 Jul 2022 17:52:52 -0700 Subject: [External] : Re: JMH results for IndexedLinkedList In-Reply-To: References: Message-ID: <25627fe6-79e3-a262-b8b6-7cbee87891c0@oracle.com> On 7/10/22 8:25 AM, Tagir Valeev wrote: > Hello! > > On Sun, Jul 10, 2022 at 6:33 AM Rodion Efremov wrote: >> I am interested in >> https://bugs.openjdk.org/browse/JDK-8143850 >> >> Is there a way for becoming an assignee for the above issue? If yes, how do I proceed and what is the schedule? > > Stuart Marks might be the right person to ask. Adding to CC. Thanks Tagir. There is already a considerable implementation overlap between ArrayList and ArrayDeque that seems difficult to unify. I'm loathe to add yet another data structure implementation that's functionally similar to the existing ones but has a bunch of subtle performance and usage tradeoffs. Doing this would add to the maintenance cost of the JDK and also make it more difficult for programmers to choose the "right" data structure for their application. Already there is a problem with ArrayList and ArrayDeque being separate classes. ArrayDeque "fixes" the performance problem with addition/removal at the front of an ArrayList; yet last time I checked, ArrayDeque was used only about 1% as frequently as ArrayList. Maybe this is because people don't know about it, or maybe because people are uncomfortable losing List-like indexed access with ArrayDeque. Regarding JDK-8143850 there is a twisty maze through the constraints of avoiding adding too much code, avoiding too much API surface area, and maintaining performance. I have a prototype of ArrayList that makes it double-ended, which seems promising, to me at least. (This is independent of SequencedCollection -- JDK-8266572 -- which is an API move, not an implementation move.) But doing this necessarily slows down append-only operations, while providing a performance boon for operations at the front for all but the smallest lists. The tradeoffs here are quite subtle. In any case I think the best path forward for "new" data structures with interesting performance characteristics is to publish an artifact on Maven central. This will allow people who have specialized performance needs to use it. s'marks > > With best regards, > Tagir Valeev. > >> >> Best regards, >> rodde >> >> la 9.7.2022 klo 22.33 Tagir Valeev kirjoitti: >>> >>> Note that nobody these days cares about LinkedList. Use-cases where LinkedList outperforms careful use of ArrayList or ArrayDeque are next to none. So saying that your data structure is better than LinkedList is totally not a reason to add it to JDK. It should be better than ArrayList and ArrayDeque. >>> >>> Having a single data structure that provides list and deque interface is a reasonable idea. However it would be much simpler to retrofit existing data structure like ArrayDeque, rather than create a new data structure. Here's an issue for this: >>> https://bugs.openjdk.org/browse/JDK-8143850 >>> >>> There were also discussions to enhance collections in general, adding more useful methods like getFirst() or removeLast() to ArrayList, etc. See for details: >>> https://bugs.openjdk.org/browse/JDK-8266572 >>> >>> To conclude, the idea of adding one more collection implementation looks questionable to me. It will add more confusion when people need to select which collection fits their needs better. It will require more learning. This could be justified if there are clear benefits in using it in real world problems, compared to existing collections. But so far I don't see the examples of such problems. >>> >>> With best regards, >>> Tagir Valeev >>> >>> ??, 9 ???. 2022 ?., 11:22 Rodion Efremov : >>>> >>>> Hello, >>>> >>>> My benchmarking suggests, that, if nothing else, my IndexedLinkedList outperforms gracefully the java.util.LinkedList, so the use case should be the same (List + Deque -interfaces) for both of the aforementioned data structures. >>>> >>>> Best regards, >>>> rodde >>>> >>>> >>>> On Sat, Jul 9, 2022 at 11:19 AM Tagir Valeev wrote: >>>>> >>>>> Hello! >>>>> >>>>> Are there real world problems/use cases where IndexedLinkedList would be preferred in terms of CPU/memory usage over ArrayList? >>>>> >>>>> ??, 9 ???. 2022 ?., 07:18 Rodion Efremov : >>>>>> >>>>>> Data structure repo: >>>>>> https://urldefense.com/v3/__https://github.com/coderodde/IndexedLinkedList__;!!ACWV5N9M2RV99hQ!LBLiZkI0ZS8UoU_DXtnXCXGFsFzBUd3q7qyok0L3vUbTQXbnDnXoyb8GsZUyyt2pnCjra9VSKVLJG8h-$ >>>>>> >>>>>> Benchmark repo: >>>>>> https://urldefense.com/v3/__https://github.com/coderodde/IndexedLinkedListBenchmark__;!!ACWV5N9M2RV99hQ!LBLiZkI0ZS8UoU_DXtnXCXGFsFzBUd3q7qyok0L3vUbTQXbnDnXoyb8GsZUyyt2pnCjra9VSKafWnZNi$ >>>>>> >>>>>> I have profiled my data structure and it seems it?s more performant than java.util.LinkedList or TreeList, if nothing else. >>>>>> >>>>>> So, is there any chance of including IndexedLinkedList to JDK? >>>>>> >>>>>> Best regards, >>>>>> rodde From duke at openjdk.org Thu Jul 14 01:17:11 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 14 Jul 2022 01:17:11 GMT Subject: RFR: 8289511: Axes: child [v2] In-Reply-To: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: > This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. Bill Huang 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 'openjdk:master' into JDK-8289511 - Added more XPath expression test cases and created negative tests for invalid expressions. - Created XPathChildTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9484/files - new: https://git.openjdk.org/jdk/pull/9484/files/09dbb67b..31525f8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9484&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9484&range=00-01 Stats: 83253 lines in 1820 files changed: 41928 ins; 26600 del; 14725 mod Patch: https://git.openjdk.org/jdk/pull/9484.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9484/head:pull/9484 PR: https://git.openjdk.org/jdk/pull/9484 From jpai at openjdk.org Thu Jul 14 01:26:02 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 14 Jul 2022 01:26:02 GMT Subject: RFR: 8249834: java/util/ArrayList/Bug8146568.java and j/u/Vector/Bug8148174.java use @ignore w/o bug-id [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:53:45 GMT, Bill Huang wrote: >> Tests Bug8146568 and Bug8148174 were disabled for high memory consumption, over 17G. This is a task to re-enable these two tests by marking them as manual tests. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Added missing backslash in jdk/TEST.groups Thank you for running those tests, Bill. Please go ahead and issue a integrate command when you are ready and I can sponsor this for you. ------------- PR: https://git.openjdk.org/jdk/pull/9404 From joehw at openjdk.org Thu Jul 14 01:34:06 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 14 Jul 2022 01:34:06 GMT Subject: RFR: 8289511: Axes: child [v2] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: On Thu, 14 Jul 2022 01:17:11 GMT, Bill Huang wrote: >> This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. > > Bill Huang 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 'openjdk:master' into JDK-8289511 > - Added more XPath expression test cases and created negative tests for invalid expressions. > - Created XPathChildTest.java Nice test overall. Pls see comments below. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathChildTest.java line 41: > 39: > 40: /* > 41: * @test Add bug id here: @bug 8289511 test/jaxp/javax/xml/jaxp/unittest/xpath/XPathChildTest.java line 45: > 43: * @summary Tests for XPath child axis specifier. > 44: */ > 45: public class XPathChildTest { Change the name to: XPathExpChildTest. The idea was to add more test cases to XPathExpTest. But since you've created the long list of test cases, it looks okay to be in a separate test. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathChildTest.java line 135: > 133: {"/store/child::*[attribute::*]/author", AUTHOR_1}, > 134: {"/store/*[*][*][*][*][*][*][*][*]/author", AUTHOR_1}, > 135: {"/store/*[@*][@*][@*][@*][@*][@*][@*][@*]/author", AUTHOR_1}, What are we testing here, I mean vs ```*[*] or *[@*]?``` test/jaxp/javax/xml/jaxp/unittest/xpath/XPathChildTest.java line 156: > 154: public Object[][] getInvalidExp() { > 155: return new Object[][]{ > 156: // NullPointerException These NPE tests need to be revisited. First of all, by the spec, NPE shall throw only "If expression or returnType is null" (and that's already covered in the Exception test). Secondly, these NPEs were not thrown by the eval process, it was merely because the NodeList was empty or Node was null. The expressions themselves were not "invalid". ------------- PR: https://git.openjdk.org/jdk/pull/9484 From duke at openjdk.org Thu Jul 14 01:34:30 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 14 Jul 2022 01:34:30 GMT Subject: Integrated: 8249834: java/util/ArrayList/Bug8146568.java and j/u/Vector/Bug8148174.java use @ignore w/o bug-id In-Reply-To: References: Message-ID: <1YoD6QYq4oPiXT9cW0roydpuEkDFRsQ7cpFOvH0v0ys=.2ef83561-cb78-454b-9dae-fdc654ddcf9e@github.com> On Wed, 6 Jul 2022 21:19:51 GMT, Bill Huang wrote: > Tests Bug8146568 and Bug8148174 were disabled for high memory consumption, over 17G. This is a task to re-enable these two tests by marking them as manual tests. This pull request has now been integrated. Changeset: dbab827b Author: Bill Huang Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/dbab827bee5297c19b10f0923a962fe6c0ac5cbd Stats: 7 lines in 3 files changed: 2 ins; 0 del; 5 mod 8249834: java/util/ArrayList/Bug8146568.java and j/u/Vector/Bug8148174.java use @ignore w/o bug-id Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/9404 From duke at openjdk.org Thu Jul 14 03:01:14 2022 From: duke at openjdk.org (xpbob) Date: Thu, 14 Jul 2022 03:01:14 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v3] In-Reply-To: References: Message-ID: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with one additional commit since the last revision: Add non-programmatic beans ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/8f63af82..042885dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=01-02 Stats: 517 lines in 7 files changed: 229 ins; 288 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Thu Jul 14 03:16:30 2022 From: duke at openjdk.org (xpbob) Date: Thu, 14 Jul 2022 03:16:30 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v4] In-Reply-To: References: Message-ID: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with one additional commit since the last revision: Back to modify ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/042885dc..1dcf96b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=02-03 Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Thu Jul 14 03:18:40 2022 From: duke at openjdk.org (xpbob) Date: Thu, 14 Jul 2022 03:18:40 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v5] In-Reply-To: References: Message-ID: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with one additional commit since the last revision: Back to modify ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/1dcf96b8..4a668926 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Thu Jul 14 03:27:07 2022 From: duke at openjdk.org (xpbob) Date: Thu, 14 Jul 2022 03:27:07 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v6] In-Reply-To: References: Message-ID: > Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. > Results the following > ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) xpbob has updated the pull request incrementally with one additional commit since the last revision: modify class name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9372/files - new: https://git.openjdk.org/jdk/pull/9372/files/4a668926..4d5faab3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9372&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9372.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9372/head:pull/9372 PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Thu Jul 14 03:36:04 2022 From: duke at openjdk.org (xpbob) Date: Thu, 14 Jul 2022 03:36:04 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com> References: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com> Message-ID: <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com> On Tue, 12 Jul 2022 15:48:57 GMT, Alan Bateman wrote: >>> @AlanBateman @jerboaa That's a good idea.Adding a special bean is only available on Linux systems.I do not know the process of creating a CSR, can you help me create a CSR >> >> It's too early to think about a CSR, probably a bit premature to create a PR too because it will take a few iterations to come to agreement on what API to expose, if any. >> >> I don't think this should be a standard API, meaning java.management/java.lang.management.ContainerMXBean is not the right place for this. A JDK-specific MXBean is an option but it would only be usable on Linux and maybe only usable when running in a container environment. Working down, it's not clear to me how stable the attributes are and the mapping to both cgroup v1 and v2. There is also overlap with OperatingSystemMXBean which already defines the "TotalSwapSpaceSize" attribute. There's another level of detail beyond that with unusual value -2 to distinguish "not available" from "not supported". So I think there are a few things to think about there. >> >> Another direction to think about is not exposing an API that you can compile against but instead just register a MBean that provides access to the attributes that are interesting for the container environment. By this I mean ManagementFactory.getPlatformMBeanServer().registerMBean(...). This would be enough to browse the MBean and its attributes in any JMX console and may give you a bit more flexibility to expose attributes that are specific to the cgroup version. I'm not saying this is the right direction, I'm just listing it here as something that could be explored. If the main use case is JMX consoles rather than programmatic access then it may not be too bad. > >> @AlanBateman OperatingSystemMXBean makes the CPU and Memory related information for a process available regardless of whether that process is running in a native operating system environment or a containerized environment. It does not provide container configuration information such as its provider (crgoups v1 or v2), CPU shares, CPU quota etc, which can be useful for monitoring and troubleshooting purposes. > > Yes, I know this but I think there is a lot more thought required before deciding to augment this with another API for the container environment. There are a couple of things to explore. @AlanBateman @jerboaa @poonamparhar @DamonFool Thanks for review. I add mBeans using the registerMBean method. We can get configuration information through JConsole, JMX exporter ------------- PR: https://git.openjdk.org/jdk/pull/9372 From ysatowse at openjdk.org Thu Jul 14 04:28:06 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Thu, 14 Jul 2022 04:28:06 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK Message-ID: Please review this PR. The PR open sources the closed timezone tests. ------------- Commit messages: - Minor change added to Makefile - 8028265: Move closed timezone tests to open repository Changes: https://git.openjdk.org/jdk/pull/9476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8028265 Stats: 1221 lines in 9 files changed: 1221 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9476.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9476/head:pull/9476 PR: https://git.openjdk.org/jdk/pull/9476 From ysatowse at openjdk.org Thu Jul 14 04:28:06 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Thu, 14 Jul 2022 04:28:06 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. Can I ask you to help reviewing this PR? @coffeys @naotoj ------------- PR: https://git.openjdk.org/jdk/pull/9476 From coffeys at openjdk.org Thu Jul 14 04:28:08 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 14 Jul 2022 04:28:08 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. 1 minor comment. Looks good to me. test/jdk/java/util/TimeZone/tools/share/Makefile line 33: > 31: # > 32: > 33: TZDATA = ../../../../../../../../open/src/java.base/share/data/tzdata suggest you replace this with `../../../../../../../src/java.base/share/data/tzdata/` ------------- PR: https://git.openjdk.org/jdk/pull/9476 From naoto at openjdk.org Thu Jul 14 04:28:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 14 Jul 2022 04:28:09 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. Please modify the PR title to match the JBS. ------------- PR: https://git.openjdk.org/jdk/pull/9476 From darcy at openjdk.org Thu Jul 14 05:21:03 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 14 Jul 2022 05:21:03 GMT Subject: RFR: 8288933: Improve the implementation of Double/Float.isInfinite In-Reply-To: References: Message-ID: <3ACF4446eOlmU4fy37s0ethO60isKd4Gd_Wtr18k-MA=.069bece8-1b36-4f40-9a79-16efb018762d@github.com> On Wed, 22 Jun 2022 12:43:53 GMT, Quan Anh Mai wrote: > Improve the implementation of `Double/Float.isInfinite` to reduce branching. Using `>` comparison with `MAX_VALUE` instead of `==` with `POSITIVE_INFINITY` improves code emission on x86 and produces similar code for arm. This is also the way gcc implements `std::isinf` on x86 and arm (clang uses the pattern `Math.abs(v) == POSITIVE_INFINITY` on arm). > > `test/micro/org/openjdk/bench/java/lang/FPComparison.java` has been added in #8525, the results are reshown here: > > Benchmark Mode Cnt Score Error Score Error Unit Ratio > FPComparison.isInfiniteDouble avgt 5 1232.800 ? 31.677 621.185 ? 11.935 ns/op 1.98 > FPComparison.isInfiniteFloat avgt 5 1234.708 ? 70.239 623.566 ? 15.206 ns/op 1.98 > > Thank you very much. @merykitty, the proposed change is functionally correct. @cl4es, what set of platforms do we usually consider for evaluating performance changes like this? ------------- PR: https://git.openjdk.org/jdk/pull/9238 From darcy at openjdk.org Thu Jul 14 05:34:02 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 14 Jul 2022 05:34:02 GMT Subject: RFR: JDK-8289106: Add model of class file versions to core reflection [v2] In-Reply-To: References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> Message-ID: On Mon, 11 Jul 2022 20:31:04 GMT, Mandy Chung wrote: > This `ClassFileFormatVersion` API is a good proposal. It can also reference `java.class.version` system property to map to the latest class file format version. Good idea Mandy; I'll add that reference and start working on the implementation of the partially implemented method. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9299 From jwilhelm at openjdk.org Thu Jul 14 06:23:49 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 14 Jul 2022 06:23:49 GMT Subject: Integrated: Merge jdk19 In-Reply-To: <0kV4AZaoLszVYbNjgtP-POvZBo8IlSUi1DhF5G6YYrc=.b18a6389-52ff-4d1a-95de-f537f506fef4@github.com> References: <0kV4AZaoLszVYbNjgtP-POvZBo8IlSUi1DhF5G6YYrc=.b18a6389-52ff-4d1a-95de-f537f506fef4@github.com> Message-ID: On Wed, 13 Jul 2022 12:15:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: a7f83582 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/a7f83582d323b0dc39abc0b2114144206183af45 Stats: 120 lines in 9 files changed: 59 ins; 3 del; 58 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9479 From djelinski at openjdk.org Thu Jul 14 06:41:04 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 14 Jul 2022 06:41:04 GMT Subject: Integrated: 8290178: failure_handler: run netstat without name lookups In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 13:16:12 GMT, Daniel Jeli?ski wrote: > `netstat -av` in Mac OS X failure handler is frequently running into the 20 second timeout, leaving us with no socket information. This PR proposes running `netstat -anv` along with the existing `netstat -av`, so that we have at least some socket information if the original command times out. > > `netstat -anv` does not perform reverse DNS lookups on the socket IP addresses. The output contains IP addresses instead of DNS names. The command usually finishes in a few milliseconds. This pull request has now been integrated. Changeset: 292d909e Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/292d909e81266a75221d660e8914cbcec7640061 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8290178: failure_handler: run netstat without name lookups Reviewed-by: jpai, dfuchs, msheppar, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/9469 From alanb at openjdk.org Thu Jul 14 07:08:54 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Jul 2022 07:08:54 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com> References: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com> <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com> Message-ID: On Thu, 14 Jul 2022 03:32:35 GMT, xpbob wrote: > Thanks for review. > I add mBeans using the registerMBean method. > We can get configuration information through JConsole, JMX exporter This iteration is a bit confusing because it adds a public interface to java.lang.management. For the registerMBean prototype then you shouldn't need any API changes to the java.management module. ------------- PR: https://git.openjdk.org/jdk/pull/9372 From duke at openjdk.org Thu Jul 14 07:57:02 2022 From: duke at openjdk.org (xpbob) Date: Thu, 14 Jul 2022 07:57:02 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: References: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com> <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com> Message-ID: On Thu, 14 Jul 2022 07:05:25 GMT, Alan Bateman wrote: > > Thanks for review. > > I add mBeans using the registerMBean method. > > We can get configuration information through JConsole, JMX exporter > > This iteration is a bit confusing because it adds a public interface to java.lang.management. For the registerMBean prototype then you shouldn't need any API changes to the java.management module. @AlanBateman Thanks for review. The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management. ------------- PR: https://git.openjdk.org/jdk/pull/9372 From coffeys at openjdk.org Thu Jul 14 08:19:47 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 14 Jul 2022 08:19:47 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. Marked as reviewed by coffeys (Reviewer). test/jdk/java/util/TimeZone/tools/share/makeZoneData.pl line 32: > 30: # static TimeZoneData. > 31: # For J2SE since JDK1.4, this script is used to generate testdata(reference) > 32: # for ZoneData.sh which is one of TimeZone Regression test. suggest that you remove these lines - redundant information. ------------- PR: https://git.openjdk.org/jdk/pull/9476 From alanb at openjdk.org Thu Jul 14 08:27:01 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Jul 2022 08:27:01 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: References: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com> <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com> Message-ID: <0sZ6kqzuwDz6k4TFqvhwdWgR5wK0epStqZ7dD5OOH4I=.9c98a700-84d0-49d1-9a43-fdd645be5b61@github.com> On Thu, 14 Jul 2022 07:54:56 GMT, xpbob wrote: > Thanks for review. The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management. I don't think this feature should be adding to the standard API. Can you move ContainerInfoMXBean to sun.management and do some experiments? ------------- PR: https://git.openjdk.org/jdk/pull/9372 From aturbanov at openjdk.org Thu Jul 14 11:51:15 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 14 Jul 2022 11:51:15 GMT Subject: RFR: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] [v5] In-Reply-To: References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Wed, 13 Jul 2022 17:42:18 GMT, ?????? ??????? wrote: >> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. >> >> Benchmark results: >> >> before >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op >> >> after >> >> Benchmark Mode Cnt Score Error Units >> StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op >> StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op >> StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op >> StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op >> StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op >> StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8289908: Fix typo > - 8289908: Fix typo Marked as reviewed by aturbanov (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/9407 From dl at openjdk.org Thu Jul 14 12:04:27 2022 From: dl at openjdk.org (Doug Lea) Date: Thu, 14 Jul 2022 12:04:27 GMT Subject: RFR: 8290264 : java/util/concurrent/locks/Lock/OOMEInAQS.java fails with "exit code: 0" Message-ID: This test now conforms to jtreg rules about not using System.exit to cover untested OutOfMemoryErrors ------------- Commit messages: - Avoid System.exit in jtreg tests Changes: https://git.openjdk.org/jdk/pull/9491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290264 Stats: 19 lines in 1 file changed: 15 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9491.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9491/head:pull/9491 PR: https://git.openjdk.org/jdk/pull/9491 From duke at openjdk.org Thu Jul 14 12:24:03 2022 From: duke at openjdk.org (xpbob) Date: Thu, 14 Jul 2022 12:24:03 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v2] In-Reply-To: <0sZ6kqzuwDz6k4TFqvhwdWgR5wK0epStqZ7dD5OOH4I=.9c98a700-84d0-49d1-9a43-fdd645be5b61@github.com> References: <913Moxv3p4mJOrpO663wmSpyShLUfsxnDbpySjIupU4=.eb17deea-ee32-4c33-a101-a7c7c3ae055d@github.com> <5xRoT2NhbsZdTNCDFb65_chzA7oa-mi6gAbRKZpXUv8=.c8960d27-726e-45fd-ae23-d70d0100af7f@github.com> <_ki4Kwj67fWZ993oFgb51Rkkm0hpTC6N9Jq52TrsfEI=.bcadf7b3-8c8e-4abb-8e83-a83df23c9e7c@github.com> <0sZ6kqzuwDz6k4TFqvhwdWgR5wK0epStqZ7dD5OOH4I=.9c98a700-84d0-49d1-9a43-fdd645be5b61@github.com> Message-ID: On Thu, 14 Jul 2022 08:23:37 GMT, Alan Bateman wrote: >>> > Thanks for review. >>> > I add mBeans using the registerMBean method. >>> > We can get configuration information through JConsole, JMX exporter >>> >>> This iteration is a bit confusing because it adds a public interface to java.lang.management. For the registerMBean prototype then you shouldn't need any API changes to the java.management module. >> @AlanBateman Thanks for review. >> The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management. > >> Thanks for review. The runtime information is already fetched through the OperatingSystemMXBean, and I'm wrapped through the interface, keeping only the configuration data.Such an interface could be part of management. > > I don't think this feature should be adding to the standard API. Can you move ContainerInfoMXBean to sun.management and do some experiments? Thanks for review. @AlanBateman I move ContainerInfoMXBean to sun.management, the data is not available, ![??](https://user-images.githubusercontent.com/7837910/178977950-3a058e90-86cc-4630-b496-5249f3e34a9f.png) The red character indicates that it is not available ------------- PR: https://git.openjdk.org/jdk/pull/9372 From jpai at openjdk.org Thu Jul 14 12:58:05 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 14 Jul 2022 12:58:05 GMT Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" [v2] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 14:06:00 GMT, Roger Riggs wrote: >> The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java` >> Fails intermittently when expected output from a subprocess is not found. >> >> I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced. >> >> The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded. >> The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released. >> When released the child process exits and the driver test will find all of the output it expects. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup waiting for library unload test/jdk/java/lang/ClassLoader/loadLibraryUnload/libloadLibraryUnload.c line 48: > 46: if (ref == NULL) { > 47: // Only create a single GlobalRef > 48: ref = (*env)->NewGlobalRef(env, obj); Hello Roger, do we not use any synchronization here because even if both winning threads end up concurrently here, the `Object` instance they will be setting as a global ref will be the same one? Ofcourse, there will then be two calls to `NewGlobalRef` for the same instance. I am unaware what the semantics of that call will be in such cases and if it is of any concern. ------------- PR: https://git.openjdk.org/jdk/pull/9474 From jwilhelm at openjdk.org Thu Jul 14 13:08:58 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 14 Jul 2022 13:08:58 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge - 8288112: C2: Error: ShouldNotReachHere() in Type::typerr() - 8290209: jcup.md missing additional text - 8290207: Missing notice in dom.md The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9493&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9493&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9493/files Stats: 242 lines in 11 files changed: 232 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9493.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9493/head:pull/9493 PR: https://git.openjdk.org/jdk/pull/9493 From dholmes at openjdk.org Thu Jul 14 13:37:09 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Jul 2022 13:37:09 GMT Subject: RFR: 8290264 : java/util/concurrent/locks/Lock/OOMEInAQS.java fails with "exit code: 0" In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 11:57:37 GMT, Doug Lea
        wrote: > This test now conforms to jtreg rules about not using System.exit to cover untested OutOfMemoryErrors Hi Doug, One pre-existing style nit but otherwise the termination logic seems okay. Thanks. test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java line 108: > 106: cond.signalAll(); > 107: } finally { > 108: lock.unlock(); Pre-existing but the lock() should be before the try block (even if now it can't throw exceptions). ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9491 From rriggs at openjdk.org Thu Jul 14 15:07:04 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 14 Jul 2022 15:07:04 GMT Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" [v2] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 20:39:53 GMT, Mandy Chung wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup waiting for library unload > > test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 168: > >> 166: for (int i = 0; i < LOADER_COUNT; i++) { >> 167: System.gc(); >> 168: var res = refQueue.remove(); > > This should block until one becomes available or `InterruptedException` gets thrown. So `res` would never be null? The test for null was leftover from a previous version that used `remove(timeout)`. I'll restore the timeout; that version will produce a better message than just relying on jtreg to timeout the entire test with a generic message. ------------- PR: https://git.openjdk.org/jdk/pull/9474 From rriggs at openjdk.org Thu Jul 14 15:07:07 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 14 Jul 2022 15:07:07 GMT Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 12:54:43 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup waiting for library unload > > test/jdk/java/lang/ClassLoader/loadLibraryUnload/libloadLibraryUnload.c line 48: > >> 46: if (ref == NULL) { >> 47: // Only create a single GlobalRef >> 48: ref = (*env)->NewGlobalRef(env, obj); > > Hello Roger, do we not use any synchronization here because even if both winning threads end up concurrently here, the `Object` instance they will be setting as a global ref will be the same one? Ofcourse, there will then be two calls to `NewGlobalRef` for the same instance. I am unaware what the semantics of that call will be in such cases and if it is of any concern. Its a racy bug, each NewGlobalRef will have a reference to the object and only the global ref in the last call to `setRef` will be cleared. The easiest fix is to synchronize on `Class1.class` in Class1.loadLibrary(). ------------- PR: https://git.openjdk.org/jdk/pull/9474 From rriggs at openjdk.org Thu Jul 14 15:24:20 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 14 Jul 2022 15:24:20 GMT Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" [v3] In-Reply-To: References: Message-ID: > The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java` > Fails intermittently when expected output from a subprocess is not found. > > I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced. > > The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded. > The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released. > When released the child process exits and the driver test will find all of the output it expects. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Fix racy canary setting and improve timeout/failure messaging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9474/files - new: https://git.openjdk.org/jdk/pull/9474/files/68532938..cedaa015 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9474&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9474&range=01-02 Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9474.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9474/head:pull/9474 PR: https://git.openjdk.org/jdk/pull/9474 From mchung at openjdk.org Thu Jul 14 15:34:58 2022 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 14 Jul 2022 15:34:58 GMT Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" [v3] In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 15:24:20 GMT, Roger Riggs wrote: >> The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java` >> Fails intermittently when expected output from a subprocess is not found. >> >> I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced. >> >> The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded. >> The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released. >> When released the child process exits and the driver test will find all of the output it expects. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Fix racy canary setting and improve timeout/failure messaging test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 168: > 166: for (int i = 0; i < LOADER_COUNT; i++) { > 167: System.gc(); > 168: var res = refQueue.remove(5 * 1000L); I suggest to use the jtreg timeout factor here (similar to what test/lib/jdk/test/lib/util/ForceGC.java` has done). ------------- PR: https://git.openjdk.org/jdk/pull/9474 From dl at openjdk.org Thu Jul 14 16:15:48 2022 From: dl at openjdk.org (Doug Lea) Date: Thu, 14 Jul 2022 16:15:48 GMT Subject: RFR: 8290264 : java/util/concurrent/locks/Lock/OOMEInAQS.java fails with "exit code: 0" [v2] In-Reply-To: References: Message-ID: > This test now conforms to jtreg rules about not using System.exit to cover untested OutOfMemoryErrors Doug Lea has updated the pull request incrementally with one additional commit since the last revision: try/lock() style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9491/files - new: https://git.openjdk.org/jdk/pull/9491/files/971f3343..f013bb09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9491&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9491&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9491.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9491/head:pull/9491 PR: https://git.openjdk.org/jdk/pull/9491 From dl at openjdk.org Thu Jul 14 16:15:48 2022 From: dl at openjdk.org (Doug Lea) Date: Thu, 14 Jul 2022 16:15:48 GMT Subject: RFR: 8290264 : java/util/concurrent/locks/Lock/OOMEInAQS.java fails with "exit code: 0" [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 13:29:50 GMT, David Holmes wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> try/lock() style > > test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java line 108: > >> 106: cond.signalAll(); >> 107: } finally { >> 108: lock.unlock(); > > Pre-existing but the lock() should be before the try block (even if now it can't throw exceptions). Thanks.; changed ------------- PR: https://git.openjdk.org/jdk/pull/9491 From alanb at openjdk.org Thu Jul 14 16:25:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Jul 2022 16:25:04 GMT Subject: RFR: 8290264 : java/util/concurrent/locks/Lock/OOMEInAQS.java fails with "exit code: 0" [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 16:15:48 GMT, Doug Lea
        wrote: >> This test now conforms to jtreg rules about not using System.exit to cover untested OutOfMemoryErrors > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > try/lock() style Sorry I missed the use of System.exit when looking at the origin version. The update looks good (the explicit System.gc is probably not needed, setting data to null is enough) ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9491 From jwilhelm at openjdk.org Thu Jul 14 16:34:10 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 14 Jul 2022 16:34:10 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 13:02:21 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 3ad39505 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/3ad39505605f8eab74adec9c68f211dd44796759 Stats: 242 lines in 11 files changed: 232 ins; 2 del; 8 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9493 From dcubed at openjdk.org Thu Jul 14 18:43:08 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 14 Jul 2022 18:43:08 GMT Subject: RFR: 8290264 : java/util/concurrent/locks/Lock/OOMEInAQS.java fails with "exit code: 0" [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 16:15:48 GMT, Doug Lea
        wrote: >> This test now conforms to jtreg rules about not using System.exit to cover untested OutOfMemoryErrors > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > try/lock() style Thumbs up. I'm kicking off a Mach5 Tier1 on the latest version of this patch (v01). ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9491 From naoto at openjdk.org Thu Jul 14 19:46:04 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 14 Jul 2022 19:46:04 GMT Subject: RFR: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9476 From dl at openjdk.org Thu Jul 14 19:56:24 2022 From: dl at openjdk.org (Doug Lea) Date: Thu, 14 Jul 2022 19:56:24 GMT Subject: Integrated: 8290264 : java/util/concurrent/locks/Lock/OOMEInAQS.java fails with "exit code: 0" In-Reply-To: References: Message-ID: <9BhvuMq7jF4C15sZ17IJlcXYuZsY-jZxiEzS5P4Nc38=.c674b38f-f344-4b1e-94f5-ecbb0de34a4e@github.com> On Thu, 14 Jul 2022 11:57:37 GMT, Doug Lea
        wrote: > This test now conforms to jtreg rules about not using System.exit to cover untested OutOfMemoryErrors This pull request has now been integrated. Changeset: 890bcedd Author: Doug Lea
        URL: https://git.openjdk.org/jdk/commit/890bcedd49fb791074862cc295c0e6bf64ef4d81 Stats: 21 lines in 1 file changed: 16 ins; 2 del; 3 mod 8290264: java/util/concurrent/locks/Lock/OOMEInAQS.java fails with "exit code: 0" Reviewed-by: dholmes, alanb, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/9491 From duke at openjdk.org Thu Jul 14 20:09:04 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 14 Jul 2022 20:09:04 GMT Subject: RFR: 8289511: Axes: child [v2] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: <-4pFqpe9wGx5fD1JuKdFqcWe9RSPwBBg14-nnu2kVRI=.b987bef3-8987-4e80-b814-7a471063bf27@github.com> On Thu, 14 Jul 2022 01:16:43 GMT, Joe Wang wrote: >> Bill Huang 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 'openjdk:master' into JDK-8289511 >> - Added more XPath expression test cases and created negative tests for invalid expressions. >> - Created XPathChildTest.java > > test/jaxp/javax/xml/jaxp/unittest/xpath/XPathChildTest.java line 135: > >> 133: {"/store/child::*[attribute::*]/author", AUTHOR_1}, >> 134: {"/store/*[*][*][*][*][*][*][*][*]/author", AUTHOR_1}, >> 135: {"/store/*[@*][@*][@*][@*][@*][@*][@*][@*]/author", AUTHOR_1}, > > What are we testing here, I mean vs ```*[*] or *[@*]?``` Given the wildcard `*` selects all children of the context node, `*[*] or *[@*]` will select all children that with at least one child or one attribute. This is what we cover with line 132 and 133. For line 134 and 135, we are trying to see if multiple wildcards swallow the child node in the chain. ------------- PR: https://git.openjdk.org/jdk/pull/9484 From duke at openjdk.org Thu Jul 14 20:17:06 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 14 Jul 2022 20:17:06 GMT Subject: RFR: 8289511: Axes: child [v2] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: <1ZpNv5nO3Teo1Wmmv9W9Jm3xW_3HTvSOCw03w1kaNmc=.9159c92e-228d-418c-a665-eaea6948e391@github.com> On Thu, 14 Jul 2022 01:25:38 GMT, Joe Wang wrote: >> Bill Huang 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 'openjdk:master' into JDK-8289511 >> - Added more XPath expression test cases and created negative tests for invalid expressions. >> - Created XPathChildTest.java > > test/jaxp/javax/xml/jaxp/unittest/xpath/XPathChildTest.java line 156: > >> 154: public Object[][] getInvalidExp() { >> 155: return new Object[][]{ >> 156: // NullPointerException > > These NPE tests need to be revisited. First of all, by the spec, NPE shall throw only "If expression or returnType is null" (and that's already covered in the Exception test). Secondly, these NPEs were not thrown by the eval process, it was merely because the NodeList was empty or Node was null. The expressions themselves were not "invalid". Agreed. These expressions are not invalid and they are more on a focus of zero children rather than NPE. I can move them to a different test case. ------------- PR: https://git.openjdk.org/jdk/pull/9484 From duke at openjdk.org Thu Jul 14 20:52:18 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 14 Jul 2022 20:52:18 GMT Subject: RFR: 8289511: Axes: child [v3] In-Reply-To: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: > This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Renamed XPahtExpChildTest.java and moved NPE test cases from invalid test case to zero children test case. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9484/files - new: https://git.openjdk.org/jdk/pull/9484/files/31525f8c..9a57de45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9484&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9484&range=01-02 Stats: 454 lines in 2 files changed: 237 ins; 217 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9484.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9484/head:pull/9484 PR: https://git.openjdk.org/jdk/pull/9484 From darcy at openjdk.org Thu Jul 14 21:01:18 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 14 Jul 2022 21:01:18 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 12:38:23 GMT, Raffaello Giulietti wrote: >> Initial implementation. > > src/java.base/share/classes/java/lang/Float.java line 1100: > >> 1098: >> 1099: // The overflow threshold is binary16 MAX_VALUE + 1/2 ulp >> 1100: if (abs_f > (65504.0f + 16.0f) ) { > > if (abs_f >= (65504.0f + 16.0f) ) { > > Value exactly halfway must round to infinity. Good catch. The rest of the code computed the right value, but the condition should be changed as suggested. > src/java.base/share/classes/java/lang/Float.java line 1141: > >> 1139: >> 1140: // Significand bits as if using rounding to zero (truncation). >> 1141: signif_bits = (short)((doppel & 0x0007f_e000) >> > > signif_bits = (short)((doppel & 0x007f_e000) >> > > or even > > signif_bits = (short)((doppel & 0x007f_ffff) >> > > 32 bit hex are more readable when they have 8 hex digits Oops; yes, I intended for the int hex constants to have at most 8 hex digits. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From darcy at openjdk.org Thu Jul 14 21:01:19 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 14 Jul 2022 21:01:19 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 20:54:59 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/Float.java line 1100: >> >>> 1098: >>> 1099: // The overflow threshold is binary16 MAX_VALUE + 1/2 ulp >>> 1100: if (abs_f > (65504.0f + 16.0f) ) { >> >> if (abs_f >= (65504.0f + 16.0f) ) { >> >> Value exactly halfway must round to infinity. > > Good catch. The rest of the code computed the right value, but the condition should be changed as suggested. I increased test coverage around Binary16.MAX_VALUE+0.5*ulp(Binary16.MAX_VALUE). ------------- PR: https://git.openjdk.org/jdk/pull/9422 From joehw at openjdk.org Thu Jul 14 21:04:09 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 14 Jul 2022 21:04:09 GMT Subject: RFR: 8289511: Axes: child [v3] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: On Thu, 14 Jul 2022 20:52:18 GMT, Bill Huang wrote: >> This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Renamed XPahtExpChildTest.java and moved NPE test cases from invalid test case to zero children test case. Thanks for the update. The update looks good. One more comment below. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpChildTest.java line 99: > 97: // position > 98: {"/store/child::book[position()=1]/author", AUTHOR_1}, > 99: {"/store/child::book[last()]/author", AUTHOR_2}, If the intention is to test the last() function, it would be good to have more books than 2 (e.g. at least 3). But if the focus is on Axes: child, plus functions will be tested in the other subtask, I'm ok if you don't want to make further changes. ------------- PR: https://git.openjdk.org/jdk/pull/9484 From darcy at openjdk.org Thu Jul 14 21:04:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 14 Jul 2022 21:04:20 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 14:33:49 GMT, Raffaello Giulietti wrote: >> Initial implementation. > > test/jdk/java/lang/Float/SixteenBitFormats.java line 239: > >> 237: public static boolean isNaN(short binary16) { >> 238: return ((binary16 & 0x7c00) == 0x7c00) // Max exponent and... >> 239: && ((binary16 & 0x03ff) != 0 ); // significand nonzero. > > return (binary16 & 0x7fff) > 0x7c00; > > is more concise In this case, I think the more verbose coding pattern is clearer. > test/jdk/java/lang/Float/SixteenBitFormats.java line 244: > >> 242: public static short negate(short binary16) { >> 243: return (short)(((binary16 & 0x8000) ^ 0x8000) | // Isolate and flip sign bit >> 244: (binary16 & 0x7fff)); > > return (short)(binary16 ^ 0x8000); > > is shorter Good suggestion. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From duke at openjdk.org Thu Jul 14 21:23:13 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 14 Jul 2022 21:23:13 GMT Subject: RFR: 8289511: Axes: child [v3] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: <3xyQ6aSXB6C4q_KFW7LqUPcAw74H7jpma3toulDgd7M=.d66898c6-44fc-4ebd-a925-3e6b04d96987@github.com> On Thu, 14 Jul 2022 20:59:33 GMT, Joe Wang wrote: >> Bill Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed XPahtExpChildTest.java and moved NPE test cases from invalid test case to zero children test case. > > test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpChildTest.java line 99: > >> 97: // position >> 98: {"/store/child::book[position()=1]/author", AUTHOR_1}, >> 99: {"/store/child::book[last()]/author", AUTHOR_2}, > > If the intention is to test the last() function, it would be good to have more books than 2 (e.g. at least 3). But if the focus is on Axes: child, plus functions will be tested in the other subtask, I'm ok if you don't want to make further changes. Noted. We will cover that in the XPath function() test. ------------- PR: https://git.openjdk.org/jdk/pull/9484 From joehw at openjdk.org Thu Jul 14 21:30:04 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 14 Jul 2022 21:30:04 GMT Subject: RFR: 8289511: Axes: child [v3] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: <22dhKuyD8tJfWK8_ZE3mTA5ef41lPy69LmBVhpxgIGs=.20c302bc-a8e7-4aed-b0a0-f16353920cf7@github.com> On Thu, 14 Jul 2022 20:52:18 GMT, Bill Huang wrote: >> This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Renamed XPahtExpChildTest.java and moved NPE test cases from invalid test case to zero children test case. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9484 From iklam at openjdk.org Thu Jul 14 21:44:07 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Jul 2022 21:44:07 GMT Subject: RFR: 8289511: Axes: child [v3] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: On Thu, 14 Jul 2022 20:52:18 GMT, Bill Huang wrote: >> This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Renamed XPahtExpChildTest.java and moved NPE test cases from invalid test case to zero children test case. Please rename the issue to something more meaningful. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9484 From joehw at openjdk.org Thu Jul 14 22:00:04 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 14 Jul 2022 22:00:04 GMT Subject: RFR: 8289511: Axes: child [v3] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: On Thu, 14 Jul 2022 21:41:24 GMT, Ioi Lam wrote: > Please rename the issue to something more meaningful. Pls refer to the main issue. This is one of the subtasks. ------------- PR: https://git.openjdk.org/jdk/pull/9484 From iklam at openjdk.org Thu Jul 14 22:04:09 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Jul 2022 22:04:09 GMT Subject: RFR: 8289511: Axes: child [v3] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: On Thu, 14 Jul 2022 21:56:27 GMT, Joe Wang wrote: > > Please rename the issue to something more meaningful. > > Pls refer to the main issue. This is one of the subtasks. The problem is when this commit is integrated into the JDK repo, it does not show up as a subtask of another commit. When browsing the Git commit log, we should be able to have some idea what a change is about without going to JBS. ------------- PR: https://git.openjdk.org/jdk/pull/9484 From ecki at zusammenkunft.net Thu Jul 14 23:07:03 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 14 Jul 2022 23:07:03 +0000 Subject: XMLOutputFactory REUSE_INSTANCE property defaults to true Message-ID: The XMLOutputFactoryImpl does not allow to share the writer instances: https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.xml/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java#L167 So this is initialized and set to false: https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.xml/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java#L62 However when you query the property from the PropertyManager it?s default seems to be true: https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java#L154 Should this be aligned to Boolean.FALSE? Or maybe complete remove the shared instance code? I also wonder is it expected to instantiate the Impl directly: there is no programmatic api way to request the default impl unless you define global config or system property (and this also required the impl class name so you can as well create a instance reflectively). Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.org Thu Jul 14 23:40:19 2022 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 14 Jul 2022 23:40:19 GMT Subject: RFR: 8290327: Remove java/lang/reflect/callerCache/ReflectionCallerCacheTest.java from ProblemList-Xcomp.txt Message-ID: It's expected that [JDK-8287596](https://bugs.openjdk.org/browse/JDK-8287596) has resolved [JDK-8288286](https://bugs.openjdk.org/browse/JDK-8288286). Remove ReflectionCallerCacheTest.java from the problem list for test execution. ------------- Commit messages: - 8290327: Remove java/lang/reflect/callerCache/ReflectionCallerCacheTest.java from ProblemList-Xcomp.txt Changes: https://git.openjdk.org/jdk/pull/9500/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9500&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290327 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9500.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9500/head:pull/9500 PR: https://git.openjdk.org/jdk/pull/9500 From joehw at openjdk.org Fri Jul 15 00:44:06 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 15 Jul 2022 00:44:06 GMT Subject: RFR: 8289511: Improve test coverage for XPath Axes: child [v3] In-Reply-To: References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: On Thu, 14 Jul 2022 20:52:18 GMT, Bill Huang wrote: >> This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Renamed XPahtExpChildTest.java and moved NPE test cases from invalid test case to zero children test case. Sounds good. @bwhuang-us Bill, could you edit the title to match the JBS. I've changed the synopsis for all subtasks. nvm, I changed the subtask to match the PR. ------------- PR: https://git.openjdk.org/jdk/pull/9484 From huizhe.wang at oracle.com Fri Jul 15 01:31:20 2022 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 14 Jul 2022 18:31:20 -0700 Subject: XMLOutputFactory REUSE_INSTANCE property defaults to true In-Reply-To: References: Message-ID: <8ec06fc6-4f28-0310-dee4-43a0d2b3e265@oracle.com> On 7/14/22 4:07 PM, Bernd Eckenfels wrote: > The XMLOutputFactoryImpl does not allow to share the writer instances: > > https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.xml/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java#L167 Sounds like a bug. > > So this is initialized and set to false: > > https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.xml/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java#L62 > > However when you query the property from the PropertyManager it?s > default seems to be true: > > https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java#L154 > > Should this be aligned to Boolean.FALSE? Or maybe complete remove the > shared instance code? Agree, needs to be aligned. > > I also wonder is it expected to instantiate the Impl directly: there > is no programmatic api way to request the default impl unless you > define global config or system property (and this also required the > impl class name so you can as well create a instance reflectively). To get the default impl directly, use XMLOutputFactory::newDefaultFactory(). Best, Joe > > Gruss > Bernd > -- > http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Fri Jul 15 05:17:49 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 15 Jul 2022 05:17:49 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 12:28:29 GMT, Raffaello Giulietti wrote: >> Initial implementation. > > src/java.base/share/classes/java/lang/Float.java line 1090: > >> 1088: public static short floatToBinary16AsShortBits(float f) { >> 1089: if (Float.isNaN(f)) { >> 1090: // Arbitrary binary16 NaN value; could try to preserve the > > // Arbitrary binary16 quiet NaN value; could try to preserve the I double-checked the 754-2019 standard; unlike in some earlier versions of the standard, the 2019 edition does specify how a quiet vs signaling NaN is supposed to be encoded. Quoting from section 6.2.1: "A quiet NaN bit string should be encoded with the first bit (d1) of the trailing significand field T being 1. A signaling NaN bit string should be encoded with the first bit of the trailing significand field being 0." So the NaN bit pattern used is a quiet NaN. In any case, I'll update this code to more faithfully pass along the bits of a Float NaN. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From jpai at openjdk.org Fri Jul 15 07:16:01 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 15 Jul 2022 07:16:01 GMT Subject: RFR: 8290327: Remove java/lang/reflect/callerCache/ReflectionCallerCacheTest.java from ProblemList-Xcomp.txt In-Reply-To: References: Message-ID: <5RuoSsxKcLzn3rfz_g3bkIYkiobrbbNeOnSec9Qok7s=.d7a8d82a-f21f-4a55-90be-641df28a59e3@github.com> On Thu, 14 Jul 2022 21:01:05 GMT, Mandy Chung wrote: > It's expected that [JDK-8287596](https://bugs.openjdk.org/browse/JDK-8287596) has resolved [JDK-8288286](https://bugs.openjdk.org/browse/JDK-8288286). Remove ReflectionCallerCacheTest.java from the problem list for test execution. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9500 From ysatowse at openjdk.org Fri Jul 15 07:18:52 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Fri, 15 Jul 2022 07:18:52 GMT Subject: Integrated: 8028265: Add legacy tz tests to OpenJDK In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote: > Please review this PR. The PR open sources the closed timezone tests. This pull request has now been integrated. Changeset: 92deab54 Author: Yoshiki Sato Committer: Sean Coffey URL: https://git.openjdk.org/jdk/commit/92deab546549ca549408a983fe361d9536d2cd37 Stats: 1221 lines in 9 files changed: 1221 ins; 0 del; 0 mod 8028265: Add legacy tz tests to OpenJDK Reviewed-by: coffeys, naoto ------------- PR: https://git.openjdk.org/jdk/pull/9476 From Shruthi.Shruthi1 at ibm.com Fri Jul 15 07:24:05 2022 From: Shruthi.Shruthi1 at ibm.com (Shruthi Shruthi1) Date: Fri, 15 Jul 2022 07:24:05 +0000 Subject: RFR: 8289471: Issue in Initialization of keys in ErrorMsg.java and XPATHErrorResources.java Message-ID: OpenJDK bug:?JDK-8289471 PR:?https://github.com/openjdk/jdk/pull/9369 From jpai at openjdk.org Fri Jul 15 07:24:49 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 15 Jul 2022 07:24:49 GMT Subject: RFR: 8290327: Remove java/lang/reflect/callerCache/ReflectionCallerCacheTest.java from ProblemList-Xcomp.txt In-Reply-To: References: Message-ID: <8EqhpUmBmFLqJHmGYGvf_-sfW49itcuKm8mrRAbQ6lk=.ccdd9b18-71b3-4baf-ae3b-8efd78045e4c@github.com> On Thu, 14 Jul 2022 21:01:05 GMT, Mandy Chung wrote: > It's expected that [JDK-8287596](https://bugs.openjdk.org/browse/JDK-8287596) has resolved [JDK-8288286](https://bugs.openjdk.org/browse/JDK-8288286). Remove ReflectionCallerCacheTest.java from the problem list for test execution. Hello Mandy, I just noticed that this test was problem listed in JDK 19. Should this removal of problem listing as well as the fix in ForceGC (https://bugs.openjdk.org/browse/JDK-8287596) be done in 19 too? ------------- PR: https://git.openjdk.org/jdk/pull/9500 From duke at openjdk.org Fri Jul 15 08:49:51 2022 From: duke at openjdk.org (liach) Date: Fri, 15 Jul 2022 08:49:51 GMT Subject: RFR: 8286849: Use @Stable for generic repositories In-Reply-To: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com> References: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com> Message-ID: On Tue, 17 May 2022 04:40:50 GMT, liach wrote: > Generic repositories, the implementation detail for generic information in core reflection, can be updated to use the `@Stable` annotation to replace their `volatile` access. Their existing accessor code is already safe, reading the cache fields only once. > > In addition, fixed potentially non-thread-safe `genericInfo` access in `Method`, `Field`, and `RecordComponent`. I should probably split the patch fixing thread safety of some generic information container off. ------------- PR: https://git.openjdk.org/jdk/pull/8742 From duke at openjdk.org Fri Jul 15 12:10:32 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:10:32 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable Message-ID: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Simplify code with `String.join()` ------------- Commit messages: - 8290300: Fix copy-right year - 8290300: Use standard String-joining tools where applicable Changes: https://git.openjdk.org/jdk/pull/9513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290300 Stats: 90 lines in 8 files changed: 1 ins; 68 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From ecki at zusammenkunft.net Fri Jul 15 12:17:20 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 15 Jul 2022 12:17:20 +0000 Subject: Case Insensitive DateFormatSymbols for parsing Message-ID: Hello, I noticed that it is surprisingly hard to make SimpleDateFormat accept all-uppercase month names while parsing. Even with a custom DateFormatSymbols that?s hard because you can only specify a single symbol for a month name. For parsing it would be good if you can either specify a list of names like ?June,june,JUNE? or have it allow a special case insensitive configuration option. (The list would also allow custom short forms like ?ja? ?fe? but not ?ju?? Am I missing something? Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.org Fri Jul 15 12:28:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 15 Jul 2022 12:28:48 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` LGTM, however are there tests that ensure the changes are benign? ------------- PR: https://git.openjdk.org/jdk/pull/9513 From alanb at openjdk.org Fri Jul 15 12:33:48 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 12:33:48 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` joptsimple is a 3rd party code so we probably don't want to change that. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: - 8290300: Revert jops - 8290300: Revert jops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/f3020263..80384470 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=00-01 Stats: 73 lines in 4 files changed: 58 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` Reverted jops ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:25:07 GMT, Jim Laskey wrote: >> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8290300: Revert jops >> - 8290300: Revert jops > > LGTM, however are there tests that ensure the changes are benign? @JimLaskey I'll double check and add tests if necessary ------------- PR: https://git.openjdk.org/jdk/pull/9513 From roger.riggs at oracle.com Fri Jul 15 14:14:16 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 15 Jul 2022 10:14:16 -0400 Subject: Case Insensitive DateFormatSymbols for parsing In-Reply-To: References: Message-ID: <86f0a06a-8549-1571-42f2-89396f00f1d5@oracle.com> Hi Bernd, Perhaps use java.time.format.DateTimeFormatter. You can create a case-insensitive DateTimeFormatterBuilder using .parseCaseInsensitive(). https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/time/format/DateTimeFormatterBuilder.html#parseCaseInsensitive() Regards, Roger On 7/15/22 8:17 AM, Bernd Eckenfels wrote: > Hello, > > I noticed that it is surprisingly hard to make SimpleDateFormat accept > all-uppercase month names while parsing. Even with a custom > DateFormatSymbols that?s hard because you can only specify a single > symbol for a month name. For parsing it would be good if you can > either specify a list of names like ?June,june,JUNE? or have it allow > a special case insensitive configuration option. (The list would also > allow custom short forms like ?ja? ?fe? but not ?ju?? > > Am I missing something? > > Gruss > Bernd > -- > http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Fri Jul 15 15:01:41 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 15 Jul 2022 15:01:41 +0000 Subject: Case Insensitive DateFormatSymbols for parsing In-Reply-To: <86f0a06a-8549-1571-42f2-89396f00f1d5@oracle.com> References: <86f0a06a-8549-1571-42f2-89396f00f1d5@oracle.com> Message-ID: Hello Roger, Thanks for the Tipp, that?s indeed a good reason why it?s not needed in the legacy SDF API. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Roger Riggs Gesendet: Friday, July 15, 2022 4:14:16 PM An: core-libs-dev at openjdk.org Betreff: Re: Case Insensitive DateFormatSymbols for parsing Hi Bernd, Perhaps use java.time.format.DateTimeFormatter. You can create a case-insensitive DateTimeFormatterBuilder using .parseCaseInsensitive(). https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/time/format/DateTimeFormatterBuilder.html#parseCaseInsensitive() Regards, Roger On 7/15/22 8:17 AM, Bernd Eckenfels wrote: Hello, I noticed that it is surprisingly hard to make SimpleDateFormat accept all-uppercase month names while parsing. Even with a custom DateFormatSymbols that?s hard because you can only specify a single symbol for a month name. For parsing it would be good if you can either specify a list of names like ?June,june,JUNE? or have it allow a special case insensitive configuration option. (The list would also allow custom short forms like ?ja? ?fe? but not ?ju?? Am I missing something? Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Fri Jul 15 15:31:45 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 15 Jul 2022 15:31:45 GMT Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" [v4] In-Reply-To: References: Message-ID: <4e5OcQhOryLDup6ttBbT19EOJr5iLj-pKs03FIEYKRc=.b7800c24-c7bd-41d0-9f96-1e142e531ce8@github.com> > The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java` > Fails intermittently when expected output from a subprocess is not found. > > I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced. > > The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded. > The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released. > When released the child process exits and the driver test will find all of the output it expects. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add Utils.adjustTimeout to waits for refs to be cleared ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9474/files - new: https://git.openjdk.org/jdk/pull/9474/files/cedaa015..8534379c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9474&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9474&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9474.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9474/head:pull/9474 PR: https://git.openjdk.org/jdk/pull/9474 From duke at openjdk.org Fri Jul 15 16:16:37 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 15 Jul 2022 16:16:37 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base Message-ID: This commit guards uses of Files methods returning path streams in java.base to use try-with-resources. ------------- Commit messages: - 8290316: Ensure that all directory streams are closed in java.base Changes: https://git.openjdk.org/jdk/pull/9518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290316 Stats: 52 lines in 5 files changed: 12 ins; 7 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/9518.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9518/head:pull/9518 PR: https://git.openjdk.org/jdk/pull/9518 From duke at openjdk.org Fri Jul 15 16:24:35 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 15 Jul 2022 16:24:35 GMT Subject: RFR: 8290359: Ensure that all directory streams are closed in jdk.link Message-ID: This commit adds try-with-resources for uses of Stream from Files methods that walk directories. ------------- Commit messages: - 8290359: Ensure that all directory streams are closed in jdk.link Changes: https://git.openjdk.org/jdk/pull/9520/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9520&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290359 Stats: 73 lines in 3 files changed: 17 ins; 4 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/9520.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9520/head:pull/9520 PR: https://git.openjdk.org/jdk/pull/9520 From naoto at openjdk.org Fri Jul 15 16:31:46 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 15 Jul 2022 16:31:46 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <4lc5aVxpfSL9ukqHt2IDLR_LQDkQx-3htusBXQDsx1I=.9c453024-986b-4828-9775-f5a1561d0097@github.com> On Fri, 15 Jul 2022 12:40:50 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8290300: Revert jops > - 8290300: Revert jops Changes to `Locale` look good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9513 From alanb at openjdk.org Fri Jul 15 16:38:12 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 16:38:12 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Changing these usages to close the stream is good but needs to keep the formatting/style consistent with the existing code. Also can you make sure the copyright date is updated on the files that need it. src/java.base/share/classes/java/time/chrono/HijrahChronology.java line 1040: > 1038: if (Files.isDirectory(CONF_PATH)) { > 1039: try (Stream stream = Files.list(CONF_PATH)) { > 1040: stream.map(p -> p.getFileName().toString()) I can't tell if there is a tab here but it looks like you've changed this to indent by 8 instead of 4 spaces. src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 141: > 139: .map(path -> toPackageName(top, path)) > 140: .filter(Checks::isPackageName) > 141: .forEach(packages::add); The formatting seems to a bit messed up here too, I don't know if you means to do that. In the try-block the indentation of stream.filter should be 4 spaces, not 8. Also can you restore the alignment of the expression provided to filter then it will be easier to read. src/java.base/share/classes/jdk/internal/module/ModulePath.java line 669: > 667: try (Stream stream = > 668: Files.find(dir, Integer.MAX_VALUE, (path, attrs) -> attrs.isRegularFile() && !isHidden(path))) { > 669: return stream.map(dir::relativize) This is inconsistent with existing code. If you change to something like the following then it would make future side-by-side diffs easier to read: try (Stream s = Files.find(dir, Integer.MAX_VALUE, (path, attrs) -> attrs.isRegularFile() && !isHidden(path))) { return s.map(...); } catch (IOException x) { throw new UncheckedIOException(x); } ------------- Changes requested by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9518 From alanb at openjdk.org Fri Jul 15 16:43:06 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 16:43:06 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base In-Reply-To: References: Message-ID: <-XwW6yYEuhCSKzYzMkz7EwBvlZLWtgLZBg5lClwS1MM=.e4c21bb0-c341-46dc-90fe-9be6e92ad82d@github.com> On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. src/java.base/share/classes/jdk/internal/module/ModuleHashes.java line 119: > 117: } > 118: try { > 119: byte[] buf = new byte[32*1024]; Can you move the declaration of bug to before the try? That would reduce the nesting. ------------- PR: https://git.openjdk.org/jdk/pull/9518 From mchung at openjdk.org Fri Jul 15 17:43:59 2022 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 15 Jul 2022 17:43:59 GMT Subject: RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" [v4] In-Reply-To: <4e5OcQhOryLDup6ttBbT19EOJr5iLj-pKs03FIEYKRc=.b7800c24-c7bd-41d0-9f96-1e142e531ce8@github.com> References: <4e5OcQhOryLDup6ttBbT19EOJr5iLj-pKs03FIEYKRc=.b7800c24-c7bd-41d0-9f96-1e142e531ce8@github.com> Message-ID: On Fri, 15 Jul 2022 15:31:45 GMT, Roger Riggs wrote: >> The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java` >> Fails intermittently when expected output from a subprocess is not found. >> >> I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced. >> >> The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded. >> The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released. >> When released the child process exits and the driver test will find all of the output it expects. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add Utils.adjustTimeout to waits for refs to be cleared Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9474 From mchung at openjdk.org Fri Jul 15 17:55:03 2022 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 15 Jul 2022 17:55:03 GMT Subject: RFR: 8290327: Remove java/lang/reflect/callerCache/ReflectionCallerCacheTest.java from ProblemList-Xcomp.txt In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 21:01:05 GMT, Mandy Chung wrote: > It's expected that [JDK-8287596](https://bugs.openjdk.org/browse/JDK-8287596) has resolved [JDK-8288286](https://bugs.openjdk.org/browse/JDK-8288286). Remove ReflectionCallerCacheTest.java from the problem list for test execution. I want to let the test executed in CI for 20 for a little while. If it's okay, then will backport to 19. ------------- PR: https://git.openjdk.org/jdk/pull/9500 From mchung at openjdk.org Fri Jul 15 18:14:42 2022 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 15 Jul 2022 18:14:42 GMT Subject: Integrated: 8290327: Remove java/lang/reflect/callerCache/ReflectionCallerCacheTest.java from ProblemList-Xcomp.txt In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 21:01:05 GMT, Mandy Chung wrote: > It's expected that [JDK-8287596](https://bugs.openjdk.org/browse/JDK-8287596) has resolved [JDK-8288286](https://bugs.openjdk.org/browse/JDK-8288286). Remove ReflectionCallerCacheTest.java from the problem list for test execution. This pull request has now been integrated. Changeset: cca91f7b Author: Mandy Chung URL: https://git.openjdk.org/jdk/commit/cca91f7bccc17932307fc05bac745b2bf814dac1 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8290327: Remove java/lang/reflect/callerCache/ReflectionCallerCacheTest.java from ProblemList-Xcomp.txt Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/9500 From rriggs at openjdk.org Fri Jul 15 18:30:26 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 15 Jul 2022 18:30:26 GMT Subject: Integrated: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 20:00:22 GMT, Roger Riggs wrote: > The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java` > Fails intermittently when expected output from a subprocess is not found. > > I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced. > > The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded. > The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released. > When released the child process exits and the driver test will find all of the output it expects. This pull request has now been integrated. Changeset: 0184f46b Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/0184f46bdfe4441ea6ef28c658c6677c4c736ee9 Stats: 73 lines in 4 files changed: 51 ins; 3 del; 19 mod 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library" Reviewed-by: mchung ------------- PR: https://git.openjdk.org/jdk/pull/9474 From ecaspole at openjdk.org Fri Jul 15 18:48:29 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Fri, 15 Jul 2022 18:48:29 GMT Subject: RFR: 8290391: Reduce runtime of java.util package microbenchmarks Message-ID: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> Adds Warmup, Measurement and Fork annotations to reduce the run time from 1 day 16 hours to 8 hours for this set. ------------- Commit messages: - 8290391: Reduce runtime of java.util package microbenchmarks Changes: https://git.openjdk.org/jdk/pull/9523/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9523&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290391 Stats: 173 lines in 16 files changed: 71 ins; 85 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/9523.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9523/head:pull/9523 PR: https://git.openjdk.org/jdk/pull/9523 From duke at openjdk.org Fri Jul 15 19:33:56 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 15 Jul 2022 19:33:56 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2] In-Reply-To: References: Message-ID: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: address formatting feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9518/files - new: https://git.openjdk.org/jdk/pull/9518/files/bba7406f..c0a09f91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=00-01 Stats: 25 lines in 4 files changed: 3 ins; 4 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9518.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9518/head:pull/9518 PR: https://git.openjdk.org/jdk/pull/9518 From duke at openjdk.org Fri Jul 15 19:33:57 2022 From: duke at openjdk.org (Ryan Ernst) Date: Fri, 15 Jul 2022 19:33:57 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Thanks Alan. The 8 space indents were unintentional. I think I've addressed all your comments in [c0a09f9](https://github.com/openjdk/jdk/pull/9518/commits/c0a09f91be22acce0555e5a8d06023975185d307). ------------- PR: https://git.openjdk.org/jdk/pull/9518 From darcy at openjdk.org Fri Jul 15 20:54:03 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 15 Jul 2022 20:54:03 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 13:11:33 GMT, Raffaello Giulietti wrote: >> Initial implementation. > > src/java.base/share/classes/java/lang/Float.java line 1174: > >> 1172: >> 1173: short result = 0; >> 1174: result = (short)(((exp + 15) << 10) | signif_bits); > > result = (short)(((exp + 15) << 10) + signif_bits); > > The final exponent needs to be incremented when `signif_bits == 0x400`. The `|` is not enough for this to happen. Good catch; I'll correct this bug in the next push. I'll be adding a test to verify correct rounding of all the values in a binade - the set of floating-point values with the same exponent. That test reveals this issue. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From darcy at openjdk.org Sat Jul 16 01:39:56 2022 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 16 Jul 2022 01:39:56 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v2] In-Reply-To: References: Message-ID: > Initial implementation. Joe Darcy 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 15 additional commits since the last revision: - Respond to review feedback. - Correct carry-out bug; add full binade test. - Improve NaN significand fidelity; refine tests. - Partial implementation of review feedback; test refinement. - Merge branch 'master' into JDK-8289551 - Further refine spec. - Refine spec and tests. - Fix implementation thresholds; refine tests. - Initial implementation of float -> binary16 round-to-nearest with tests. - Implement review feedback from John Rose. - ... and 5 more: https://git.openjdk.org/jdk/compare/28899bfd...b09fdfc3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/399248d2..b09fdfc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=00-01 Stats: 3640 lines in 185 files changed: 1849 ins; 823 del; 968 mod Patch: https://git.openjdk.org/jdk/pull/9422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422 PR: https://git.openjdk.org/jdk/pull/9422 From darcy at openjdk.org Sat Jul 16 03:26:51 2022 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 16 Jul 2022 03:26:51 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v3] In-Reply-To: References: Message-ID: > Initial implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Preserve NaN sign bit. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/b09fdfc3..420a9f3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422 PR: https://git.openjdk.org/jdk/pull/9422 From duke at openjdk.org Sat Jul 16 03:39:11 2022 From: duke at openjdk.org (Bernd) Date: Sat, 16 Jul 2022 03:39:11 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 19:33:56 GMT, Ryan Ernst wrote: >> This commit guards uses of Files methods returning path streams in >> java.base to use try-with-resources. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > address formatting feedback src/java.base/share/classes/java/time/chrono/HijrahChronology.java line 1041: > 1039: try (Stream stream = Files.list(CONF_PATH)) { > 1040: stream.map(p -> p.getFileName().toString()) > 1041: .filter(fn -> fn.matches("hijrah-config-[^\\.]+\\.properties")) BTW Should this use RESOURCE_PREFIX/SUFFIX and is the \\ inside [character class] suppose to quote the .? ------------- PR: https://git.openjdk.org/jdk/pull/9518 From chegar at openjdk.org Sat Jul 16 08:43:46 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Sat, 16 Jul 2022 08:43:46 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 19:33:56 GMT, Ryan Ernst wrote: >> This commit guards uses of Files methods returning path streams in >> java.base to use try-with-resources. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > address formatting feedback Changes requested by chegar (Reviewer). src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 262: > 260: p = module.relativize(p); > 261: String pkgName = slashesToDots(p.toString()); > 262: // skip META-INFO and empty strings Trivially, while here can we fix this typo, META-INFO <- drop the `O` src/java.base/share/classes/jdk/internal/jrtfs/ExplodedImage.java line 271: > 269: moduleNames.add(moduleName); > 270: } > 271: }); There is a missing closing curly brace here (which should come on the next line), but otherwise looks fine. src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 138: > 136: stream.filter(path -> (!isAutomatic > 137: || path.toString().endsWith(".class")) > 138: && !isHidden(path)) Trivially, can the indentation of the two boolean operators be pushed in so that they align underneath the lambda parameter. ------------- PR: https://git.openjdk.org/jdk/pull/9518 From chegar at openjdk.org Sat Jul 16 08:43:47 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Sat, 16 Jul 2022 08:43:47 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2] In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 03:35:06 GMT, Bernd wrote: >> Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: >> >> address formatting feedback > > src/java.base/share/classes/java/time/chrono/HijrahChronology.java line 1041: > >> 1039: try (Stream stream = Files.list(CONF_PATH)) { >> 1040: stream.map(p -> p.getFileName().toString()) >> 1041: .filter(fn -> fn.matches("hijrah-config-[^\\.]+\\.properties")) > > BTW Should this use RESOURCE_PREFIX/SUFFIX and is the \\ inside [character class] suppose to quote the .? @ecki this seems orthogonal to this particular issue. Maybe it could be considered separately, if needed. ------------- PR: https://git.openjdk.org/jdk/pull/9518 From jwilhelm at openjdk.org Sat Jul 16 12:36:44 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 16 Jul 2022 12:36:44 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8281969: Bad result for the snippet @link tag if substring/regex consists of whitespace - 8290250: Shenandoah: disable Loom for iu mode - 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9526&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9526&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9526/files Stats: 68 lines in 7 files changed: 34 ins; 12 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/9526.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9526/head:pull/9526 PR: https://git.openjdk.org/jdk/pull/9526 From duke at openjdk.org Sat Jul 16 17:50:01 2022 From: duke at openjdk.org (j3graham) Date: Sat, 16 Jul 2022 17:50:01 GMT Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2] In-Reply-To: References: Message-ID: <_N15VLFpOaVEcls36OIDYj5LXJ6WowKsTj7eKG2H8CA=.b3bf22b1-c12e-4fa3-85d9-8f5bc606bb27@github.com> On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. >> >> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Refactored empty stream implementations to reduce duplicate code and improved unordered() > Added StreamSupport.empty for primitive spliterators and use that in Arrays.stream() I hope this PR isn?t abandoned. It?s the kind of optimization I would hope steams could do - even if this was initially only applied to arrays and immutable lists. One minor suggestion would be to move the implementations into a new package-visible EmptyStreams class to reduce churn in the already large Streams ------------- PR: https://git.openjdk.org/jdk/pull/6275 From asemenyuk at openjdk.org Sat Jul 16 19:45:51 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 16 Jul 2022 19:45:51 GMT Subject: RFR: 8283707: Support version format on Windows Message-ID: 8283707: Support version format on Windows ------------- Commit messages: - Create separate tests for the new feature. - Trailing whitespaces fixed - Better test coverage - Bugfixes after manual testing - 8283707: Support version format on Windows Changes: https://git.openjdk.org/jdk/pull/9507/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9507&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283707 Stats: 1316 lines in 15 files changed: 1256 ins; 18 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/9507.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9507/head:pull/9507 PR: https://git.openjdk.org/jdk/pull/9507 From asemenyuk at openjdk.org Sat Jul 16 21:31:32 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 16 Jul 2022 21:31:32 GMT Subject: RFR: 8290398: jpackage exe instellers are not installed in jtreg tests Message-ID: <-2uU1ZgiQtTJWlv4HlMp2-rML96PbNusmKVHv5f-lQI=.316389bb-beb7-4445-bf69-30335aea5a0b@github.com> 8290398: jpackage exe instellers are not installed in jtreg tests ------------- Commit messages: - 8290398: jpackage exe instellers are not installed in jtreg tests Changes: https://git.openjdk.org/jdk/pull/9530/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9530&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290398 Stats: 56 lines in 1 file changed: 35 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9530.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9530/head:pull/9530 PR: https://git.openjdk.org/jdk/pull/9530 From asemenyuk at openjdk.org Sat Jul 16 21:42:38 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 16 Jul 2022 21:42:38 GMT Subject: RFR: 8290400: Must run exe installers in jpackage jtreg tests without UI Message-ID: 8290400: Must run exe installers in jpackage jtreg tests without UI ------------- Commit messages: - 8290400: Must run exe installers in jpackage jtreg tests without UI Changes: https://git.openjdk.org/jdk/pull/9531/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9531&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290400 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9531.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9531/head:pull/9531 PR: https://git.openjdk.org/jdk/pull/9531 From duke at openjdk.org Sat Jul 16 21:47:43 2022 From: duke at openjdk.org (j3graham) Date: Sat, 16 Jul 2022 21:47:43 GMT Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2] In-Reply-To: References: Message-ID: <2rOVszHV4pPiq87z3rwopNbrFpKlog5CffWu0RoUGsk=.2de7dd1c-0682-47a0-a138-25343b45eca1@github.com> On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. >> >> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Refactored empty stream implementations to reduce duplicate code and improved unordered() > Added StreamSupport.empty for primitive spliterators and use that in Arrays.stream() src/java.base/share/classes/java/util/stream/StreamSupport.java line 339: > 337: * @return a new sequential empty {@code IntStream} > 338: */ > 339: public static IntStream emptyIntStream(Spliterator.OfInt spliterator) { In the interest of not adding new public APIs, can these be removed in favour of eg, IntStream.empty()? It wouldn?t take the spliterator, but perhaps it isn?t necessary. ------------- PR: https://git.openjdk.org/jdk/pull/6275 From asemenyuk at openjdk.org Sat Jul 16 21:57:29 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 16 Jul 2022 21:57:29 GMT Subject: RFR: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure Message-ID: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure ------------- Commit messages: - 8290402: jpackage exe uninstallers don't return correct exit code in case of failure Changes: https://git.openjdk.org/jdk/pull/9532/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9532&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290402 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9532.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9532/head:pull/9532 PR: https://git.openjdk.org/jdk/pull/9532 From asemenyuk at openjdk.org Sat Jul 16 22:08:12 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 16 Jul 2022 22:08:12 GMT Subject: RFR: 8283707: Support version format on Windows [v2] In-Reply-To: References: Message-ID: > 8283707: Support version format on Windows Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Comments fixed and better naming in the code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9507/files - new: https://git.openjdk.org/jdk/pull/9507/files/f8b187f2..0e2238da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9507&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9507&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9507.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9507/head:pull/9507 PR: https://git.openjdk.org/jdk/pull/9507 From redestad at openjdk.org Sun Jul 17 11:02:00 2022 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 17 Jul 2022 11:02:00 GMT Subject: RFR: 8288933: Improve the implementation of Double/Float.isInfinite In-Reply-To: <3ACF4446eOlmU4fy37s0ethO60isKd4Gd_Wtr18k-MA=.069bece8-1b36-4f40-9a79-16efb018762d@github.com> References: <3ACF4446eOlmU4fy37s0ethO60isKd4Gd_Wtr18k-MA=.069bece8-1b36-4f40-9a79-16efb018762d@github.com> Message-ID: On Thu, 14 Jul 2022 05:17:09 GMT, Joe Darcy wrote: > @cl4es, what set of platforms do we usually consider for evaluating performance changes like A mix of x86 and aarch64 systems, some old, some new. We could run the microbenchmark on our internal performance system to verify the reported performance gain. I assume the first score column is the baseline and the second the patched version, so a 2x gain on x86, right @merykitty? ------------- PR: https://git.openjdk.org/jdk/pull/9238 From jwilhelm at openjdk.org Sun Jul 17 15:15:03 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sun, 17 Jul 2022 15:15:03 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 12:26:23 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 522b6574 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/522b65743ca10fcba0a27d25b8fa11319999e228 Stats: 68 lines in 7 files changed: 34 ins; 12 del; 22 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9526 From dholmes at openjdk.org Sun Jul 17 23:03:37 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 17 Jul 2022 23:03:37 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC Message-ID: Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: The Java manpage was missing updates from: - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. The Java manpage has slight formatting differences from: - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) The keytool manpage was missing updates from: - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA The jar manpage was missing updates from: - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) The jarsigner manpage was missing updates from: - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA The javadoc manpage was missing updates from: - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option The jmod manpage was missing updates from: - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) The jpackage manpage was missing updates from: - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code The jshell manpage was missing updates from: - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. ------------- Commit messages: - 8278274: Update nroff pages in JDK 19 before RC Changes: https://git.openjdk.org/jdk19/pull/145/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=145&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278274 Stats: 515 lines in 28 files changed: 431 ins; 16 del; 68 mod Patch: https://git.openjdk.org/jdk19/pull/145.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/145/head:pull/145 PR: https://git.openjdk.org/jdk19/pull/145 From duke at openjdk.org Mon Jul 18 02:17:04 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Mon, 18 Jul 2022 02:17:04 GMT Subject: RFR: 8288933: Improve the implementation of Double/Float.isInfinite In-Reply-To: References: <3ACF4446eOlmU4fy37s0ethO60isKd4Gd_Wtr18k-MA=.069bece8-1b36-4f40-9a79-16efb018762d@github.com> Message-ID: On Sun, 17 Jul 2022 10:58:45 GMT, Claes Redestad wrote: >> @merykitty, the proposed change is functionally correct. >> >> @cl4es, what set of platforms do we usually consider for evaluating performance changes like this? > >> @cl4es, what set of platforms do we usually consider for evaluating performance changes like > > A mix of x86 and aarch64 systems, some old, some new. We could run the microbenchmark on our internal performance system to verify the reported performance gain. I assume the first score column is the baseline and the second the patched version, so a 2x gain on x86, right @merykitty? @cl4es yes the former numbers are the baseline and the latters are of this patch ------------- PR: https://git.openjdk.org/jdk/pull/9238 From iklam at openjdk.org Mon Jul 18 03:28:39 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 18 Jul 2022 03:28:39 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle Message-ID: Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., class pkg1.Base { protected void doit(String s) { System.out.println(s); } } class pkg2.Child extends pkg1.Base { void test() { Optional opt = Optional.of("foo"); opt.ifPresent(this::doit); } } More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 More details about the condition that triggers the error can be found in the test file Child.jcod. ------------- Commit messages: - 8290417: CDS cannot archive lamda proxy with useImplMethodHandle Changes: https://git.openjdk.org/jdk19/pull/146/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290417 Stats: 436 lines in 6 files changed: 434 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/146.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/146/head:pull/146 PR: https://git.openjdk.org/jdk19/pull/146 From dholmes at openjdk.org Mon Jul 18 03:45:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Jul 2022 03:45:13 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 03:15:02 GMT, Ioi Lam wrote: > Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). > > CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., > > > class pkg1.Base { > protected void doit(String s) { > System.out.println(s); > } > } > class pkg2.Child extends pkg1.Base { > void test() { > Optional opt = Optional.of("foo"); > opt.ifPresent(this::doit); > } > } > > > More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 > > More details about the condition that triggers the error can be found in the test file Child.jcod. Looks good! Thanks. test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java line 28: > 26: * @test > 27: * @bug 8290417 > 28: * @summary CDS cannot archive lamda proxy with useImplMethodHandle typo: lamda -> lambda test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicLambdaWithUseImplMethodHandle.java line 28: > 26: * @test > 27: * @bug 8290417 > 28: * @summary CDS cannot archive lamda proxy with useImplMethodHandle typo: lamda -> lambda ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk19/pull/146 From iklam at openjdk.org Mon Jul 18 04:14:03 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 18 Jul 2022 04:14:03 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v2] In-Reply-To: References: Message-ID: > Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). > > CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., > > > class pkg1.Base { > protected void doit(String s) { > System.out.println(s); > } > } > class pkg2.Child extends pkg1.Base { > void test() { > Optional opt = Optional.of("foo"); > opt.ifPresent(this::doit); > } > } > > > More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 > > More details about the condition that triggers the error can be found in the test file Child.jcod. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed typo ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/146/files - new: https://git.openjdk.org/jdk19/pull/146/files/5ce2cbd9..7122e367 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=146&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=146&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/146.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/146/head:pull/146 PR: https://git.openjdk.org/jdk19/pull/146 From duke at openjdk.org Mon Jul 18 05:17:59 2022 From: duke at openjdk.org (Chris Hennick) Date: Mon, 18 Jul 2022 05:17:59 GMT Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v14] In-Reply-To: References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com> Message-ID: <9iV27yGM7SIM9-PcxbQcLtONy3x6fIPNkj7IQIZPQrY=.d3108372-b63a-4263-a038-9eaa26367dbb@github.com> On Sun, 19 Jun 2022 23:38:36 GMT, Chris Hennick wrote: >> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections: >> >> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`. >> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.) >> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`. > > Chris Hennick has updated the pull request incrementally with one additional commit since the last revision: > > Rewrite Javadoc Keep open; I'll submit some benchmarks when I have a chance. ------------- PR: https://git.openjdk.org/jdk/pull/8131 From shade at openjdk.org Mon Jul 18 07:45:04 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Jul 2022 07:45:04 GMT Subject: [jdk19] RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 08:08:15 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions Seems too late for JDK 19, rebased to mainline: https://github.com/openjdk/jdk/pull/9533 ------------- PR: https://git.openjdk.org/jdk19/pull/27 From shade at openjdk.org Mon Jul 18 07:45:04 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Jul 2022 07:45:04 GMT Subject: [jdk19] Withdrawn: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 08:08:15 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk19/pull/27 From shade at openjdk.org Mon Jul 18 07:48:34 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Jul 2022 07:48:34 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs Message-ID: Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success test ObjectStreamClassCaching.testCachingEffectiveness(): failure java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] at org.testng.Assert.fail(Assert.java:99) at org.testng.Assert.failNotEquals(Assert.java:1037) at org.testng.Assert.assertFalse(Assert.java:67) I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. Additional testing: - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/9533/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9533&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283276 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9533.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9533/head:pull/9533 PR: https://git.openjdk.org/jdk/pull/9533 From duke at openjdk.org Mon Jul 18 11:17:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:17:37 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v3] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <6NKq2IAULEe2WYW2aIEOvu9-8_p4aKtrW1ZFRJo16mc=.17712761-2483-49b4-acf4-2faa394a1a99@github.com> > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Remove unused piece of code in formatList() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/80384470..4f2bbfd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 11:17:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:17:37 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v3] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:25:07 GMT, Jim Laskey wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290300: Remove unused piece of code in formatList() > > LGTM, however are there tests that ensure the changes are benign? @JimLaskey changes in `WindowsPath` are covered by `PathOps`, apart from this there are 10 tests calling this method. With `ProcessBuilder` and `Locale` it looks like the code I've changed is never executed at all for `ProcessStartEvent.isEnabled()` always return false. For `Locale` all the call sites of `formatList()` never pass null, so the code in `if` block is never executed. I think we can delete this unused parts of the code in `Locale`, but I'm not sure about `ProcessBuilder`. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 11:31:59 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:31:59 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/4f2bbfd3..5b18c39c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 14:02:47 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 18 Jul 2022 14:02:47 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v3] In-Reply-To: References: Message-ID: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: fix compile and address more feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9518/files - new: https://git.openjdk.org/jdk/pull/9518/files/c0a09f91..b5076b1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9518&range=01-02 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9518.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9518/head:pull/9518 PR: https://git.openjdk.org/jdk/pull/9518 From duke at openjdk.org Mon Jul 18 14:14:06 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 18 Jul 2022 14:14:06 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list Message-ID: This commit adds additional clarification to the javadocs of ModuleReader::list about needing to close the stream. The new wording is similar to that used in Files::find and other similar methods. ------------- Commit messages: - 8290353: Clarify the streams returned by ModuleReader::list Changes: https://git.openjdk.org/jdk/pull/9538/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9538&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290353 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9538.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9538/head:pull/9538 PR: https://git.openjdk.org/jdk/pull/9538 From stuefe at openjdk.org Mon Jul 18 14:29:16 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 18 Jul 2022 14:29:16 GMT Subject: RFR: JDK-8290460: Alpine: disable some panama tests that rely on std::thread Message-ID: <6av2IizSbvXAPApqrH9cFcnbrhHlUAsEvnziCh9XObM=.aeb252ed-7771-4d7f-a905-bbf8a1ef7fc2@github.com> Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, I'd like to disable - java/foreign/TestUpcallAsync.java - java/foreign/enablenativeaccess/TestEnableNativeAccess.java on muslc to take load from our CIs. Tests: tested locally that the tests are excluded on Alpine, and remain active on other platforms. ------------- Commit messages: - Disable tests Changes: https://git.openjdk.org/jdk/pull/9539/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9539&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290460 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9539.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9539/head:pull/9539 PR: https://git.openjdk.org/jdk/pull/9539 From rriggs at openjdk.org Mon Jul 18 14:52:04 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 14:52:04 GMT Subject: [jdk19] RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 08:08:15 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions Test bugs can be fixed through RPD2: https://openjdk.org/jeps/3#rdp-2 See the section on 'Test and Documentation bugs'. Committing to the mainline and then requesting a backport of the changeset works too. Adding the `noreg-self` label identifies it as a test-only fix. ------------- PR: https://git.openjdk.org/jdk19/pull/27 From rriggs at openjdk.org Mon Jul 18 14:54:58 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 14:54:58 GMT Subject: RFR: 8290391: Reduce runtime of java.util package microbenchmarks In-Reply-To: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> References: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> Message-ID: On Fri, 15 Jul 2022 18:41:09 GMT, Eric Caspole wrote: > Adds Warmup, Measurement and Fork annotations to reduce the run time from 1 day 16 hours to 8 hours for this set. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9523 From chegar at openjdk.org Mon Jul 18 14:57:50 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 18 Jul 2022 14:57:50 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 14:06:00 GMT, Ryan Ernst wrote: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. src/java.base/share/classes/java/lang/module/ModuleReader.java line 217: > 215: * > 216: *

        The returned stream contains references to one or more open directories > 217: * in the module. The directories are closed by closing the stream.

        This mostly looks good - I agree with adding the note here. Should the wording be relaxed a little - replace "contains references" with "may contain references" - since the stream will not always contain references to open directories - it depends on the type of reader. The end result / guidance is the same - use in a try-with-resources block - I'm just suggesting a slight relaxing of the wording. src/java.base/share/classes/java/lang/module/ModuleReader.java line 224: > 222: * @apiNote > 223: * This method must be used within a try-with-resources statement or similar > 224: * control structure to ensure that the stream's open directories are closed Similar to my other comment - should "must' be replaced with "should" - for the same aforementioned reason. ------------- PR: https://git.openjdk.org/jdk/pull/9538 From chegar at openjdk.org Mon Jul 18 15:03:49 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 18 Jul 2022 15:03:49 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 14:06:00 GMT, Ryan Ernst wrote: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Given the recommendation to close streams returned by the `list` method, then this PR could be extended to update any usages in, at least, java.base. If there are many usages beyond java.base, then a separate issue could be filed to update them too. ( if not already covered by a previous PR in this area ) ------------- PR: https://git.openjdk.org/jdk/pull/9538 From redestad at openjdk.org Mon Jul 18 15:08:07 2022 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 18 Jul 2022 15:08:07 GMT Subject: RFR: 8290391: Reduce runtime of java.util package microbenchmarks In-Reply-To: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> References: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> Message-ID: On Fri, 15 Jul 2022 18:41:09 GMT, Eric Caspole wrote: > Adds Warmup, Measurement and Fork annotations to reduce the run time from 1 day 16 hours to 8 hours for this set. LGTM, some suggestions inline that you can choose to ignore test/micro/org/openjdk/bench/java/util/ArraysFill.java line 48: > 46: public class ArraysFill { > 47: > 48: @Param({"10", "16", "31", "59", "89", "126", "250", "266", "511", "1021", "2047", "2048", "4095", "8195"}) Can we prune a few of these? test/micro/org/openjdk/bench/java/util/ArraysMismatchPartialInlining.java line 47: > 45: public class ArraysMismatchPartialInlining { > 46: > 47: @Param({"3", "4", "5", "6", "7", "15", "31", "63", "95", "800"}) Can we prune a few of these? At least 4, 5, 6 seem like they'll not add much signal. test/micro/org/openjdk/bench/java/util/Base64VarLenDecode.java line 87: > 85: > 86: @Benchmark > 87: @Warmup(iterations = 4, time = 2) I prefer putting these at class level (even when there's only one `@Benchmark`) ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.org/jdk/pull/9523 From jjg at openjdk.org Mon Jul 18 15:24:06 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 18 Jul 2022 15:24:06 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote: > Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. > > All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: > > The Java manpage was missing updates from: > - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. > > The Java manpage has slight formatting differences from: > - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux > - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS > > The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) > > > The keytool manpage was missing updates from: > - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The jar manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jarsigner manpage was missing updates from: > - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The javadoc manpage was missing updates from: > - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option > > The jmod manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jpackage manpage was missing updates from: > - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature > - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 > - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code > > The jshell manpage was missing updates from: > - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. src/java.base/share/man/keytool.1 line 456: > 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the > 455: keystore. > 456: This option is used to sign the certificate with the signer?s private Not a problem with this PR as such, but we still have a `?` character in the output. ------------- PR: https://git.openjdk.org/jdk19/pull/145 From chegar at openjdk.org Mon Jul 18 15:24:54 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 18 Jul 2022 15:24:54 GMT Subject: RFR: 8290316: Ensure that all directory streams are closed in java.base [v3] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 14:02:47 GMT, Ryan Ernst wrote: >> This commit guards uses of Files methods returning path streams in >> java.base to use try-with-resources. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > fix compile and address more feedback LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9518 From jjg at openjdk.org Mon Jul 18 15:30:09 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 18 Jul 2022 15:30:09 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote: > Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. > > All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: > > The Java manpage was missing updates from: > - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. > > The Java manpage has slight formatting differences from: > - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux > - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS > > The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) > > > The keytool manpage was missing updates from: > - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The jar manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jarsigner manpage was missing updates from: > - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The javadoc manpage was missing updates from: > - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option > > The jmod manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jpackage manpage was missing updates from: > - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature > - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 > - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code > > The jshell manpage was missing updates from: > - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. The version changes in each file look good (`19-ea` to `19`). The changes for javadoc look good. I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.org/jdk19/pull/145 From chegar at openjdk.org Mon Jul 18 15:45:52 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 18 Jul 2022 15:45:52 GMT Subject: RFR: 8290359: Ensure that all directory streams are closed in jdk.link In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 16:18:17 GMT, Ryan Ernst wrote: > This commit adds try-with-resources for uses of Stream from Files > methods that walk directories. Changes requested by chegar (Reviewer). src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 834: > 832: name.endsWith(".EC") || > 833: name.startsWith("META-INF/SIG-") > 834: ); Trivially, can we please keep the indentation consistent with the previous version. So, align all `name.endsWith` expressions under the 's' from startsWith. ------------- PR: https://git.openjdk.org/jdk/pull/9520 From ccheung at openjdk.org Mon Jul 18 16:18:28 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 18 Jul 2022 16:18:28 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 04:14:03 GMT, Ioi Lam wrote: >> Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). >> >> CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., >> >> >> class pkg1.Base { >> protected void doit(String s) { >> System.out.println(s); >> } >> } >> class pkg2.Child extends pkg1.Base { >> void test() { >> Optional opt = Optional.of("foo"); >> opt.ifPresent(this::doit); >> } >> } >> >> >> More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 >> >> More details about the condition that triggers the error can be found in the test file Child.jcod. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo Looks good. Just couple of nits. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicLambdaWithUseImplMethodHandle.java line 41: > 39: > 40: import jdk.test.lib.cds.CDSOptions; > 41: import jdk.test.lib.cds.CDSTestUtils; Extra import statements? test/hotspot/jtreg/runtime/cds/appcds/test-classes/pkg2/Child.jcod line 59: > 57: // > 58: // Javac in JDK 17 generates a public method for accessing the protected method > 59: // in the base class. As a result, InnerClassLambdaMetafactory will no generate typo no -> not? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk19/pull/146 From naoto at openjdk.org Mon Jul 18 16:49:45 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 18 Jul 2022 16:49:45 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Mon, 18 Jul 2022 11:08:24 GMT, ?????? ??????? wrote: > For `Locale` all the call sites of `formatList()` never pass null, so the code in `if` block is never executed. I think we can delete this unused parts of the code in `Locale`, Are you sure about this? `pattern` is derived from `LocaleResources.getLocaleName()` which could return `null`. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From ecaspole at openjdk.org Mon Jul 18 17:11:08 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Mon, 18 Jul 2022 17:11:08 GMT Subject: RFR: 8290391: Reduce runtime of java.util package microbenchmarks [v2] In-Reply-To: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> References: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> Message-ID: <57OZqvSIyMZtaLUiyYJcrfdgDqfnx5UrGrkIY_CCtLw=.51a666b4-f8f2-4574-87d4-5b1d66583ee9@github.com> > Adds Warmup, Measurement and Fork annotations to reduce the run time from 1 day 16 hours to 8 hours for this set. Eric Caspole has updated the pull request incrementally with one additional commit since the last revision: Apply @cl4es comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9523/files - new: https://git.openjdk.org/jdk/pull/9523/files/8d71eb4e..50028d59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9523&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9523&range=00-01 Stats: 9 lines in 3 files changed: 3 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9523.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9523/head:pull/9523 PR: https://git.openjdk.org/jdk/pull/9523 From duke at openjdk.org Mon Jul 18 17:20:08 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 17:20:08 GMT Subject: Integrated: 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com> Message-ID: On Thu, 7 Jul 2022 10:21:06 GMT, ?????? ??????? wrote: > We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null. > > Benchmark results: > > before > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,815 ? 0,154 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,462 ? 0,068 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,653 ? 0,040 ns/op > StringConstructor.newStringFromRangedArray avgt 50 5,090 ? 0,066 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,550 ? 0,041 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 8,080 ? 0,055 ns/op > > after > > Benchmark Mode Cnt Score Error Units > StringConstructor.newStringFromArray avgt 50 4,595 ? 0,053 ns/op > StringConstructor.newStringFromArrayWithCharset avgt 50 4,038 ? 0,062 ns/op > StringConstructor.newStringFromArrayWithCharsetName avgt 50 8,035 ? 0,031 ns/op > StringConstructor.newStringFromRangedArray avgt 50 4,084 ? 0,007 ns/op > StringConstructor.newStringFromRangedArrayWithCharset avgt 50 4,014 ? 0,008 ns/op > StringConstructor.newStringFromRangedArrayWithCharsetName avgt 50 7,466 ? 0,071 ns/op This pull request has now been integrated. Changeset: efed7a7f Author: Sergey Tsypanov Committer: Phil Race URL: https://git.openjdk.org/jdk/commit/efed7a7f65c0fa4b757ac6b448d11d7ddebdcc9a Stats: 97 lines in 5 files changed: 84 ins; 1 del; 12 mod 8289908: Skip bounds check for cases when String is constructed from entirely used byte[] Reviewed-by: prr, rriggs, aturbanov ------------- PR: https://git.openjdk.org/jdk/pull/9407 From ecaspole at openjdk.org Mon Jul 18 17:25:02 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Mon, 18 Jul 2022 17:25:02 GMT Subject: RFR: 8290391: Reduce runtime of java.util package microbenchmarks [v2] In-Reply-To: <57OZqvSIyMZtaLUiyYJcrfdgDqfnx5UrGrkIY_CCtLw=.51a666b4-f8f2-4574-87d4-5b1d66583ee9@github.com> References: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> <57OZqvSIyMZtaLUiyYJcrfdgDqfnx5UrGrkIY_CCtLw=.51a666b4-f8f2-4574-87d4-5b1d66583ee9@github.com> Message-ID: On Mon, 18 Jul 2022 17:11:08 GMT, Eric Caspole wrote: >> Adds Warmup, Measurement and Fork annotations to reduce the run time from 1 day 16 hours to 8 hours for this set. > > Eric Caspole has updated the pull request incrementally with one additional commit since the last revision: > > Apply @cl4es comments I applied Claes comments in the last push. ------------- PR: https://git.openjdk.org/jdk/pull/9523 From rriggs at openjdk.org Mon Jul 18 17:53:16 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 17:53:16 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v7] In-Reply-To: References: Message-ID: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. Roger Riggs 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 10 additional commits since the last revision: - Remove diagnostics output from ProcessBuilder - Merge branch '8289643-pipeline-start-leak' of https://github.com/RogerRiggs/jdk into 8289643-pipeline-start-leak - Add DEBUG diagnostics to determine cause of GitHub Action test failures due to unexpected pipes - Merge branch 'master' into 8289643-pipeline-start-leak - Add DEBUG diagnostics to determine cause of GitHub Action test failures due to unexpected pipes - Use DirectoryStream and handle IOExceptions - remove debug output - Add TWR for Files.walk of /proc - Cleanup of PipelineLeaksFD test improving error messages and source cleanup. - 8289643: File descriptor leak with ProcessBuilder.startPipeline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9414/files - new: https://git.openjdk.org/jdk/pull/9414/files/ffddeed9..095e76b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=05-06 Stats: 81632 lines in 1825 files changed: 42313 ins; 25394 del; 13925 mod Patch: https://git.openjdk.org/jdk/pull/9414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9414/head:pull/9414 PR: https://git.openjdk.org/jdk/pull/9414 From rriggs at openjdk.org Mon Jul 18 17:53:22 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 17:53:22 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v7] In-Reply-To: <-zow6jtPRp6kV5ITtRp0vhXTfR0zH2-4SSkEnQnoueA=.2b7a7512-4fc2-4352-9abe-e9138d36ca7a@github.com> References: <-zow6jtPRp6kV5ITtRp0vhXTfR0zH2-4SSkEnQnoueA=.2b7a7512-4fc2-4352-9abe-e9138d36ca7a@github.com> Message-ID: On Fri, 8 Jul 2022 13:29:12 GMT, Jaikiran Pai wrote: >> Roger Riggs 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 10 additional commits since the last revision: >> >> - Remove diagnostics output from ProcessBuilder >> - Merge branch '8289643-pipeline-start-leak' of https://github.com/RogerRiggs/jdk into 8289643-pipeline-start-leak >> - Add DEBUG diagnostics to determine cause of GitHub Action test failures due to unexpected pipes >> - Merge branch 'master' into 8289643-pipeline-start-leak >> - Add DEBUG diagnostics to determine cause of GitHub Action test failures due to unexpected pipes >> - Use DirectoryStream and handle IOExceptions >> - remove debug output >> - Add TWR for Files.walk of /proc >> - Cleanup of PipelineLeaksFD test improving error messages and source cleanup. >> - 8289643: File descriptor leak with ProcessBuilder.startPipeline > > test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 101: > >> 99: >> 100: Set pipesAfter = myPipes(); >> 101: if (!pipesBefore.equals(pipesAfter)) { > > Since `myPipes()` can return null, should there be a null check here for `pipesBefore`? No longer returns null. ------------- PR: https://git.openjdk.org/jdk/pull/9414 From mchung at openjdk.org Mon Jul 18 18:10:09 2022 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 18 Jul 2022 18:10:09 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v2] In-Reply-To: References: Message-ID: <51RB-rT9YovQIVC5EiCRRJFHxs_oKbexzyBhCruaS4c=.a0c7f7b5-4400-4bed-b655-58fc820008b1@github.com> On Mon, 18 Jul 2022 04:14:03 GMT, Ioi Lam wrote: >> Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). >> >> CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., >> >> >> class pkg1.Base { >> protected void doit(String s) { >> System.out.println(s); >> } >> } >> class pkg2.Child extends pkg1.Base { >> void test() { >> Optional opt = Optional.of("foo"); >> opt.ifPresent(this::doit); >> } >> } >> >> >> More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 >> >> More details about the condition that triggers the error can be found in the test file Child.jcod. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo Looks fine. I agree that this fix is low risk to disable archiving the lambda proxy in the case when passing a live method handle for invocation. test/hotspot/jtreg/runtime/cds/appcds/test-classes/pkg1/BaseWithProtectedMethod.java line 29: > 27: public class BaseWithProtectedMethod { > 28: protected void protectedMethod(String s) { > 29: Thread.dumpStack(); is it intentional for the test to keep dumping the stack? ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk19/pull/146 From mchung at openjdk.org Mon Jul 18 18:14:05 2022 From: mchung at openjdk.org (Mandy Chung) Date: Mon, 18 Jul 2022 18:14:05 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 14:53:19 GMT, Chris Hegarty wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > src/java.base/share/classes/java/lang/module/ModuleReader.java line 217: > >> 215: * >> 216: *

        The returned stream contains references to one or more open directories >> 217: * in the module. The directories are closed by closing the stream.

        > > This mostly looks good - I agree with adding the note here. Should the wording be relaxed a little - replace "contains references" with "may contain references" - since the stream will not always contain references to open directories - it depends on the type of reader. The end result / guidance is the same - use in a try-with-resources block - I'm just suggesting a slight relaxing of the wording. "may contain references" is good. I agree that the wordings should be relaxed a little. Similar for the apiNote. ------------- PR: https://git.openjdk.org/jdk/pull/9538 From duke at openjdk.org Mon Jul 18 18:19:49 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 18 Jul 2022 18:19:49 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 14:06:00 GMT, Ryan Ernst wrote: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. I relaxed the wording in [0b3ca18](https://github.com/openjdk/jdk/pull/9538/commits/0b3ca18267b4a54db7d749dba036b4618f2eb0e6) and addressed uses of list() in java.base in [a72a5b9](https://github.com/openjdk/jdk/pull/9538/commits/a72a5b9ec4e22ca4a414554b722042d4cbfaef58). ------------- PR: https://git.openjdk.org/jdk/pull/9538 From duke at openjdk.org Mon Jul 18 18:22:02 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 18 Jul 2022 18:22:02 GMT Subject: RFR: 8290359: Ensure that all directory streams are closed in jdk.link [v2] In-Reply-To: References: Message-ID: > This commit adds try-with-resources for uses of Stream from Files > methods that walk directories. Ryan Ernst 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 try_files/jdk.link - fix alignment - 8290359: Ensure that all directory streams are closed in jdk.link This commit adds try-with-resources for uses of Stream from Files methods that walk directories. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9520/files - new: https://git.openjdk.org/jdk/pull/9520/files/f5d4fd2e..4e9eede0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9520&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9520&range=00-01 Stats: 1454 lines in 71 files changed: 802 ins; 379 del; 273 mod Patch: https://git.openjdk.org/jdk/pull/9520.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9520/head:pull/9520 PR: https://git.openjdk.org/jdk/pull/9520 From duke at openjdk.org Mon Jul 18 18:22:04 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 18 Jul 2022 18:22:04 GMT Subject: RFR: 8290359: Ensure that all directory streams are closed in jdk.link [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 15:35:25 GMT, Chris Hegarty wrote: >> Ryan Ernst 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 try_files/jdk.link >> - fix alignment >> - 8290359: Ensure that all directory streams are closed in jdk.link >> >> This commit adds try-with-resources for uses of Stream from Files >> methods that walk directories. > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 834: > >> 832: name.endsWith(".EC") || >> 833: name.startsWith("META-INF/SIG-") >> 834: ); > > Trivially, can we please keep the indentation consistent with the previous version. So, align all `name.endsWith` expressions under the 's' from startsWith. Done in [c628479](https://github.com/openjdk/jdk/pull/9520/commits/c62847976c4a34ee97be61bbac3002513028e87c) ------------- PR: https://git.openjdk.org/jdk/pull/9520 From duke at openjdk.org Mon Jul 18 18:19:48 2022 From: duke at openjdk.org (Ryan Ernst) Date: Mon, 18 Jul 2022 18:19:48 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list [v2] In-Reply-To: References: Message-ID: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Ryan Ernst has updated the pull request incrementally with two additional commits since the last revision: - adjust wording - fix uses of list() in java.base ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9538/files - new: https://git.openjdk.org/jdk/pull/9538/files/6c9750f7..0b3ca182 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9538&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9538&range=00-01 Stats: 23 lines in 6 files changed: 10 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/9538.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9538/head:pull/9538 PR: https://git.openjdk.org/jdk/pull/9538 From duke at openjdk.org Mon Jul 18 18:40:51 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 18:40:51 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Revert erroneous changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/5b18c39c..af555897 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=03-04 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 18:40:51 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 18:40:51 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Mon, 18 Jul 2022 11:31:59 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Remove unused import Right, my bad. I've confused arguments. The changes reverted. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From iklam at openjdk.org Mon Jul 18 18:54:05 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 18 Jul 2022 18:54:05 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v3] In-Reply-To: References: Message-ID: <5SOTcKAImbEb6-bKuqCTSzAPuqhoOw-7YnMEXlIXUio=.fdc8c19a-3d46-4bd1-b14d-607d1bfa1f78@github.com> > Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). > > CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., > > > class pkg1.Base { > protected void doit(String s) { > System.out.println(s); > } > } > class pkg2.Child extends pkg1.Base { > void test() { > Optional opt = Optional.of("foo"); > opt.ifPresent(this::doit); > } > } > > > More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 > > More details about the condition that triggers the error can be found in the test file Child.jcod. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @calvinccheung comments: fixed typo and removed unnecessary imports ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/146/files - new: https://git.openjdk.org/jdk19/pull/146/files/7122e367..6736b66b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=146&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=146&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/146.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/146/head:pull/146 PR: https://git.openjdk.org/jdk19/pull/146 From iklam at openjdk.org Mon Jul 18 18:54:09 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 18 Jul 2022 18:54:09 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v2] In-Reply-To: References: Message-ID: <7Vt9CPinIH7KewjPc1RHCeEGi8BmDqUoDfHpqrYGDCg=.3c78f699-c0a4-4de0-8eb7-07c8bcac0d7b@github.com> On Mon, 18 Jul 2022 16:15:26 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo > > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicLambdaWithUseImplMethodHandle.java line 41: > >> 39: >> 40: import jdk.test.lib.cds.CDSOptions; >> 41: import jdk.test.lib.cds.CDSTestUtils; > > Extra import statements? Fixed. > test/hotspot/jtreg/runtime/cds/appcds/test-classes/pkg2/Child.jcod line 59: > >> 57: // >> 58: // Javac in JDK 17 generates a public method for accessing the protected method >> 59: // in the base class. As a result, InnerClassLambdaMetafactory will no generate > > typo no -> not? Fixed. ------------- PR: https://git.openjdk.org/jdk19/pull/146 From iklam at openjdk.org Mon Jul 18 18:54:12 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 18 Jul 2022 18:54:12 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v2] In-Reply-To: <51RB-rT9YovQIVC5EiCRRJFHxs_oKbexzyBhCruaS4c=.a0c7f7b5-4400-4bed-b655-58fc820008b1@github.com> References: <51RB-rT9YovQIVC5EiCRRJFHxs_oKbexzyBhCruaS4c=.a0c7f7b5-4400-4bed-b655-58fc820008b1@github.com> Message-ID: On Mon, 18 Jul 2022 17:56:23 GMT, Mandy Chung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo > > test/hotspot/jtreg/runtime/cds/appcds/test-classes/pkg1/BaseWithProtectedMethod.java line 29: > >> 27: public class BaseWithProtectedMethod { >> 28: protected void protectedMethod(String s) { >> 29: Thread.dumpStack(); > > is it intentional for the test to keep dumping the stack? Yes, this is intentional. The stack dump is used in Child.jcod to explain the difference between javac from JDK 8/11 vs JDK 17. This is done once during test execution and it doesn't affect the pass/fail of the test. ------------- PR: https://git.openjdk.org/jdk19/pull/146 From naoto at openjdk.org Mon Jul 18 18:56:50 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 18 Jul 2022 18:56:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> Message-ID: <9nxXC6TKJOwD19iPW3lSojz6aWMT91DCTH3rrqx4C-8=.d43bb635-f3b1-4ebf-8baa-7b85078b7694@github.com> On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Revert erroneous changes Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9513 From iklam at openjdk.org Mon Jul 18 19:01:28 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 18 Jul 2022 19:01:28 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v4] In-Reply-To: References: Message-ID: > Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). > > CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., > > > class pkg1.Base { > protected void doit(String s) { > System.out.println(s); > } > } > class pkg2.Child extends pkg1.Base { > void test() { > Optional opt = Optional.of("foo"); > opt.ifPresent(this::doit); > } > } > > > More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 > > More details about the condition that triggers the error can be found in the test file Child.jcod. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed tier4 failure with hotspot_appcds_dynamic testing ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/146/files - new: https://git.openjdk.org/jdk19/pull/146/files/6736b66b..67d153ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=146&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=146&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/146.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/146/head:pull/146 PR: https://git.openjdk.org/jdk19/pull/146 From rriggs at openjdk.org Mon Jul 18 19:10:11 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 19:10:11 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> Message-ID: <4MM9EyQBrfbebIry8tPi_LRPHaRGPbmVYp7xwf0hewQ=.6ae982ac-d33f-49f0-927c-f574c148ec35@github.com> On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Revert erroneous changes Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9513 From mr at openjdk.org Mon Jul 18 19:52:07 2022 From: mr at openjdk.org (Mark Reinhold) Date: Mon, 18 Jul 2022 19:52:07 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 18:19:48 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst has updated the pull request incrementally with two additional commits since the last revision: > > - adjust wording > - fix uses of list() in java.base It?s odd to mix adding some advice to the Javadoc with adopting that advice in the code base. Consider opening a new issue and PR for the actual code changes. Also, a better summary for this issue (and PR) would be ?ModuleReader::list specification should suggest closing the returned stream,? since that?s the essence of it. ------------- PR: https://git.openjdk.org/jdk/pull/9538 From ccheung at openjdk.org Mon Jul 18 20:25:52 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 18 Jul 2022 20:25:52 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v4] In-Reply-To: References: Message-ID: <9ISYL0-Yitt39ZS_eeOdrhNtLAJewmnRCi9bXs_7gZw=.cb7169b6-a0c1-4505-99c0-1ad5c14373a7@github.com> On Mon, 18 Jul 2022 19:01:28 GMT, Ioi Lam wrote: >> Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). >> >> CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., >> >> >> class pkg1.Base { >> protected void doit(String s) { >> System.out.println(s); >> } >> } >> class pkg2.Child extends pkg1.Base { >> void test() { >> Optional opt = Optional.of("foo"); >> opt.ifPresent(this::doit); >> } >> } >> >> >> More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 >> >> More details about the condition that triggers the error can be found in the test file Child.jcod. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed tier4 failure with hotspot_appcds_dynamic testing Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/146 From darcy at openjdk.org Mon Jul 18 20:30:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 18 Jul 2022 20:30:21 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v4] In-Reply-To: References: Message-ID: > Initial implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add NaN test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/420a9f3f..a30daf2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=02-03 Stats: 83 lines in 1 file changed: 83 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422 PR: https://git.openjdk.org/jdk/pull/9422 From darcy at openjdk.org Mon Jul 18 20:37:13 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 18 Jul 2022 20:37:13 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v4] In-Reply-To: References: Message-ID: <6no69LnYCUh7ZGs0aSnFQONeDHhG2Mk1aO8JJpEuSLo=.990c1d1e-ba97-4ac4-a51e-1038792d6d85@github.com> On Mon, 18 Jul 2022 20:30:21 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add NaN test. I added NaN round-trip tests is a separate file since the properties being testing are not required by the specification, unlike the properties explored in the other tests. If the NaN tests need special handling on certain platforms/configurations, that can be don't without complicating the tests of most of the functionality. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From almatvee at openjdk.org Mon Jul 18 21:56:05 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 18 Jul 2022 21:56:05 GMT Subject: RFR: 8283707: Support version format on Windows [v2] In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 22:08:12 GMT, Alexey Semenyuk wrote: >> 8283707: Support version format on Windows > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Comments fixed and better naming in the code. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9507 From almatvee at openjdk.org Mon Jul 18 21:59:57 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 18 Jul 2022 21:59:57 GMT Subject: RFR: 8290398: jpackage exe instellers are not installed in jtreg tests In-Reply-To: <-2uU1ZgiQtTJWlv4HlMp2-rML96PbNusmKVHv5f-lQI=.316389bb-beb7-4445-bf69-30335aea5a0b@github.com> References: <-2uU1ZgiQtTJWlv4HlMp2-rML96PbNusmKVHv5f-lQI=.316389bb-beb7-4445-bf69-30335aea5a0b@github.com> Message-ID: On Sat, 16 Jul 2022 21:22:46 GMT, Alexey Semenyuk wrote: > 8290398: jpackage exe instellers are not installed in jtreg tests Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9530 From almatvee at openjdk.org Mon Jul 18 22:00:50 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 18 Jul 2022 22:00:50 GMT Subject: RFR: 8290400: Must run exe installers in jpackage jtreg tests without UI In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 21:32:07 GMT, Alexey Semenyuk wrote: > 8290400: Must run exe installers in jpackage jtreg tests without UI Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9531 From almatvee at openjdk.org Mon Jul 18 22:03:10 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 18 Jul 2022 22:03:10 GMT Subject: RFR: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 21:47:43 GMT, Alexey Semenyuk wrote: > 8290402: jpackage exe uninstallers don't return correct exit code in case of failure src/jdk.jpackage/windows/native/msiwrapper/MsiWrapper.cpp line 53: > 51: > 52: // Uninstall product. > 53: msi::SuppressUI suppressUI; Do you know why this needed and what it do? ------------- PR: https://git.openjdk.org/jdk/pull/9532 From jvernee at openjdk.org Mon Jul 18 22:25:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 18 Jul 2022 22:25:03 GMT Subject: RFR: JDK-8290460: Alpine: disable some panama tests that rely on std::thread In-Reply-To: <6av2IizSbvXAPApqrH9cFcnbrhHlUAsEvnziCh9XObM=.aeb252ed-7771-4d7f-a905-bbf8a1ef7fc2@github.com> References: <6av2IizSbvXAPApqrH9cFcnbrhHlUAsEvnziCh9XObM=.aeb252ed-7771-4d7f-a905-bbf8a1ef7fc2@github.com> Message-ID: On Mon, 18 Jul 2022 14:21:19 GMT, Thomas Stuefe wrote: > Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, I'd like to disable > > - java/foreign/TestUpcallAsync.java > - java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > on muslc to take load from our CIs. > > Tests: tested locally that the tests are excluded on Alpine, and remain active on other platforms. LGTM. ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.org/jdk/pull/9539 From rriggs at openjdk.org Mon Jul 18 22:38:35 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 22:38:35 GMT Subject: RFR: 8290397: LoadLibraryUnload.java failed with "Too few cleared WeakReferences" Message-ID: When running with -Xcomp it seems the wait time for GC to clear references is insufficient. Extend timeout waiting for GC. ------------- Commit messages: - 8290397: LoadLibraryUnload.java failed with "Too few cleared WeakReferences" Changes: https://git.openjdk.org/jdk/pull/9545/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9545&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290397 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9545.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9545/head:pull/9545 PR: https://git.openjdk.org/jdk/pull/9545 From akasko at openjdk.org Mon Jul 18 22:38:45 2022 From: akasko at openjdk.org (Alex Kasko) Date: Mon, 18 Jul 2022 22:38:45 GMT Subject: RFR: 8290471: jpackage: allow to specify codepage on Windows Message-ID: It is proposed to introduce support for `--win-codepage` argument, and substitute the `Codepage` attribute with `--win-codepage` specified value in primary l10n file when it is being copied to the config dir. Instead of copying all internal l10n files, it is proposed to copy only the primary file. Plain copy is used if `--win-codepage` is not specified. Otherwise `--win-codepage` value is substituted in l10n file using DOM and XPath. See more details in issue description and in links added there. Testing: - [x] ran `jtreg:jdk/tools/jpackage` - [x] test for `--win-codepage` argument is included with the patch ------------- Commit messages: - jpackage: allow to specify codepage on Windows Changes: https://git.openjdk.org/jdk/pull/9546/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9546&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290471 Stats: 158 lines in 8 files changed: 151 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9546.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9546/head:pull/9546 PR: https://git.openjdk.org/jdk/pull/9546 From asemenyuk at openjdk.org Mon Jul 18 22:39:46 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 18 Jul 2022 22:39:46 GMT Subject: RFR: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 22:01:09 GMT, Alexander Matveev wrote: >> 8290402: jpackage exe uninstallers don't return correct exit code in case of failure > > src/jdk.jpackage/windows/native/msiwrapper/MsiWrapper.cpp line 53: > >> 51: >> 52: // Uninstall product. >> 53: msi::SuppressUI suppressUI; > > Do you know why this needed and what it do? It is required to run uninstallation silently, without showing UI ------------- PR: https://git.openjdk.org/jdk/pull/9532 From asemenyuk at openjdk.org Mon Jul 18 23:05:50 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 18 Jul 2022 23:05:50 GMT Subject: RFR: 8290471: jpackage: allow to specify codepage on Windows In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 22:33:15 GMT, Alex Kasko wrote: > It is proposed to introduce support for `--win-codepage` argument, and substitute the `Codepage` attribute with `--win-codepage` specified value in primary l10n file when it is being copied to the config dir. > > Instead of copying all internal l10n files, it is proposed to copy only the primary file. Plain copy is used if `--win-codepage` is not specified. Otherwise `--win-codepage` value is substituted in l10n file using DOM and XPath. > > See more details in issue description and in links added there. > > Testing: > > - [x] ran `jtreg:jdk/tools/jpackage` > - [x] test for `--win-codepage` argument is included with the patch This is a proposal to change public API. It requires CSR. One of jpackage CSRs - https://bugs.openjdk.org/browse/JDK-8261538. You can use it as a reference. CSR wiki - https://wiki.openjdk.org/display/csr ------------- PR: https://git.openjdk.org/jdk/pull/9546 From dholmes at openjdk.org Mon Jul 18 23:32:04 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Jul 2022 23:32:04 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 15:26:23 GMT, Jonathan Gibbons wrote: >> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. >> >> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: >> >> The Java manpage was missing updates from: >> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. >> >> The Java manpage has slight formatting differences from: >> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux >> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS >> >> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) >> >> >> The keytool manpage was missing updates from: >> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The jar manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jarsigner manpage was missing updates from: >> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The javadoc manpage was missing updates from: >> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option >> >> The jmod manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jpackage manpage was missing updates from: >> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature >> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 >> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code >> >> The jshell manpage was missing updates from: >> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. > > The version changes in each file look good (`19-ea` to `19`). > The changes for javadoc look good. > > I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK. Thanks for the review @jonathan-gibbons ! I'll wait a day in case there are any further comments. > src/java.base/share/man/keytool.1 line 456: > >> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >> 455: keystore. >> 456: This option is used to sign the certificate with the signer?s private > > Not a problem with this PR as such, but we still have a `?` character in the output. Yeah I spotted that too, but it would need to be fixed in source and nroff. Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline? ------------- PR: https://git.openjdk.org/jdk19/pull/145 From almatvee at openjdk.org Tue Jul 19 00:01:08 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 19 Jul 2022 00:01:08 GMT Subject: RFR: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 21:47:43 GMT, Alexey Semenyuk wrote: > 8290402: jpackage exe uninstallers don't return correct exit code in case of failure Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9532 From mchung at openjdk.org Tue Jul 19 02:55:46 2022 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 19 Jul 2022 02:55:46 GMT Subject: RFR: 8290397: LoadLibraryUnload.java failed with "Too few cleared WeakReferences" In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 22:31:13 GMT, Roger Riggs wrote: > When running with -Xcomp it seems the wait time for GC to clear references is insufficient. > Extend timeout waiting for GC. For timeout factor = 10, it will wait for 300 seconds which seem okay. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/9545 From iklam at openjdk.org Tue Jul 19 04:40:04 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 19 Jul 2022 04:40:04 GMT Subject: [jdk19] RFR: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle [v4] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 03:41:45 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed tier4 failure with hotspot_appcds_dynamic testing > > Looks good! > > Thanks. Thanks @dholmes-ora, @calvinccheung, @mlchung for the review. Passed tiers 1 - 5. ------------- PR: https://git.openjdk.org/jdk19/pull/146 From iklam at openjdk.org Tue Jul 19 04:40:06 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 19 Jul 2022 04:40:06 GMT Subject: [jdk19] Integrated: 8290417: CDS cannot archive lamda proxy with useImplMethodHandle In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 03:15:02 GMT, Ioi Lam wrote: > Since the impact of this bug can be big, and the fix is simple and low risk (just avoids doing optimizations), I'd like to put this into JDK 19 before RDP2 (Jul 21). > > CDS cannot handle Lambda proxy classes that are generated in the useImplMethodHandle mode. This could happen with classfiles generated by JDK 8 or JDK 11 that access protected methods in a base class from a different package. E.g., > > > class pkg1.Base { > protected void doit(String s) { > System.out.println(s); > } > } > class pkg2.Child extends pkg1.Base { > void test() { > Optional opt = Optional.of("foo"); > opt.ifPresent(this::doit); > } > } > > > More details of useImplMethodHandle can be found here: https://github.com/openjdk/jdk/blob/522b65743ca10fcba0a27d25b8fa11319999e228/src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java#L183-L191 > > More details about the condition that triggers the error can be found in the test file Child.jcod. This pull request has now been integrated. Changeset: 4dc421ca Author: Ioi Lam URL: https://git.openjdk.org/jdk19/commit/4dc421caa02caedd7061ede6a5ec44dbb6ec738e Stats: 435 lines in 7 files changed: 433 ins; 0 del; 2 mod 8290417: CDS cannot archive lamda proxy with useImplMethodHandle Reviewed-by: dholmes, ccheung, mchung ------------- PR: https://git.openjdk.org/jdk19/pull/146 From dholmes at openjdk.org Tue Jul 19 06:31:04 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Jul 2022 06:31:04 GMT Subject: RFR: JDK-8290460: Alpine: disable some panama tests that rely on std::thread In-Reply-To: <6av2IizSbvXAPApqrH9cFcnbrhHlUAsEvnziCh9XObM=.aeb252ed-7771-4d7f-a905-bbf8a1ef7fc2@github.com> References: <6av2IizSbvXAPApqrH9cFcnbrhHlUAsEvnziCh9XObM=.aeb252ed-7771-4d7f-a905-bbf8a1ef7fc2@github.com> Message-ID: On Mon, 18 Jul 2022 14:21:19 GMT, Thomas Stuefe wrote: > Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, I'd like to disable > > - java/foreign/TestUpcallAsync.java > - java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > on muslc to take load from our CIs. > > Tests: tested locally that the tests are excluded on Alpine, and remain active on other platforms. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9539 From duke at openjdk.org Tue Jul 19 06:46:09 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Tue, 19 Jul 2022 06:46:09 GMT Subject: RFR: 8289797: tools/launcher/I18NArgTest.java fails on Japanese Windows enviromnent In-Reply-To: References: Message-ID: <05ghKhomalFvaIgSivpnjuYw2vBIzzUl13IrDpomfOk=.1eb7f450-c03d-468b-a043-92a01f22a7e6@github.com> On Fri, 8 Jul 2022 12:10:29 GMT, Jaikiran Pai wrote: >> I removed a section of via JDK_JAVA_OPTIONS because including main class is not allowed in the specification. >> This behavior is added in JDK-8170832, which add JAVA_OPTIONS environment variable. At this time, this test is mismatch with the specification. >> I tried to test and get Passed on Japanese Windows environment. >> Could you review this fix, please? > > The change looks fine to me since in its current form the usage of `JDK_JAVA_OPTIONS` is incorrect. > > Having said that and looking at the history of this file, I think, this part of the test was added to check if the `java` launcher would be able to read an environment variable (specifically the `JDK_JAVA_OPTIONS`) whose value was in `MS932` encoding, and pass it along as a correctly encoded String, all the way to the main method of the application. If we remove this section of the test, then we would be skipping that code path completely. > > Perhaps this part of the test could be modified a bit to let it pass the `JDK_JAVA_OPTIONS` environment variable with a `MS932` encoded value that acts some option to the java launcher, instead of being the argument to the main method? That way, you won't have to specify the main class name in the value of the environment variable. Specifically, something like: > > > diff --git a/test/jdk/tools/launcher/I18NArgTest.java b/test/jdk/tools/launcher/I18NArgTest.java > index fa09736da2f..2ba724d6f1d 100644 > --- a/test/jdk/tools/launcher/I18NArgTest.java > +++ b/test/jdk/tools/launcher/I18NArgTest.java > @@ -97,12 +97,17 @@ public class I18NArgTest extends TestHelper { > > // Test via JDK_JAVA_OPTIONS > Map env = new HashMap<>(); > - String cmd = "-Dtest.src=" + TEST_SOURCES_DIR.getAbsolutePath() + > - " -Dtest.classes=" + TEST_CLASSES_DIR.getAbsolutePath() + > - " -cp " + TEST_CLASSES_DIR.getAbsolutePath() + > - " I18NArgTest " + unicodeStr + " " + hexValue; > - env.put("JDK_JAVA_OPTIONS", cmd); > - tr = doExec(env, javaCmd); > + String sysPropName = "foo.bar"; > + // pass "-Dfoo.bar=" through the JDK_JAVA_OPTIONS environment variable. > + // we expect that system property value to be passed along to the main method with the > + // correct encoding > + String jdkJavaOpts = "-D" + sysPropName + "=" + unicodeStr; > + env.put("JDK_JAVA_OPTIONS", jdkJavaOpts); > + tr = doExec(env,javaCmd, > + "-Dtest.src=" + TEST_SOURCES_DIR.getAbsolutePath(), > + "-Dtest.classes=" + TEST_CLASSES_DIR.getAbsolutePath(), > + "-cp", TEST_CLASSES_DIR.getAbsolutePath(), > + "I18NArgTest", unicodeStr, hexValue, sysPropName); > System.out.println(tr.testOutput); > if (!tr.isOK()) { > System.err.println(tr); > @@ -125,5 +130,23 @@ public class I18NArgTest extends TestHelper { > "expected:" + expected + " obtained:" + hexValue; > throw new RuntimeException(message); > } > + if (args.length == 3) { > + // verify the value of the system property matches the expected value > + String sysPropName = args[2]; > + String sysPropVal = System.getProperty(sysPropName); > + if (sysPropVal == null) { > + throw new RuntimeException("Missing system property " + sysPropName); > + } > + String sysPropHexVal = ""; > + for (int i = 0; i < sysPropVal.length(); i++) { > + sysPropHexVal = sysPropHexVal.concat(Integer.toHexString(sysPropVal.charAt(i))); > + } > + System.out.println("System property " + sysPropName + " computed hex value: " > + + sysPropHexVal); > + if (!sysPropHexVal.equals(expected)) { > + throw new RuntimeException("Unexpected value in system property, expected " > + + expected + ", but got " + sysPropHexVal); > + } > + } > } > } > > I haven't tested this change, so you might have to experiment with it a bit. What do you think? @jaikiran Thank you for your comment. I agree to the additional check. I run the test you proposed, but it failed. I'm surveying that reason. ------------- PR: https://git.openjdk.org/jdk/pull/9389 From chegar at openjdk.org Tue Jul 19 07:12:07 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Tue, 19 Jul 2022 07:12:07 GMT Subject: RFR: 8290359: Ensure that all directory streams are closed in jdk.link [v2] In-Reply-To: References: Message-ID: <9SlNsmsjD4er-niM6X8nqfszu1HIRX7iXjfZdBFQWrw=.a9e2ab67-6330-445e-a35b-aa78fd7d72c9@github.com> On Mon, 18 Jul 2022 18:22:02 GMT, Ryan Ernst wrote: >> This commit adds try-with-resources for uses of Stream from Files >> methods that walk directories. > > Ryan Ernst 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 try_files/jdk.link > - fix alignment > - 8290359: Ensure that all directory streams are closed in jdk.link > > This commit adds try-with-resources for uses of Stream from Files > methods that walk directories. LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9520 From stuefe at openjdk.org Tue Jul 19 07:16:23 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 19 Jul 2022 07:16:23 GMT Subject: RFR: JDK-8290460: Alpine: disable some panama tests that rely on std::thread In-Reply-To: References: <6av2IizSbvXAPApqrH9cFcnbrhHlUAsEvnziCh9XObM=.aeb252ed-7771-4d7f-a905-bbf8a1ef7fc2@github.com> Message-ID: On Mon, 18 Jul 2022 22:21:44 GMT, Jorn Vernee wrote: >> Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, I'd like to disable >> >> - java/foreign/TestUpcallAsync.java >> - java/foreign/enablenativeaccess/TestEnableNativeAccess.java >> >> on muslc to take load from our CIs. >> >> Tests: tested locally that the tests are excluded on Alpine, and remain active on other platforms. > > LGTM. Thanks @JornVernee and @dholmes-ora ! ------------- PR: https://git.openjdk.org/jdk/pull/9539 From stuefe at openjdk.org Tue Jul 19 07:16:25 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 19 Jul 2022 07:16:25 GMT Subject: Integrated: JDK-8290460: Alpine: disable some panama tests that rely on std::thread In-Reply-To: <6av2IizSbvXAPApqrH9cFcnbrhHlUAsEvnziCh9XObM=.aeb252ed-7771-4d7f-a905-bbf8a1ef7fc2@github.com> References: <6av2IizSbvXAPApqrH9cFcnbrhHlUAsEvnziCh9XObM=.aeb252ed-7771-4d7f-a905-bbf8a1ef7fc2@github.com> Message-ID: On Mon, 18 Jul 2022 14:21:19 GMT, Thomas Stuefe wrote: > Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, I'd like to disable > > - java/foreign/TestUpcallAsync.java > - java/foreign/enablenativeaccess/TestEnableNativeAccess.java > > on muslc to take load from our CIs. > > Tests: tested locally that the tests are excluded on Alpine, and remain active on other platforms. This pull request has now been integrated. Changeset: d7f0de27 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8290460: Alpine: disable some panama tests that rely on std::thread Reviewed-by: jvernee, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9539 From shade at openjdk.org Tue Jul 19 07:31:07 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Jul 2022 07:31:07 GMT Subject: [jdk19] RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 14:48:42 GMT, Roger Riggs wrote: > Committing to the mainline and then requesting a backport of the changeset works too. Yes, that would be my plan. ------------- PR: https://git.openjdk.org/jdk19/pull/27 From chegar at openjdk.org Tue Jul 19 09:54:51 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Tue, 19 Jul 2022 09:54:51 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 19:48:02 GMT, Mark Reinhold wrote: > It?s odd to mix adding some advice to the Javadoc with adopting that advice in the code base. Consider opening a new issue and PR for the actual code changes. [JDK-8290504][1] has been filed to track the implementation changes. @rjernst please separate out the implementation changes into a separate PR, using 8290504 as the linked JIRA issue. (apologies, I previously asked for the implementation changes to be in this PR ) > Also, a better summary for this issue (and PR) would be ?ModuleReader::list specification should suggest closing the returned stream,? since that?s the essence of it. Agreed. I updated the JIRA issue summary as suggested. @rjernst please update the title of this PR to match. [1]: https://bugs.openjdk.org/browse/JDK-8290504 ------------- PR: https://git.openjdk.org/jdk/pull/9538 From chegar at openjdk.org Tue Jul 19 10:45:05 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Tue, 19 Jul 2022 10:45:05 GMT Subject: RFR: 8290353: Clarify the streams returned by ModuleReader::list [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 18:19:48 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst has updated the pull request incrementally with two additional commits since the last revision: > > - adjust wording > - fix uses of list() in java.base The following CSR has been filed for this issue, https://bugs.openjdk.org/browse/JDK-8290521. Please review. ------------- PR: https://git.openjdk.org/jdk/pull/9538 From akasko at openjdk.org Tue Jul 19 11:08:06 2022 From: akasko at openjdk.org (Alex Kasko) Date: Tue, 19 Jul 2022 11:08:06 GMT Subject: RFR: 8290471: jpackage: allow to specify codepage on Windows In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 22:33:15 GMT, Alex Kasko wrote: > It is proposed to introduce support for `--win-codepage` argument, and substitute the `Codepage` attribute with `--win-codepage` specified value in primary l10n file when it is being copied to the config dir. > > Instead of copying all internal l10n files, it is proposed to copy only the primary file. Plain copy is used if `--win-codepage` is not specified. Otherwise `--win-codepage` value is substituted in l10n file using DOM and XPath. > > See more details in issue description and in links added there. > > Testing: > > - [x] ran `jtreg:jdk/tools/jpackage` > - [x] test for `--win-codepage` argument is included with the patch Thanks for the example link! I've filed CSR based on it - [JDK-8290519](https://bugs.openjdk.org/browse/JDK-8290519). ------------- PR: https://git.openjdk.org/jdk/pull/9546 From mcimadamore at openjdk.org Tue Jul 19 11:14:32 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 19 Jul 2022 11:14:32 GMT Subject: [jdk19] RFR: 8290524: Typo in javadoc of MemorySegment/MemoryAddress Message-ID: This patch fixes several `toRowLongValue` instead of `toRawLongValue` scattered in the javadoc for accessor methods in `MemorySegment` and `MemoryAddress`. ------------- Commit messages: - Fix MemoryAddress typos - Initial push Changes: https://git.openjdk.org/jdk19/pull/148/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290524 Stats: 69 lines in 2 files changed: 0 ins; 0 del; 69 mod Patch: https://git.openjdk.org/jdk19/pull/148.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/148/head:pull/148 PR: https://git.openjdk.org/jdk19/pull/148 From rriggs at openjdk.org Tue Jul 19 11:55:02 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 19 Jul 2022 11:55:02 GMT Subject: Integrated: 8290397: LoadLibraryUnload.java failed with "Too few cleared WeakReferences" In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 22:31:13 GMT, Roger Riggs wrote: > When running with -Xcomp it seems the wait time for GC to clear references is insufficient. > Extend timeout waiting for GC. This pull request has now been integrated. Changeset: e02627ca Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/e02627ca0a3381b3a52a71aef41ce5ba3329142b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8290397: LoadLibraryUnload.java failed with "Too few cleared WeakReferences" Reviewed-by: mchung ------------- PR: https://git.openjdk.org/jdk/pull/9545 From shade at openjdk.org Tue Jul 19 13:00:28 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Jul 2022 13:00:28 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply Message-ID: Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: # release before real 4m41.424s user 24m18.064s sys 1m16.440s # release after real 2m47.769s ; -40% user 23m44.622s sys 1m15.240s # fastdebug before real 5m38.078s user 67m23.516s sys 1m56.446s # fastdebug after real 4m9.249s ; -26% user 67m21.940s sys 1m57.625s ------------- Commit messages: - More fixes - Fix Changes: https://git.openjdk.org/jdk/pull/9554/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9554&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290531 Stats: 34 lines in 2 files changed: 19 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9554.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9554/head:pull/9554 PR: https://git.openjdk.org/jdk/pull/9554 From duke at openjdk.org Tue Jul 19 14:06:52 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 19 Jul 2022 14:06:52 GMT Subject: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3] In-Reply-To: References: Message-ID: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Ryan Ernst 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 branch 'master' into try_files/module_reader - Revert "fix uses of list() in java.base" This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. - adjust wording - fix uses of list() in java.base - 8290353: Clarify the streams returned by ModuleReader::list This commit adds additional clarification to the javadocs of ModuleReader::list about needing to close the stream. The new wording is similar to that used in Files::find and other similar methods. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9538/files - new: https://git.openjdk.org/jdk/pull/9538/files/0b3ca182..181c47a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9538&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9538&range=01-02 Stats: 1282 lines in 88 files changed: 948 ins; 133 del; 201 mod Patch: https://git.openjdk.org/jdk/pull/9538.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9538/head:pull/9538 PR: https://git.openjdk.org/jdk/pull/9538 From duke at openjdk.org Tue Jul 19 14:16:18 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 19 Jul 2022 14:16:18 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list Message-ID: This commit ensures streams returned by ModuleReader::list are closed. ------------- Commit messages: - 8290504: Close streams returned by ModuleReader::list Changes: https://git.openjdk.org/jdk/pull/9557/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9557&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290504 Stats: 19 lines in 5 files changed: 10 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9557.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9557/head:pull/9557 PR: https://git.openjdk.org/jdk/pull/9557 From duke at openjdk.org Tue Jul 19 14:20:00 2022 From: duke at openjdk.org (Ryan Ernst) Date: Tue, 19 Jul 2022 14:20:00 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. Note that ModulePatcher::list delegates to ModuleReader::list, but since the stream it builds closes the underlying stream, the use doesn't need to be closed within the list method. ------------- PR: https://git.openjdk.org/jdk/pull/9557 From sgehwolf at openjdk.org Tue Jul 19 14:22:08 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 19 Jul 2022 14:22:08 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> Message-ID: On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor hotspot gtest > - Separate into function. Fix comment. It's still on my plate to work on, but priorities keep this pushed to the bottom... ------------- PR: https://git.openjdk.org/jdk/pull/8629 From jvernee at openjdk.org Tue Jul 19 14:22:10 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 19 Jul 2022 14:22:10 GMT Subject: [jdk19] RFR: 8290524: Typo in javadoc of MemorySegment/MemoryAddress In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 11:07:27 GMT, Maurizio Cimadamore wrote: > This patch fixes several `toRowLongValue` instead of `toRawLongValue` scattered in the javadoc for accessor methods in `MemorySegment` and `MemoryAddress`. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/148 From mcimadamore at openjdk.org Tue Jul 19 14:36:26 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 19 Jul 2022 14:36:26 GMT Subject: [jdk19] Integrated: 8290524: Typo in javadoc of MemorySegment/MemoryAddress In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 11:07:27 GMT, Maurizio Cimadamore wrote: > This patch fixes several `toRowLongValue` instead of `toRawLongValue` scattered in the javadoc for accessor methods in `MemorySegment` and `MemoryAddress`. This pull request has now been integrated. Changeset: e062dff1 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk19/commit/e062dff1bfd1abd5f14e8915dc5417cc22d622ac Stats: 69 lines in 2 files changed: 0 ins; 0 del; 69 mod 8290524: Typo in javadoc of MemorySegment/MemoryAddress Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk19/pull/148 From chegar at openjdk.org Tue Jul 19 15:16:46 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Tue, 19 Jul 2022 15:16:46 GMT Subject: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3] In-Reply-To: References: Message-ID: <7sxCRhz_jeDDd-tAUSzc_qacqiFLYMfqW5MoipUOO8E=.c9681e69-7fa8-4107-aa65-06bd57330874@github.com> On Tue, 19 Jul 2022 14:06:52 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > > This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9538 From mchung at openjdk.org Tue Jul 19 16:17:06 2022 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 19 Jul 2022 16:17:06 GMT Subject: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3] In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 14:06:52 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > > This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Marked as reviewed by mchung (Reviewer). Looks good to me. I reviewed the CSR. ------------- PR: https://git.openjdk.org/jdk/pull/9538 From ecaspole at openjdk.org Tue Jul 19 16:33:25 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Tue, 19 Jul 2022 16:33:25 GMT Subject: Integrated: 8290391: Reduce runtime of java.util package microbenchmarks In-Reply-To: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> References: <8FzA-1uE6VpMZNv1b4s4FKXZO3X8wtydNNS8lqHZLHQ=.971cedb8-0d88-486b-880a-fc698ca9332b@github.com> Message-ID: On Fri, 15 Jul 2022 18:41:09 GMT, Eric Caspole wrote: > Adds Warmup, Measurement and Fork annotations to reduce the run time from 1 day 16 hours to 8 hours for this set. This pull request has now been integrated. Changeset: 2cb659e7 Author: Eric Caspole URL: https://git.openjdk.org/jdk/commit/2cb659e7f45e5ed4c2db7f1a091bb78f4f7accc2 Stats: 175 lines in 16 files changed: 71 ins; 85 del; 19 mod 8290391: Reduce runtime of java.util package microbenchmarks Reviewed-by: rriggs, redestad ------------- PR: https://git.openjdk.org/jdk/pull/9523 From jwilhelm at openjdk.org Tue Jul 19 16:51:55 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 19 Jul 2022 16:51:55 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8290524: Typo in javadoc of MemorySegment/MemoryAddress - 8288482: JFR: Cannot resolve method - 8290417: CDS cannot archive lamda proxy with useImplMethodHandle The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9561&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9561&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9561/files Stats: 510 lines in 10 files changed: 437 ins; 0 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/9561.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9561/head:pull/9561 PR: https://git.openjdk.org/jdk/pull/9561 From asemenyuk at openjdk.org Tue Jul 19 17:04:20 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 19 Jul 2022 17:04:20 GMT Subject: Integrated: 8290402: jpackage exe uninstallers don't return correct exit code in case of failure In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 21:47:43 GMT, Alexey Semenyuk wrote: > 8290402: jpackage exe uninstallers don't return correct exit code in case of failure This pull request has now been integrated. Changeset: d67e7ccd Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/d67e7ccda56998d1d60bdaa4e5940a0c501ead23 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8290402: jpackage exe uninstallers don't return correct exit code in case of failure Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/9532 From asemenyuk at openjdk.org Tue Jul 19 17:04:22 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 19 Jul 2022 17:04:22 GMT Subject: Integrated: 8283707: Support version format on Windows In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 04:37:58 GMT, Alexey Semenyuk wrote: > 8283707: Support version format on Windows This pull request has now been integrated. Changeset: 977e0948 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/977e09489dd1f49d8f373ef7b8c5e47fedb82793 Stats: 1316 lines in 15 files changed: 1256 ins; 18 del; 42 mod 8283707: Support version format on Windows Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/9507 From asemenyuk at openjdk.org Tue Jul 19 17:06:42 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 19 Jul 2022 17:06:42 GMT Subject: Integrated: 8290400: Must run exe installers in jpackage jtreg tests without UI In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 21:32:07 GMT, Alexey Semenyuk wrote: > 8290400: Must run exe installers in jpackage jtreg tests without UI This pull request has now been integrated. Changeset: 1af7c33d Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/1af7c33df59cd043bdae3f681aeded2919dc27aa Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8290400: Must run exe installers in jpackage jtreg tests without UI Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/9531 From asemenyuk at openjdk.org Tue Jul 19 19:52:03 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 19 Jul 2022 19:52:03 GMT Subject: Integrated: 8290398: jpackage exe installers are not installed in jtreg tests In-Reply-To: <-2uU1ZgiQtTJWlv4HlMp2-rML96PbNusmKVHv5f-lQI=.316389bb-beb7-4445-bf69-30335aea5a0b@github.com> References: <-2uU1ZgiQtTJWlv4HlMp2-rML96PbNusmKVHv5f-lQI=.316389bb-beb7-4445-bf69-30335aea5a0b@github.com> Message-ID: On Sat, 16 Jul 2022 21:22:46 GMT, Alexey Semenyuk wrote: > 8290398: jpackage exe installers are not installed in jtreg tests This pull request has now been integrated. Changeset: c2cbeb3e Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/c2cbeb3ee875936c98bb15ec32d692f7d866df76 Stats: 56 lines in 1 file changed: 35 ins; 0 del; 21 mod 8290398: jpackage exe installers are not installed in jtreg tests Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/9530 From mr at openjdk.org Tue Jul 19 21:28:42 2022 From: mr at openjdk.org (Mark Reinhold) Date: Tue, 19 Jul 2022 21:28:42 GMT Subject: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3] In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 14:06:52 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > > This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Ship it! ------------- Marked as reviewed by mr (Lead). PR: https://git.openjdk.org/jdk/pull/9538 From mchung at openjdk.org Wed Jul 20 00:43:47 2022 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 20 Jul 2022 00:43:47 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. LGTM ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/9557 From jpai at openjdk.org Wed Jul 20 03:30:00 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 20 Jul 2022 03:30:00 GMT Subject: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3] In-Reply-To: References: Message-ID: <1fiVVr2jGpyEfRqcciddOf2PR5O_UmduchKdPm5dGnU=.4b81c61c-3c4d-4014-b0d8-15f1337eefb5@github.com> On Tue, 19 Jul 2022 14:06:52 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > > This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Hello Ryan, the change looks fine to me. Please update the copyright year on the ModuleReader.java file, from 2020 to 2022. ------------- PR: https://git.openjdk.org/jdk/pull/9538 From jpai at openjdk.org Wed Jul 20 03:35:52 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 20 Jul 2022 03:35:52 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list In-Reply-To: References: Message-ID: <53duaqg6dFOGiQpLFZn55kLZz3EgjitIM86fIs0vc44=.1dcff81a-faa6-4e1e-8927-d2b2cf71f4f8@github.com> On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. Hello Ryan, the failures reported in the GitHub Actions jobs look related to this change. One such failure is in `CallerSensitiveAccess` test which throws an exception as follows: java.lang.RuntimeException: java.lang.IllegalStateException: source already consumed or closed at org.testng.internal.MethodInvocationHelper.invokeMethodNoCheckedException(MethodInvocationHelper.java:49) at org.testng.internal.MethodInvocationHelper.invokeDataProvider(MethodInvocationHelper.java:145) at org.testng.internal.Parameters.handleParameters(Parameters.java:797) at org.testng.internal.Parameters.handleParameters(Parameters.java:740) at org.testng.internal.ParameterHandler.handleParameters(ParameterHandler.java:59) at org.testng.internal.ParameterHandler.createParameters(ParameterHandler.java:38) at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:789) at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) at org.testng.TestRunner.privateRun(TestRunner.java:764) at org.testng.TestRunner.run(TestRunner.java:585) at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) at org.testng.SuiteRunner.run(SuiteRunner.java:286) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) at org.testng.TestNG.runSuites(TestNG.java:1069) at org.testng.TestNG.run(TestNG.java:1037) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1589) Caused by: java.lang.IllegalStateException: source already consumed or closed at java.base/java.util.stream.AbstractPipeline.sourceSpliterator(AbstractPipeline.java:409) at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) at CallerSensitiveAccess.callerSensitiveMethods(CallerSensitiveAccess.java:67) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:76) at org.testng.internal.MethodInvocationHelper.invokeMethodNoCheckedException(MethodInvocationHelper.java:45) ... 28 more ------------- Changes requested by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9557 From dholmes at openjdk.org Wed Jul 20 04:44:05 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Jul 2022 04:44:05 GMT Subject: [jdk19] Integrated: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes wrote: > Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. > > All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: > > The Java manpage was missing updates from: > - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. > > The Java manpage has slight formatting differences from: > - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux > - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS > > The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) > > > The keytool manpage was missing updates from: > - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The jar manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jarsigner manpage was missing updates from: > - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. > - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA > > The javadoc manpage was missing updates from: > - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option > > The jmod manpage was missing updates from: > - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) > > The jpackage manpage was missing updates from: > - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature > - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 > - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code > > The jshell manpage was missing updates from: > - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. This pull request has now been integrated. Changeset: 618f3a82 Author: David Holmes URL: https://git.openjdk.org/jdk19/commit/618f3a82a4d45cdb66b86259ae60dd1c322b987b Stats: 515 lines in 28 files changed: 431 ins; 16 del; 68 mod 8278274: Update nroff pages in JDK 19 before RC Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk19/pull/145 From dholmes at openjdk.org Wed Jul 20 05:37:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Jul 2022 05:37:13 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 23:27:58 GMT, David Holmes wrote: >> src/java.base/share/man/keytool.1 line 456: >> >>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >>> 455: keystore. >>> 456: This option is used to sign the certificate with the signer?s private >> >> Not a problem with this PR as such, but we still have a `?` character in the output. > > Yeah I spotted that too, but it would need to be fixed in source and nroff. Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline? Filed [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626). It can easily be fixed before RDP2. ------------- PR: https://git.openjdk.org/jdk19/pull/145 From jwilhelm at openjdk.org Wed Jul 20 07:42:49 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 20 Jul 2022 07:42:49 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: <55eEOvGRHsbKUu5hZ65TSNxRS6cS1ED5vnoZfxmgkJM=.86583e3d-bad5-471e-8d1b-c8e3283105be@github.com> On Tue, 19 Jul 2022 16:41:54 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: a3e07d95 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/a3e07d950ae752daf779607693c422a4c35924a6 Stats: 510 lines in 10 files changed: 437 ins; 0 del; 73 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9561 From chegar at openjdk.org Wed Jul 20 08:18:00 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 20 Jul 2022 08:18:00 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list In-Reply-To: References: Message-ID: <_AcLTYuwaDsqIJTtLfPShQ2brFvgUljmLqRpoHh9buM=.33b04e43-7340-4724-ad8a-dcf50cab6ce6@github.com> On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java line 411: > 409: try (ModuleReader reader = mref.open(); > 410: Stream stream = reader.list()) { > 411: return stream This change is causing the test to fail, in the `callerSensitiveMethods` DataProvider, because the data provider is expecting an open stream to be returned by `callerSensitiveMethods(Module)` - the stream is now closed. There are a couple of ways to resolve this, but the most straightforward would be to revert this part of the change, and have the `callerSensitiveMethods` DataProvider close the returned stream. E.g.: @DataProvider(name = "callerSensitiveMethods") static Object[][] callerSensitiveMethods() { try (var methodStream = callerSensitiveMethods(Object.class.getModule())) { return methodStream .map(m -> new Object[]{m, shortDescription(m)}) .toArray(Object[][]::new); } } ------------- PR: https://git.openjdk.org/jdk/pull/9557 From aturbanov at openjdk.org Wed Jul 20 11:19:07 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 20 Jul 2022 11:19:07 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v4] In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: > Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time revert 'computeIfAbsent' when it requires custom key class. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9208/files - new: https://git.openjdk.org/jdk/pull/9208/files/70223b4b..94f57445 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9208&range=02-03 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9208.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9208/head:pull/9208 PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Wed Jul 20 11:21:21 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 20 Jul 2022 11:21:21 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> Message-ID: On Wed, 6 Jul 2022 14:11:39 GMT, Roger Riggs wrote: >> @RogerRiggs in my view, it's not about performance per se??I'll sometimes help along these kinds of small fix PRs (that are more likely than not driven by IntelliJ code refactoring suggestions) if I think they lead to more idiomatic code in the JDK with no drawbacks. I think there's value in periodically revisiting existing code and improve it to use new language and library construct that have become available since ? people study JDK source code, and I think it's important they see as good examples in there as possible. I do like seeing an old example of hand-rolled compute-if-absent being replaced by an actual `computeIfAbsent` call. Similarly, I think using records as composite keys is in general a better practice over simulating a composite key by creating a string representation of it. >> >> Yeah, it'll load additional code at runtime for that record's class, and yes, I'm aware records' `hashCode`/`equals`/`toString` are implemented by delegating to factory methods that heavily use method handle combinators. If records are meant as lightweight value-semantics composites, it should be okay to use them like this and if there are performance concerns with their use, then those concerns should be addressed by improving their performance. OTOH, MH combinators installed into constant call sites are well optimized by HotSpot these days??anyhow, a discussion for another day. >> >> In this specific instance, the value domain of the keys is limited, but the number of method calls to `WeekFields.of` isn't. It could be benchmarked but if there's concerns, it's also okay to de-scope the record-as-key from this PR. I don't have strong feelings either way. > > The comment was about WeekFields.of(), I misplaced the comment. > > @szegedi All good points about modernizing code... > One of the reasons to ask about specific performance data is to validate the general performance impact of using lambdas. In the case of WeekFields.of(), the lambda is passed on every call to `computeIfAbsent` even if the key is present and the lambda won't be used. `WeekFields` is way-way down the long tail of frequency of use and I expect that 99% of calls are for the same one or two combinations. I agree with @RogerRiggs that performance of JDK is very important. It was one of main motivation for removing `.get` call. I'm not an expert in microbenchmarking, and it would require significant time/resources for me to investigate which is better. So I decided to revert back to original proposal (without lambda and `computeIfAbsent`) in `WeekFields`. If you think that it's better to improve code, I think we can always fill a separate issue for it. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From akasko at openjdk.org Wed Jul 20 16:52:04 2022 From: akasko at openjdk.org (Alex Kasko) Date: Wed, 20 Jul 2022 16:52:04 GMT Subject: RFR: 8290471: jpackage: allow to specify codepage on Windows [v2] In-Reply-To: References: Message-ID: > It is proposed to introduce support for `--win-codepage` argument, and substitute the `Codepage` attribute with `--win-codepage` specified value in primary l10n file when it is being copied to the config dir. > > Instead of copying all internal l10n files, it is proposed to copy only the primary file. Plain copy is used if `--win-codepage` is not specified. Otherwise `--win-codepage` value is substituted in l10n file using DOM and XPath. > > See more details in issue description and in links added there. > > Testing: > > - [x] ran `jtreg:jdk/tools/jpackage` > - [x] test for `--win-codepage` argument is included with the patch Alex Kasko has updated the pull request incrementally with two additional commits since the last revision: - extend the test to cover utf-8 codepage - new argument description in --help output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9546/files - new: https://git.openjdk.org/jdk/pull/9546/files/aefec1ce..0e4241ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9546&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9546&range=00-01 Stats: 58 lines in 5 files changed: 44 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9546.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9546/head:pull/9546 PR: https://git.openjdk.org/jdk/pull/9546 From akasko at openjdk.org Wed Jul 20 16:53:17 2022 From: akasko at openjdk.org (Alex Kasko) Date: Wed, 20 Jul 2022 16:53:17 GMT Subject: RFR: 8290471: jpackage: allow to specify codepage on Windows In-Reply-To: References: Message-ID: <13okb8_cat_CCTZRWasqhRq3lQrEqXvXGjHwhmDlb60=.0bd00088-9c3e-445f-973b-90435e9dfa89@github.com> On Mon, 18 Jul 2022 22:33:15 GMT, Alex Kasko wrote: > It is proposed to introduce support for `--win-codepage` argument, and substitute the `Codepage` attribute with `--win-codepage` specified value in primary l10n file when it is being copied to the config dir. > > Instead of copying all internal l10n files, it is proposed to copy only the primary file. Plain copy is used if `--win-codepage` is not specified. Otherwise `--win-codepage` value is substituted in l10n file using DOM and XPath. > > See more details in issue description and in links added there. > > Testing: > > - [x] ran `jtreg:jdk/tools/jpackage` > - [x] test for `--win-codepage` argument is included with the patch I've extended the test covering multiple languages with UTF-8. Also added new flag description to `--help` output. ------------- PR: https://git.openjdk.org/jdk/pull/9546 From attila at openjdk.org Wed Jul 20 18:08:00 2022 From: attila at openjdk.org (Attila Szegedi) Date: Wed, 20 Jul 2022 18:08:00 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v4] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > > revert 'computeIfAbsent' when it requires custom key class. Marked as reviewed by attila (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9208 From attila at openjdk.org Wed Jul 20 18:08:02 2022 From: attila at openjdk.org (Attila Szegedi) Date: Wed, 20 Jul 2022 18:08:02 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v2] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> <6vhuyCUEh-vPPge9hMbzMfAlKQ7bqKSxAMgScEkCAtE=.9202220b-4c2f-4d28-96a5-c6328fd54f53@github.com> Message-ID: On Wed, 20 Jul 2022 11:19:11 GMT, Andrey Turbanov wrote: >> The comment was about WeekFields.of(), I misplaced the comment. >> >> @szegedi All good points about modernizing code... >> One of the reasons to ask about specific performance data is to validate the general performance impact of using lambdas. In the case of WeekFields.of(), the lambda is passed on every call to `computeIfAbsent` even if the key is present and the lambda won't be used. `WeekFields` is way-way down the long tail of frequency of use and I expect that 99% of calls are for the same one or two combinations. > > I agree with @RogerRiggs that performance of JDK is very important. It was one of main motivation for removing `.get` call. > I'm not an expert in microbenchmarking, and it would require significant time/resources for me to investigate which is better. > So I decided to revert back to original proposal (without lambda and `computeIfAbsent`) in `WeekFields`. If you think that it's better to improve code, I think we can always fill a separate issue for it. Fair. ------------- PR: https://git.openjdk.org/jdk/pull/9208 From rriggs at openjdk.org Wed Jul 20 18:16:00 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 20 Jul 2022 18:16:00 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v4] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > > revert 'computeIfAbsent' when it requires custom key class. Looks good, thanks ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9208 From mchung at openjdk.org Wed Jul 20 20:21:03 2022 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 20 Jul 2022 20:21:03 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list In-Reply-To: <_AcLTYuwaDsqIJTtLfPShQ2brFvgUljmLqRpoHh9buM=.33b04e43-7340-4724-ad8a-dcf50cab6ce6@github.com> References: <_AcLTYuwaDsqIJTtLfPShQ2brFvgUljmLqRpoHh9buM=.33b04e43-7340-4724-ad8a-dcf50cab6ce6@github.com> Message-ID: On Wed, 20 Jul 2022 08:14:39 GMT, Chris Hegarty wrote: >> This commit ensures streams returned by ModuleReader::list are closed. > > test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java line 411: > >> 409: try (ModuleReader reader = mref.open(); >> 410: Stream stream = reader.list()) { >> 411: return stream > > This change is causing the test to fail, in the `callerSensitiveMethods` DataProvider, because the data provider is expecting an open stream to be returned by `callerSensitiveMethods(Module)` - the stream is now closed. > > There are a couple of ways to resolve this, but the most straightforward would be to revert this part of the change, and have the `callerSensitiveMethods` DataProvider close the returned stream. E.g.: > > > @DataProvider(name = "callerSensitiveMethods") > static Object[][] callerSensitiveMethods() { > try (var methodStream = callerSensitiveMethods(Object.class.getModule())) { > return methodStream > .map(m -> new Object[]{m, shortDescription(m)}) > .toArray(Object[][]::new); > } > } yes, this would solve it. ------------- PR: https://git.openjdk.org/jdk/pull/9557 From duke at openjdk.org Wed Jul 20 20:57:05 2022 From: duke at openjdk.org (Ryan Ernst) Date: Wed, 20 Jul 2022 20:57:05 GMT Subject: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v4] In-Reply-To: References: Message-ID: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Ryan Ernst 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 try_files/module_reader - update copyright - Merge branch 'master' into try_files/module_reader - Revert "fix uses of list() in java.base" This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. - adjust wording - fix uses of list() in java.base - 8290353: Clarify the streams returned by ModuleReader::list This commit adds additional clarification to the javadocs of ModuleReader::list about needing to close the stream. The new wording is similar to that used in Files::find and other similar methods. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9538/files - new: https://git.openjdk.org/jdk/pull/9538/files/181c47a1..58ac453a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9538&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9538&range=02-03 Stats: 5020 lines in 109 files changed: 3388 ins; 1182 del; 450 mod Patch: https://git.openjdk.org/jdk/pull/9538.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9538/head:pull/9538 PR: https://git.openjdk.org/jdk/pull/9538 From duke at openjdk.org Wed Jul 20 20:58:55 2022 From: duke at openjdk.org (Ryan Ernst) Date: Wed, 20 Jul 2022 20:58:55 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list [v2] In-Reply-To: References: Message-ID: > This commit ensures streams returned by ModuleReader::list are closed. Ryan Ernst 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 try_files/module_reader_uses - revert CallerSensitiveAccess change - 8290504: Close streams returned by ModuleReader::list This commit ensures streams returned by ModuleReader::list are closed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9557/files - new: https://git.openjdk.org/jdk/pull/9557/files/3fc8cca8..d09846fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9557&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9557&range=00-01 Stats: 5022 lines in 109 files changed: 3388 ins; 1183 del; 451 mod Patch: https://git.openjdk.org/jdk/pull/9557.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9557/head:pull/9557 PR: https://git.openjdk.org/jdk/pull/9557 From duke at openjdk.org Wed Jul 20 20:58:58 2022 From: duke at openjdk.org (Ryan Ernst) Date: Wed, 20 Jul 2022 20:58:58 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list [v2] In-Reply-To: References: <_AcLTYuwaDsqIJTtLfPShQ2brFvgUljmLqRpoHh9buM=.33b04e43-7340-4724-ad8a-dcf50cab6ce6@github.com> Message-ID: On Wed, 20 Jul 2022 20:17:27 GMT, Mandy Chung wrote: >> test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java line 411: >> >>> 409: try (ModuleReader reader = mref.open(); >>> 410: Stream stream = reader.list()) { >>> 411: return stream >> >> This change is causing the test to fail, in the `callerSensitiveMethods` DataProvider, because the data provider is expecting an open stream to be returned by `callerSensitiveMethods(Module)` - the stream is now closed. >> >> There are a couple of ways to resolve this, but the most straightforward would be to revert this part of the change, and have the `callerSensitiveMethods` DataProvider close the returned stream. E.g.: >> >> >> @DataProvider(name = "callerSensitiveMethods") >> static Object[][] callerSensitiveMethods() { >> try (var methodStream = callerSensitiveMethods(Object.class.getModule())) { >> return methodStream >> .map(m -> new Object[]{m, shortDescription(m)}) >> .toArray(Object[][]::new); >> } >> } > > yes, this would solve it. Done in [4a94c64](https://github.com/openjdk/jdk/pull/9557/commits/4a94c645fe1e37abc694f81fd8e401c5dc367d68) ------------- PR: https://git.openjdk.org/jdk/pull/9557 From duke at openjdk.org Wed Jul 20 21:16:05 2022 From: duke at openjdk.org (Petr Portnov | PROgrm_JARvis) Date: Wed, 20 Jul 2022 21:16:05 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list [v2] In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 20:58:55 GMT, Ryan Ernst wrote: >> This commit ensures streams returned by ModuleReader::list are closed. > > Ryan Ernst 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 try_files/module_reader_uses > - revert CallerSensitiveAccess change > - 8290504: Close streams returned by ModuleReader::list > > This commit ensures streams returned by ModuleReader::list are closed. Changes requested by JarvisCraft at github.com (no known OpenJDK username). src/java.base/share/classes/jdk/internal/module/ModuleHashes.java line 118: > 116: throw new IllegalArgumentException(e); > 117: } > 118: try (Stream stream = reader.list()){ Suggestion: try (Stream stream = reader.list()) { ------------- PR: https://git.openjdk.org/jdk/pull/9557 From duke at openjdk.org Wed Jul 20 21:58:58 2022 From: duke at openjdk.org (Ryan Ernst) Date: Wed, 20 Jul 2022 21:58:58 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list [v3] In-Reply-To: References: Message-ID: > This commit ensures streams returned by ModuleReader::list are closed. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: silly spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9557/files - new: https://git.openjdk.org/jdk/pull/9557/files/d09846fa..b041233a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9557&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9557&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9557.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9557/head:pull/9557 PR: https://git.openjdk.org/jdk/pull/9557 From bchristi at openjdk.org Wed Jul 20 22:21:35 2022 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 20 Jul 2022 22:21:35 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v14] In-Reply-To: References: Message-ID: > Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. > > The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. > > Details of note: > 1. Some operations need to change the state values (the update() method is probably the most interesting). > 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. > > The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. > > The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). > > Thanks. Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - remove tab - Merge conflicts - Convert fix to use VarHandle fences - Merge branch 'master' into remove-finalizers - reference emunCtx and homeCtx consistently in constructor - Restore EnumCtx to being an inner class, to keep all the state together in the code - Restore comments in ldap capture file - Update test files - add copyright, etc - added getters to EnumCtx, and moved it to top level ; use getters + local variables to reduce code changes - test comment udpate - ... and 16 more: https://git.openjdk.org/jdk/compare/b1817a30...dc444a54 ------------- Changes: https://git.openjdk.org/jdk/pull/8311/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8311&range=13 Stats: 847 lines in 7 files changed: 505 ins; 119 del; 223 mod Patch: https://git.openjdk.org/jdk/pull/8311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8311/head:pull/8311 PR: https://git.openjdk.org/jdk/pull/8311 From dcubed at openjdk.org Wed Jul 20 22:44:07 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 20 Jul 2022 22:44:07 GMT Subject: RFR: Merge jdk19 Message-ID: Merge jdk19 -> jdk20. ------------- Commit messages: - Merge - 8290625: Test jdk/javadoc/tool/CheckManPageOptions.java after manpage update - 8278274: Update nroff pages in JDK 19 before RC - 8287916: Address the inconsistency between the constant array and pool size - 8285407: Improve Xalan supports - 8282676: Improve subject handling - 8284370: Improve zlib usage - 8283190: Improve MIDI processing - 8281866: Enhance MethodHandle invocations - 8281859: Improve class compilation - ... and 3 more: https://git.openjdk.org/jdk/compare/b1817a30...aaca8b9d The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/9578/files Stats: 504 lines in 28 files changed: 428 ins; 16 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/9578.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9578/head:pull/9578 PR: https://git.openjdk.org/jdk/pull/9578 From dcubed at openjdk.org Wed Jul 20 22:59:25 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 20 Jul 2022 22:59:25 GMT Subject: RFR: Merge jdk19 In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty wrote: > Merge jdk19 -> jdk20. Mach5 Tier1 passed. ------------- PR: https://git.openjdk.org/jdk/pull/9578 From dcubed at openjdk.org Wed Jul 20 22:59:26 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 20 Jul 2022 22:59:26 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty wrote: > Merge jdk19 -> jdk20. This pull request has now been integrated. Changeset: 9c19d89c Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/9c19d89c9c564e436732c5f7851f4960fb5d783c Stats: 504 lines in 28 files changed: 428 ins; 16 del; 60 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9578 From bpb at openjdk.org Wed Jul 20 23:41:04 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 20 Jul 2022 23:41:04 GMT Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available [v7] In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com> References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com> Message-ID: > Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput. Brian Burkhalter 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: - 6478546: Miscellaneous cleanup - Merge - Merge - 6478546: Use dynamically sized temporary direct buffers - Merge - Merge - 6478546: Add break in write loop on ExceptionOccurred - Merge - 6478546: Clean up io_util.c - Merge - ... and 2 more: https://git.openjdk.org/jdk/compare/e6806d33...9a138636 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8235/files - new: https://git.openjdk.org/jdk/pull/8235/files/e6f3b457..9a138636 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8235&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8235&range=05-06 Stats: 130985 lines in 2621 files changed: 80827 ins; 31518 del; 18640 mod Patch: https://git.openjdk.org/jdk/pull/8235.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8235/head:pull/8235 PR: https://git.openjdk.org/jdk/pull/8235 From duke at openjdk.org Thu Jul 21 00:20:00 2022 From: duke at openjdk.org (duke) Date: Thu, 21 Jul 2022 00:20:00 GMT Subject: Withdrawn: 8279986: methods Math::asXExact for safely checked primitive casts In-Reply-To: References: Message-ID: On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti wrote: > Add a family of "safe" cast methods. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8548 From dholmes at openjdk.org Thu Jul 21 00:43:38 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Jul 2022 00:43:38 GMT Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20 Message-ID: The version will be 20-ea and the copyright year 2023 (for March 2023 release date). Thanks. ------------- Commit messages: - 8290489: Initial nroff manpage generation for JDK 20 Changes: https://git.openjdk.org/jdk/pull/9581/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9581&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290489 Stats: 28 lines in 28 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9581.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9581/head:pull/9581 PR: https://git.openjdk.org/jdk/pull/9581 From dcubed at openjdk.org Thu Jul 21 01:07:02 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 21 Jul 2022 01:07:02 GMT Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20 In-Reply-To: References: Message-ID: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com> On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes wrote: > The version will be 20-ea and the copyright year 2023 (for March 2023 release date). > > Thanks. Thumbs up. This is a trivial change. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9581 From jrose at openjdk.org Thu Jul 21 02:12:14 2022 From: jrose at openjdk.org (John R Rose) Date: Thu, 21 Jul 2022 02:12:14 GMT Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. >> >> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Refactored empty stream implementations to reduce duplicate code and improved unordered() > Added StreamSupport.empty for primitive spliterators and use that in Arrays.stream() I agree it?s the ?kind of? optimization that would be nice. ?Kind of?. Personally I would be happier to see complexity like this added that would help a larger class of common streams. It?s a harder problem, and I know this is case of ?the best is the enemy of the good?, but I think a stream which has less content bulk than pipeline phases (according to some heuristic weighting) might possibly be handled better by dumping the elements into an Object array and running each phase in sequence over that array, rather than composing a ?net result of all phases? object and then running it over the few elements. Stream object creation can be reduced, perhaps, by building the stream around a small internal buffer that collects pipeline phases (and their lambdas), by side effect. The terminal operation runs this Rube-Goldberg contraption in an interpretive manner over the elements. An advantage would arise if the contraption were smaller and simpler than a fully-composed stream of today, and the optimizations lost by having an interpreter instead of a specialized object ness were insignificant due to the small bulk of the stream source. If such an optimization really works, it would automatically handle the zero-elements case, but would also cover lots of use cases (in the JDK code even) where streams are used for their notational convenience, rather than their ability to process many elements efficiently. I looked at this for a few days, several months ago. I solved enough problems to see that there is a long tail of difficulties in stream implementation! (Many are noted in this PR thread.) I noticed that some pipeline phases can expand the ?bulk? (flatMap and friends). Bulk-reducing phases (filter) are not a problem, for already-small streams. (These issues do not arise for truly empty streams.) For expansion there would have to be an option to inflate a previously-small stream to use the general paths. Another issue is avoiding running any lambdas until the terminal operation, which means capturing them in some orderly fashion. Again, if a bizarre pipeline structure shows up, inflation is an option. And for truly empty streams some or all of the pipeline structure can be just dropped on the floor, as this PR proposes. In the end, I think the best leverage will come from a completely different set of techniques, from whatever allows us to do ?loop customization?. By loop customization which I mean the ability to compile the loop in the terminal operation separately for each ?interestingly distinct? combination of pipeline components, in such a way that the loop can constant-fold their lambdas, the shape of the stream source, and anything else that affects loop code quality. That technique should apply well regardless of ?bulk?, since the most complex object allocation should happen during specialization, which is a link-time operation, instead of every time a stream is created. Current state of the art uses mega-inlining, which has complex limitations and failure modes. (It utterly fails for parallel streams.) When we get to specialized generics, I hope to take another run at the problem, so that the type of each pipeline lambda ?feeds? into a specialization syndrome that the JVM ?sees? distinct from other specializations, and can optimize separately. (Making streams be value classes could help also.) I guess all *that* might be ?the impossible dream being the enemy of the best?. Anyway, FWIW? ------------- PR: https://git.openjdk.org/jdk/pull/6275 From jwaters at openjdk.org Thu Jul 21 02:14:07 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 21 Jul 2022 02:14:07 GMT Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti wrote: > A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path. Impressive performance improvements, I also like the PR title :P ------------- PR: https://git.openjdk.org/jdk/pull/9410 From jpai at openjdk.org Thu Jul 21 02:15:16 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Jul 2022 02:15:16 GMT Subject: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 20:57:05 GMT, Ryan Ernst wrote: >> This commit adds additional clarification to the javadocs of >> ModuleReader::list about needing to close the stream. The new wording is >> similar to that used in Files::find and other similar methods. > > Ryan Ernst 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 try_files/module_reader > - update copyright > - Merge branch 'master' into try_files/module_reader > - Revert "fix uses of list() in java.base" > > This reverts commit a72a5b9ec4e22ca4a414554b722042d4cbfaef58. > - adjust wording > - fix uses of list() in java.base > - 8290353: Clarify the streams returned by ModuleReader::list > > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Thank you Ryan for the copyright change. Looks fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9538 From dholmes at openjdk.org Thu Jul 21 05:49:57 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Jul 2022 05:49:57 GMT Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20 In-Reply-To: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com> References: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com> Message-ID: On Thu, 21 Jul 2022 01:03:46 GMT, Daniel D. Daugherty wrote: >> The version will be 20-ea and the copyright year 2023 (for March 2023 release date). >> >> Thanks. > > Thumbs up. This is a trivial change. Thanks @dcubed-ojdk ! ------------- PR: https://git.openjdk.org/jdk/pull/9581 From duke at openjdk.org Thu Jul 21 06:20:04 2022 From: duke at openjdk.org (Ryan Ernst) Date: Thu, 21 Jul 2022 06:20:04 GMT Subject: Integrated: 8290353: ModuleReader::list specification should suggest closing the returned stream In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 14:06:00 GMT, Ryan Ernst wrote: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. This pull request has now been integrated. Changeset: db1e44c2 Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openjdk.org/jdk/commit/db1e44c2ddd5b5f0db07dfc55f34fb03132f7726 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8290353: ModuleReader::list specification should suggest closing the returned stream Reviewed-by: chegar, mchung, mr, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9538 From duke at openjdk.org Thu Jul 21 06:23:06 2022 From: duke at openjdk.org (Ryan Ernst) Date: Thu, 21 Jul 2022 06:23:06 GMT Subject: Integrated: 8290316: Ensure that all directory streams are closed in java.base In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. This pull request has now been integrated. Changeset: 53fc495e Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openjdk.org/jdk/commit/53fc495e3aca7d89af697639d727051fb9adf9c7 Stats: 38 lines in 5 files changed: 8 ins; 3 del; 27 mod 8290316: Ensure that all directory streams are closed in java.base Reviewed-by: chegar ------------- PR: https://git.openjdk.org/jdk/pull/9518 From duke at openjdk.org Thu Jul 21 06:24:08 2022 From: duke at openjdk.org (Ryan Ernst) Date: Thu, 21 Jul 2022 06:24:08 GMT Subject: Integrated: 8290359: Ensure that all directory streams are closed in jdk.link In-Reply-To: References: Message-ID: <_wE2olz6VQBkO6Nw-5fjGn7Y_LJlQTNN2P5rNHj4ssA=.c992691a-ac19-49e1-b9d7-2374f512324c@github.com> On Fri, 15 Jul 2022 16:18:17 GMT, Ryan Ernst wrote: > This commit adds try-with-resources for uses of Stream from Files > methods that walk directories. This pull request has now been integrated. Changeset: 3582fd9e Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openjdk.org/jdk/commit/3582fd9e93d9733c6fdf1f3848e0a093d44f6865 Stats: 69 lines in 3 files changed: 17 ins; 4 del; 48 mod 8290359: Ensure that all directory streams are closed in jdk.link Reviewed-by: chegar ------------- PR: https://git.openjdk.org/jdk/pull/9520 From chegar at openjdk.org Thu Jul 21 06:56:03 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Thu, 21 Jul 2022 06:56:03 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list [v3] In-Reply-To: References: <_AcLTYuwaDsqIJTtLfPShQ2brFvgUljmLqRpoHh9buM=.33b04e43-7340-4724-ad8a-dcf50cab6ce6@github.com> Message-ID: On Wed, 20 Jul 2022 20:54:27 GMT, Ryan Ernst wrote: >> yes, this would solve it. > > Done in [4a94c64](https://github.com/openjdk/jdk/pull/9557/commits/4a94c645fe1e37abc694f81fd8e401c5dc367d68) @rjernst it seems that the _revert_ part of the above has been done, but not the "have the callerSensitiveMethods DataProvider close the returned stream". ------------- PR: https://git.openjdk.org/jdk/pull/9557 From duke at openjdk.org Thu Jul 21 07:31:09 2022 From: duke at openjdk.org (kabutz) Date: Thu, 21 Jul 2022 07:31:09 GMT Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. >> >> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Refactored empty stream implementations to reduce duplicate code and improved unordered() > Added StreamSupport.empty for primitive spliterators and use that in Arrays.stream() Indeed, this was a nice experiment, but it would be even better to solve the issues in a more general way. It also turned into a rather complex change that modified a bit how streams currently work. Even though it took a couple of weeks of work, especially in creating the unit tests, I am 100% in favour of mothballing this. Until we solve it, there is an easy workaround that should also work in the future. Just check ahead of time whether the collection is empty, and in that case, don't create a stream. ------------- PR: https://git.openjdk.org/jdk/pull/6275 From jpai at openjdk.org Thu Jul 21 09:34:04 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Jul 2022 09:34:04 GMT Subject: RFR: 8285405: add test and check for negative argument to HashMap::newHashMap et al [v3] In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 08:26:02 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285405? >> >> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing `test/jdk/java/util/LinkedHashMap/Basic.java` since that test has tests for various APIs of this class. >> >> For `WeakHashMap.newWeakHashMap` and `HashMap.newHashMap`, I have created new test classes under relevant locations, since these classes already have test classes (almost) per API/feature in those locations. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > add newline at the end of the new file Work is in progress, I'll be reviving this shortly. ------------- PR: https://git.openjdk.org/jdk/pull/9036 From aturbanov at openjdk.org Thu Jul 21 10:24:15 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 21 Jul 2022 10:24:15 GMT Subject: RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time [v4] In-Reply-To: References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <3SfGNgdGfFlMG6G3Vfi8ZhXWwGCag5yA3_44kzuEIWo=.3a8de0e2-2ad6-43ae-9c14-bbe8b4e06110@github.com> On Wed, 20 Jul 2022 11:19:07 GMT, Andrey Turbanov wrote: >> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8288723: Avoid redundant ConcurrentHashMap.get call in java.time > > revert 'computeIfAbsent' when it requires custom key class. Thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/9208 From aturbanov at openjdk.org Thu Jul 21 10:27:04 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 21 Jul 2022 10:27:04 GMT Subject: Integrated: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com> Message-ID: <0OGe40FCcdVT8cbaEo9RWPhz0XvZ9qYx2gm9v18VeX4=.ec405884-3d16-4e16-a386-ab3486d5bd72@github.com> On Sat, 18 Jun 2022 10:43:08 GMT, Andrey Turbanov wrote: > Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call. This pull request has now been integrated. Changeset: 52cc6cd0 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/52cc6cd063c167229f8883ba5a81be306c38a73c Stats: 30 lines in 4 files changed: 2 ins; 16 del; 12 mod 8288723: Avoid redundant ConcurrentHashMap.get call in java.time Reviewed-by: attila, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/9208 From mcimadamore at openjdk.org Thu Jul 21 12:15:45 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 21 Jul 2022 12:15:45 GMT Subject: [jdk19] RFR: 8290455: jck test api/java_lang/foreign/VaList/Empty.html fails on some platforms Message-ID: The javadoc for `Linker` states that some operations throw `UnsupportedOperationException` when called on an unsupported platform. These operations are: * `Linker::nativeLinker` * `VaList::empty` * `VaList::make` * `VaList::ofAddress` While the code throws an UOE as required, since the exception is thrown in a static initialized, it gets wrapped in an `ExceptionInInitializerError`. The solution is to set the `CABI` value to `null` if the platform is unknown. Then, when clients call the `CABI.current()` method, we can throw at that point, which will result in the behavior requested by the API spec. ------------- Commit messages: - Add test - Initial push Changes: https://git.openjdk.org/jdk19/pull/150/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=150&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290455 Stats: 89 lines in 3 files changed: 67 ins; 7 del; 15 mod Patch: https://git.openjdk.org/jdk19/pull/150.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/150/head:pull/150 PR: https://git.openjdk.org/jdk19/pull/150 From jvernee at openjdk.org Thu Jul 21 12:31:14 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 21 Jul 2022 12:31:14 GMT Subject: [jdk19] RFR: 8290455: jck test api/java_lang/foreign/VaList/Empty.html fails on some platforms In-Reply-To: References: Message-ID: <41NfcuoBrB8ojBGu-7kD4yyWCn268WRuSTeOSAAXPME=.73afdea2-d3c9-4ed8-90d0-f41f46c80723@github.com> On Thu, 21 Jul 2022 12:06:37 GMT, Maurizio Cimadamore wrote: > The javadoc for `Linker` states that some operations throw `UnsupportedOperationException` when called on an unsupported platform. These operations are: > > * `Linker::nativeLinker` > * `VaList::empty` > * `VaList::make` > * `VaList::ofAddress` > > While the code throws an UOE as required, since the exception is thrown in a static initialized, it gets wrapped in an `ExceptionInInitializerError`. > > The solution is to set the `CABI` value to `null` if the platform is unknown. Then, when clients call the `CABI.current()` method, we can throw at that point, which will result in the behavior requested by the API spec. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/150 From duke at openjdk.org Thu Jul 21 13:23:43 2022 From: duke at openjdk.org (Ryan Ernst) Date: Thu, 21 Jul 2022 13:23:43 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list [v4] In-Reply-To: References: Message-ID: > This commit ensures streams returned by ModuleReader::list are closed. Ryan Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into try_files/module_reader_uses - fix caller sensitive test uses - silly spaces - Merge branch 'master' into try_files/module_reader_uses - revert CallerSensitiveAccess change - 8290504: Close streams returned by ModuleReader::list This commit ensures streams returned by ModuleReader::list are closed. ------------- Changes: https://git.openjdk.org/jdk/pull/9557/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9557&range=03 Stats: 20 lines in 4 files changed: 11 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9557.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9557/head:pull/9557 PR: https://git.openjdk.org/jdk/pull/9557 From duke at openjdk.org Thu Jul 21 13:23:43 2022 From: duke at openjdk.org (Ryan Ernst) Date: Thu, 21 Jul 2022 13:23:43 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list [v4] In-Reply-To: References: <_AcLTYuwaDsqIJTtLfPShQ2brFvgUljmLqRpoHh9buM=.33b04e43-7340-4724-ad8a-dcf50cab6ce6@github.com> Message-ID: On Thu, 21 Jul 2022 06:53:53 GMT, Chris Hegarty wrote: >> Done in [4a94c64](https://github.com/openjdk/jdk/pull/9557/commits/4a94c645fe1e37abc694f81fd8e401c5dc367d68) > > @rjernst it seems that the _revert_ part of the above has been done, but not the "have the callerSensitiveMethods DataProvider close the returned stream". Sorry I misunderstood. Fixed now in [3080378](https://github.com/openjdk/jdk/pull/9557/commits/30803780ca0bd1bcf03b99947ebf8cd4b42e6070). ------------- PR: https://git.openjdk.org/jdk/pull/9557 From forax at univ-mlv.fr Thu Jul 21 14:34:01 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 21 Jul 2022 16:34:01 +0200 (CEST) Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2] In-Reply-To: References: Message-ID: <1280244784.13951537.1658414041754.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "John R Rose" > To: core-libs-dev at openjdk.org > Sent: Thursday, July 21, 2022 4:12:14 AM > Subject: Re: RFR: JDK-8277095 : Empty streams create too many objects [v2] > On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: > >>> This is a draft proposal for how we could improve stream performance for the >>> case where the streams are empty. Empty collections are common-place. If we >>> iterate over them with an Iterator, we would have to create one small Iterator >>> object (which could often be eliminated) and if it is empty we are done. >>> However, with Streams we first have to build up the entire pipeline, until we >>> realize that there is no work to do. With this example, we change >>> Collection#stream() to first check if the collection is empty, and if it is, we >>> simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and >>> EmptyDoubleStream. We have taken great care for these to have the same >>> characteristics and behaviour as the streams returned by Stream.empty(), >>> IntStream.empty(), etc. >>> >>> Some of the JDK tests fail with this, due to ClassCastExceptions (our >>> EmptyStream is not an AbstractPipeline) and AssertionError, since we can call >>> some methods repeatedly on the stream without it failing. On the plus side, >>> creating a complex stream on an empty stream gives us upwards of 50x increase >>> in performance due to a much smaller object allocation rate. This PR includes >>> the code for the change, unit tests and also a JMH benchmark to demonstrate the >>> improvement. >> >> kabutz has updated the pull request incrementally with one additional commit >> since the last revision: >> >> Refactored empty stream implementations to reduce duplicate code and improved >> unordered() >> Added StreamSupport.empty for primitive spliterators and use that in >> Arrays.stream() > > I agree it?s the ?kind of? optimization that would be nice. ?Kind of?. > Personally I would be happier to see complexity like this added that would > help a larger class of common streams. > > It?s a harder problem, and I know this is case of ?the best is the enemy of the > good?, but I think a stream which has less content bulk than pipeline phases > (according to some heuristic weighting) might possibly be handled better by > dumping the elements into an Object array and running each phase in sequence > over that array, rather than composing a ?net result of all phases? object and > then running it over the few elements. Stream object creation can be reduced, > perhaps, by building the stream around a small internal buffer that collects > pipeline phases (and their lambdas), by side effect. The terminal operation > runs this Rube-Goldberg contraption in an interpretive manner over the > elements. An advantage would arise if the contraption were smaller and simpler > than a fully-composed stream of today, and the optimizations lost by having an > interpreter instead of a specialized object ness were insignificant due to the > small bulk of the stream source. I don't think it will ever work in real life because there are a lot of streams that only works based on luck and how stream are currently implemented. Last week, when grading a student project, i've seen a stream that can be simplified to Arrays.asList(3, null).stream().map(Object::toString).count() > > ------------- > > PR: https://git.openjdk.org/jdk/pull/6275 R?mi From chegar at openjdk.org Thu Jul 21 14:37:11 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Thu, 21 Jul 2022 14:37:11 GMT Subject: RFR: 8290504: Close streams returned by ModuleReader::list [v4] In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 13:23:43 GMT, Ryan Ernst wrote: >> This commit ensures streams returned by ModuleReader::list are closed. > > Ryan Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into try_files/module_reader_uses > - fix caller sensitive test uses > - silly spaces > - Merge branch 'master' into try_files/module_reader_uses > - revert CallerSensitiveAccess change > - 8290504: Close streams returned by ModuleReader::list > > This commit ensures streams returned by ModuleReader::list are closed. LGTM. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9557 From jpai at openjdk.org Thu Jul 21 14:44:29 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Jul 2022 14:44:29 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v7] In-Reply-To: References: Message-ID: <2tc7ZNVsi6ayTjmTjH_mIIe35IMLXr9lkGr1pRUrpDI=.0f2a0ec3-7901-450a-bd02-24c8c9edc902@github.com> On Mon, 18 Jul 2022 17:53:16 GMT, Roger Riggs wrote: >> The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. >> >> The process calling `pipelineStart()` is creating the pipes between the stages. >> As each process is launched, the file descriptor is inherited by the child process and >> the child process `dup`s them to the respective stdin/stdout/stderr fd. >> These copies of inherited file descriptors are handled correctly. >> >> Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. >> >> However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. >> The fix is to close the fd after it has been used as the input of the next process. >> >> A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. >> The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. >> >> The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. > > Roger Riggs 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 10 additional commits since the last revision: > > - Remove diagnostics output from ProcessBuilder > - Merge branch '8289643-pipeline-start-leak' of https://github.com/RogerRiggs/jdk into 8289643-pipeline-start-leak > - Add DEBUG diagnostics to determine cause of GitHub Action test failures due to unexpected pipes > - Merge branch 'master' into 8289643-pipeline-start-leak > - Add DEBUG diagnostics to determine cause of GitHub Action test failures due to unexpected pipes > - Use DirectoryStream and handle IOExceptions > - remove debug output > - Add TWR for Files.walk of /proc > - Cleanup of PipelineLeaksFD test improving error messages and source cleanup. > - 8289643: File descriptor leak with ProcessBuilder.startPipeline Marked as reviewed by jpai (Reviewer). Hello Roger, the latest state of this PR looks fine to me. The GitHub actions job too has now passed. I have added just a couple of minor comments inline. test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 43: > 41: * @requires (os.family == "linux" & !vm.musl) > 42: * @summary file descriptor leak with ProcessBuilder.startPipeline > 43: * @run testng/othervm -DDEBUG PipelineLeaksFD It looks like the `DEBUG` system property is no longer used in this test. Should we remove this passing of this property too? test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 119: > 117: * Collect a Set of pairs of /proc fd paths and the symbol links that are pipes. > 118: * @return A set of PipeRecords, possibly empty > 119: * @throws IOException if reading the directory entries of "/proc//fd/*" fails With these latest changes, it looks like the `IOException` will no longer be thrown by this method. Should we remove this from the javadoc then? ------------- PR: https://git.openjdk.org/jdk/pull/9414 From duke at openjdk.org Thu Jul 21 15:33:12 2022 From: duke at openjdk.org (j3graham) Date: Thu, 21 Jul 2022 15:33:12 GMT Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. >> >> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Refactored empty stream implementations to reduce duplicate code and improved unordered() > Added StreamSupport.empty for primitive spliterators and use that in Arrays.stream() Sounds reasonable. I?ve been seeing streams being used because of them being a convenient api more, which made me wonder more about how well they dealt with optimizations. I appreciate the extra insight. ------------- PR: https://git.openjdk.org/jdk/pull/6275 From duke at openjdk.org Thu Jul 21 15:50:35 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 21 Jul 2022 15:50:35 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate code Message-ID: We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. ------------- Commit messages: - 8290824: Remove unused JavaDoc - 8290824: Use InputStream.readAllBytes() instead of surrogate code Changes: https://git.openjdk.org/jdk/pull/9596/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9596&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290824 Stats: 30 lines in 2 files changed: 0 ins; 21 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9596.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9596/head:pull/9596 PR: https://git.openjdk.org/jdk/pull/9596 From bpb at openjdk.org Thu Jul 21 15:54:29 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 15:54:29 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length Message-ID: For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check int pos = syntaxAndInput.indexOf(':'); if (pos <= 0 || pos == syntaxAndInput.length()) to if (pos <= 0) ------------- Commit messages: - 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length Changes: https://git.openjdk.org/jdk/pull/9595/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290047 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9595.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9595/head:pull/9595 PR: https://git.openjdk.org/jdk/pull/9595 From rriggs at openjdk.org Thu Jul 21 16:01:01 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Jul 2022 16:01:01 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v8] In-Reply-To: References: Message-ID: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Cleanup review comment loose ends ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9414/files - new: https://git.openjdk.org/jdk/pull/9414/files/095e76b2..fbd4751b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9414&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9414/head:pull/9414 PR: https://git.openjdk.org/jdk/pull/9414 From naoto at openjdk.org Thu Jul 21 17:03:50 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 21 Jul 2022 17:03:50 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:29:10 GMT, Brian Burkhalter wrote: > For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check > > int pos = syntaxAndInput.indexOf(':'); > if (pos <= 0 || pos == syntaxAndInput.length()) > > to > > if (pos <= 0) Looks good, Brian. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9595 From rriggs at openjdk.org Thu Jul 21 17:17:48 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Jul 2022 17:17:48 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:29:10 GMT, Brian Burkhalter wrote: > For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check > > int pos = syntaxAndInput.indexOf(':'); > if (pos <= 0 || pos == syntaxAndInput.length()) > > to > > if (pos <= 0) src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java line 178: > 176: public PathMatcher getPathMatcher(String syntaxAndInput) { > 177: int pos = syntaxAndInput.indexOf(':'); > 178: if (pos <= 0 || pos == syntaxAndInput.length()) { Is this really a different bug? Should it be checking for `length() - 1` to throw IAE. That would then throw if there was no string after the syntax selector; for example "glob:" ------------- PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 17:17:48 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 17:17:48 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 17:10:12 GMT, Roger Riggs wrote: >> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check >> >> int pos = syntaxAndInput.indexOf(':'); >> if (pos <= 0 || pos == syntaxAndInput.length()) >> >> to >> >> if (pos <= 0) > > src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java line 178: > >> 176: public PathMatcher getPathMatcher(String syntaxAndInput) { >> 177: int pos = syntaxAndInput.indexOf(':'); >> 178: if (pos <= 0 || pos == syntaxAndInput.length()) { > > Is this really a different bug? Should it be checking for `length() - 1` to throw IAE. > That would then throw if there was no string after the syntax selector; for example "glob:" You have a point there. It does not want the ":" to be at the first position so it should not want it at the last position as the "pattern" part of the string would be empty. That fits with the specification IllegalArgumentException.html - If the parameter does not take the form: syntax:pattern ------------- PR: https://git.openjdk.org/jdk/pull/9595 From mr at openjdk.org Thu Jul 21 17:32:58 2022 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 21 Jul 2022 17:32:58 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate code In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? wrote: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. Why do you say ?instead of surrogate code?? I don?t see any Unicode surrogate processing here, but maybe you mean something else. Would ?instead of explicit loops? be a better summary? ------------- PR: https://git.openjdk.org/jdk/pull/9596 From rriggs at openjdk.org Thu Jul 21 17:45:07 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Jul 2022 17:45:07 GMT Subject: RFR: 8290115: ArrayCopyObject JMH has wrong package In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 17:04:47 GMT, Eric Caspole wrote: > This JMH was accidentally committed with package vm.compiler but it is in the path bench/java/lang. I renamed the package so as to more easily run it with the other ArrayCopy JMH. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9472 From mr at openjdk.org Thu Jul 21 17:49:08 2022 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 21 Jul 2022 17:49:08 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v10] In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: <5LOH-9ywUPltn3Xnt9KUy8fzSqStQRbbM3MMhTxqHYA=.942a1d30-df54-4d9e-add8-c650f123abf3@github.com> On Mon, 9 May 2022 09:56:19 GMT, Volker Simonis wrote: >> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. >> >> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. >> >> ### TL;DR >> >> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. >> >> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. >> >> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. >> >> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+` *k*`]` (where *k* is the number of inflated bytes). >> >> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Updated wording based on @JoeDarcy's third CSR review First, I?ll observe that there is no specification conflict here. The specifications of `InflaterInputStream::read(byte[] b, int off, int len)` and `Inflater::inflate(byte[] b, int off, int len)` are not in conflict at all. The latter is simply weaker than the former. What is true is that if you build the JDK in the default manner, without any patches, then what you wind up with is an `InflaterInputStream::read(...)` implementation that satisfies the inherited `InputStream::read(...)` specification, including the constraint that a read operation must not _scribble_ in the caller?s output buffer, _i.e._, modify any byte in that buffer beyond the returned byte count. (That constraint is, so far as we know, satisfied by every `InputStream` subclass defined in the JDK.) A default JDK build?s `InflaterInputStream::read(...)` method doesn?t scribble because - The implementation of `InflaterInputStream::read(...)` assumes that the implementation of `Inflater::inflate(...)` doesn?t scribble, and - The implementation of `Inflater::inflate(...)` satisfies that assumption because it invokes the corresponding function in the [standard native Zip implementation](https://zlib.net/), which itself doesn?t scribble. So, not only does the specification forbid `InflaterInputStream::read(...)` from scribbling, but in the official Java SE Reference Implementation ? which is simply a default JDK build ? that method does not scribble. (Perhaps by accident, but that is immaterial here.) Therefore, if in your own JDK build you substitute an alternative Zip implementation whose `inflate` function does scribble then you wind up with a JDK that both violates the specification and behaves differently than the RI. It is incompatible. If you use such a JDK in production then you risk breaking existing code. Now, compatibility is one of the key values of the Java Platform, but performance is not unimportant. Is there something we can do to accommodate [alternative, faster, scribbling Zip implementations][faster-zlib]? @simonis lists three options in the [issue]. I?ll cast the options somewhat differently. 1. Do not change the specification in any way. The specification text that forbids scribbling dates back to Java 1.1, released over 25 years ago. (Arguably that text over-specifies the `InputStream::read(...)` method, but that is also immaterial.) It?s all too possible that existing code ? no matter how odd or poorly written we think it might be ? depends upon this constraint. With this option, a JDK build that uses a scribbling Zip implementation would have to buffer that implementation?s output and copy only the returned number of bytes into the caller?s buffer. This would degrade any performance benefit. 2. Weaken the specification of `InflaterInputStream` ? and, thereby, that of its subclasses `GZipInputStream` and `ZipInputStream` ? to allow scribbling. This is essentially @simonis?s initial suggestion, as embodied in [63ae357] earlier in this PR. This option risks breaking existing code that depends upon the 25-year-old promise that `InflaterInputStream::read(...)` will not scribble. Changing the specification of an indirect subclass of `InputStream`, moreover, is apt to go unnoticed by many developers, who routinely deal with instances of `InputStream` without any knowledge of those instances? concrete classes. (@jaikiran gives one example above.) 3. Weaken the specification of the `InputStream::read(...)` method to allow scribbling, as [suggested by @jddarcy in the CSR][jddarcy]. This option is at least as risky to existing code as the second option, though it?s marginally more likely that developers writing new code will notice the specification change. What?s worse, however, is that this option gives developers writing new subclasses of `InputStream` permission to deviate from both that class?s longstanding specification and the actual behavior of every `InputStream` subclass defined in the JDK. In the long term, that could wreak subtle bugs throughout the ecosystem, even breaking code that does absolutely nothing with Zip-related input streams. In favor of both the second and third options is @simonis?s statement above that his employer (Amazon) has used JDK builds with a scribbling Zip implementation in production for two years. He has further elaborated (privately) that this includes hundreds of services built with many of the usual popular frameworks and libraries (Spring, Hibernate, ASM, etc.). This suggests that the practical impact, out in the wild, of allowing scribbling Zip implementations is acceptable. On that basis I am ? just barely ? comfortable with the second option, _i.e._, weakening the specification of `InflaterInputStream` to allow scribbling, thereby contradicting the specification of its `InputStream` superclass. Explicitly specifying a subclass in a way that?s inconsistent with the specification of one of its superclasses is generally a really bad idea. It violates the [Liskov Substitution Principle][lsp], which enables instances of a subclass to be substituted freely for instances of one of its superclasses. Thus we do not condone such changes lightly. There are, however, precedents in a handful of special cases in the Java Platform; _e.g._, in the [`java.util.IdentityHashMap`][ihm] and [`java.sql.Timestamp`][ts] classes. The third option above would not violate the Liskov substitution principle, but in my view could prove more harmful in the long run. Recommendations: - Revert this PR back to [63ae357], and make corresponding updates to the [issue] and the [CSR]. - Additionally, find every method in every `java.*` class that?s declared to return an `InputStream` (_e.g._, `ZipFile::getInputStream(...)` but actually returns an instance of `InflaterInputStream` or one of its subclasses. Add an API note to each such method to let developers know that the returned input stream might scribble, per @jaikiran?s suggestion above. These notes can all use the same text, linking to the revised `InflaterInputStream::read(...)` specification. - Revise the summary of this PR, the issue, and the CSR to reflect the true nature of the proposed change rather than assert a nonexistent conflict. Consider ?Weaken the `InflaterInputStream` specification in order to allow faster Zip implementations?. - Change the issue type from a bug ? which it?s not ? to an enhancement. - Create a related release-note issue, as @RogerRiggs suggests above. [faster-zlib]: https://github.com/simonis/zlib-chromium#inflater-improvements-in-zlib-chromium [issue]: https://bugs.openjdk.org/browse/JDK-8282648 [63ae357]: https://github.com/openjdk/jdk/pull/7986/commits/63ae3572da674a0926bb9d0adcea88d89bb56707 [jddarcy]: https://bugs.openjdk.org/browse/JDK-8283758?focusedCommentId=14492930&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14492930 [CSR]: https://bugs.openjdk.org/browse/JDK-8283758 [lsp]: https://en.wikipedia.org/wiki/Liskov_substitution_principle [ihm]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/IdentityHashMap.html [ts]: https://docs.oracle.com/en/java/javase/18/docs/api/java.sql/java/sql/Timestamp.html ------------- PR: https://git.openjdk.org/jdk/pull/7986 From ecaspole at openjdk.org Thu Jul 21 17:52:08 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Thu, 21 Jul 2022 17:52:08 GMT Subject: RFR: 8290115: ArrayCopyObject JMH has wrong package In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 17:04:47 GMT, Eric Caspole wrote: > This JMH was accidentally committed with package vm.compiler but it is in the path bench/java/lang. I renamed the package so as to more easily run it with the other ArrayCopy JMH. Thanks Roger! ------------- PR: https://git.openjdk.org/jdk/pull/9472 From ecaspole at openjdk.org Thu Jul 21 17:52:09 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Thu, 21 Jul 2022 17:52:09 GMT Subject: Integrated: 8290115: ArrayCopyObject JMH has wrong package In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 17:04:47 GMT, Eric Caspole wrote: > This JMH was accidentally committed with package vm.compiler but it is in the path bench/java/lang. I renamed the package so as to more easily run it with the other ArrayCopy JMH. This pull request has now been integrated. Changeset: 15f4b304 Author: Eric Caspole URL: https://git.openjdk.org/jdk/commit/15f4b30459d936f721fc984c20cf3ada7b7f5d4a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8290115: ArrayCopyObject JMH has wrong package Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/9472 From lancea at openjdk.org Thu Jul 21 18:05:06 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 21 Jul 2022 18:05:06 GMT Subject: RFR: 8289643: File descriptor leak with ProcessBuilder.startPipeline [v8] In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 16:01:01 GMT, Roger Riggs wrote: >> The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. >> >> The process calling `pipelineStart()` is creating the pipes between the stages. >> As each process is launched, the file descriptor is inherited by the child process and >> the child process `dup`s them to the respective stdin/stdout/stderr fd. >> These copies of inherited file descriptors are handled correctly. >> >> Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. >> >> However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. >> The fix is to close the fd after it has been used as the input of the next process. >> >> A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. >> The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. >> >> The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup review comment loose ends Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9414 From duke at openjdk.org Thu Jul 21 18:05:07 2022 From: duke at openjdk.org (Ryan Ernst) Date: Thu, 21 Jul 2022 18:05:07 GMT Subject: Integrated: 8290504: Close streams returned by ModuleReader::list In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. This pull request has now been integrated. Changeset: 80bd8c35 Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openjdk.org/jdk/commit/80bd8c35494c85491963d590e7b78ea499fb691d Stats: 20 lines in 4 files changed: 11 ins; 0 del; 9 mod 8290504: Close streams returned by ModuleReader::list Reviewed-by: mchung, chegar ------------- PR: https://git.openjdk.org/jdk/pull/9557 From bpb at openjdk.org Thu Jul 21 18:29:03 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 18:29:03 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: References: Message-ID: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> > For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check > > int pos = syntaxAndInput.indexOf(':'); > if (pos <= 0 || pos == syntaxAndInput.length()) > > to > > if (pos <= 0) Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8290047: Ensure that colon is not at the last index ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9595/files - new: https://git.openjdk.org/jdk/pull/9595/files/291ef674..5765fa1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=00-01 Stats: 55 lines in 8 files changed: 43 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9595.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9595/head:pull/9595 PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 18:31:24 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 18:31:24 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 17:13:58 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java line 178: >> >>> 176: public PathMatcher getPathMatcher(String syntaxAndInput) { >>> 177: int pos = syntaxAndInput.indexOf(':'); >>> 178: if (pos <= 0 || pos == syntaxAndInput.length()) { >> >> Is this really a different bug? Should it be checking for `length() - 1` to throw IAE. >> That would then throw if there was no string after the syntax selector; for example "glob:" > > You have a point there. It does not want the ":" to be at the first position so it should not want it at the last position as the "pattern" part of the string would be empty. That fits with the specification > > IllegalArgumentException.html - If the parameter does not take the form: syntax:pattern Corrected in 5765fa1c6883575da57499c7b70f6626443d869d. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From weijun at openjdk.org Thu Jul 21 18:32:10 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 21 Jul 2022 18:32:10 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate code In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? wrote: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. The `X509CertPath.java` change looks fine, but I'm not sure about the other one. It means the whole content from the input stream is read into a single array and this could lead to a sudden peak memory usage if the size is big. ------------- PR: https://git.openjdk.org/jdk/pull/9596 From naoto at openjdk.org Thu Jul 21 18:41:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 21 Jul 2022 18:41:09 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:29:03 GMT, Brian Burkhalter wrote: >> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check >> >> int pos = syntaxAndInput.indexOf(':'); >> if (pos <= 0 || pos == syntaxAndInput.length()) >> >> to >> >> if (pos <= 0) > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290047: Ensure that colon is not at the last index src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 744: > 742: } > 743: } catch (Throwable x) { > 744: System.out.println("Caught " + x); Leftover debug output? src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 749: > 747: exc = x; > 748: } finally { > 749: System.out.println("finally"); As above ------------- PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 18:46:07 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 18:46:07 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:36:57 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290047: Ensure that colon is not at the last index > > src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 744: > >> 742: } >> 743: } catch (Throwable x) { >> 744: System.out.println("Caught " + x); > > Leftover debug output? Yes, thanks for catching. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From rriggs at openjdk.org Thu Jul 21 18:56:13 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Jul 2022 18:56:13 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:29:03 GMT, Brian Burkhalter wrote: >> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check >> >> int pos = syntaxAndInput.indexOf(':'); >> if (pos <= 0 || pos == syntaxAndInput.length()) >> >> to >> >> if (pos <= 0) > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290047: Ensure that colon is not at the last index Please update the issue title and description and PR title and description to match the new understanding. The IAE message in JrtFileSystem wording is a bit like it is leftover debugging output. The messages for all 4 IAE could be something as simple as "missing pattern". ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9595 From rriggs at openjdk.org Thu Jul 21 19:01:05 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Jul 2022 19:01:05 GMT Subject: Integrated: 8289643: File descriptor leak with ProcessBuilder.startPipeline In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 19:08:35 GMT, Roger Riggs wrote: > The `ProcessBuilder.pipelineStart()` implementation does not close all of the file descriptors it uses to create the pipeline of processes. > > The process calling `pipelineStart()` is creating the pipes between the stages. > As each process is launched, the file descriptor is inherited by the child process and > the child process `dup`s them to the respective stdin/stdout/stderr fd. > These copies of inherited file descriptors are handled correctly. > > Between the launching of each Process, the file descriptor for the read-side of the pipe for the output of the previous process is kept open (in the parent process invoking `pipelineStart`). The file descriptor is correctly passed to the child and is dup'd to the stdin of the next process. > > However, the open file descriptor in the parent is not closed after it has been used as the input for the next Process. > The fix is to close the fd after it has been used as the input of the next process. > > A new test verifies that after `pipelineStart` is complete, the same file descriptors are open for Unix Pipes as before the test. > The test only runs on Linux using the /proc//fd filesystem to identify open file descriptors. > > The bug fix is in `ProcessBuilder.pipelineStart` and is applicable to all platforms. This pull request has now been integrated. Changeset: 620c8a04 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/620c8a045f92126c2552347b9f369405ab2d6d36 Stats: 144 lines in 2 files changed: 143 ins; 0 del; 1 mod 8289643: File descriptor leak with ProcessBuilder.startPipeline Reviewed-by: alanb, jpai, lancea ------------- PR: https://git.openjdk.org/jdk/pull/9414 From bpb at openjdk.org Thu Jul 21 19:09:08 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 19:09:08 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:37:25 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290047: Ensure that colon is not at the last index > > src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 749: > >> 747: exc = x; >> 748: } finally { >> 749: System.out.println("finally"); > > As above This file was a leftover from a different issue I was looking at and was accidentally included here. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 19:17:03 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 19:17:03 GMT Subject: RFR: (fs) FileSystem.getPathMatcher does not check for ":" at last index [v2] In-Reply-To: References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:54:04 GMT, Roger Riggs wrote: > The IAE message in JrtFileSystem wording is a bit like it is leftover debugging output. The messages for all 4 IAE could be something as simple as "missing pattern". Not sure a message is needed. At the other extreme one could say "missing syntax" for ":pattern" and "missing pattern" for "syntax:". Or it could be "Parameter does not take the form: syntax:pattern". ------------- PR: https://git.openjdk.org/jdk/pull/9595 From duke at openjdk.org Thu Jul 21 19:49:08 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 21 Jul 2022 19:49:08 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate code In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? wrote: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. By "surrogate code" I mean hand-written snippets reading all the bytes from an InputStream. > It means the whole content from the input stream is read into a single array and this could lead to a sudden peak memory usage if the size is big. `InputStream.readAllBytes()` reads data from the InputStream in chunks of 8192 bytes, then combines them into one resulting array which is returned. In theory this could lead even to OOME in case the size the resulting array exceeds `Integer.MAX_VALUE`, I doubt however this would ever happen. I've looked into the history of `ModulerHashes`: prior to `byte[]` it used `ByteBuffer` of the same size (32 kB) as intermediate storage. I think digesting all the data at once might be faster than doing it chunk by chunk, on the other hand I understand memory concern. Can I reliably measure it somehow? ------------- PR: https://git.openjdk.org/jdk/pull/9596 From bpb at openjdk.org Thu Jul 21 19:58:50 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 19:58:50 GMT Subject: RFR: (fs) FileSystem.getPathMatcher does not check for ":" at last index [v3] In-Reply-To: References: Message-ID: > For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check > > int pos = syntaxAndInput.indexOf(':'); > if (pos <= 0 || pos == syntaxAndInput.length()) > > to > > if (pos <= 0) Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8290047: Remove IAE message in JrtFileSystem.getPathMatcher() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9595/files - new: https://git.openjdk.org/jdk/pull/9595/files/5765fa1c..ff404d4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9595.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9595/head:pull/9595 PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 19:58:51 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 19:58:51 GMT Subject: RFR: (fs) FileSystem.getPathMatcher does not check for ":" at last index [v2] In-Reply-To: References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:42:40 GMT, Brian Burkhalter wrote: >> src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 744: >> >>> 742: } >>> 743: } catch (Throwable x) { >>> 744: System.out.println("Caught " + x); >> >> Leftover debug output? > > Yes, thanks for catching. Fixed in ff404d4b52c5ecf4f00743be1d4d4a266483460c. >> src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 749: >> >>> 747: exc = x; >>> 748: } finally { >>> 749: System.out.println("finally"); >> >> As above > > This file was a leftover from a different issue I was looking at and was accidentally included here. Fixed in ff404d4b52c5ecf4f00743be1d4d4a266483460c. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From mr at openjdk.org Thu Jul 21 21:18:04 2022 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 21 Jul 2022 21:18:04 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate code In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? wrote: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. If by ?surrogates? you mean ?substitutes?, then this wording is confusing. At the time these explicit loops were written they weren?t surrogates for anything, since `InputStream::readAllBytes` didn?t yet exist. Please revise the summary to say ?... instead of explicit loops?. I share @wangweij?s concern about the change to the `ModuleHashes` class. The original code does not read the entirety of each stream into a single byte array because it doesn?t need to in order to update the digest. Furthermore, it re-uses the same byte array for all of the (potentially many) input streams. Your change would allocate a new byte array for each input stream, which seems likely to be slower. Please measure this (using, e.g., [JMH]) before making such a change. [JMH]: https://github.com/openjdk/jmh ------------- PR: https://git.openjdk.org/jdk/pull/9596 From darcy at openjdk.org Thu Jul 21 21:22:19 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 21 Jul 2022 21:22:19 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v5] In-Reply-To: References: Message-ID: <07DDwJ22DC4FB8yVVIjplbW2iu9k6PqHD6qcEzZBh_c=.0c9290a2-04ba-4ced-806f-1e59b624d071@github.com> > Initial implementation. Joe Darcy 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 20 additional commits since the last revision: - Method rename. - Merge branch 'master' into JDK-8289551 - Respond to review feedback; improve tests. - Add NaN test. - Preserve NaN sign bit. - Respond to review feedback. - Correct carry-out bug; add full binade test. - Improve NaN significand fidelity; refine tests. - Partial implementation of review feedback; test refinement. - Merge branch 'master' into JDK-8289551 - ... and 10 more: https://git.openjdk.org/jdk/compare/fc62ffae...9b060185 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/a30daf2f..9b060185 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=03-04 Stats: 11169 lines in 334 files changed: 7634 ins; 2341 del; 1194 mod Patch: https://git.openjdk.org/jdk/pull/9422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422 PR: https://git.openjdk.org/jdk/pull/9422 From bchristi at openjdk.org Thu Jul 21 21:35:02 2022 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 21 Jul 2022 21:35:02 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v15] In-Reply-To: References: Message-ID: > Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. > > The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. > > Details of note: > 1. Some operations need to change the state values (the update() method is probably the most interesting). > 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. > > The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. > > The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). > > Thanks. Brent Christian has updated the pull request incrementally with two additional commits since the last revision: - simplify some comments - Update ForceGC usage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8311/files - new: https://git.openjdk.org/jdk/pull/8311/files/dc444a54..a7208339 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8311&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8311&range=13-14 Stats: 33 lines in 3 files changed: 0 ins; 22 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/8311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8311/head:pull/8311 PR: https://git.openjdk.org/jdk/pull/8311 From bchristi at openjdk.org Thu Jul 21 21:35:11 2022 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 21 Jul 2022 21:35:11 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v14] In-Reply-To: References: Message-ID: <0ck1AOMFhECy6vezgHfew6Cfje98kJGtXoKGde82Itk=.3b204b80-bf5e-4676-a35e-67c168e3998e@github.com> On Wed, 20 Jul 2022 22:21:35 GMT, Brent Christian wrote: >> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. >> >> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. >> >> Details of note: >> 1. Some operations need to change the state values (the update() method is probably the most interesting). >> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. >> >> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. >> >> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). >> >> Thanks. > > Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - remove tab > - Merge conflicts > - Convert fix to use VarHandle fences > - Merge branch 'master' into remove-finalizers > - reference emunCtx and homeCtx consistently in constructor > - Restore EnumCtx to being an inner class, to keep all the state together in the code > - Restore comments in ldap capture file > - Update test files - add copyright, etc > - added getters to EnumCtx, and moved it to top level ; use getters + local variables to reduce code changes > - test comment udpate > - ... and 16 more: https://git.openjdk.org/jdk/compare/b1817a30...dc444a54 I've updated how the reachability and memory visibility issues (per [comment](https://bugs.openjdk.org/browse/JDK-8283660?focusedCommentId=14498566&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14498566)) are addressed: **Additional reachability fences** Unless it's _immediately obvious_ that _**no**_ cleanable state is **_accessed_** during the course of a method's execution, all methods should include a `reachabilityFence` to ensure that cleanable state is not cleaned up while a method is still running. This applies to any class that uses a `Cleaner` (or a finalizer, really). **`VarHandle.fullFence` to ensure memory visibility, instead of synchronized methods** This makes for simpler code, and better reflects our intentions. Unless it's _immediately obvious_ that **_no_** cleanable state is **_modified_** during the course of the method's execution, all methods should include a `fullFence` to ensure changes made on the main/program thread are seen by the cleanup thread. This applies to any class that uses a `Cleaner` (or a finalizer, really) where the state to be cleaned can be mutated during the course of execution. Other possibilities for triggering the necessary volatile operations could be: * empty synchronized blocks * adding some "junk" variable to EnumCtx, along with volatile reads/writes of the variable where needed --- One could perhaps use deep code tracing to determine that cleanable state is not accessed/written during the course of a method's execution, and omit fences based on that knowledge. However I believe that leaves too large a burden on future maintainers and reviewers to remember to re-perform the code tracing and re-confirm non-use of cleanable state, even when changing possibly "far away" code. ------------- PR: https://git.openjdk.org/jdk/pull/8311 From duke at openjdk.org Thu Jul 21 21:58:14 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Thu, 21 Jul 2022 21:58:14 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v5] In-Reply-To: <07DDwJ22DC4FB8yVVIjplbW2iu9k6PqHD6qcEzZBh_c=.0c9290a2-04ba-4ced-806f-1e59b624d071@github.com> References: <07DDwJ22DC4FB8yVVIjplbW2iu9k6PqHD6qcEzZBh_c=.0c9290a2-04ba-4ced-806f-1e59b624d071@github.com> Message-ID: On Thu, 21 Jul 2022 21:22:19 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy 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 20 additional commits since the last revision: > > - Method rename. > - Merge branch 'master' into JDK-8289551 > - Respond to review feedback; improve tests. > - Add NaN test. > - Preserve NaN sign bit. > - Respond to review feedback. > - Correct carry-out bug; add full binade test. > - Improve NaN significand fidelity; refine tests. > - Partial implementation of review feedback; test refinement. > - Merge branch 'master' into JDK-8289551 > - ... and 10 more: https://git.openjdk.org/jdk/compare/6cc2c3a9...9b060185 src/java.base/share/classes/java/lang/Float.java line 1141: > 1139: // propagate all the way up, take the bottom 11 bits > 1140: // rather than bottom 10 bits. Adding this value, > 1141: // rather than OR'ing htis value, will cause the right `htis` -> `this` src/java.base/share/classes/java/lang/Float.java line 1173: > 1171: int sticky = doppel & 0x0000_0fff; > 1172: > 1173: if (round != 0 && (lsb != 0 || sticky != 0 )) { You may want to reverse the order of `(lsb != 0 || sticky != 0)` to `(sticky != 0 || lsb != 0)` to improve the likelihood that the evaluation of `||` does not need to evaluate its right-hand side. Statistically, `sticky != 0` has a much higher chance to evaluate to `true` than `lsb != 0`. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From darcy at openjdk.org Thu Jul 21 22:27:12 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 21 Jul 2022 22:27:12 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v5] In-Reply-To: <07DDwJ22DC4FB8yVVIjplbW2iu9k6PqHD6qcEzZBh_c=.0c9290a2-04ba-4ced-806f-1e59b624d071@github.com> References: <07DDwJ22DC4FB8yVVIjplbW2iu9k6PqHD6qcEzZBh_c=.0c9290a2-04ba-4ced-806f-1e59b624d071@github.com> Message-ID: On Thu, 21 Jul 2022 21:22:19 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy 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 20 additional commits since the last revision: > > - Method rename. > - Merge branch 'master' into JDK-8289551 > - Respond to review feedback; improve tests. > - Add NaN test. > - Preserve NaN sign bit. > - Respond to review feedback. > - Correct carry-out bug; add full binade test. > - Improve NaN significand fidelity; refine tests. > - Partial implementation of review feedback; test refinement. > - Merge branch 'master' into JDK-8289551 > - ... and 10 more: https://git.openjdk.org/jdk/compare/97f81c3e...9b060185 Thanks for the review comments thus far. A few notes on the recently pushed update, corresponding to webrev 04. The conversion methods have been renamed as suggested in comments received outside of the PR. Thinking more about how a future possible value class for the binary16 format might be structured (java.math.FloatBinary16? java.math.Binary16?), even if such a class cannot extend java.lang.Number, it could still implement the conversion methods found on Number. In particular, a value class for binary16 could have a "floatValue" method as well as factory to convert from float to binary16. Therefore, there need not be any overloading concerns with the methods defined on Float for this issue. (As an aside, it might be helpful to define a superinterface with the methods of java.lang.Number to better capture the ConvertibleToPrimitive API.) The regression tests were augmented in several ways. One is by the introduction of an alternative implementation of the float -> binary16 conversion that uses the hardware support for float rounding to compute the proper low-order bits. This approach benchmarked as significantly slower than the existing bit-inspection approach so it is just used to double-check in testing. Before updating the PR, all 2^32 float values were converted to binary16 using both approaches and the results matched. Testing all 2^32 values all the time seems excessive, so in the PR just one exponent value is checked. For each exponent in normal range, the rounding is analagous at corresponding positions of the number line. Therefore, testing one exponent should be sufficient for testing all the different combination of bit that influence rounding. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From lmesnik at openjdk.org Thu Jul 21 22:41:28 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Jul 2022 22:41:28 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options Message-ID: Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid. ------------- Commit messages: - 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options Changes: https://git.openjdk.org/jdk/pull/9604/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9604&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290846 Stats: 5 lines in 2 files changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9604.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9604/head:pull/9604 PR: https://git.openjdk.org/jdk/pull/9604 From cjplummer at openjdk.org Thu Jul 21 23:07:59 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Jul 2022 23:07:59 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik wrote: > Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid. test/jdk/sun/tools/jstatd/JstatGCUtilParser.java line 48: > 46: S0(GcStatisticsType.PERCENTAGE_OR_DASH), > 47: S1(GcStatisticsType.PERCENTAGE_OR_DASH), > 48: E(GcStatisticsType.PERCENTAGE_OR_DASH), I don't see jstat tests in the zgc problem list. Is this fixing known test failures? test/jdk/sun/tools/jstatd/JstatdTest.java line 131: > 129: private OutputAnalyzer runJps() throws Exception { > 130: JDKToolLauncher launcher = JDKToolLauncher.createUsingTestJDK("jps"); > 131: launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-XX:+UsePerfData")); I assume this is removed because jps only requires that the target JVMs be run with UsePerfData, but not jps itself. ------------- PR: https://git.openjdk.org/jdk/pull/9604 From lmesnik at openjdk.org Fri Jul 22 00:09:05 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 22 Jul 2022 00:09:05 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 23:01:55 GMT, Chris Plummer wrote: >> Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid. > > test/jdk/sun/tools/jstatd/JstatGCUtilParser.java line 48: > >> 46: S0(GcStatisticsType.PERCENTAGE_OR_DASH), >> 47: S1(GcStatisticsType.PERCENTAGE_OR_DASH), >> 48: E(GcStatisticsType.PERCENTAGE_OR_DASH), > > I don't see jstat tests in the zgc problem list. Is this fixing known test failures? Yes, ZGC reports dash for eden and survivor spaces. > test/jdk/sun/tools/jstatd/JstatdTest.java line 131: > >> 129: private OutputAnalyzer runJps() throws Exception { >> 130: JDKToolLauncher launcher = JDKToolLauncher.createUsingTestJDK("jps"); >> 131: launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-XX:+UsePerfData")); > > I assume this is removed because jps only requires that the target JVMs be run with UsePerfData, but not jps itself. jps doesn't require all vm options which we use for test VM. The Utils.getFilteredTestJavaOpts("-XX:+UsePerfData") don't filter anything really, because it use regexp. So we just don't set GC for jps. ------------- PR: https://git.openjdk.org/jdk/pull/9604 From cjplummer at openjdk.org Fri Jul 22 00:56:04 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 22 Jul 2022 00:56:04 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 00:03:26 GMT, Leonid Mesnik wrote: >> test/jdk/sun/tools/jstatd/JstatGCUtilParser.java line 48: >> >>> 46: S0(GcStatisticsType.PERCENTAGE_OR_DASH), >>> 47: S1(GcStatisticsType.PERCENTAGE_OR_DASH), >>> 48: E(GcStatisticsType.PERCENTAGE_OR_DASH), >> >> I don't see jstat tests in the zgc problem list. Is this fixing known test failures? > > Yes, ZGC reports dash for eden and survivor spaces. So shouldn't we have ZGC test failures then? ------------- PR: https://git.openjdk.org/jdk/pull/9604 From darcy at openjdk.org Fri Jul 22 01:29:57 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 22 Jul 2022 01:29:57 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: > Initial implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Implement review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/9b060185..d54f9c94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422 PR: https://git.openjdk.org/jdk/pull/9422 From lmesnik at openjdk.org Fri Jul 22 03:13:57 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 22 Jul 2022 03:13:57 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: Message-ID: <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com> On Fri, 22 Jul 2022 00:52:37 GMT, Chris Plummer wrote: >> Yes, ZGC reports dash for eden and survivor spaces. > > So shouldn't we have ZGC test failures then? No, test passes with ZGC. ------------- PR: https://git.openjdk.org/jdk/pull/9604 From dholmes at openjdk.org Fri Jul 22 04:45:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 22 Jul 2022 04:45:03 GMT Subject: Integrated: 8290489: Initial nroff manpage generation for JDK 20 In-Reply-To: References: Message-ID: <2vnXOAQlpH9CGjFVkGkL4pWyCPxneNmWrxV8V6j5b_w=.c951b25d-e0cd-4902-ad79-200ca4238f91@github.com> On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes wrote: > The version will be 20-ea and the copyright year 2023 (for March 2023 release date). > > Thanks. This pull request has now been integrated. Changeset: e9f97b2e Author: David Holmes URL: https://git.openjdk.org/jdk/commit/e9f97b2e8cf301ba6b69101e5efc5c71d26bc87b Stats: 28 lines in 28 files changed: 0 ins; 0 del; 28 mod 8290489: Initial nroff manpage generation for JDK 20 Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/9581 From joehw at openjdk.org Fri Jul 22 05:46:04 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 22 Jul 2022 05:46:04 GMT Subject: RFR: 8289471: Issue in Initialization of keys in ErrorMsg.java and XPATHErrorResources.java In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 17:21:14 GMT, Shruthi wrote: > Modifying inaccurate initialization of keys in ErrorMsg.java and XPATHErrorResources.java > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8289471 Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9369 From shade at openjdk.org Fri Jul 22 06:32:44 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 22 Jul 2022 06:32:44 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: <5o37cFCEnEfmF9bUcBUI1HTCYFM_LRq1TVfqev-WRMw=.60a400d0-e739-4e5b-9067-967dd786b85e@github.com> On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions Still waiting for revies. @rkennke, maybe? :) ------------- PR: https://git.openjdk.org/jdk/pull/9533 From shade at openjdk.org Fri Jul 22 07:05:49 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 22 Jul 2022 07:05:49 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: <2O9J5hTXHGy-FGAlYrUvSOTAMz0SBpX4d3ROlvwJKRI=.655df335-0e24-4e84-8a03-c083a336eaf0@github.com> On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s Any comments, @pron, @AlanBateman? ------------- PR: https://git.openjdk.org/jdk/pull/9554 From duke at openjdk.org Fri Jul 22 07:09:59 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 22 Jul 2022 07:09:59 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit loops In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 21:14:44 GMT, Mark Reinhold wrote: > Please revise the summary to say ?... instead of explicit loops?. Done. > Please measure this (using, e.g., [JMH](https://github.com/openjdk/jmh)) before making such a change. I'm aware of JMH, I was asking mostly about public API I should call in a benchmark to execute the changed code. ------------- PR: https://git.openjdk.org/jdk/pull/9596 From clanger at openjdk.org Fri Jul 22 07:12:56 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 22 Jul 2022 07:12:56 GMT Subject: [jdk19] RFR: 8290460: Alpine: disable some panama tests that rely on std::thread Message-ID: <0Jsu7udj6lBz2e6KBZDu8-Cfe4tHkOjp5XKr68_qSlU=.626e5a72-8ef7-479c-baf6-b1e453196f4b@github.com> Hi all, This pull request contains a backport of [JDK-8290460](https://bugs.openjdk.org/browse/JDK-8290460), commit [d7f0de27](https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. It is a testfix, so should be good to submit within RDP2. The issue is observed in SAP's CI. Thanks! ------------- Commit messages: - Backport d7f0de272c85ee8d0890c9d61e10065b618b69d7 Changes: https://git.openjdk.org/jdk19/pull/151/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290460 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/151.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/151/head:pull/151 PR: https://git.openjdk.org/jdk19/pull/151 From mbaesken at openjdk.org Fri Jul 22 07:15:30 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 22 Jul 2022 07:15:30 GMT Subject: [jdk19] RFR: 8290455: jck test api/java_lang/foreign/VaList/Empty.html fails on some platforms In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 12:06:37 GMT, Maurizio Cimadamore wrote: > The javadoc for `Linker` states that some operations throw `UnsupportedOperationException` when called on an unsupported platform. These operations are: > > * `Linker::nativeLinker` > * `VaList::empty` > * `VaList::make` > * `VaList::ofAddress` > > While the code throws an UOE as required, since the exception is thrown in a static initialized, it gets wrapped in an `ExceptionInInitializerError`. > > The solution is to set the `CABI` value to `null` if the platform is unknown. Then, when clients call the `CABI.current()` method, we can throw at that point, which will result in the behavior requested by the API spec. Marked as reviewed by mbaesken (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/150 From turbanoff at gmail.com Fri Jul 22 07:42:14 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Fri, 22 Jul 2022 10:42:14 +0300 Subject: Unused static field AbstractWatchKey#OVERFLOW_EVENT Message-ID: Hello. I noticed unused field sun.nio.fs.AbstractWatchKey#OVERFLOW_EVENT https://github.com/openjdk/jdk/blob/e9f97b2e8cf301ba6b69101e5efc5c71d26bc87b/src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java#L45 As I can see, it was already unused in the initial version of https://bugs.openjdk.org/browse/JDK-4313887 Does VM use this field somehow? Or used to use? Andrey Turbanov From david.holmes at oracle.com Fri Jul 22 07:50:26 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Jul 2022 17:50:26 +1000 Subject: Unused static field AbstractWatchKey#OVERFLOW_EVENT In-Reply-To: References: Message-ID: On 22/07/2022 5:42 pm, Andrey Turbanov wrote: > Hello. > I noticed unused field sun.nio.fs.AbstractWatchKey#OVERFLOW_EVENT > https://github.com/openjdk/jdk/blob/e9f97b2e8cf301ba6b69101e5efc5c71d26bc87b/src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java#L45 > > As I can see, it was already unused in the initial version of > https://bugs.openjdk.org/browse/JDK-4313887 > Does VM use this field somehow? Or used to use? Not used by the VM . Seems never used as you indicated. Cheers, David > Andrey Turbanov From duke at openjdk.org Fri Jul 22 09:04:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 22 Jul 2022 09:04:37 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit loops In-Reply-To: References: Message-ID: <75Z4l_p686QUxHIeWcYbnLf6jpumFGmdpEgFy_REWPg=.7a41bc88-44b3-4f50-94fa-98d2565d3d6a@github.com> On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? wrote: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. Could one advise how to execute smth like `jmod hash --module-path ~/openjdk-18.0.2/Contents/Home/jmods --hash-modules .*`? This command doesn't work for me. ------------- PR: https://git.openjdk.org/jdk/pull/9596 From rkennke at openjdk.org Fri Jul 22 10:42:58 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 22 Jul 2022 10:42:58 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions WhiteBox has a number of methods that allow better control over GC, e.g. fullGC(), concurrentGCRunToIdle(), etc. Would that help? See for example: test/hotspot/jtreg/gc/TestReferenceRefersTo.java ------------- PR: https://git.openjdk.org/jdk/pull/9533 From shade at openjdk.org Fri Jul 22 10:42:58 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 22 Jul 2022 10:42:58 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 10:36:32 GMT, Roman Kennke wrote: > WhiteBox has a number of methods that allow better control over GC, e.g. fullGC(), concurrentGCRunToIdle(), etc. Would that help? I think the test relies on assumption that `System.gc()` does the weak reference clearing. Which is not given, for example if concurrent GC cycle is triggered without weak refs processing. I don't think we can solve this with GC control, unless we hack into the each of the GC's policies with Whitebox... ------------- PR: https://git.openjdk.org/jdk/pull/9533 From rkennke at openjdk.org Fri Jul 22 10:49:05 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 22 Jul 2022 10:49:05 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions > > WhiteBox has a number of methods that allow better control over GC, e.g. fullGC(), concurrentGCRunToIdle(), etc. Would that help? > > I think the test relies on assumption that `System.gc()` does the weak reference clearing. Which is not given, for example if concurrent GC cycle is triggered without weak refs processing. I don't think we can solve this with GC control, unless we hack into the each of the GC's policies with Whitebox... Well, WB GC control can run concurrent GC, and wait until certain control points are reached or conc cycle is finished. An example that does that and checks referents get cleared is: test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java TBH, not certain how GC policies play into that, and how well WB is supported in each GC. Might be worth trying? Other that that, how does removinch System.gc() help make the test more reliable? ------------- PR: https://git.openjdk.org/jdk/pull/9533 From shade at openjdk.org Fri Jul 22 10:53:04 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 22 Jul 2022 10:53:04 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 10:46:57 GMT, Roman Kennke wrote: > TBH, not certain how GC policies play into that, and how well WB is supported in each GC. Might be worth trying? > Other that that, how does removinch System.gc() help make the test more reliable? When you call `System.gc()` on some collectors, they blow out the weak references, which includes the cache in question. The assert then fails, thinking there was no reason to clear the cache. That is, the assert assumes the "memory pressure" is the only way the cache would be dropped, which is evidently not true. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From clanger at openjdk.org Fri Jul 22 11:37:09 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 22 Jul 2022 11:37:09 GMT Subject: [jdk19] Integrated: 8290460: Alpine: disable some panama tests that rely on std::thread In-Reply-To: <0Jsu7udj6lBz2e6KBZDu8-Cfe4tHkOjp5XKr68_qSlU=.626e5a72-8ef7-479c-baf6-b1e453196f4b@github.com> References: <0Jsu7udj6lBz2e6KBZDu8-Cfe4tHkOjp5XKr68_qSlU=.626e5a72-8ef7-479c-baf6-b1e453196f4b@github.com> Message-ID: On Fri, 22 Jul 2022 07:04:29 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of [JDK-8290460](https://bugs.openjdk.org/browse/JDK-8290460), commit [d7f0de27](https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > It is a testfix, so should be good to submit within RDP2. The issue is observed in SAP's CI. > > Thanks! This pull request has now been integrated. Changeset: c29242eb Author: Christoph Langer URL: https://git.openjdk.org/jdk19/commit/c29242ebb0cfd3eaa56240664af607c02a11324e Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8290460: Alpine: disable some panama tests that rely on std::thread Backport-of: d7f0de272c85ee8d0890c9d61e10065b618b69d7 ------------- PR: https://git.openjdk.org/jdk19/pull/151 From rkennke at openjdk.org Fri Jul 22 11:37:57 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 22 Jul 2022 11:37:57 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions Looks good, then. Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.org/jdk/pull/9533 From rpressler at openjdk.org Fri Jul 22 11:56:04 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 22 Jul 2022 11:56:04 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s The changes to Fuzz.java seem fine to me. ------------- Marked as reviewed by rpressler (Committer). PR: https://git.openjdk.org/jdk/pull/9554 From jvernee at openjdk.org Fri Jul 22 13:22:28 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 13:22:28 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests Message-ID: This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). Testing: Running the affected tests on platforms that implement the linker. ------------- Commit messages: - Linux fixes - Don't use std::thread in j.l.f tests Changes: https://git.openjdk.org/jdk/pull/9599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290059 Stats: 171 lines in 7 files changed: 123 ins; 7 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From rriggs at openjdk.org Fri Jul 22 14:48:04 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 22 Jul 2022 14:48:04 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v15] In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 21:35:02 GMT, Brent Christian wrote: >> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. >> >> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. >> >> Details of note: >> 1. Some operations need to change the state values (the update() method is probably the most interesting). >> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. >> >> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. >> >> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). >> >> Thanks. > > Brent Christian has updated the pull request incrementally with two additional commits since the last revision: > > - simplify some comments > - Update ForceGC usage LGTM (Except for a TODO and some tabs that should be spaces) (Probably there's a higher level lesson to be learned about designing this kind of interaction with a server and the teardown needed). src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 517: > 515: refEx = ne.refEx; > 516: listArg = ne.listArg; > 517: // record a previous exception and quit if any limit is reached Replace tabs with spaces. ------------- PR: https://git.openjdk.org/jdk/pull/8311 From duke at openjdk.org Fri Jul 22 15:00:43 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Fri, 22 Jul 2022 15:00:43 GMT Subject: RFR: 8205592: BigDecimal.doubleValue() is depressingly slow In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 02:10:27 GMT, Julian Waters wrote: >> A reimplementation of `BigDecimal.[double|float]Value()` to enhance performance, avoiding an intermediate string and its subsequent parsing on the slow path. > > Impressive performance improvements, I also like the PR title :P @TheShermanTanker The title is the one from the JBS issue. As for the performance improvements, note that microbenchmarks are what they are. The overall effect of these improvements might be barely noticeable in some programs using BigDecimal and might be positively impact others. ------------- PR: https://git.openjdk.org/jdk/pull/9410 From mcimadamore at openjdk.org Fri Jul 22 15:01:12 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 22 Jul 2022 15:01:12 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Looks good! test/lib/native/testlib_threads.h line 37: > 35: typedef HANDLE THREAD_ID; > 36: > 37: #else // !_WIN32 the comments in the #else are inconsistent - some use `!_WIN32`, some use `!windows` others use nothing. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Fri Jul 22 16:45:55 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 16:45:55 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9599/files - new: https://git.openjdk.org/jdk/pull/9599/files/8e538b47..49e60f2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=00-01 Stats: 17 lines in 1 file changed: 5 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From mcimadamore at openjdk.org Fri Jul 22 16:45:56 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 22 Jul 2022 16:45:56 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: <3oZXLMv51fsA2eyUVWSGTfhXOWM5ESXJmOp-PhxEPoE=.bdf26040-dc62-4141-a33b-79b0f4ff7cd0@github.com> On Fri, 22 Jul 2022 16:41:24 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9599 From clanger at openjdk.org Fri Jul 22 16:45:57 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 22 Jul 2022 16:45:57 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. @JornVernee thanks for doing this so quickly. I suggest undoing https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7 in this change, too. If you update this PR I can run it through our Alpine test pipeline. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Fri Jul 22 16:45:58 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 16:45:58 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 15:09:13 GMT, Christoph Langer wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > @JornVernee thanks for doing this so quickly. I suggest undoing https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7 in this change, too. If you update this PR I can run it through our Alpine test pipeline. @RealCLanger Note that I'm not setting the stack size of the thread in this patch. I'm just using the defaults. From the discussion on the bug, I don't think this sufficient to make the tests pass on Apline/MuslC. I avoided getting into that since I don't have ready access to an Alpine/MuslC testing environment atm. So, I've left setting the stack size on MuslC, and re-enabling the tests for someone that does. Hopefully this patch is enough to get that going easily. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Fri Jul 22 16:45:59 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 22 Jul 2022 16:45:59 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 14:56:16 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes > > Looks good! @mcimadamore Thanks for the comments. I've cleaned up the comments on the compiler switches (just removed them). I also realized there was an unused typedef for `THREAD_ID`, which I've removed. Finally, I realized that after printing an error, we should probably also exit the test (I'd forgotten to add this before making the PR public). I've added a helper function called `fatal` that prints the error message and then calls `exit`. The tests still pass with that. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From clanger at openjdk.org Fri Jul 22 16:46:00 2022 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 22 Jul 2022 16:46:00 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 15:09:13 GMT, Christoph Langer wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > @JornVernee thanks for doing this so quickly. I suggest undoing https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69d7 in this change, too. If you update this PR I can run it through our Alpine test pipeline. > @RealCLanger Note that I'm not setting the stack size of the thread in this patch. I'm just using the defaults. From the discussion on the bug, I don't think this sufficient to make the tests pass on Apline/MuslC. > > I avoided getting into that since I don't have ready access to an Alpine/MuslC testing environment atm. So, I've left setting the stack size on MuslC, and re-enabling the tests for someone that does. Hopefully this patch is enough to get that going easily. OK, thanks for clarifying that. @tstuefe, maybe you want to have a look after this fix is in? ------------- PR: https://git.openjdk.org/jdk/pull/9599 From stuefe at openjdk.org Fri Jul 22 18:47:20 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 22 Jul 2022 18:47:20 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes Hi @JornVernee, good job and thanks for doing it so quickly. Looks good, module the GetLastError comment. About the stack size and Alpine, I am fine with doing the A?pine-specific fix in a follow-up, or you can do it as part of this change. Strictly speaking its not part of this bug report to adjust the stack size. If you fix the GetLastError issue, I don't need another look. Thanks, Thomas test/lib/native/testlib_threads.h line 50: > 48: static void fatal(const char* message) { > 49: perror(message); > 50: exit(-1); Won't work as intended for Windows APIs. I would print the result of `GetLastError()` instead. Alternatively I am fine fine with just omitting the error code, because I think the old tests did not handle errors either. Or did we catch std::thread exceptions somewhere? test/lib/native/testlib_threads.h line 61: > 59: helper->proc(helper->context); > 60: return 0; > 61: } I'm curious, does this only exist because of the DWORD vs void* return value size of the native thread functions? I wondered why you don't just pass the test procedure to the thread start API directly. About stdcall, does Oracle still build Windows 32bit? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9599 From rriggs at openjdk.org Fri Jul 22 20:02:40 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 22 Jul 2022 20:02:40 GMT Subject: RFR: 8290893: ProblemList java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload Message-ID: java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java should be ProblemListed until the cause can be found. ------------- Commit messages: - 8290894: ProblemList java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload Changes: https://git.openjdk.org/jdk/pull/9617/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9617&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290893 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9617.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9617/head:pull/9617 PR: https://git.openjdk.org/jdk/pull/9617 From dcubed at openjdk.org Fri Jul 22 20:02:40 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 22 Jul 2022 20:02:40 GMT Subject: RFR: 8290893: ProblemList java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 19:48:45 GMT, Roger Riggs wrote: > java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java should be ProblemListed until the cause can be found. This test might only be failing with -Xcomp. Let me check... ------------- PR: https://git.openjdk.org/jdk/pull/9617 From rriggs at openjdk.org Fri Jul 22 20:06:00 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 22 Jul 2022 20:06:00 GMT Subject: RFR: 8290893: ProblemList java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload [v2] In-Reply-To: References: Message-ID: > java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java should be ProblemListed until the cause can be found. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Move to ProblemList-Xcomp.txt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9617/files - new: https://git.openjdk.org/jdk/pull/9617/files/dabed318..9ea189bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9617&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9617&range=00-01 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9617.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9617/head:pull/9617 PR: https://git.openjdk.org/jdk/pull/9617 From dcubed at openjdk.org Fri Jul 22 20:10:04 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 22 Jul 2022 20:10:04 GMT Subject: RFR: 8290893: ProblemList java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 20:06:00 GMT, Roger Riggs wrote: >> java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java should be ProblemListed until the cause can be found. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Move to ProblemList-Xcomp.txt Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9617 From rriggs at openjdk.org Fri Jul 22 20:15:02 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 22 Jul 2022 20:15:02 GMT Subject: Integrated: 8290893: ProblemList java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 19:48:45 GMT, Roger Riggs wrote: > java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java should be ProblemListed until the cause can be found. This pull request has now been integrated. Changeset: 2660a926 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/2660a9268b36afc24787273eb22a12c1bc1b9dca Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8290893: ProblemList java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/9617 From asemenyuk at openjdk.org Fri Jul 22 20:31:37 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 22 Jul 2022 20:31:37 GMT Subject: RFR: 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file" Message-ID: 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file" ------------- Commit messages: - 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file" Changes: https://git.openjdk.org/jdk/pull/9618/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9618&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290557 Stats: 52 lines in 1 file changed: 45 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9618.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9618/head:pull/9618 PR: https://git.openjdk.org/jdk/pull/9618 From bchristi at openjdk.org Fri Jul 22 20:51:59 2022 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 22 Jul 2022 20:51:59 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: > Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. > > The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. > > Details of note: > 1. Some operations need to change the state values (the update() method is probably the most interesting). > 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. > > The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. > > The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). > > Thanks. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: remove some more tabs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8311/files - new: https://git.openjdk.org/jdk/pull/8311/files/a7208339..3bccc074 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8311&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8311&range=14-15 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/8311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8311/head:pull/8311 PR: https://git.openjdk.org/jdk/pull/8311 From ecaspole at openjdk.org Fri Jul 22 20:56:34 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Fri, 22 Jul 2022 20:56:34 GMT Subject: RFR: 8290894: Reduce runtime of vm.lang microbenchmarks Message-ID: Adds fork and iterations controls. This reduces the runtime from 4h26m to about 21m and still seems stable enough for weekly testing. ------------- Commit messages: - 8290894: Reduce runtime of vm.lang microbenchmarks Changes: https://git.openjdk.org/jdk/pull/9619/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9619&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290894 Stats: 39 lines in 5 files changed: 30 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9619.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9619/head:pull/9619 PR: https://git.openjdk.org/jdk/pull/9619 From almatvee at openjdk.org Fri Jul 22 22:00:04 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 22 Jul 2022 22:00:04 GMT Subject: RFR: 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file" In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 20:21:57 GMT, Alexey Semenyuk wrote: > 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file" Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9618 From naoto at openjdk.org Fri Jul 22 22:01:39 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 22 Jul 2022 22:01:39 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content Message-ID: This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. ------------- Commit messages: - IllformedLocaleEx -> LocaleSyntaxEx - SystemProperty tests - Revived returning Optional - Some clean-ups, including making Extension a sealed class. - Bring the specialized methods back - Using Optional - FieldSeparators()/FieldSubtag() -> Fields() - 8289227: Support for BCP 47 Extension T - T-ext Changes: https://git.openjdk.org/jdk/pull/9620/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289227 Stats: 776 lines in 23 files changed: 600 ins; 135 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From mik3hall at gmail.com Fri Jul 22 22:03:04 2022 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 22 Jul 2022 17:03:04 -0500 Subject: [External] : Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2] In-Reply-To: <7E5EB1E3-CA01-4955-B7B3-5967B0083615@oracle.com> References: <4FF6CE80-8B6F-4E86-85ED-6A4E3579A70E@gmail.com> <9DC8A6BB-8AA9-4FFE-838A-7FA34B8B0026@gmail.com> <05C49884-09B4-4633-A947-2010841AD2BB@gmail.com> <65B9A26A-0B72-4ABE-A4BC-359ECC268229@oracle.com> <4141519E-6FDB-4BA4-A8C0-E2E6BB2FC7C8@gmail.com> <11662D86-632D-4C26-992F-7D6F4C381F18@oracle.com> <2DA5739B-AC6E-4E82-B3D0-87FC0CA49BF4@gmail.com> <42566B83-8ACF-49F3-B4B9-4CE7703784FD@gmail.com> <31387ED8-F976-4F7D-BB99-11F5DCBC2C71@gmail.com> <95342BF4-8CB7-4109-9B19-B977AC38B705@oracle.com> <3262D90C-0DA4-4F49-AA75-96A0E7478AAF@gmail.com> <0D8431F2-5E1F-4990-BA32-2748BB4336B6@gmail.com> <7E5EB1E3-CA01-4955-B7B3-5967B0083615@oracle.com> Message-ID: > On Jun 22, 2022, at 10:28 PM, Alexander Matveev wrote: > > Hi Michael, > > I filed it as https://bugs.openjdk.org/browse/JDK-8289030 > > Thanks, > Alexander > Alexander, Checking on this it appears to be resolved but still doesn?t seem to be in jdk19 early access. OpenJDK Runtime Environment (build 19-ea+32-2220) Should I be looking for it later? Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jul 22 22:13:12 2022 From: duke at openjdk.org (Shruthi) Date: Fri, 22 Jul 2022 22:13:12 GMT Subject: Integrated: 8289471: Issue in Initialization of keys in ErrorMsg.java and XPATHErrorResources.java In-Reply-To: References: Message-ID: On Mon, 4 Jul 2022 17:21:14 GMT, Shruthi wrote: > Modifying inaccurate initialization of keys in ErrorMsg.java and XPATHErrorResources.java > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8289471 This pull request has now been integrated. Changeset: 987656d6 Author: Shruthi Committer: Joe Wang URL: https://git.openjdk.org/jdk/commit/987656d69065b5b61d658cec3704a181a4aef18b Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8289471: Issue in Initialization of keys in ErrorMsg.java and XPATHErrorResources.java Reviewed-by: joehw ------------- PR: https://git.openjdk.org/jdk/pull/9369 From smarks at openjdk.org Fri Jul 22 22:21:08 2022 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 22 Jul 2022 22:21:08 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian wrote: >> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. >> >> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. >> >> Details of note: >> 1. Some operations need to change the state values (the update() method is probably the most interesting). >> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. >> >> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. >> >> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). >> >> Thanks. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > remove some more tabs src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 158: > 156: // reachable. > 157: // TODO: Is anything else needed so that this constructor > 158: // "happens-before" the cleaning action ? I think the resolution of this TODO is to modify the specification of Cleaner to require that: 1. the object being registered is guaranteed reachable until after registration has completed; and 2. a "memory consistency effects" clause should also be added to Cleaner.register. For an example, see the class specification of CopyOnWriteArrayList. It may be that reachabilityFences are already in the right place in Cleaner. Great. But last time I looked it doesn't have any memory visibility operations. I'd suggest opening a bug on Cleaner for the spec change and accumulating notes there. ------------- PR: https://git.openjdk.org/jdk/pull/8311 From smarks at openjdk.org Fri Jul 22 22:27:04 2022 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 22 Jul 2022 22:27:04 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian wrote: >> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. >> >> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. >> >> Details of note: >> 1. Some operations need to change the state values (the update() method is probably the most interesting). >> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. >> >> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. >> >> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). >> >> Thanks. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > remove some more tabs I think the main outstanding issues here are as follows. First, are we convinced that it's necessary to add a try/finally block with a memory fence and a reachability fence in pretty much every mutator method? I think the answer is Yes, but we ought to have this ratified by memory model and GC experts. A second issue is whether VarHandle::fullFence is the right memory fence operation. I'm not quite convinced that it is, but I'm not sure what the right alternative is either. Finally, we probably also need approval from the maintainers of this code. :-) ------------- PR: https://git.openjdk.org/jdk/pull/8311 From psandoz at openjdk.org Fri Jul 22 23:01:11 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 22 Jul 2022 23:01:11 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 01:29:57 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Implement review feedback. I don't claim to be an expert in IEEE formats... the methods generally look good with thorough testing. Looking forward to the impact intrinsification will have! test/jdk/java/lang/Float/Binary16Conversion.java line 29: > 27: * @summary Verify conversion between float and the binary16 format > 28: * @library ../Math > 29: * @build FloatConsts Is this line necessary? test/jdk/java/lang/Float/Binary16Conversion.java line 33: > 31: */ > 32: > 33: import static java.lang.Float.*; Unused. test/jdk/java/lang/Float/Binary16Conversion.java line 100: > 98: > 99: return errors; > 100: }; Suggestion: } test/jdk/java/lang/Float/Binary16Conversion.java line 409: > 407: public static final short MAX_SUBNORMAL = 0x03ff; > 408: public static final short MIN_VALUE = 0x0001; > 409: public static final short NEGATIVE_ZERO = (short)0x8000; Unused. test/jdk/java/lang/Float/Binary16ConversionNaN.java line 30: > 28: */ > 29: > 30: import static java.lang.Float.*; Unused. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.org/jdk/pull/9422 From achung at openjdk.org Sat Jul 23 03:11:02 2022 From: achung at openjdk.org (Alisen Chung) Date: Sat, 23 Jul 2022 03:11:02 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 Message-ID: open l10n msg drop All tests passed. ------------- Commit messages: - open l10n drop Changes: https://git.openjdk.org/jdk19/pull/154/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290889 Stats: 3930 lines in 44 files changed: 3336 ins; 540 del; 54 mod Patch: https://git.openjdk.org/jdk19/pull/154.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154 PR: https://git.openjdk.org/jdk19/pull/154 From jrose at openjdk.org Sat Jul 23 05:40:12 2022 From: jrose at openjdk.org (John R Rose) Date: Sat, 23 Jul 2022 05:40:12 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: <0aoKqwwXEVIDeACyczupt2zb4TgZIhIPZhntXig8Bn0=.7317c218-2251-4a90-9f50-99de18342d2c@github.com> On Fri, 22 Jul 2022 01:29:57 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Implement review feedback. Looks good. ------------- Marked as reviewed by jrose (Reviewer). PR: https://git.openjdk.org/jdk/pull/9422 From dholmes at openjdk.org Sat Jul 23 06:02:14 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 23 Jul 2022 06:02:14 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes `run_async` is an odd name for this, especially as the fact you create then join mean it doesn't run asynchronously at all - it runs synchronously in another thread. The API would be more generally useful if you split the start and the join, but that would require also exposing an opaque thread "handle" (though splitting also means you don't have to try and think of a good name for `run_in_a_new_thread-and_join_it()` - you just have `threadStart` and `threadJoin`). ------------- PR: https://git.openjdk.org/jdk/pull/9599 From turbanoff at gmail.com Sat Jul 23 18:04:50 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sat, 23 Jul 2022 21:04:50 +0300 Subject: TimeZone implementations questions Message-ID: Hello. While I was browsing the source of java.util.TimeZone found a couple of confusing things: 1. Static methods 'getAvailableIDs' and 'getAvailableIDs' are marked as synchronized. But all they do - just delegate call to sun.util.calendar.ZoneInfoFile methods: public static synchronized String[] getAvailableIDs(int rawOffset) { return ZoneInfo.getAvailableIDs(rawOffset); } public static synchronized String[] getAvailableIDs() { return ZoneInfo.getAvailableIDs(); } It seems 'synchronized's are unnecessary there. Am I right? 2. There is confusing NPE catch in a method 'java.util.TimeZone#setDefaultZone' try { zoneID = getSystemTimeZoneID(javaHome); if (zoneID == null) { zoneID = GMT_ID; } } catch (NullPointerException e) { zoneID = GMT_ID; } Only possible source of NPE here is the method 'getSystemTimeZoneID'. I checked native sources and it seems there is no NPE thrown. Can we remove the catch (NullPointerException) then? Andrey Turbanov From aturbanov at openjdk.org Sat Jul 23 18:13:37 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sat, 23 Jul 2022 18:13:37 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit loops In-Reply-To: References: Message-ID: <2PIIeyDxI3wzRLKMLgHy22LmmZobKIYeYtcDwZ1yhyk=.7846ffdd-cbe7-4c8b-9008-c905629570c6@github.com> On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? wrote: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. Ow. I've created similar PR for `X509CertPath` recently #9263 ------------- PR: https://git.openjdk.org/jdk/pull/9596 From duke at openjdk.org Sat Jul 23 18:44:44 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sat, 23 Jul 2022 18:44:44 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit loops In-Reply-To: <2PIIeyDxI3wzRLKMLgHy22LmmZobKIYeYtcDwZ1yhyk=.7846ffdd-cbe7-4c8b-9008-c905629570c6@github.com> References: <2PIIeyDxI3wzRLKMLgHy22LmmZobKIYeYtcDwZ1yhyk=.7846ffdd-cbe7-4c8b-9008-c905629570c6@github.com> Message-ID: On Sat, 23 Jul 2022 18:10:15 GMT, Andrey Turbanov wrote: >> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. > > Ow. I've created similar PR for `X509CertPath` recently #9263 @turbanoff I'll then remove the mentioned piece from this PR ------------- PR: https://git.openjdk.org/jdk/pull/9596 From duke at openjdk.org Sat Jul 23 20:07:12 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Sat, 23 Jul 2022 20:07:12 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 01:29:57 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Implement review feedback. src/java.base/share/classes/java/lang/Float.java line 980: > 978: > 979: /** > 980: * {@return the {@code float} value closest to the numerical value `{@return` seems to be out of place and missing a closing `}` src/java.base/share/classes/java/lang/Float.java line 1028: > 1026: // Shift left difference in the number of significand bits in > 1027: // the float and binary16 formats > 1028: final int SIGNIF_SHIFT = (FloatConsts.SIGNIFICAND_WIDTH - 11); Wouldn't it make more sense to declare this local as `private static final`? It could then even be used in the next method. src/java.base/share/classes/java/lang/Float.java line 1036: > 1034: // (significand width includes the implicit bit so shift one > 1035: // less). > 1036: int bin16Exp = (((bin16ExpBits >> 10) - 15)); Opening `((` and closing `))` are ?ber-redundant src/java.base/share/classes/java/lang/Float.java line 1059: > 1057: int result = (floatExpBits | > 1058: (bin16SignifBits << SIGNIF_SHIFT)); > 1059: return sign * Float.intBitsToFloat(result); One could use `bin16SignBit` when preparing the `int result` bits to avoid a `float` multiplication just to generate the sign src/java.base/share/classes/java/lang/Float.java line 1063: > 1061: > 1062: /** > 1063: * {@return the floating-point binary16 value, encoded in a {@code `{@0return` seems to be out of place and missing a closing `}` src/java.base/share/classes/java/lang/Float.java line 1110: > 1108: > 1109: // The overflow threshold is binary16 MAX_VALUE + 1/2 ulp > 1110: if (abs_f >= (65504.0f + 16.0f) ) { What about `(0x1.ffcp15f + 0x0.002p15f)` for the overflow threshold? The bits are reflected more clearly. src/java.base/share/classes/java/lang/Float.java line 1112: > 1110: if (abs_f >= (65504.0f + 16.0f) ) { > 1111: return (short)(sign_bit | 0x7c00); // Positive or negative infinity > 1112: } else { The ` else {` with the corresponding closing `}` could be removed and the code in this branch could be un-indented. This would make the code visually less "jagged". src/java.base/share/classes/java/lang/Float.java line 1115: > 1113: // Smallest magnitude nonzero representable binary16 value > 1114: // is equal to 0x1.0p-24; half-way and smaller rounds to zero. > 1115: if (abs_f <= 0x1.0p-25f) { // Covers float zeros and subnormals. I think `0x0.002p-14f` or `0.5f * 0x0.004p-14f` might be clearer than `0x1.0p-25f`. The latter requires mental calculation to verify. src/java.base/share/classes/java/lang/Float.java line 1122: > 1120: // binary16 (when rounding is done, could still round up) > 1121: int exp = Math.getExponent(f); > 1122: assert -25 <= exp && exp <= 15; I think that both the subnormal and the normal case can be unified if we pay closer attention to the positions of the lsb, round and sticky bits in subnormals. // Clamp exp to the [-15, 15] range while retaining the // difference between the original value and -15 on clamping. // This is the excess shift value in addition to 13. int expdelta = Math.max(0, -15 - exp); exp += expdelta; assert -15 <= exp && exp <= 15; int f_signif_bits = doppel & 0x007f_ffff; // original significand // Significand bits as if using rounding to zero (truncation). short signif_bits = (short)(f_signif_bits >> (13 + expdelta)); // For round to nearest even, determining whether or // not to round up (in magnitude) is a function of the // least significant bit (LSB), the next bit position // (the round position), and the sticky bit (whether // there are any nonzero bits in the exact result to // the right of the round digit). An increment occurs // in three cases: // // LSB Round Sticky // 0 1 1 // 1 1 0 // 1 1 1 // See "Computer Arithmetic Algorithms," Koren, Table 4.9 int lsb = f_signif_bits & (1 << 13 + expdelta); int round = f_signif_bits & (1 << 12 + expdelta); int sticky = f_signif_bits & ((1 << 12 + expdelta) - 1); if (round != 0 && ((lsb | sticky) != 0 )) { signif_bits++; } // No bits set in significand beyond the *first* exponent // bit, not just the sigificand; quantity is added to the // exponent to implement a carry out from rounding the // significand. assert (0xf800 & signif_bits) == 0x0; return (short)(sign_bit | ( ((exp + 15) << 10) + signif_bits ) ); src/java.base/share/classes/java/lang/Float.java line 1186: > 1184: return (short)(sign_bit | ( ((exp + 15) << 10) + signif_bits ) ); > 1185: } > 1186: } `}` should be indented by 4 spaces. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From duke at openjdk.org Sat Jul 23 20:07:13 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Sat, 23 Jul 2022 20:07:13 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 18:55:03 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement review feedback. > > src/java.base/share/classes/java/lang/Float.java line 1122: > >> 1120: // binary16 (when rounding is done, could still round up) >> 1121: int exp = Math.getExponent(f); >> 1122: assert -25 <= exp && exp <= 15; > > I think that both the subnormal and the normal case can be unified if we pay closer attention to the positions of the lsb, round and sticky bits in subnormals. > > > // Clamp exp to the [-15, 15] range while retaining the > // difference between the original value and -15 on clamping. > // This is the excess shift value in addition to 13. > int expdelta = Math.max(0, -15 - exp); > exp += expdelta; > assert -15 <= exp && exp <= 15; > > int f_signif_bits = doppel & 0x007f_ffff; // original significand > // Significand bits as if using rounding to zero (truncation). > short signif_bits = (short)(f_signif_bits >> (13 + expdelta)); > > // For round to nearest even, determining whether or > // not to round up (in magnitude) is a function of the > // least significant bit (LSB), the next bit position > // (the round position), and the sticky bit (whether > // there are any nonzero bits in the exact result to > // the right of the round digit). An increment occurs > // in three cases: > // > // LSB Round Sticky > // 0 1 1 > // 1 1 0 > // 1 1 1 > // See "Computer Arithmetic Algorithms," Koren, Table 4.9 > > int lsb = f_signif_bits & (1 << 13 + expdelta); > int round = f_signif_bits & (1 << 12 + expdelta); > int sticky = f_signif_bits & ((1 << 12 + expdelta) - 1); > > if (round != 0 && ((lsb | sticky) != 0 )) { > signif_bits++; > } > > // No bits set in significand beyond the *first* exponent > // bit, not just the sigificand; quantity is added to the > // exponent to implement a carry out from rounding the > // significand. > assert (0xf800 & signif_bits) == 0x0; > > return (short)(sign_bit | ( ((exp + 15) << 10) + signif_bits ) ); I didn't test this variant, will do tomorrow when also reviewing the tests themselves. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From duke at openjdk.org Sun Jul 24 15:48:45 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Sun, 24 Jul 2022 15:48:45 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 20:03:39 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/lang/Float.java line 1122: >> >>> 1120: // binary16 (when rounding is done, could still round up) >>> 1121: int exp = Math.getExponent(f); >>> 1122: assert -25 <= exp && exp <= 15; >> >> I think that both the subnormal and the normal case can be unified if we pay closer attention to the positions of the lsb, round and sticky bits in subnormals. >> >> >> // Clamp exp to the [-15, 15] range while retaining the >> // difference between the original value and -15 on clamping. >> // This is the excess shift value in addition to 13. >> int expdelta = Math.max(0, -15 - exp); >> exp += expdelta; >> assert -15 <= exp && exp <= 15; >> >> int f_signif_bits = doppel & 0x007f_ffff; // original significand >> // Significand bits as if using rounding to zero (truncation). >> short signif_bits = (short)(f_signif_bits >> (13 + expdelta)); >> >> // For round to nearest even, determining whether or >> // not to round up (in magnitude) is a function of the >> // least significant bit (LSB), the next bit position >> // (the round position), and the sticky bit (whether >> // there are any nonzero bits in the exact result to >> // the right of the round digit). An increment occurs >> // in three cases: >> // >> // LSB Round Sticky >> // 0 1 1 >> // 1 1 0 >> // 1 1 1 >> // See "Computer Arithmetic Algorithms," Koren, Table 4.9 >> >> int lsb = f_signif_bits & (1 << 13 + expdelta); >> int round = f_signif_bits & (1 << 12 + expdelta); >> int sticky = f_signif_bits & ((1 << 12 + expdelta) - 1); >> >> if (round != 0 && ((lsb | sticky) != 0 )) { >> signif_bits++; >> } >> >> // No bits set in significand beyond the *first* exponent >> // bit, not just the sigificand; quantity is added to the >> // exponent to implement a carry out from rounding the >> // significand. >> assert (0xf800 & signif_bits) == 0x0; >> >> return (short)(sign_bit | ( ((exp + 15) << 10) + signif_bits ) ); > > I didn't test this variant, will do tomorrow when also reviewing the tests themselves. The correct variant below passes the tests. // For binary16 subnormals, beside forcing exp to -15, // retain the difference expdelta = E_min - exp. // This is the excess shift value, in addition to 13, to be used // in the computations below. // Further the (hidden) msb with value 1 in f must be involved as well. int expdelta = 0; int msb = 0x0000_0000; if (exp < -14) { expdelta = -14 - exp; exp = -15; msb = 0x0080_0000; } int f_signif_bits = doppel & 0x007f_ffff | msb; // Significand bits as if using rounding to zero (truncation). short signif_bits = (short)(f_signif_bits >> (13 + expdelta)); // For round to nearest even, determining whether or // not to round up (in magnitude) is a function of the // least significant bit (LSB), the next bit position // (the round position), and the sticky bit (whether // there are any nonzero bits in the exact result to // the right of the round digit). An increment occurs // in three cases: // // LSB Round Sticky // 0 1 1 // 1 1 0 // 1 1 1 // See "Computer Arithmetic Algorithms," Koren, Table 4.9 int lsb = f_signif_bits & (1 << 13 + expdelta); int round = f_signif_bits & (1 << 12 + expdelta); int sticky = f_signif_bits & ((1 << 12 + expdelta) - 1); if (round != 0 && ((lsb | sticky) != 0 )) { signif_bits++; } // No bits set in significand beyond the *first* exponent // bit, not just the sigificand; quantity is added to the // exponent to implement a carry out from rounding the // significand. assert (0xf800 & signif_bits) == 0x0; return (short)(sign_bit | ( ((exp + 15) << 10) + signif_bits ) ); ------------- PR: https://git.openjdk.org/jdk/pull/9422 From hboehm at google.com Mon Jul 25 04:10:14 2022 From: hboehm at google.com (Hans Boehm) Date: Sun, 24 Jul 2022 21:10:14 -0700 Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: I also have concerns about the use of fullFence here. I believe it should be the case that reachabilityFence guarantees visibility of memory operations program-ordered before the reachabilityFence(p) to the Cleaner associated with p. Mutator-collector synchronization should normally ensure that. On rereading, it also appears to me that the current reachabilityFence() documentation does not make that as clear as it should. It appears to me that this is addressing an instance of the problem for which I suggested a more general, though also not completely elegant, solution in https://docs.google.com/document/d/1yMC4VzZobMQTrVAraMy7xBdWPCJ0p7G5r_43yaqsj-s/edit?usp=sharing . On Fri, Jul 22, 2022 at 3:27 PM Stuart Marks wrote: > On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian > wrote: > > >> Please review this change to replace the finalizer in > `AbstractLdapNamingEnumeration` with a Cleaner. > >> > >> The pieces of state required for cleanup (`LdapCtx homeCtx`, > `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner > class . From there, the change is fairly mechanical. > >> > >> Details of note: > >> 1. Some operations need to change the state values (the update() method > is probably the most interesting). > >> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to > read `homeCtx` from the superclass's `state`. > >> > >> The test case is based on a copy of > `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test > case might be possible, but this was done for expediency. > >> > >> The test only confirms that the new Cleaner use does not keep the > object reachable. It only tests `LdapSearchEnumeration` (not > `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are > subclasses of `AbstractLdapNamingEnumeration`). > >> > >> Thanks. > > > > Brent Christian has updated the pull request incrementally with one > additional commit since the last revision: > > > > remove some more tabs > > I think the main outstanding issues here are as follows. > > First, are we convinced that it's necessary to add a try/finally block > with a memory fence and a reachability fence in pretty much every mutator > method? I think the answer is Yes, but we ought to have this ratified by > memory model and GC experts. > > A second issue is whether VarHandle::fullFence is the right memory fence > operation. I'm not quite convinced that it is, but I'm not sure what the > right alternative is either. > > Finally, we probably also need approval from the maintainers of this code. > :-) > > ------------- > > PR: https://git.openjdk.org/jdk/pull/8311 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jul 25 06:40:49 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 25 Jul 2022 06:40:49 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit loops [v2] In-Reply-To: References: Message-ID: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8278461: Revert X509CertPath ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9596/files - new: https://git.openjdk.org/jdk/pull/9596/files/04415d08..0079ed3b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9596&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9596&range=00-01 Stats: 24 lines in 1 file changed: 17 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9596.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9596/head:pull/9596 PR: https://git.openjdk.org/jdk/pull/9596 From duke at openjdk.org Mon Jul 25 08:56:10 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 25 Jul 2022 08:56:10 GMT Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit loops [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 06:40:49 GMT, ?????? ??????? wrote: >> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8278461: Revert X509CertPath I've measured this with benchmark @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MILLISECONDS) @Fork(jvmArgsAppend = {"-Xms1g", "-Xmx1g"}) public class HashBenchmark { private final Path path = Path.of("/Users/stsypanov/Library/Java/JavaVirtualMachines/openjdk-18.0.2/Contents/Home/jmods"); private final ModuleFinder finder = ModulePath.of(Runtime.version(), true, path); @Benchmark public byte[] hash() throws Exception { return hash(finder, "java.base"); } private byte[] hash(ModuleFinder finder, String name) throws Exception { ModuleReference mref = finder.find(name).orElseThrow(RuntimeException::new); try (ModuleReader reader = mref.open()) { return ModuleHashes.computeHash(reader, "SHA-256"); } } } and indeed the change makes things slower: baseline Benchmark Mode Cnt Score Error Units HashBenchmark.hash avgt 50 174,632 ? 5,581 ms/op HashBenchmark.hash:?gc.alloc.rate avgt 50 165,848 ? 4,574 MB/sec HashBenchmark.hash:?gc.alloc.rate.norm avgt 50 31773902,052 ? 24870,662 B/op HashBenchmark.hash:?gc.churn.G1_Eden_Space avgt 50 166,357 ? 9,399 MB/sec HashBenchmark.hash:?gc.churn.G1_Eden_Space.norm avgt 50 31891221,589 ? 1725370,956 B/op HashBenchmark.hash:?gc.churn.G1_Old_Gen avgt 50 5,553 ? 0,327 MB/sec HashBenchmark.hash:?gc.churn.G1_Old_Gen.norm avgt 50 1064354,875 ? 60435,285 B/op HashBenchmark.hash:?gc.churn.G1_Survivor_Space avgt 50 0,034 ? 0,032 MB/sec HashBenchmark.hash:?gc.churn.G1_Survivor_Space.norm avgt 50 6754,365 ? 6398,008 B/op HashBenchmark.hash:?gc.count avgt 50 144,000 counts HashBenchmark.hash:?gc.time avgt 50 249,000 ms patched Benchmark Mode Cnt Score Error Units HashBenchmark.hash avgt 50 192,068 ? 8,236 ms/op HashBenchmark.hash:?gc.alloc.rate avgt 50 568,790 ? 22,912 MB/sec HashBenchmark.hash:?gc.alloc.rate.norm avgt 50 119441637,758 ? 28476,724 B/op HashBenchmark.hash:?gc.churn.G1_Eden_Space avgt 50 568,892 ? 26,936 MB/sec HashBenchmark.hash:?gc.churn.G1_Eden_Space.norm avgt 50 119444622,067 ? 2746230,425 B/op HashBenchmark.hash:?gc.churn.G1_Old_Gen avgt 50 4,964 ? 0,238 MB/sec HashBenchmark.hash:?gc.churn.G1_Old_Gen.norm avgt 50 1042019,563 ? 23557,187 B/op HashBenchmark.hash:?gc.churn.G1_Survivor_Space avgt 50 0,043 ? 0,033 MB/sec HashBenchmark.hash:?gc.churn.G1_Survivor_Space.norm avgt 50 9130,656 ? 7040,858 B/op HashBenchmark.hash:?gc.count avgt 50 492,000 counts HashBenchmark.hash:?gc.time avgt 50 738,000 ms I'll close this PR then. ------------- PR: https://git.openjdk.org/jdk/pull/9596 From duke at openjdk.org Mon Jul 25 08:56:11 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 25 Jul 2022 08:56:11 GMT Subject: Withdrawn: 8290824: Use InputStream.readAllBytes() instead of explicit loops In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? wrote: > We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9596 From shade at openjdk.org Mon Jul 25 10:04:01 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Jul 2022 10:04:01 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions Thanks! Any other reviews, please? ------------- PR: https://git.openjdk.org/jdk/pull/9533 From sergei.tsypanov at yandex.ru Mon Jul 25 10:38:20 2022 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Mon, 25 Jul 2022 12:38:20 +0200 Subject: Redundant BufferedInputStream in FileURLConnection Message-ID: <180261658744887@mail.yandex.ru> An HTML attachment was scrubbed... URL: From plevart at openjdk.org Mon Jul 25 13:08:03 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 25 Jul 2022 13:08:03 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions Just a note that the failing test is not about checking that cache is cleared after plain System.gc(), but about checking that cache is NOT cleared after System.gc() when there was no real memory pressure. The cache uses SoftReference(s). So it appears that some gc(s) do clear SoftReference(s) on System.gc(). Does WhiteBox GC util have a means to provoke gc without SoftReference processing? ------------- PR: https://git.openjdk.org/jdk/pull/9533 From shade at openjdk.org Mon Jul 25 13:17:03 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Jul 2022 13:17:03 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 13:04:46 GMT, Peter Levart wrote: > Just a note that the failing test is not about checking that cache is cleared after plain System.gc(), but about checking that cache is NOT cleared after System.gc() when there was no real memory pressure. The cache uses SoftReference(s). So it appears that some gc(s) do clear SoftReference(s) on System.gc(). Does WhiteBox GC util have a means to provoke gc without SoftReference processing? As I said above, there seem to be no such method. It would require hacking into each GC policy to prevent weakrefs clearing. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From plevart at openjdk.org Mon Jul 25 13:27:56 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 25 Jul 2022 13:27:56 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions ...my above claims might appear strange to some reader as the test clearly wraps a cached ObjectStreamClass instance with a WeakReference and then checks whether this WeakReference is cleared or not. So an explanation is in order... The internal cache uses SoftReference(s). Since the cache is encapsulated, the test does not check it directly but uses a trick. It wraps the cached instance with a WeakReference. Since the instance is already wrapped with SoftReference in the cache and there is no strong reference holding it, the instance can be considered Softly Reachable. And we know that GC must clear all XxxReference(s) regardless of their type pointing to the same referent atomically. By detecting in the test that a WeakReference is cleared, we assume that the internal SoftReference is cleared too. If this was not the case, GC could be considdered to have a bug and is not by the spec. So what we are observing now is either System.gc() clearing SoftReference or a GC bug. I don't bel ive it is a GC bug though. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From plevart at openjdk.org Mon Jul 25 13:36:03 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 25 Jul 2022 13:36:03 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 13:13:30 GMT, Aleksey Shipilev wrote: > > Just a note that the failing test is not about checking that cache is cleared after plain System.gc(), but about checking that cache is NOT cleared after System.gc() when there was no real memory pressure. The cache uses SoftReference(s). So it appears that some gc(s) do clear SoftReference(s) on System.gc(). Does WhiteBox GC util have a means to provoke gc without SoftReference processing? > > As I said above, there seem to be no such method. It would require hacking into each GC policy to prevent weakrefs clearing. Just to be on the same page... It is not about weakref clearing but about softref clearing. The test assumes that System.gc() would not clear a softref on the 1st call at least. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From duke at openjdk.org Mon Jul 25 13:39:01 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Mon, 25 Jul 2022 13:39:01 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: On Sun, 24 Jul 2022 15:45:17 GMT, Raffaello Giulietti wrote: >> I didn't test this variant, will do tomorrow when also reviewing the tests themselves. > > The correct variant below passes the tests. > > > // For binary16 subnormals, beside forcing exp to -15, > // retain the difference expdelta = E_min - exp. > // This is the excess shift value, in addition to 13, to be used > // in the computations below. > // Further the (hidden) msb with value 1 in f must be involved as well. > int expdelta = 0; > int msb = 0x0000_0000; > if (exp < -14) { > expdelta = -14 - exp; > exp = -15; > msb = 0x0080_0000; > } > int f_signif_bits = doppel & 0x007f_ffff | msb; > > // Significand bits as if using rounding to zero (truncation). > short signif_bits = (short)(f_signif_bits >> (13 + expdelta)); > > // For round to nearest even, determining whether or > // not to round up (in magnitude) is a function of the > // least significant bit (LSB), the next bit position > // (the round position), and the sticky bit (whether > // there are any nonzero bits in the exact result to > // the right of the round digit). An increment occurs > // in three cases: > // > // LSB Round Sticky > // 0 1 1 > // 1 1 0 > // 1 1 1 > // See "Computer Arithmetic Algorithms," Koren, Table 4.9 > > int lsb = f_signif_bits & (1 << 13 + expdelta); > int round = f_signif_bits & (1 << 12 + expdelta); > int sticky = f_signif_bits & ((1 << 12 + expdelta) - 1); > > if (round != 0 && ((lsb | sticky) != 0 )) { > signif_bits++; > } > > // No bits set in significand beyond the *first* exponent > // bit, not just the sigificand; quantity is added to the > // exponent to implement a carry out from rounding the > // significand. > assert (0xf800 & signif_bits) == 0x0; > > return (short)(sign_bit | ( ((exp + 15) << 10) + signif_bits ) ); Test classes look good. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From plevart at openjdk.org Mon Jul 25 13:49:57 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 25 Jul 2022 13:49:57 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions Contemplating how this test could be fixed without using WhiteBox gc testing... The test could wrap the cached instance with a WeakReference as it does now (ref1) and then have a second WeakReference that would wrap an instance of "new Object()", (ref2)... Then the test coul gradually allocate more and more heap in a loop, checking both WeakReference(s) as it goes. When ref2 is cleared but ref1 is not, the test would succeed. Any other outcome ( such as both refs being cleared at the same point) could be considered a failure. This would assume that GCs would 1st clear XxxReferences of weakly reachable referents and only much later those of softly reachable. I hope this property is universal to all GCs although it is not guaranteed by the spec. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From plevart at openjdk.org Mon Jul 25 14:54:58 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 25 Jul 2022 14:54:58 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions ...I can take this over, unless you want to do it, Aleksey? ------------- PR: https://git.openjdk.org/jdk/pull/9533 From naoto at openjdk.org Mon Jul 25 16:10:02 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 25 Jul 2022 16:10:02 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v2] In-Reply-To: References: Message-ID: > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed unnecessary `contains()` check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/1f1526bc..a869efaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=00-01 Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From naoto.sato at oracle.com Mon Jul 25 16:40:36 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 25 Jul 2022 09:40:36 -0700 Subject: TimeZone implementations questions In-Reply-To: References: Message-ID: Hi Andrey, Not the original author of the code but I guess they are left over from the old refactorings. On 7/23/22 11:04 AM, Andrey Turbanov wrote: > Hello. > While I was browsing the source of java.util.TimeZone found a couple > of confusing things: > > 1. Static methods 'getAvailableIDs' and 'getAvailableIDs' are marked > as synchronized. > But all they do - just delegate call to sun.util.calendar.ZoneInfoFile methods: > > public static synchronized String[] getAvailableIDs(int rawOffset) { > return ZoneInfo.getAvailableIDs(rawOffset); > } > > public static synchronized String[] getAvailableIDs() { > return ZoneInfo.getAvailableIDs(); > } > It seems 'synchronized's are unnecessary there. Am I right? There's a piece of very old code in this JIRA issue: https://bugs.openjdk.org/browse/JDK-4250355 where getAvailableIDs() was doing some logic within the method, but since then the code has been refactored to simply call `ZoneInfo`. So I think you are correct, but I am hesitant to remove it as this is a sensitive code for the JDK startup. > > 2. There is confusing NPE catch in a method 'java.util.TimeZone#setDefaultZone' > > try { > zoneID = getSystemTimeZoneID(javaHome); > if (zoneID == null) { > zoneID = GMT_ID; > } > } catch (NullPointerException e) { > zoneID = GMT_ID; > } > > Only possible source of NPE here is the method 'getSystemTimeZoneID'. > I checked native sources and it seems there is no NPE thrown. > Can we remove the catch (NullPointerException) then? It could be that it was meant to avoid the case where `java.Home` could be null, before the fix to StaticProperty change. So I think this one can be removed. Naoto From shade at openjdk.org Mon Jul 25 16:44:47 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Jul 2022 16:44:47 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 14:51:32 GMT, Peter Levart wrote: > ...I can take this over, unless you want to do it, Aleksey? I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? ------------- PR: https://git.openjdk.org/jdk/pull/9533 From naoto at openjdk.org Mon Jul 25 17:05:38 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 25 Jul 2022 17:05:38 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung wrote: > open l10n msg drop > All tests passed. Changes requested by naoto (Reviewer). src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP These currency symbols (`XXX=XXX`) are all in the base `CurrencyNames.properties`, so not needed in each localized resources (They are in the base in order to avoid throwing exceptions). Also, the localized files should not reside in `java.base`, but to be merged with the ones in `jdk.localedata` module These comments hold for all localized resources (de, ja, zh-CN). For furure reference, it may be good to add some comment in the base `CurrencyNames.properties` about this. src/java.base/share/data/currency/CurrencyData_de.properties line 1: > 1: # `CurrencyData.properties` is not a localizable resource bundle, but a properties file containing currency data. No need to add these localized resources. ------------- PR: https://git.openjdk.org/jdk19/pull/154 From rriggs at openjdk.org Mon Jul 25 18:47:29 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 25 Jul 2022 18:47:29 GMT Subject: RFR: 8290972: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java Message-ID: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java The earlier fix is not sufficient for higher tier tests possibly related to -Xcomp. ------------- Commit messages: - 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fails Changes: https://git.openjdk.org/jdk/pull/9630/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9630&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290972 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9630.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9630/head:pull/9630 PR: https://git.openjdk.org/jdk/pull/9630 From asemenyuk at openjdk.org Mon Jul 25 18:52:15 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 25 Jul 2022 18:52:15 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com> On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung wrote: > open l10n msg drop > All tests passed. Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop? ------------- PR: https://git.openjdk.org/jdk19/pull/154 From iris at openjdk.org Mon Jul 25 18:54:03 2022 From: iris at openjdk.org (Iris Clark) Date: Mon, 25 Jul 2022 18:54:03 GMT Subject: RFR: 8290972: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 17:09:10 GMT, Roger Riggs wrote: > ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java > The earlier fix is not sufficient for higher tier tests possibly related to -Xcomp. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9630 From darcy at openjdk.org Mon Jul 25 20:11:06 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 25 Jul 2022 20:11:06 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 16:38:34 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement review feedback. > > src/java.base/share/classes/java/lang/Float.java line 980: > >> 978: >> 979: /** >> 980: * {@return the {@code float} value closest to the numerical value > > `{@return` seems to be out of place and missing a closing `}` The closing brace is on line 982, "... {@code short}}" (Using the in-line form of the @return tag allows an explicit @return tag to be skipped by reusing the initial sentence. The generated javadoc is as intended.) ------------- PR: https://git.openjdk.org/jdk/pull/9422 From duke at openjdk.org Mon Jul 25 20:23:13 2022 From: duke at openjdk.org (duke) Date: Mon, 25 Jul 2022 20:23:13 GMT Subject: Withdrawn: 8284638: store skip buffers in InputStream Object In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 21:19:36 GMT, XenoAmess wrote: > @jmehrens what about this then? > I think it safe now(actually this mechanism is learned from Reader) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/5872 From darcy at openjdk.org Mon Jul 25 21:09:03 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 25 Jul 2022 21:09:03 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: <6hCxhFWI3C8oeu3cU5Ujb788yeyHijoW-rpUBAVfFhs=.e2f608aa-c167-44c3-8e1d-61ad58b105b1@github.com> On Sat, 23 Jul 2022 18:00:12 GMT, Raffaello Giulietti wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement review feedback. > > src/java.base/share/classes/java/lang/Float.java line 1112: > >> 1110: if (abs_f >= (65504.0f + 16.0f) ) { >> 1111: return (short)(sign_bit | 0x7c00); // Positive or negative infinity >> 1112: } else { > > The ` else {` with the corresponding closing `}` could be removed and the code in this branch could be un-indented. This would make the code visually less "jagged". Good suggestion; the reduced indenting in this case also allows some of the comment blocks to take up fewer lines. ------------- PR: https://git.openjdk.org/jdk/pull/9422 From ecaspole at openjdk.org Mon Jul 25 21:13:48 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Mon, 25 Jul 2022 21:13:48 GMT Subject: RFR: 8290894: Reduce runtime of vm.lang microbenchmarks [v2] In-Reply-To: References: Message-ID: > Adds fork and iterations controls. This reduces the runtime from 4h26m to about 21m and still seems stable enough for weekly testing. Eric Caspole 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 'master' into JDK-8290894 - 8290894: Reduce runtime of vm.lang microbenchmarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9619/files - new: https://git.openjdk.org/jdk/pull/9619/files/373da451..08449dd5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9619&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9619&range=00-01 Stats: 2646 lines in 96 files changed: 1352 ins; 1038 del; 256 mod Patch: https://git.openjdk.org/jdk/pull/9619.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9619/head:pull/9619 PR: https://git.openjdk.org/jdk/pull/9619 From darcy at openjdk.org Mon Jul 25 21:16:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 25 Jul 2022 21:16:20 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v7] In-Reply-To: References: Message-ID: > Initial implementation. Joe Darcy 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 23 additional commits since the last revision: - Implement review feedback. - Merge branch 'master' into JDK-8289551 - Implement review feedback. - Method rename. - Merge branch 'master' into JDK-8289551 - Respond to review feedback; improve tests. - Add NaN test. - Preserve NaN sign bit. - Respond to review feedback. - Correct carry-out bug; add full binade test. - ... and 13 more: https://git.openjdk.org/jdk/compare/a46ba547...6afaafbb ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/d54f9c94..6afaafbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=05-06 Stats: 2760 lines in 105 files changed: 1365 ins; 1054 del; 341 mod Patch: https://git.openjdk.org/jdk/pull/9422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422 PR: https://git.openjdk.org/jdk/pull/9422 From mcimadamore at openjdk.org Mon Jul 25 21:37:21 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 25 Jul 2022 21:37:21 GMT Subject: [jdk19] Integrated: 8290455: jck test api/java_lang/foreign/VaList/Empty.html fails on some platforms In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 12:06:37 GMT, Maurizio Cimadamore wrote: > The javadoc for `Linker` states that some operations throw `UnsupportedOperationException` when called on an unsupported platform. These operations are: > > * `Linker::nativeLinker` > * `VaList::empty` > * `VaList::make` > * `VaList::ofAddress` > > While the code throws an UOE as required, since the exception is thrown in a static initialized, it gets wrapped in an `ExceptionInInitializerError`. > > The solution is to set the `CABI` value to `null` if the platform is unknown. Then, when clients call the `CABI.current()` method, we can throw at that point, which will result in the behavior requested by the API spec. This pull request has now been integrated. Changeset: 8c9d5ad4 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk19/commit/8c9d5ad4f89e7af18f4ee3b8f236083491d7f6fa Stats: 89 lines in 3 files changed: 67 ins; 7 del; 15 mod 8290455: jck test api/java_lang/foreign/VaList/Empty.html fails on some platforms Reviewed-by: jvernee, mbaesken ------------- PR: https://git.openjdk.org/jdk19/pull/150 From asemenyuk at openjdk.org Mon Jul 25 21:55:16 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 25 Jul 2022 21:55:16 GMT Subject: Integrated: 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file" In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 20:21:57 GMT, Alexey Semenyuk wrote: > 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file" This pull request has now been integrated. Changeset: 7c3cfd13 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/7c3cfd13e3d67c185d15abb1c935853c856e8a42 Stats: 52 lines in 1 file changed: 45 ins; 0 del; 7 mod 8290557: tools/jpackage/share/AddLauncherTest.java#id1 failed with "ERROR: Failed: Check icon file" Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/9618 From erikj at openjdk.org Mon Jul 25 22:35:01 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 25 Jul 2022 22:35:01 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/9599 From duke at openjdk.org Mon Jul 25 22:38:08 2022 From: duke at openjdk.org (Bill Huang) Date: Mon, 25 Jul 2022 22:38:08 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions Message-ID: Provided coverage for XPath node set functions. Functions include: - id() - last() - position() - count() - local-name() - namespace-uri() - name() ------------- Commit messages: - Removed unwanted whitespaces. - Updated copyright header. - Created XPathExpFnTest.java for XPath functions and implemented test cases for node set functions. Changes: https://git.openjdk.org/jdk/pull/9633/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289948 Stats: 215 lines in 2 files changed: 189 ins; 10 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9633/head:pull/9633 PR: https://git.openjdk.org/jdk/pull/9633 From joehw at openjdk.org Tue Jul 26 01:36:47 2022 From: joehw at openjdk.org (Joe Wang) Date: Tue, 26 Jul 2022 01:36:47 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 16:10:02 GMT, Naoto Sato wrote: >> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Removed unnecessary `contains()` check Looks good to me. Some minor comments below. src/java.base/share/classes/java/util/Locale.java line 236: > 234: * particular Unicode locale attributes or key/type pairs. > 235: * > 236: *

        Transformed Content extension

        Both the full name "Transformed Content extension" and the abbreviated forms "T Extension" are used in this document. I see Unicode and the RFC referred to it as "T Extension", " 't' Extension", and "Extension T". If we describe the extension as "T Extension", maybe we can make it clear in the title, e.g.: Transformed Content (T) Extension could thus in the doc thereafter use "T Extension". The existing methods look like used full extension name, but for T Extension, the short form, e.g. getTExtensionFields also matches its javadoc ("Returns the map of fields in the T extension"). Your call. src/java.base/share/classes/java/util/Locale.java line 265: > 263: * field separator (one alpha + one digit), followed by one or more subtags of the length 3 to 8, > 264: * each delimited by a hyphen. > 265: *

        The transformed content information {@code source} language tag and {@code fields} are returned "transformed content information" seems not needed as "The {@code source} language tag and {@code fields}" are known from the previous paragraph. src/java.base/share/classes/sun/util/locale/TransformedContentExtension.java line 40: > 38: public final class TransformedContentExtension extends Extension { > 39: > 40: public static final char SINGLETON = 't'; "singleton" as in "The singleton identifier" in the doc, seems to mean the key consists of a single character. But it can be confused with the Singleton pattern. T_EXTENSION_KEY (as methods such as isTransformedContentxxx expect a key) or Locale.TRANSFORMED_CONTENT_EXTENSION might be better. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From duke at openjdk.org Tue Jul 26 02:08:47 2022 From: duke at openjdk.org (Bill Huang) Date: Tue, 26 Jul 2022 02:08:47 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v2] In-Reply-To: References: Message-ID: <2-EDv0VxbbwZ_OsZtVehZFAbY5NuCM4TBvsC05Ksez8=.5f1f907c-5b5a-44d0-a318-079b80edb791@github.com> > Provided coverage for XPath node set functions. Functions include: > - id() > - last() > - position() > - count() > - local-name() > - namespace-uri() > - name() Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Fixed attibute validation error by renaming attibutes to be starting with non-digit charaters. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9633/files - new: https://git.openjdk.org/jdk/pull/9633/files/3635dbaf..5fe3e92f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=00-01 Stats: 35 lines in 2 files changed: 9 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/9633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9633/head:pull/9633 PR: https://git.openjdk.org/jdk/pull/9633 From darcy at openjdk.org Tue Jul 26 02:10:54 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 26 Jul 2022 02:10:54 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: Message-ID: > Initial implementation. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Implement additional review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/6afaafbb..c4ded352 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422 PR: https://git.openjdk.org/jdk/pull/9422 From duke at openjdk.org Tue Jul 26 02:15:55 2022 From: duke at openjdk.org (Bill Huang) Date: Tue, 26 Jul 2022 02:15:55 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v3] In-Reply-To: References: Message-ID: <-Fcn_9F1tZ_N4f83s8Tmskv5ikQkRouF4hVHGZSrmds=.30dce6d7-d603-4961-acb0-e864de84411e@github.com> > Provided coverage for XPath node set functions. Functions include: > - id() > - last() > - position() > - count() > - local-name() > - namespace-uri() > - name() Bill Huang 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: Fixed validation error by renaming attributes to be starting with non-digit charaters. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9633/files - new: https://git.openjdk.org/jdk/pull/9633/files/5fe3e92f..2029ce13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9633/head:pull/9633 PR: https://git.openjdk.org/jdk/pull/9633 From jpai at openjdk.org Tue Jul 26 02:27:56 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 26 Jul 2022 02:27:56 GMT Subject: RFR: 8290972: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 17:09:10 GMT, Roger Riggs wrote: > ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java > The earlier fix is not sufficient for higher tier tests possibly related to -Xcomp. Hello Roger, the change looks fine to me. There's a mention that this issue was noticed once on a setup where `-Xcomp` wasn't used by `-Xcheck:jni` was used. Would problem listing this only in this `ProblemList-Xcomp.txt` file, address that one too? ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9630 From darcy at openjdk.org Tue Jul 26 05:27:26 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 26 Jul 2022 05:27:26 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v9] In-Reply-To: References: Message-ID: <9W3k5Ye537Kef1fIKhf0PJN2jr8tgMMl3KldpnR7w8k=.73cb82a6-9c55-495a-bc8d-337814034e0b@github.com> > Initial implementation. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Adopt alternative implementaiton from review. - Refactor equivalent() implementation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9422/files - new: https://git.openjdk.org/jdk/pull/9422/files/c4ded352..f012d1d0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9422&range=07-08 Stats: 54 lines in 2 files changed: 0 ins; 18 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/9422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9422/head:pull/9422 PR: https://git.openjdk.org/jdk/pull/9422 From smarks at openjdk.org Tue Jul 26 05:29:57 2022 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 26 Jul 2022 05:29:57 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian wrote: >> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. >> >> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. >> >> Details of note: >> 1. Some operations need to change the state values (the update() method is probably the most interesting). >> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. >> >> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. >> >> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). >> >> Thanks. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > remove some more tabs Hans Boehm wrote: > I also have concerns about the use of fullFence here. I believe it should be the case that reachabilityFence guarantees visibility of memory operations program-ordered before the reachabilityFence(p) to the Cleaner associated with p. Mutator-collector synchronization should normally ensure that. On rereading, it also appears to me that the current reachabilityFence() documentation does not make that as clear as it should. > It appears to me that this is addressing an instance of the problem for which I suggested a more general, though also not completely elegant, solution in https://docs.google.com/document/d/1yMC4VzZobMQTrVAraMy7xBdWPCJ0p7G5r_43yaqsj-s/edit?usp=sharing . Hi Hans, thanks for looking at this. In the prior discussions on reachabilityFence and premature finalization, I don't recall seeing any mention of memory model issues. To my mind the discussions here are the first mention of them. (Of course it's possible I could have missed something.) The memory model is quite subtle and it's difficult to be sure of anything. However, as time goes on we've become more confident that there _IS_ an issue here with the memory model that needs to be addressed. Then there is a the question of what to do about it. One possibility is to add some memory ordering semantics into reachabilityFence(p), as you suggest. As convenient as it might seem, it's not obvious to me that we want reachability fused with memory order. At least we should discuss them separately before deciding what to do. This PR seems to be on a long journey :-) so let me describe some of the background and where I think this ought to go. First, like most PRs, this started off as an effort to make some code changes. In this case it's part of Brent's (@bchristi-git) effort to convert finalizers in the JDK to Cleaners. This is related to discovering coding patterns for how to do this effectively. For example, the entire object's state is available to the finalizer. But in order to convert this to a Cleaner, the state available to the cleaning action needs to be refactored into a separate object from the "outer" object. The `EnumCtx` nested class serves this role here. Second, we're trying to address the reachability issues. You (Hans) have been writing and speaking about this for some time, mostly in the context of finalization. We in the JDK group haven't prioritized fixing this issue with respect to finalization (since it's old and deprecated and nobody should be using it, yeah right). Now that we're converting things to use Cleaner, which has the same issues, we're forced to confront them. Our working position is that there needs to be a reachabilityFence within a try/finally block in the "right" places; determining the definition of "right" is one of the goals here. The third issue is memory ordering. For finalization-based objects, the JLS specifies a happens-before edge between the constructor and the finalizer. (I think this works for objects whose finalizable state is fully initialized in the constructor. But it doesn't work for objects, like this one, whose finalizable state is mutable throughout the lifetime of the object.) There is nothing specified for memory ordering edges for Cleaner or java.lang.ref references at all that I can see. Given the lack of such specifications, we're faced with using the right low-level memory ordering mechanisms to get the memory order we require. We're using VarHandle::fullFence as kind of a placeholder for this. (We've also considered empty synchronized blocks, writes/reads to "junk" variables created expressly for this purpose, and other VarHandle fence operations, but none seem obviously better. I'm sure there are other alternatives we haven't considered.) I'd welcome discussion of the proper alternativ e. The fourth issue is, do we really want every programmer who uses Cleaner to have to figure out all this reachabilityFence and VarHandle fence stuff? Of course not. It would be nice to have some higher-level construct (such as a language change like the "Reachability Revisited" proposal), or possibly to create some library APIs to facilitate this. At a minimum, I think we need to adjust various specifications like Cleaner and java.lang.ref to address memory ordering issues. There is certainly more that needs to be done though. The difficulty with trying to come up with language changes or library APIs is that I don't think we understand this problem well enough to define what those mechanisms are actually supposed to do. So before we get to that point, I think we should see attempt to write down a correct solution using the existing reachability and memory ordering mechanisms. That's what Brent has done here. We should review and iterate on this and identify the places where the specs need to change, and arrive at a point where the we believe the code, even if ugly and inconvenient, is correct under that spec. Maybe at that point we can contemplate a higher-level approach such as a language mechanism or a library API (or both), but I don't think we're quite there yet. Or maybe some alternative path forward might emerge. ------------- PR: https://git.openjdk.org/jdk/pull/8311 From shade at openjdk.org Tue Jul 26 07:22:45 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Jul 2022 07:22:45 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s Is @AlanBateman on vacation? Can I have someone review the NIO test change? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9554 From asotona at openjdk.org Tue Jul 26 08:32:00 2022 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 26 Jul 2022 08:32:00 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v14] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 27 Jun 2022 09:25:58 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le ping to keep the PR open ------------- PR: https://git.openjdk.org/jdk/pull/8599 From asotona at openjdk.org Tue Jul 26 08:32:46 2022 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 26 Jul 2022 08:32:46 GMT Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v3] In-Reply-To: References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com> Message-ID: On Mon, 20 Jun 2022 07:45:46 GMT, Adam Sotona wrote: >> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. >> >> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. >> >> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name. >> Class internal name validation and extended ClassDescTest are also parts of this patch. >> >> CSR is linked with the issue. >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated ClassDesc::ofInternal javadoc with JVMS link and fixed indentation ping to keep the PR open ------------- PR: https://git.openjdk.org/jdk/pull/9201 From rpressler at openjdk.org Tue Jul 26 09:25:44 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Tue, 26 Jul 2022 09:25:44 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: <6rlQ25jHrT5G8ZrHqRarV1QF9rd9saZ82wCVKjVYQLU=.ffb206af-0100-4828-8966-fb74db4ccb98@github.com> On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s He is. He'll be back next week, but maybe someone else wants to review this. ------------- PR: https://git.openjdk.org/jdk/pull/9554 From mcimadamore at openjdk.org Tue Jul 26 09:29:04 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 26 Jul 2022 09:29:04 GMT Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v3] In-Reply-To: References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com> Message-ID: On Mon, 20 Jun 2022 07:45:46 GMT, Adam Sotona wrote: >> The symbolic constants API (`java.lang.constant`) was designed, in part, to provide bytecode parsing and generation APIs with a validated, common, symbolic form for constants in Java class files. >> >> There is an easy way to create a `ClassDesc` from a binary name (`ClassDesc::of`) or a field descriptor (`ClassDesc::ofDescriptor`) but not from an internal name. But, the internal name is common in low-level bytecode-manipulation code. >> >> This patch adds `ClassDesc::ofInternalName` static factory method that creates a `ClassDesc` from class internal name. >> Class internal name validation and extended ClassDescTest are also parts of this patch. >> >> CSR is linked with the issue. >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated ClassDesc::ofInternal javadoc with JVMS link and fixed indentation src/java.base/share/classes/java/lang/constant/ClassDesc.java line 85: > 83: * given the name of the class or interface in internal form, > 84: * such as {@code "java/lang/String"}. > 85: * (To create a descriptor for an array type, either use {@link #ofDescriptor(String)} It feels like this section could be expanded a bit (and parenthesis removed). E.g. as you point out in the comment, this method only supports reference types, so we should state so clearly. And then present alternatives (like you do now). test/jdk/java/lang/constant/ClassDescTest.java line 268: > 266: } > 267: > 268: List badInternalNames = List.of("I;", "[]", is `[]` a good test for arrays? Wouldn't something more realistic like `[Ljava/lang/String` be better? I note that `[]` is also used in another test. Problem with testing `[]` is that if the checking logic has a bug, or a regression is introduced so that it only detects `]` instead of `[` the test would not detect that (but I guess that's a remote possibility). ------------- PR: https://git.openjdk.org/jdk/pull/9201 From mcimadamore at openjdk.org Tue Jul 26 09:54:38 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 26 Jul 2022 09:54:38 GMT Subject: [jdk19] RFR: 8291006: java/foreign/TestUnsupportedPlatform fails after JDK-8290455 Message-ID: This patch removes java/foreign/TestUnsupportedPlatform, which has been superseded by TestUnsupportedLinker, and is no longer required. This old test relies on unspecified behavior and should be removed. ------------- Commit messages: - Drop TestUnsupportedPlatform test Changes: https://git.openjdk.org/jdk19/pull/155/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291006 Stats: 45 lines in 1 file changed: 0 ins; 45 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/155.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/155/head:pull/155 PR: https://git.openjdk.org/jdk19/pull/155 From jpai at openjdk.org Tue Jul 26 10:10:05 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 26 Jul 2022 10:10:05 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s test/jdk/java/nio/channels/vthread/BlockingChannelOps.java line 36: > 34: * @test id=useDirectRegister > 35: * @bug 8284161 > 36: * @summary Basic tests of virtual threads doing blocking I/O with NIO channels Hello Aleksey, I see that previously the `@bug` and `@summary` was only there on one test definition. So maybe remove this duplicated `@bug` and `@summary` from this new test definition? Other than that, this test change looks OK to me. ------------- PR: https://git.openjdk.org/jdk/pull/9554 From jpai at openjdk.org Tue Jul 26 10:18:49 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 26 Jul 2022 10:18:49 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 10:06:31 GMT, Jaikiran Pai wrote: >> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. >> >> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: >> >> >> # release before >> real 4m41.424s >> user 24m18.064s >> sys 1m16.440s >> >> # release after >> real 2m47.769s ; -40% >> user 23m44.622s >> sys 1m15.240s >> >> >> # fastdebug before >> real 5m38.078s >> user 67m23.516s >> sys 1m56.446s >> >> # fastdebug after >> real 4m9.249s ; -26% >> user 67m21.940s >> sys 1m57.625s > > test/jdk/java/nio/channels/vthread/BlockingChannelOps.java line 36: > >> 34: * @test id=useDirectRegister >> 35: * @bug 8284161 >> 36: * @summary Basic tests of virtual threads doing blocking I/O with NIO channels > > Hello Aleksey, I see that previously the `@bug` and `@summary` was only there on one test definition. So maybe remove this duplicated `@bug` and `@summary` from this new test definition? > Other than that, this test change looks OK to me. On a related note - I had a brief look at the jtreg docs including the FAQ https://openjdk.org/jtreg/faq.html and I don't see any mention about how it treats multiple test definitions in a single source file, when it comes to running them concurrently. But I believe you have more experience with it and have already tested the difference in parallelism, so I think what you suggest here is fine. ------------- PR: https://git.openjdk.org/jdk/pull/9554 From duke at openjdk.org Tue Jul 26 10:49:14 2022 From: duke at openjdk.org (Raffaello Giulietti) Date: Tue, 26 Jul 2022 10:49:14 GMT Subject: RFR: JDK-8289551: Conversions between bit representations of half precision values and floats [v9] In-Reply-To: <9W3k5Ye537Kef1fIKhf0PJN2jr8tgMMl3KldpnR7w8k=.73cb82a6-9c55-495a-bc8d-337814034e0b@github.com> References: <9W3k5Ye537Kef1fIKhf0PJN2jr8tgMMl3KldpnR7w8k=.73cb82a6-9c55-495a-bc8d-337814034e0b@github.com> Message-ID: On Tue, 26 Jul 2022 05:27:26 GMT, Joe Darcy wrote: >> Initial implementation. > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Adopt alternative implementaiton from review. > - Refactor equivalent() implementation. LGTM ------------- PR: https://git.openjdk.org/jdk/pull/9422 From rriggs at openjdk.org Tue Jul 26 11:57:23 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Jul 2022 11:57:23 GMT Subject: RFR: 8290972: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 02:24:19 GMT, Jaikiran Pai wrote: > Hello Roger, the change looks fine to me. There's a mention that this issue was noticed once on a setup where `-Xcomp` wasn't used but `-Xcheck:jni` was used. Would problem listing this only in this `ProblemList-Xcomp.txt` file, address that one too? Though the problem is unlikely to be related to -Xcheck:jni, the bulk of the failures seem to be -Xcomp related, this will cut down on the noise in the higher tiers. ------------- PR: https://git.openjdk.org/jdk/pull/9630 From rriggs at openjdk.org Tue Jul 26 11:57:24 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Jul 2022 11:57:24 GMT Subject: Integrated: 8290972: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 17:09:10 GMT, Roger Riggs wrote: > ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java > The earlier fix is not sufficient for higher tier tests possibly related to -Xcomp. This pull request has now been integrated. Changeset: 28bbdc5e Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/28bbdc5ebb8e3f08b47d3c6e7e4e1f41b0408bee Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8290972: ProblemList java/lang/ProcessBuilder/PipelineLeaksFD.java Reviewed-by: iris, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9630 From shade at openjdk.org Tue Jul 26 12:10:10 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Jul 2022 12:10:10 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 10:16:31 GMT, Jaikiran Pai wrote: >> test/jdk/java/nio/channels/vthread/BlockingChannelOps.java line 36: >> >>> 34: * @test id=useDirectRegister >>> 35: * @bug 8284161 >>> 36: * @summary Basic tests of virtual threads doing blocking I/O with NIO channels >> >> Hello Aleksey, I see that previously the `@bug` and `@summary` was only there on one test definition. So maybe remove this duplicated `@bug` and `@summary` from this new test definition? >> Other than that, this test change looks OK to me. > > On a related note - I had a brief look at the jtreg docs including the FAQ https://openjdk.org/jtreg/faq.html and I don't see any mention about how it treats multiple test definitions in a single source file, when it comes to running them concurrently. But I believe you have more experience with it and have already tested the difference in parallelism, so I think what you suggest here is fine. Yes, this is a usual thing to replicate the test sections. It is also a usual practice to copy-paste the entirety of run definition/config. ------------- PR: https://git.openjdk.org/jdk/pull/9554 From jpai at openjdk.org Tue Jul 26 13:00:38 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 26 Jul 2022 13:00:38 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: <6AktxwcOfu3Tg7aKa5d1fVa5aQJHqL7TrVzrmbJA4QU=.6977647f-a273-4da4-9926-88e4b916cc25@github.com> On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9554 From jvernee at openjdk.org Tue Jul 26 13:02:36 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:02:36 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 18:32:56 GMT, Thomas Stuefe wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes > > test/lib/native/testlib_threads.h line 50: > >> 48: static void fatal(const char* message) { >> 49: perror(message); >> 50: exit(-1); > > Won't work as intended for Windows APIs. I would print the result of `GetLastError()` instead. > > Alternatively I am fine fine with just omitting the error code, because I think the old tests did not handle errors either. Or did we catch std::thread exceptions somewhere? The intent was to exit the test with a non-zero exit code, in order to avoid any accidental false positives. I could return the error code from `GetLastError` and from the respective pthread apis as an exit code instead. Is that what you mean? ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 13:06:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:06:50 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 18:37:02 GMT, Thomas Stuefe wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes > > test/lib/native/testlib_threads.h line 61: > >> 59: helper->proc(helper->context); >> 60: return 0; >> 61: } > > I'm curious, does this only exist because of the DWORD vs void* return value size of the native thread functions? I wondered why you don't just pass the test procedure to the thread start API directly. > > About stdcall, does Oracle still build Windows 32bit? Yes, this exists as an adapter from PROCEDURE to whatever callback type the OS API expects. I tried passing the procedure to the start API as well, but the compiler complains that the types don't match. Even if I make PROCEDURE return `int`, it seems to want `DWORD` explicitly. This was taken from the old library code which uses `_beginthreadex`. That one explicitly wants to use `__stdcall`, so I just matched that. Looking again, it doesn't look like the same is required for `CreateThread` [1]. I'll remove it for clarity. [1] : https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85) ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 13:12:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:12:03 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 05:58:42 GMT, David Holmes wrote: > `run_async` is an odd name for this, especially as the fact you create then join mean it doesn't run asynchronously at all - it runs synchronously in another thread. I took the name from the CompleteableFuture API [1], although in that case a future is returned on which a user can call `get`. I can rename the function. Does `run_in_new_thread` seem good enough? > The API would be more generally useful if you split the start and the join, but that would require also exposing an opaque thread "handle" (though splitting also means you don't have to try and think of a good name for `run_in_a_new_thread-and_join_it()` - you just have `threadStart` and `threadJoin`). I can see this being useful in order to start many threads up front, and then join then all afterwards (to get them running concurrently). Though, I'd like to hold off on getting into that since the current tests don't need that functionality. The library header can be freely amended later as well. [1] : https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/concurrent/CompletableFuture.html#runAsync(java.lang.Runnable) ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 13:43:05 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:43:05 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: <2_x86cAiZlRioKzyKzv7PDMqNucasO_M79C0AW-HRb0=.8e2690d0-6e21-4787-8c04-f5eb47d01ea3@github.com> On Tue, 26 Jul 2022 12:58:09 GMT, Jorn Vernee wrote: >> test/lib/native/testlib_threads.h line 50: >> >>> 48: static void fatal(const char* message) { >>> 49: perror(message); >>> 50: exit(-1); >> >> Won't work as intended for Windows APIs. I would print the result of `GetLastError()` instead. >> >> Alternatively I am fine fine with just omitting the error code, because I think the old tests did not handle errors either. Or did we catch std::thread exceptions somewhere? > > The intent was to exit the test with a non-zero exit code, in order to avoid any accidental false positives. > > I could return the error code from `GetLastError` and from the respective pthread apis as an exit code instead. Is that what you mean? FWIW, `perror` just prints to `stderr`: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/perror-wperror?view=msvc-170 ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 13:47:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 13:47:03 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: <2_x86cAiZlRioKzyKzv7PDMqNucasO_M79C0AW-HRb0=.8e2690d0-6e21-4787-8c04-f5eb47d01ea3@github.com> References: <2_x86cAiZlRioKzyKzv7PDMqNucasO_M79C0AW-HRb0=.8e2690d0-6e21-4787-8c04-f5eb47d01ea3@github.com> Message-ID: On Tue, 26 Jul 2022 13:39:50 GMT, Jorn Vernee wrote: >> The intent was to exit the test with a non-zero exit code, in order to avoid any accidental false positives. >> >> I could return the error code from `GetLastError` and from the respective pthread apis as an exit code instead. Is that what you mean? > > FWIW, `perror` just prints to `stderr`: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/perror-wperror?view=msvc-170 Ah, I see what you mean now. The C standard library function `perror` defines this to also print a textual description of `errno`. https://en.cppreference.com/w/c/io/perror so that won't work for the Windows APIs. I think the alternative would be to use `FormatMessage` on Windows. I didn't really think that much into this. Maybe it's clearer to use `fputs` with `stderr` here. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 14:31:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 14:31:03 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v3] In-Reply-To: References: Message-ID: <45HrpHpQSNAgY1Pu-pqnKcenMRKrPNfOTorearwc2Aw=.8db27bf0-019f-4344-b7db-54899bee876e@github.com> > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9599/files - new: https://git.openjdk.org/jdk/pull/9599/files/49e60f2d..cf415f5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=01-02 Stats: 22 lines in 6 files changed: 6 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 14:34:19 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 14:34:19 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v4] In-Reply-To: References: Message-ID: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: 1 more comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9599/files - new: https://git.openjdk.org/jdk/pull/9599/files/cf415f5d..721f70bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Tue Jul 26 14:34:22 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 26 Jul 2022 14:34:22 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fixes I made some tentative changes based on the review comments: - Added some code comments. - Switch `perror` to `fputs` with `stderr` for clarity. - Use the OS API error code as exit code. - Switch the windows type of `procedure` to exactly what the `CreateThread` expects: https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ms686736(v=vs.85) - Renamed `run_async` to `run_in_new_thread`. Please take another look. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From darcy at openjdk.org Tue Jul 26 16:58:03 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 26 Jul 2022 16:58:03 GMT Subject: Integrated: JDK-8289551: Conversions between bit representations of half precision values and floats In-Reply-To: References: Message-ID: <3n5UDfwIhb_dfAq707Gfry7Ms2EHVWzZ9bm-CytC9Ng=.fa568cb4-e4dd-49fc-bec9-badc00d87502@github.com> On Fri, 8 Jul 2022 06:11:22 GMT, Joe Darcy wrote: > Initial implementation. This pull request has now been integrated. Changeset: 7318b222 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/7318b22209a83c593176ec600647a9b050362932 Stats: 703 lines in 3 files changed: 703 ins; 0 del; 0 mod 8289551: Conversions between bit representations of half precision values and floats Reviewed-by: psandoz, jrose ------------- PR: https://git.openjdk.org/jdk/pull/9422 From naoto at openjdk.org Tue Jul 26 17:17:46 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 17:17:46 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. 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 12 additional commits since the last revision: - Modified javadoc of the transformed conent - Merge branch 'master' into JDK-8289227-T-ext - Removed unnecessary `contains()` check - IllformedLocaleEx -> LocaleSyntaxEx - SystemProperty tests - Revived returning Optional - Some clean-ups, including making Extension a sealed class. - Bring the specialized methods back Some documentation fixes - Using Optional - FieldSeparators()/FieldSubtag() -> Fields() - ... and 2 more: https://git.openjdk.org/jdk/compare/69ea6e10...780f712e ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/a869efaa..780f712e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=01-02 Stats: 6329 lines in 181 files changed: 3452 ins; 2172 del; 705 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Tue Jul 26 17:27:07 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 17:27:07 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v2] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 01:07:29 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unnecessary `contains()` check > > src/java.base/share/classes/java/util/Locale.java line 236: > >> 234: * particular Unicode locale attributes or key/type pairs. >> 235: * >> 236: *

        Transformed Content extension

        > > Both the full name "Transformed Content extension" and the abbreviated forms "T Extension" are used in this document. I see Unicode and the RFC referred to it as "T Extension", " 't' Extension", and "Extension T". If we describe the extension as "T Extension", maybe we can make it clear in the title, e.g.: > Transformed Content (T) Extension > > could thus in the doc thereafter use "T Extension". The existing methods look like used full extension name, but for T Extension, the short form, e.g. getTExtensionFields also matches its javadoc ("Returns the map of fields in the T extension"). Your call. Thanks for the suggestion, Joe. I made changes to the `Locale` class documentation, mainly to spell out `transformed content`, instead of using `T`. I believe that would be more descriptive. Since the RFC title uses `T`, I added it in the section title. > src/java.base/share/classes/java/util/Locale.java line 265: > >> 263: * field separator (one alpha + one digit), followed by one or more subtags of the length 3 to 8, >> 264: * each delimited by a hyphen. >> 265: *

        The transformed content information {@code source} language tag and {@code fields} are returned > > "transformed content information" seems not needed as "The {@code source} language tag and {@code fields}" are known from the previous paragraph. Modified to make it more sense. > src/java.base/share/classes/sun/util/locale/TransformedContentExtension.java line 40: > >> 38: public final class TransformedContentExtension extends Extension { >> 39: >> 40: public static final char SINGLETON = 't'; > > "singleton" as in "The singleton identifier" in the doc, seems to mean the key consists of a single character. But it can be confused with the Singleton pattern. T_EXTENSION_KEY (as methods such as isTransformedContentxxx expect a key) or Locale.TRANSFORMED_CONTENT_EXTENSION might be better. This is analogous to the implementation of `UnicodeLocaleExtension`, and I believe this means the singleton as in the pattern. No need to use literal `t` everywhere. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From achung at openjdk.org Tue Jul 26 18:34:58 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 26 Jul 2022 18:34:58 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 In-Reply-To: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com> References: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com> Message-ID: On Mon, 25 Jul 2022 18:48:25 GMT, Alexey Semenyuk wrote: > Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop? Probably will be left for next drop ------------- PR: https://git.openjdk.org/jdk19/pull/154 From rriggs at openjdk.org Tue Jul 26 18:57:30 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Jul 2022 18:57:30 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 17:17:46 GMT, Naoto Sato wrote: >> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. > > 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 12 additional commits since the last revision: > > - Modified javadoc of the transformed conent > - Merge branch 'master' into JDK-8289227-T-ext > - Removed unnecessary `contains()` check > - IllformedLocaleEx -> LocaleSyntaxEx > - SystemProperty tests > - Revived returning Optional > - Some clean-ups, including making Extension a sealed class. > - Bring the specialized methods back > Some documentation fixes > - Using Optional > - FieldSeparators()/FieldSubtag() -> Fields() > - ... and 2 more: https://git.openjdk.org/jdk/compare/59bcd12a...780f712e The basic support for the "t" extension is covered by the existing methods for `Locale.getExtension()` and `Locale.Builder.setExtension`. At least initially, there will be very few developers and applications using transformed content. The transformed content extension syntax is well defined by BCP 47 and applications that need the source language or fields have a well defined format they can parse themselves from the value returned from `getExtension('t')`. I'm concerned about adding API and implementation complexity that may not be used and might accumulate in the JDK without ever being used. The parsing of the source locale and fields is a convenience but not essential to 't' support. I would suggest deferring the APIs for `getTransformedContentFields()` and `getTransformedContentSource()`. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From joehw at openjdk.org Tue Jul 26 19:06:08 2022 From: joehw at openjdk.org (Joe Wang) Date: Tue, 26 Jul 2022 19:06:08 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 17:17:46 GMT, Naoto Sato wrote: >> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. > > 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 12 additional commits since the last revision: > > - Modified javadoc of the transformed conent > - Merge branch 'master' into JDK-8289227-T-ext > - Removed unnecessary `contains()` check > - IllformedLocaleEx -> LocaleSyntaxEx > - SystemProperty tests > - Revived returning Optional > - Some clean-ups, including making Extension a sealed class. > - Bring the specialized methods back > Some documentation fixes > - Using Optional > - FieldSeparators()/FieldSubtag() -> Fields() > - ... and 2 more: https://git.openjdk.org/jdk/compare/8de5da37...780f712e Looks good to me. src/java.base/share/classes/java/util/Locale.java line 265: > 263: * field separator (one alpha + one digit), followed by one or more subtags of the length 3 to 8, > 264: * each delimited by a hyphen. > 265: *

        The transformed content information; namely {@code source} language tag and {@code fields} typo ";" (s/;/,) ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/9620 From hboehm at google.com Tue Jul 26 19:34:50 2022 From: hboehm at google.com (Hans Boehm) Date: Tue, 26 Jul 2022 12:34:50 -0700 Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: On Mon, Jul 25, 2022 at 10:30 PM Stuart Marks wrote: ... > > Hans Boehm wrote: > > > I also have concerns about the use of fullFence here. I believe it should be the case that reachabilityFence guarantees visibility > > of memory operations program-ordered before the reachabilityFence(p) to the Cleaner associated with p. Mutator-collector > > synchronization should normally ensure that. On rereading, it also appears to me that the current reachabilityFence() documentation does not make that as clear as it should. > > > It appears to me that this is addressing an instance of the problem for which I suggested a more general, though also not > > completely elegant, solution in https://docs.google.com/document/d/1yMC4VzZobMQTrVAraMy7xBdWPCJ0p7G5r_43yaqsj-s/edit?usp=sharing . > > Hi Hans, thanks for looking at this. In the prior discussions on reachabilityFence and premature finalization, I don't recall seeing any mention of > memory model issues. To my mind the discussions here are the first mention of them. (Of course it's possible I could have missed something.) > The memory model is quite subtle and it's difficult to be sure of anything. However, as time goes on we've become more confident that there _IS_ > an issue here with the memory model that needs to be addressed. > > Then there is a the question of what to do about it. One possibility is to add some memory ordering semantics into reachabilityFence(p), as you suggest. > As convenient as it might seem, it's not obvious to me that we want reachability fused with memory order. At least we should discuss them separately > before deciding what to do. > > This PR seems to be on a long journey :-) so let me describe some of the background and where I think this ought to go. > > First, like most PRs, this started off as an effort to make some code changes. In this case it's part of Brent's (@bchristi-git) effort to convert finalizers > in the JDK to Cleaners. This is related to discovering coding patterns for how to do this effectively. For example, the entire object's state is available > to the finalizer. But in order to convert this to a Cleaner, the state available to the cleaning action needs to be refactored into a separate object from the > "outer" object. The `EnumCtx` nested class serves this role here. > > Second, we're trying to address the reachability issues. You (Hans) have been writing and speaking about this for some time, mostly in the context of > finalization. We in the JDK group haven't prioritized fixing this issue with respect to finalization (since it's old and deprecated and nobody should be > using it, yeah right). Now that we're converting things to use Cleaner, which has the same issues, we're forced to confront them. Our working position > is that there needs to be a reachabilityFence within a try/finally block in the "right" places; determining the definition of "right" is one of the goals here. Fully agreed. reachabilityFence use is really orthogonal to the mechanism used for the cleanup action. It also exists for plain References. Technically, you don't even need ReferenceQueues to trigger the problem; there are probably cases in which WeakReferences are polled such that you need reachabilityFence calls. > > The third issue is memory ordering. For finalization-based objects, the JLS specifies a happens-before edge between the constructor and the > finalizer. (I think this works for objects whose finalizable state is fully initialized in the constructor. But it doesn't work for objects, like this one, > whose finalizable state is mutable throughout the lifetime of the object.) My recollection is that was added as a very minimal guarantee, that was not intended to suffice in general. Even if the state is fully initialized in the constructor, things will usually still break if the final method call that uses the state does not happen before the execution of the Cleaner. > There is nothing specified for memory ordering edges for Cleaner or > java.lang.ref references at all that I can see. Given the lack of such specifications, we're faced with using the right low-level memory ordering > mechanisms to get the memory order we require. We're using VarHandle::fullFence as kind of a placeholder for this. (We've also considered > empty synchronized blocks, writes/reads to "junk" variables created expressly for this purpose, and other VarHandle fence operations, > but none seem obviously better. I'm sure there are other alternatives we haven't considered.) I'd welcome discussion of the proper alternative. I think the intent was that JLS 12.6.2 still applies, though that section was always stated in terms of finalizers. And in the absence of reachabilityFence, it's rather weak anyway. > > The fourth issue is, do we really want every programmer who uses Cleaner to have to figure out all this reachabilityFence and VarHandle fence stuff? > Of course not. It would be nice to have some higher-level construct (such as a language change like the "Reachability Revisited" proposal), or possibly > to create some library APIs to facilitate this. At a minimum, I think we need to adjust various specifications like Cleaner and java.lang.ref to > address memory ordering issues. There is certainly more that needs to be done though. I clearly agree. > > The difficulty with trying to come up with language changes or library APIs is that I don't think we understand this problem well enough to define > what those mechanisms are actually supposed to do. So before we get to that point, I think we should see attempt to write down a correct solution > using the existing reachability and memory ordering mechanisms. That's what Brent has done here. We should review and iterate on this and identify > the places where the specs need to change, and arrive at a point where the we believe the code, even if ugly and inconvenient, is correct under that spec. I'm not convinced that's feasible without some spec clarification. Otherwise I would agree. The reachabilityFence spec currently says: "the referenced object is not reclaimable by garbage collection at least until after the invocation of this method." In my opinion, the only meaningful interpretation of this is that the reachabilityFence call happens before any Reference to the argument object is enqueued. Preventing "garbage collection" per se isn't ever a goal. (And in the case of finalizers, it happens much later than finalization, so it's not the right notion anyway.) And the only sense of "after" that makes sense in such contexts is the inverse of the happens-before relation. In retrospect, this interpretation is definitely a stretch, and the spec should be much clearer. And I suspect that if we had a clearer statement to this effect we might largely be able to get rid of 12.6.2, which would be a huge win. It sounds like you're applying an alternative reading that largely ignores the clause I quoted, and simply goes by "Ensures that the object referenced by the given reference remains strongly reachable". Presumably this implies, via the Reference spec, that References are not enqueued until later. Even there, it's unclear to me what "later" means, except in terms of happens-before. AFAICT, implementations actually do comply with my reading, though an OpenJDK expert should confirm. We won't enqueue a Reference to x, where x was last referenced by reachabilityFence(x) in thread T, unless there is an intervening GC that result in T at a safe-point past the reachabilityFence. The safepoint synchronization must ensure that the safepoint happens-before the GC decision to enqueue, which will then happen-before the actual enqueuing. Enforcing this ordering is cheap, and probably necessary for GC correctness anyway. So in implementation terms, I think my interpretation is safe. In contrast, putting in explicit fullFences is clearly horribly expensive, much more so than a reachabilityFences. And they only make sense if they occur both at the use sites and in the Cleaner. And without my "happens-before" interpretation, we technically don't know that use site one happens before the one in the Cleaner, so I don't think we have a guarantee they help, except by an assumption that also implies they're not needed. > > Maybe at that point we can contemplate a higher-level approach such as a language mechanism or a library API (or both), but I don't think we're quite there yet. > Or maybe some alternative path forward might emerge. We share that hope. None of the current options look beautiful to me either. But I think it would also be useful to agree that reachabilityFence implies memory ordering. Even if we find a better mechanism for most case, I expect that reachabilityFence will still make sense in corner cases. Hans > > ------------- > > PR: https://git.openjdk.org/jdk/pull/8311 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joehw at openjdk.org Tue Jul 26 19:49:35 2022 From: joehw at openjdk.org (Joe Wang) Date: Tue, 26 Jul 2022 19:49:35 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v3] In-Reply-To: <-Fcn_9F1tZ_N4f83s8Tmskv5ikQkRouF4hVHGZSrmds=.30dce6d7-d603-4961-acb0-e864de84411e@github.com> References: <-Fcn_9F1tZ_N4f83s8Tmskv5ikQkRouF4hVHGZSrmds=.30dce6d7-d603-4961-acb0-e864de84411e@github.com> Message-ID: On Tue, 26 Jul 2022 02:15:55 GMT, Bill Huang wrote: >> Provided coverage for XPath node set functions. Functions include: >> - id() >> - last() >> - position() >> - count() >> - local-name() >> - namespace-uri() >> - name() > > Bill Huang 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: > > Fixed validation error by renaming attributes to be starting with non-digit charaters. Nice tests overall. Some documentation would be good, that is, javadocs/comments/notes to fields, DataProviders and test methods. For name, namespace functions, it would be good to test them against XMLs with namespaces so that the results may contain elements/attributes that are relevant to the namespace. ------------- PR: https://git.openjdk.org/jdk/pull/9633 From rriggs at openjdk.org Tue Jul 26 19:58:37 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Jul 2022 19:58:37 GMT Subject: RFR: 8290894: Reduce runtime of vm.lang microbenchmarks [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 21:13:48 GMT, Eric Caspole wrote: >> Adds fork and iterations controls. This reduces the runtime from 4h26m to about 21m and still seems stable enough for weekly testing. > > Eric Caspole 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 'master' into JDK-8290894 > - 8290894: Reduce runtime of vm.lang microbenchmarks LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9619 From duke at openjdk.org Tue Jul 26 20:01:19 2022 From: duke at openjdk.org (ExE Boss) Date: Tue, 26 Jul 2022 20:01:19 GMT Subject: RFR: 8278863: Add method ClassDesc::ofInternalName [v3] In-Reply-To: References: <3WrKiVDNyaAvxuxpWsaiY7FZT_W5WDftJdwUENnqQc0=.518b7bea-2c44-45de-8832-203819529b27@github.com> Message-ID: On Tue, 26 Jul 2022 09:19:07 GMT, Maurizio Cimadamore wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> updated ClassDesc::ofInternal javadoc with JVMS link and fixed indentation > > src/java.base/share/classes/java/lang/constant/ClassDesc.java line 85: > >> 83: * given the name of the class or interface in internal form, >> 84: * such as {@code "java/lang/String"}. >> 85: * (To create a descriptor for an array type, either use {@link #ofDescriptor(String)} > > It feels like this section could be expanded a bit (and parenthesis removed). E.g. as you point out in the comment, this method only supports reference types, so we should state so clearly. And then present alternatives (like you do now). Isn?t the?internal?name of?an?array?type its?descriptor?though? So, I?feel?like this?method should?allow array?descriptors. ------------- PR: https://git.openjdk.org/jdk/pull/9201 From ecaspole at openjdk.org Tue Jul 26 20:06:33 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Tue, 26 Jul 2022 20:06:33 GMT Subject: RFR: 8290894: Reduce runtime of vm.lang microbenchmarks [v2] In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 21:13:48 GMT, Eric Caspole wrote: >> Adds fork and iterations controls. This reduces the runtime from 4h26m to about 21m and still seems stable enough for weekly testing. > > Eric Caspole 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 'master' into JDK-8290894 > - 8290894: Reduce runtime of vm.lang microbenchmarks Thanks Roger! ------------- PR: https://git.openjdk.org/jdk/pull/9619 From ecaspole at openjdk.org Tue Jul 26 20:11:09 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Tue, 26 Jul 2022 20:11:09 GMT Subject: Integrated: 8290894: Reduce runtime of vm.lang microbenchmarks In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 20:48:22 GMT, Eric Caspole wrote: > Adds fork and iterations controls. This reduces the runtime from 4h26m to about 21m and still seems stable enough for weekly testing. This pull request has now been integrated. Changeset: f0f78a91 Author: Eric Caspole URL: https://git.openjdk.org/jdk/commit/f0f78a9125b1656f2c5a55599e726117bcf73ee5 Stats: 39 lines in 5 files changed: 30 ins; 3 del; 6 mod 8290894: Reduce runtime of vm.lang microbenchmarks Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/9619 From naoto at openjdk.org Tue Jul 26 20:20:07 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 20:20:07 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 19:03:24 GMT, Joe Wang 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 12 additional commits since the last revision: >> >> - Modified javadoc of the transformed conent >> - Merge branch 'master' into JDK-8289227-T-ext >> - Removed unnecessary `contains()` check >> - IllformedLocaleEx -> LocaleSyntaxEx >> - SystemProperty tests >> - Revived returning Optional >> - Some clean-ups, including making Extension a sealed class. >> - Bring the specialized methods back >> Some documentation fixes >> - Using Optional >> - FieldSeparators()/FieldSubtag() -> Fields() >> - ... and 2 more: https://git.openjdk.org/jdk/compare/b512a057...780f712e > > src/java.base/share/classes/java/util/Locale.java line 265: > >> 263: * field separator (one alpha + one digit), followed by one or more subtags of the length 3 to 8, >> 264: * each delimited by a hyphen. >> 265: *

        The transformed content information; namely {@code source} language tag and {@code fields} > > typo ";" (s/;/,) Actually, I did mean a semicolon, but a comma may be better in this case. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From achung at openjdk.org Tue Jul 26 20:24:14 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 26 Jul 2022 20:24:14 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: > open l10n msg drop > All tests passed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: merged currencyname property files into localedata ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/154/files - new: https://git.openjdk.org/jdk19/pull/154/files/334f4c76..7ab703ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=00-01 Stats: 1540 lines in 7 files changed: 3 ins; 1534 del; 3 mod Patch: https://git.openjdk.org/jdk19/pull/154.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154 PR: https://git.openjdk.org/jdk19/pull/154 From achung at openjdk.org Tue Jul 26 20:31:44 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 26 Jul 2022 20:31:44 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: Message-ID: > open l10n msg drop > All tests passed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed localized files from base ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/154/files - new: https://git.openjdk.org/jdk19/pull/154/files/7ab703ed..6776bd0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=01-02 Stats: 1722 lines in 3 files changed: 0 ins; 1722 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/154.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154 PR: https://git.openjdk.org/jdk19/pull/154 From naoto at openjdk.org Tue Jul 26 20:42:37 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 20:42:37 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v4] In-Reply-To: References: Message-ID: > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Removed convenient APIs for now ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/780f712e..e24e5dd8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=02-03 Stats: 63 lines in 2 files changed: 0 ins; 60 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Tue Jul 26 20:56:05 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 26 Jul 2022 20:56:05 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 18:41:57 GMT, Roger Riggs wrote: > I would suggest deferring the APIs for `getTransformedContentFields()` and `getTransformedContentSource()`. OK, removed those two convenient APIs. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From darcy at openjdk.org Tue Jul 26 21:46:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 26 Jul 2022 21:46:20 GMT Subject: RFR: JDK-8289106: Add model of class file versions to core reflection [v3] In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> Message-ID: <1o4NPfbHxAylHw6TMPEHX7ztRHLZc-9hAg_OGaFTF_Y=.c3dd7f75-6425-45b7-a9f3-61dfa432dd79@github.com> > JDK-8289106: Add model of class file versions to core reflection Joe Darcy 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 branch 'master' into JDK-8289106 - Merge branch 'master' into JDK-8289106 - Add method to map from major class file version. - Merge branch 'master' into JDK-8289106 - Update phrasing. - Augment and correct docs. - Correct major versions; RELEASE_0 and RELEASE_1 are both 45. - Make major method public. - Add AccessFlag.locations(ClassFileFormatVersion) - Add ClassFileFormatVersion <-> Runtime.Version conversions. - ... and 2 more: https://git.openjdk.org/jdk/compare/7f270ba6...998b6f6b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9299/files - new: https://git.openjdk.org/jdk/pull/9299/files/27a8e194..998b6f6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=01-02 Stats: 105954 lines in 2402 files changed: 57283 ins; 31517 del; 17154 mod Patch: https://git.openjdk.org/jdk/pull/9299.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9299/head:pull/9299 PR: https://git.openjdk.org/jdk/pull/9299 From rriggs at openjdk.org Tue Jul 26 21:52:38 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Jul 2022 21:52:38 GMT Subject: RFR: 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences" Message-ID: The intermittent test failure was due to the WeakReferences being unreferenced too early. Adding a Reference.reachabilityFence to the test makes it robust. Remove from ProblemList-Xcomp.txt ------------- Commit messages: - Merge branch 'master' into 8290848-unload-too-few - 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences" Changes: https://git.openjdk.org/jdk/pull/9649/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9649&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290848 Stats: 10 lines in 2 files changed: 4 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9649.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9649/head:pull/9649 PR: https://git.openjdk.org/jdk/pull/9649 From mchung at openjdk.org Tue Jul 26 23:16:02 2022 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 26 Jul 2022 23:16:02 GMT Subject: RFR: 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences" In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 21:44:19 GMT, Roger Riggs wrote: > The intermittent test failure was due to the WeakReferences being unreferenced too early. > Adding a Reference.reachabilityFence to the test makes it robust. > > Remove from ProblemList-Xcomp.txt This looks good. Glad that you fxied this hard to find issue. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/9649 From jvernee at openjdk.org Wed Jul 27 01:50:26 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 27 Jul 2022 01:50:26 GMT Subject: [jdk19] RFR: 8291006: java/foreign/TestUnsupportedPlatform fails after JDK-8290455 In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 09:44:53 GMT, Maurizio Cimadamore wrote: > This patch removes java/foreign/TestUnsupportedPlatform, which has been superseded by TestUnsupportedLinker, and is no longer required. > This old test relies on unspecified behavior and should be removed. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/155 From dholmes at openjdk.org Wed Jul 27 05:37:09 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Jul 2022 05:37:09 GMT Subject: RFR: Merge jdk19 Message-ID: Forward port JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8290455: jck test api/java_lang/foreign/VaList/Empty.html fails on some platforms - 8290460: Alpine: disable some panama tests that rely on std::thread The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/9651/files Stats: 89 lines in 3 files changed: 67 ins; 7 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9651.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9651/head:pull/9651 PR: https://git.openjdk.org/jdk/pull/9651 From ananyanayak102 at gmail.com Wed Jul 27 06:25:14 2022 From: ananyanayak102 at gmail.com (Ananya Nayak) Date: Wed, 27 Jul 2022 11:55:14 +0530 Subject: Issue regarding hugeLength() method of ArraysSupport class in java.internal.util package Message-ID: After analysing the method declaration carefully I realized some bugs in the code: 1.the if condition on seeing min length as less than 0 returns out of memory error with a message that "required length is too large" which is contradictory to what we are checking in the condition. 2. We should actually return the out of memory error when it exceeds the SOFT_ARRAY_MAX_LENGTH. 3. Moreover we are returning minLength in the third condition when we actually shouldn't because it exceeds the limit Kindly verify this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Wed Jul 27 06:45:51 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 27 Jul 2022 06:45:51 GMT Subject: RFR: 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences" In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 21:44:19 GMT, Roger Riggs wrote: > The intermittent test failure was due to the WeakReferences being unreferenced too early. > Adding a Reference.reachabilityFence to the test makes it robust. > > Remove from ProblemList-Xcomp.txt Hello Roger, considering that the `wCanary` array will be "alive" at least till the end of the loop at line 126 (the loop within which we create the `WeakReference` instances and register them with the `refQueue`), shouldn't the `refQueue` be enqueued with these `WeakReference`s, even if `wCanary` gets unreferenced at line 126? Thus, shouldn't the `refQueue` have these unreferenced instances at line 169 - the place where we call `refQueue.remove(Utils.adjustTimeout(30 * 1000L));`? ------------- PR: https://git.openjdk.org/jdk/pull/9649 From dholmes at openjdk.org Wed Jul 27 06:47:02 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Jul 2022 06:47:02 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 13:10:00 GMT, Jorn Vernee wrote: > Does run_in_new_thread seem good enough? No, sorry, the fact it both runs and joins is a critical aspect. `run_async` in `CompleteableFuture` just does the "run in new thread" part, whereas the `get()` on the returned `FutureTask` provides the "join". So a function that does both needs to make that clear in the name - and there is no nice succinct name for that, so we get stuck with something like `run_in_new_thread_and_join`. Or we just have ` startThread` and `joinThread` :) ------------- PR: https://git.openjdk.org/jdk/pull/9599 From mcimadamore at openjdk.org Wed Jul 27 09:55:12 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 27 Jul 2022 09:55:12 GMT Subject: [jdk19] Integrated: 8291006: java/foreign/TestUnsupportedPlatform fails after JDK-8290455 In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 09:44:53 GMT, Maurizio Cimadamore wrote: > This patch removes java/foreign/TestUnsupportedPlatform, which has been superseded by TestUnsupportedLinker, and is no longer required. > This old test relies on unspecified behavior and should be removed. This pull request has now been integrated. Changeset: 36c00fdd Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk19/commit/36c00fdd74692b85e63e57e192f42c14561efd01 Stats: 45 lines in 1 file changed: 0 ins; 45 del; 0 mod 8291006: java/foreign/TestUnsupportedPlatform fails after JDK-8290455 Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk19/pull/155 From raffaello.giulietti at oracle.com Wed Jul 27 10:19:59 2022 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Wed, 27 Jul 2022 12:19:59 +0200 Subject: Issue regarding hugeLength() method of ArraysSupport class in java.internal.util package In-Reply-To: References: Message-ID: <3e39f46c-5d26-9250-fc77-56cebed2c7e5@oracle.com> 1. minLength < 0 means that there is an overflow in the preceding addition, so the error's message is correct. 2. + 3. hugeLength() is only ever invoked by the newLength() method just above. The javadoc spec of that method is quite clear about what newLength(), and thus hugeLength(), are expected to return and to throw. The interplay between these methods implements the spec correctly. Greetings Raffaello On 2022-07-27 08:25, Ananya Nayak wrote: > After analysing the method declaration carefully I realized some bugs in > the code: > > ?1.the if condition on seeing min length as less than 0 returns out of > memory error with a message that "required length is too large" which is > contradictory to what we are checking in the condition. > > 2. We should actually return the out of memory error when it exceeds the > SOFT_ARRAY_MAX_LENGTH. > > 3. Moreover we are returning minLength in the third condition when we > actually shouldn't because?it exceeds the limit > > Kindly verify this. > > From simonis at openjdk.org Wed Jul 27 10:47:44 2022 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 27 Jul 2022 10:47:44 GMT Subject: RFR: 8282648: Weaken the InflaterInputStream specification in order to allow faster Zip implementations [v11] In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: > Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. > > The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. > > ### TL;DR > > `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. > > The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. > > The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. > > These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`* k*`]` (where *k* is the number of inflated bytes). > > From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). Volker Simonis 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 apiNote to methods which return InflaterInputStreams as InputStreams - Updated wording based on @JoeDarcy's CSR review - Updated wording based on @LanceAndersen's review - Adapted wording based on @AlanBateman's review, removed implementation note on ZipFile::getInputStream and aligned wording for all ::read methods - Adapted wording and copyrights based on @jaikiran review - Added API-refinement to GZIPInputStream::read()/ZipInputStream::read() and an Implementation note to ZipFile::getInputStream() - Extended API-doc based on reviewer feedback - 8282648: Weaken the InflaterInputStream specification in order to allow faster Zip implementations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/7986/files - new: https://git.openjdk.org/jdk/pull/7986/files/d62cba43..62e25d42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=7986&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=7986&range=09-10 Stats: 725664 lines in 9719 files changed: 476036 ins; 150587 del; 99041 mod Patch: https://git.openjdk.org/jdk/pull/7986.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7986/head:pull/7986 PR: https://git.openjdk.org/jdk/pull/7986 From simonis at openjdk.org Wed Jul 27 10:49:00 2022 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 27 Jul 2022 10:49:00 GMT Subject: RFR: 8282648: Weaken the InflaterInputStream specification in order to allow faster Zip implementations [v10] In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: On Mon, 9 May 2022 09:56:19 GMT, Volker Simonis wrote: >> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. >> >> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. >> >> ### TL;DR >> >> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. >> >> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. >> >> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. >> >> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+` *k*`]` (where *k* is the number of inflated bytes). >> >> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). > > Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The latest push contains the following changes: - changed the summary of the Issue and CSR to "Weaken the InflaterInputStream specification in order to allow faster Zip implementations" as suggested - rebased the PR up to change [63ae357](https://github.com/openjdk/jdk/pull/7986/commits/63ae3572da674a0926bb9d0adcea88d89bb56707) on top of the leatest HEAD revision - Applied the same changes to the JavaDoc of `JarInputStream::read()` like to ones which were added to `ZipInputStream::read()`. `JarInputStream` which derives from `ZipInputStream` and overrides `ZipInputStream::read()` was just forgotten in the previous itetrations of this change. - Added an `@apiNote` to `ZipFile::getInputStream()`, `JarFile::getInputStream()` and `URLConnection::getInputStream()` to indicate that the returned `InputStream` might *scribble* the contents of the output array beyond the last inflated byte. I couldn't find any other public methods in the `java.*` packages which return `InflaterInputStream` instances (or derived subclasses) as a generic `InputStream`. ------------- PR: https://git.openjdk.org/jdk/pull/7986 From shade at openjdk.org Wed Jul 27 12:53:05 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 27 Jul 2022 12:53:05 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 16:41:04 GMT, Aleksey Shipilev wrote: > > ...I can take this over, unless you want to do it, Aleksey? > > I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? On the other hand, this test is in tier2, so it makes lots of testing with other GCs not clean. I would like to have this fix in, and *then* do any followups that might make the test more targeted. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From dholmes at openjdk.org Wed Jul 27 13:07:02 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Jul 2022 13:07:02 GMT Subject: RFR: Merge jdk19 In-Reply-To: References: Message-ID: <-EP4DUjmhnggnEJSphs1zYQfdkiNnmZPfmHgTPRkcYY=.6de8de61-5557-475b-a985-264f2ca45efe@github.com> On Wed, 27 Jul 2022 05:29:09 GMT, David Holmes wrote: > Forward port JDK 19 -> JDK 20 Need to pull in a follow up test fix so closing this MR. ------------- PR: https://git.openjdk.org/jdk/pull/9651 From dholmes at openjdk.org Wed Jul 27 13:07:02 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Jul 2022 13:07:02 GMT Subject: Withdrawn: Merge jdk19 In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 05:29:09 GMT, David Holmes wrote: > Forward port JDK 19 -> JDK 20 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9651 From rriggs at openjdk.org Wed Jul 27 13:50:21 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 27 Jul 2022 13:50:21 GMT Subject: RFR: 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences" In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 21:44:19 GMT, Roger Riggs wrote: > The intermittent test failure was due to the WeakReferences being unreferenced too early. > Adding a Reference.reachabilityFence to the test makes it robust. > > Remove from ProblemList-Xcomp.txt Hi Jai, The actions related to References are only true if the Reference (or subtype) is reachable. In this case, if the WeakReference cannot be reached from some other root, its semantics are void. Note that initially the WeakReference refers to the queue not the other way around. Reference processing occurs from the roots and conditionally gaining semantics when traversing through Reference objects. So at least until the weakly-reachable condition is satisfied the WeakReference must be reachable from another (strong) root. https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/ref/package-summary.html#reachability ------------- PR: https://git.openjdk.org/jdk/pull/9649 From jpai at openjdk.org Wed Jul 27 13:59:13 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 27 Jul 2022 13:59:13 GMT Subject: RFR: 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences" In-Reply-To: References: Message-ID: <3hnu2vTnXFQlhtOXOnRo1-hDfrcvTnmYhu9zBvWCusk=.5078315f-de92-443b-962e-399078388783@github.com> On Tue, 26 Jul 2022 21:44:19 GMT, Roger Riggs wrote: > The intermittent test failure was due to the WeakReferences being unreferenced too early. > Adding a Reference.reachabilityFence to the test makes it robust. > > Remove from ProblemList-Xcomp.txt Marked as reviewed by jpai (Reviewer). Thank you Roger for that explanation. That helped. ------------- PR: https://git.openjdk.org/jdk/pull/9649 From dholmes at openjdk.org Wed Jul 27 14:14:47 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Jul 2022 14:14:47 GMT Subject: Integrated: Merge jdk19 Message-ID: <1pEQazx45HzunXRltflg0BRmcunK_hxKwAmkKlbDbiY=.8369a2ec-2f5d-469c-8060-bd0f424c29d9@github.com> Forward port JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8291006: java/foreign/TestUnsupportedPlatform fails after JDK-8290455 - 8290455: jck test api/java_lang/foreign/VaList/Empty.html fails on some platforms - 8290460: Alpine: disable some panama tests that rely on std::thread The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/9656/files Stats: 134 lines in 4 files changed: 67 ins; 52 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9656.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9656/head:pull/9656 PR: https://git.openjdk.org/jdk/pull/9656 From dholmes at openjdk.org Wed Jul 27 14:14:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Jul 2022 14:14:49 GMT Subject: Integrated: Merge jdk19 In-Reply-To: <1pEQazx45HzunXRltflg0BRmcunK_hxKwAmkKlbDbiY=.8369a2ec-2f5d-469c-8060-bd0f424c29d9@github.com> References: <1pEQazx45HzunXRltflg0BRmcunK_hxKwAmkKlbDbiY=.8369a2ec-2f5d-469c-8060-bd0f424c29d9@github.com> Message-ID: On Wed, 27 Jul 2022 12:59:36 GMT, David Holmes wrote: > Forward port JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 92346246 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/923462467e52eda359249a4fb61d654f56182603 Stats: 134 lines in 4 files changed: 67 ins; 52 del; 15 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9656 From jvernee at openjdk.org Wed Jul 27 14:34:49 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 27 Jul 2022 14:34:49 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v5] In-Reply-To: References: Message-ID: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: run_in_new_thread_and_join ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9599/files - new: https://git.openjdk.org/jdk/pull/9599/files/721f70bc..be6c484b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9599&range=03-04 Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9599/head:pull/9599 PR: https://git.openjdk.org/jdk/pull/9599 From jvernee at openjdk.org Wed Jul 27 14:34:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 27 Jul 2022 14:34:50 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: <-HTKS0BueluMoHSQIduIEL24ZwPswDbdwzMOd3l64FM=.a00f15aa-2677-4319-ba9f-32639da0c23a@github.com> On Wed, 27 Jul 2022 06:43:45 GMT, David Holmes wrote: > > Does run_in_new_thread seem good enough? > > No, sorry, the fact it both runs and joins is a critical aspect. `run_async` in `CompleteableFuture` just does the "run in new thread" part, whereas the `get()` on the returned `FutureTask` provides the "join". So a function that does both needs to make that clear in the name - and there is no nice succinct name for that, so we get stuck with something like `run_in_new_thread_and_join`. Or we just have ` startThread` and `joinThread` :) `startThread` and `joinThread` is not the functionality that the tests need. The functionality that's needed is one that combines these two, so that's what I went with. An API without real users is harder to get right. I've looked into adding `startThread` and `joinThread`. But, the story is not so simple. Since now the context passed to `CreateThread` and `pthread_create` has to outlive the function, which means heap allocating, or asking the caller to stack allocate. I think a typical C API might have a `new_thread` and `delete_thread` to do the memory management. These functions could be folded into `startThread` and `joinThread`, and we'd rename those to `create_and_start_thread` and `join_and_destroy_thread` (I think it's important to signal to callers that allocation happens, so that the memory will be cleaned up by calling join as well), but at that point it feels like we're back where we started. The alternative being stack allocation. i.e. the caller declares a `THREAD` variable and passes a pointer to it to `start_thread`, which then uses that memory. This avoids the heap allocation, but adds more noise in the caller. Getting into that just feels like too much unneeded complexity at this moment. So, `run_in_new_thread_and_join` it is. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From rriggs at openjdk.org Wed Jul 27 14:50:42 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 27 Jul 2022 14:50:42 GMT Subject: Integrated: 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences" In-Reply-To: References: Message-ID: <2wey1d1geaGOSWuOpfAEq3HJCM61w4tppJueeH1qX4Y=.f4f7dc74-0fc0-4040-aed9-40ec8013023b@github.com> On Tue, 26 Jul 2022 21:44:19 GMT, Roger Riggs wrote: > The intermittent test failure was due to the WeakReferences being unreferenced too early. > Adding a Reference.reachabilityFence to the test makes it robust. > > Remove from ProblemList-Xcomp.txt This pull request has now been integrated. Changeset: c1040897 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/c1040897cd6d5bc6e76c971035cc36c9d35b31e6 Stats: 10 lines in 2 files changed: 4 ins; 5 del; 1 mod 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences" Reviewed-by: mchung, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9649 From duke at openjdk.org Wed Jul 27 20:04:54 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 27 Jul 2022 20:04:54 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v4] In-Reply-To: References: Message-ID: > Provided coverage for XPath node set functions. Functions include: > - id() > - last() > - position() > - count() > - local-name() > - namespace-uri() > - name() Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Added documentation/comments and test cases using namespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9633/files - new: https://git.openjdk.org/jdk/pull/9633/files/2029ce13..0db77643 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=02-03 Stats: 144 lines in 4 files changed: 111 ins; 0 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/9633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9633/head:pull/9633 PR: https://git.openjdk.org/jdk/pull/9633 From duke at openjdk.org Wed Jul 27 20:12:18 2022 From: duke at openjdk.org (Bill Huang) Date: Wed, 27 Jul 2022 20:12:18 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v3] In-Reply-To: References: <-Fcn_9F1tZ_N4f83s8Tmskv5ikQkRouF4hVHGZSrmds=.30dce6d7-d603-4961-acb0-e864de84411e@github.com> Message-ID: On Tue, 26 Jul 2022 19:44:51 GMT, Joe Wang wrote: >> Bill Huang 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: >> >> Fixed validation error by renaming attributes to be starting with non-digit charaters. > > Nice tests overall. Some documentation would be good, that is, javadocs/comments/notes to fields, DataProviders and test methods. > > For name, namespace functions, it would be good to test them against XMLs with namespaces so that the results may contain elements/attributes that are relevant to the namespace. @JoeWang-Java Thank you for the advice. I added a foo namespace for the name and namespace functions. More comprehensive test coverage for namespaces will be covered by [JDK-8289510](https://bugs.openjdk.org/browse/JDK-8289510). ------------- PR: https://git.openjdk.org/jdk/pull/9633 From duke at openjdk.org Wed Jul 27 20:18:16 2022 From: duke at openjdk.org (Gaurav Chaudhari) Date: Wed, 27 Jul 2022 20:18:16 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v3] In-Reply-To: References: Message-ID: > This is a REDO of the Fix that was incompletely implemented earlier: > [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660) > > Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days. > > I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works: > _(where 7200 represents 7200 seconds -> +2 hour offset)_ > Sample output: > ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png) Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: 8288377: Added GMT0 corner case and minor format fixes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9312/files - new: https://git.openjdk.org/jdk/pull/9312/files/7e462d95..8ca0a727 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=01-02 Stats: 22 lines in 1 file changed: 20 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9312.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9312/head:pull/9312 PR: https://git.openjdk.org/jdk/pull/9312 From duke at openjdk.org Wed Jul 27 20:18:17 2022 From: duke at openjdk.org (Gaurav Chaudhari) Date: Wed, 27 Jul 2022 20:18:17 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v2] In-Reply-To: <9HAc2av3J84YjjL6VgQLfSlMAUkicHuic2ONLc7x3ZA=.4b01d5f6-6a96-4996-bd83-be9ce5d19c41@github.com> References: <9HAc2av3J84YjjL6VgQLfSlMAUkicHuic2ONLc7x3ZA=.4b01d5f6-6a96-4996-bd83-be9ce5d19c41@github.com> Message-ID: On Thu, 30 Jun 2022 20:05:05 GMT, Naoto Sato wrote: >> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8288377: Simplified TZ offset calc and consolidate MACOS impl. > > src/java.base/unix/native/libjava/TimeZone_md.c line 569: > >> 567: } >> 568: >> 569: strftime(offset, 6, "%z", &localtm); > > Return value has to be examined. If it is not `5`, then I'd expect falling back to "GMT". Added check to verify output is as expected before proceeding, with fallback > src/java.base/unix/native/libjava/TimeZone_md.c line 572: > >> 570: char gmt_offset[] = {offset[0], offset[1], offset[2], ':', offset[3], offset[4], '\0'}; >> 571: >> 572: sprintf(buf, (const char *)"GMT%s", gmt_offset); > > You could use the format string as "GMT%c%c%c:%c%c" so that the extra `gmt_offset` variable can be eliminated. Adjusted, forgot that the final string returned was able to be formatted itself as well. ------------- PR: https://git.openjdk.org/jdk/pull/9312 From duke at openjdk.org Wed Jul 27 20:38:55 2022 From: duke at openjdk.org (liach) Date: Wed, 27 Jul 2022 20:38:55 GMT Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) [v4] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 22:05:35 GMT, liach wrote: >> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior. > > liach 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: > > - Move tests > - Merge branch 'master' into fix/identityhashmap-default > - Fix assertions > - Revamp test and changes. Let ci run the tests > - Fix indent > - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) Is there any update that I should push to this patch? ------------- PR: https://git.openjdk.org/jdk/pull/8259 From cjplummer at openjdk.org Wed Jul 27 21:42:24 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 27 Jul 2022 21:42:24 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com> References: <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com> Message-ID: On Fri, 22 Jul 2022 03:10:11 GMT, Leonid Mesnik wrote: >> So shouldn't we have ZGC test failures then? > > No, test passes with ZGC. I meant shouldn't we see ZGC failures before your changes. Otherwise I don't understand why this change is needed. ------------- PR: https://git.openjdk.org/jdk/pull/9604 From lmesnik at openjdk.org Wed Jul 27 21:42:24 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 27 Jul 2022 21:42:24 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com> Message-ID: On Fri, 22 Jul 2022 19:27:29 GMT, Chris Plummer wrote: >> No, test passes with ZGC. > > I meant shouldn't we see ZGC failures before your changes. Otherwise I don't understand why this change is needed. Before my changes test just silently ignored any GC setting and always use G1. ------------- PR: https://git.openjdk.org/jdk/pull/9604 From cjplummer at openjdk.org Wed Jul 27 22:34:35 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 27 Jul 2022 22:34:35 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik wrote: > Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9604 From cjplummer at openjdk.org Wed Jul 27 22:34:37 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 27 Jul 2022 22:34:37 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: <-si3mHhUSWEO_Pjo2ID0jovGkEZnNSEK5kbd_6skr4k=.bca9eaa2-58a7-40c6-9c9c-63298ac61f80@github.com> Message-ID: On Wed, 27 Jul 2022 21:39:47 GMT, Leonid Mesnik wrote: >> I meant shouldn't we see ZGC failures before your changes. Otherwise I don't understand why this change is needed. > > Before my changes test just silently ignored any GC setting and always use G1. Ah, ok. That makes sense now. ------------- PR: https://git.openjdk.org/jdk/pull/9604 From naoto at openjdk.org Wed Jul 27 22:35:50 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 27 Jul 2022 22:35:50 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v3] In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 20:18:16 GMT, Gaurav Chaudhari wrote: >> This is a REDO of the Fix that was incompletely implemented earlier: >> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660) >> >> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days. >> >> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works: >> _(where 7200 represents 7200 seconds -> +2 hour offset)_ >> Sample output: >> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png) > > Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: > > 8288377: Added GMT0 corner case and minor format fixes. Thanks. Looks good with one minor request. src/java.base/unix/native/libjava/TimeZone_md.c line 587: > 585: > 586: strftime(offset, 6, "%z", &localtm); > 587: if (strlen(offset) != 5) { What I meant was the return value from `strftime`, not the length from `strlen`, ie, `if (strftime(...) != 5)`. It should be more robust. ------------- Changes requested by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9312 From sspitsyn at openjdk.org Wed Jul 27 23:21:33 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 27 Jul 2022 23:21:33 GMT Subject: RFR: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik wrote: > Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid. Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9604 From lmesnik at openjdk.org Thu Jul 28 00:07:44 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 28 Jul 2022 00:07:44 GMT Subject: Integrated: 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 22:33:36 GMT, Leonid Mesnik wrote: > Propagate test.vm.opts/test.java.opts to tested process. Also, accept the output of non-generation (ZGC) GC as valid. This pull request has now been integrated. Changeset: 348a0521 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/348a0521e1cd602c4093955310f838cf4ce4daae Stats: 5 lines in 2 files changed: 1 ins; 1 del; 3 mod 8290846: sun/tools/jstatd/JstatdTest* tests should use VM options Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/9604 From joehw at openjdk.org Thu Jul 28 00:37:41 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 28 Jul 2022 00:37:41 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v4] In-Reply-To: References: Message-ID: <2IKKULTBx6pDotISfrXFeRxw6T1IfII_LTI6QnhxEsE=.5d69742e-9d45-42a8-b07a-29ee99b02415@github.com> On Wed, 27 Jul 2022 20:04:54 GMT, Bill Huang wrote: >> Provided coverage for XPath node set functions. Functions include: >> - id() >> - last() >> - position() >> - count() >> - local-name() >> - namespace-uri() >> - name() > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Added documentation/comments and test cases using namespace. Thanks for reminding me of [JDK-8289510](https://bugs.openjdk.org/browse/JDK-8289510) for covering more on namespace. A few comments below. Otherwise looks good. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 38: > 36: * @library /javax/xml/jaxp/unittest > 37: * @run testng xpath.XPathExpFnTest > 38: * @summary Test for XPath functions Since this test focuses on Node Set Functions, it would be good to say so, e.g. "Tests the XPath Node Set Functions". test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 45: > 43: > 44: /* > 45: * DataProvider for XPath expressions for id function. Looks like this is: "DataProvider for testing the id function". test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 62: > 60: > 61: /* > 62: * DataProvider for XPath expressions for count function. DataProvider for testing the count function. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 99: > 97: > 98: /* > 99: * DataProvider for XPath expression for position function. DataProvider for testing the position function. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 116: > 114: > 115: /* > 116: * DataProvider for XPath expression for name and local name function. DataProvider for testing the name and local-name functions. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 145: > 143: /** > 144: * This test evaluates XPath expressions of id function and checks against > 145: * the expected result. Use 3rd person descriptive, e.g. "Verifies that the result of evaluating the id function matches the expected result." test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 149: > 147: * @param exp XPath expression > 148: * @param expected expected result > 149: * @throws Exception @throws Exception if the test fails test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 167: > 165: * This test evaluates XPath expressions of count function and checks > 166: * against the expected result. > 167: * Verifies that the result of evaluating the count function matches the expected result. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 185: > 183: /** > 184: * This test evaluates XPath expressions of position function and checks > 185: * against the expected result. Verifies that the result of evaluating the position function matches the expected result. test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 207: > 205: * This test evaluates XPath expressions of name and local-name functions > 206: * and checks against the expected result. > 207: * Verifies that the result of evaluating the name and local-name functions matches the expected result. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/9633 From itakiguchi at openjdk.org Thu Jul 28 01:01:08 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Thu, 28 Jul 2022 01:01:08 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote: > Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. Hello @naotoj . I'm not reviewer, but I'd like to test this change. Could you wait for a moment ? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9661 From duke at openjdk.org Thu Jul 28 01:42:16 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 28 Jul 2022 01:42:16 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v4] In-Reply-To: <2IKKULTBx6pDotISfrXFeRxw6T1IfII_LTI6QnhxEsE=.5d69742e-9d45-42a8-b07a-29ee99b02415@github.com> References: <2IKKULTBx6pDotISfrXFeRxw6T1IfII_LTI6QnhxEsE=.5d69742e-9d45-42a8-b07a-29ee99b02415@github.com> Message-ID: On Thu, 28 Jul 2022 00:14:52 GMT, Joe Wang wrote: >> Bill Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> Added documentation/comments and test cases using namespace. > > test/jaxp/javax/xml/jaxp/unittest/xpath/XPathExpFnTest.java line 38: > >> 36: * @library /javax/xml/jaxp/unittest >> 37: * @run testng xpath.XPathExpFnTest >> 38: * @summary Test for XPath functions > > Since this test focuses on Node Set Functions, it would be good to say so, e.g. "Tests the XPath Node Set Functions". Agreed. I think it would be good to rename this file to XPathNodeSetFnTest.java. ------------- PR: https://git.openjdk.org/jdk/pull/9633 From naoto at openjdk.org Thu Jul 28 01:48:33 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 28 Jul 2022 01:48:33 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 00:58:59 GMT, Ichiroh Takiguchi wrote: >> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. > > Hello @naotoj . > I'm not reviewer, but I'd like to test this change. > Could you wait for a moment ? > Thanks. @takiguc Sure. Appreciate it. ------------- PR: https://git.openjdk.org/jdk/pull/9661 From duke at openjdk.org Thu Jul 28 01:49:13 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 28 Jul 2022 01:49:13 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v5] In-Reply-To: References: Message-ID: <_TVIzLdctx4KOOlCHEMOZeDAgIIFmE34CG0EHua2mrA=.9c26fcf8-6182-4989-8a92-38db131288d8@github.com> > Provided coverage for XPath node set functions. Functions include: > - id() > - last() > - position() > - count() > - local-name() > - namespace-uri() > - name() Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Rename test name to XPathNodeSetFnTest.java. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9633/files - new: https://git.openjdk.org/jdk/pull/9633/files/0db77643..2ac600c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9633&range=03-04 Stats: 444 lines in 2 files changed: 222 ins; 222 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9633.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9633/head:pull/9633 PR: https://git.openjdk.org/jdk/pull/9633 From joehw at openjdk.org Thu Jul 28 02:21:39 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 28 Jul 2022 02:21:39 GMT Subject: RFR: JDK-8289948: Improve test coverage for XPath functions: Node Set Functions [v5] In-Reply-To: <_TVIzLdctx4KOOlCHEMOZeDAgIIFmE34CG0EHua2mrA=.9c26fcf8-6182-4989-8a92-38db131288d8@github.com> References: <_TVIzLdctx4KOOlCHEMOZeDAgIIFmE34CG0EHua2mrA=.9c26fcf8-6182-4989-8a92-38db131288d8@github.com> Message-ID: On Thu, 28 Jul 2022 01:49:13 GMT, Bill Huang wrote: >> Provided coverage for XPath node set functions. Functions include: >> - id() >> - last() >> - position() >> - count() >> - local-name() >> - namespace-uri() >> - name() > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Rename test name to XPathNodeSetFnTest.java. Marked as reviewed by joehw (Reviewer). Thanks for the update. ------------- PR: https://git.openjdk.org/jdk/pull/9633 From dholmes at openjdk.org Thu Jul 28 04:59:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Jul 2022 04:59:31 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: <-HTKS0BueluMoHSQIduIEL24ZwPswDbdwzMOd3l64FM=.a00f15aa-2677-4319-ba9f-32639da0c23a@github.com> References: <-HTKS0BueluMoHSQIduIEL24ZwPswDbdwzMOd3l64FM=.a00f15aa-2677-4319-ba9f-32639da0c23a@github.com> Message-ID: <1eo26bTf2CEWe-9qAq4ZSWIuI436q4itVdSqkMrvcPk=.481da348-9fd2-4407-9885-19500b65eb93@github.com> On Wed, 27 Jul 2022 14:29:26 GMT, Jorn Vernee wrote: > startThread and joinThread is not the functionality that the tests need. But it is the functionality the tests are already using. > now the context passed to CreateThread and pthread_create has to outlive the function That's not an issue for the API to solve, that is an issue for the user of the API to solve. pthread_create doesn't involve any memory management. > So, run_in_new_thread_and_join it is. Okay, that is fine. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From redestad at openjdk.org Thu Jul 28 09:28:35 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 28 Jul 2022 09:28:35 GMT Subject: RFR: 8288732: Reduce runtime of java.util.concurrent microbenchmarks In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 10:47:35 GMT, Claes Redestad wrote: > - Refactor so that various baseline micros are not run repeatedly with different parameter values that does not affect the baseline > - Tune iteration times, counts, forks.. > > Reduces runtime of java.util.concurrent micros from an estimated 14h43m to 1h21m Still waiting for a Reviewer on this one ------------- PR: https://git.openjdk.org/jdk/pull/9214 From itakiguchi at openjdk.org Thu Jul 28 10:32:48 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Thu, 28 Jul 2022 10:32:48 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: <0dcA7IfbHxn9XCjncuVEVSoA6jcygKHckFumifkPmuM=.adf1d4ff-dfc0-4f23-bfd2-94b03d773624@github.com> On Thu, 28 Jul 2022 01:46:26 GMT, Naoto Sato wrote: >> Hello @naotoj . >> I'm not reviewer, but I'd like to test this change. >> Could you wait for a moment ? >> Thanks. > > @takiguc Sure. Appreciate it. Many thanks @naotoj . I checked the latest IBM-864 mapping table. (I assume current OpenJDK's IBM864 may refer older mapping table) https://raw.githubusercontent.com/unicode-org/icu/main/icu4c/source/data/mappings/ibm-864_X110-1999.ucm .ucm file format is as follows: https://unicode-org.github.io/icu/userguide/conversion/data.html#ucm-file-format I checked roundtrip mapping | IBM864.map | ibm-864_X110-1999.ucm | | --- | --- | | 0x1a U+001a | 0x1a U+001c | | 0x1c U+001c | 0x1c U+007f | | **0x25 U+066a** | **0x25 U+0025** | | 0x7f U+007f | 0x7f U+001a | | 0x9f U+fffd | 0x9f U+200b | | 0xd7 U+fec1 | 0xd7 U+fec3 | | 0xd8 U+fec5 | 0xd8 U+fec7 | | 0xf1 U+0651 | 0xf1 U+fe7c | **Note**: 0x1a <-> U+001c / 0x1c <-> U+007f / 0x7f <-> U+001a entries are control character rotation for DOS. I think it should be ignored. I think, roundtrip side should be changed. 0x25 entry should be U+0025 on IBM864.map Add `0x25 U+066a` into IBM864.c2b Modify test/jdk/sun/nio/cs/mapping/Cp864.b2c for `0025 0025` Add `0025 066a` into test/jdk/sun/nio/cs/mapping/Cp864.c2b-irreversible This issue just for U+0025, but f possible, please add `0x9f, 0xd7, 0xd8, 0xf1` entries. ------------- PR: https://git.openjdk.org/jdk/pull/9661 From jvernee at openjdk.org Thu Jul 28 11:21:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 28 Jul 2022 11:21:50 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v2] In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 18:44:30 GMT, Thomas Stuefe wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes > > Hi @JornVernee, > > good job and thanks for doing it so quickly. Looks good, module the GetLastError comment. > > About the stack size and Alpine, I am fine with doing the A?pine-specific fix in a follow-up, or you can do it as part of this change. Strictly speaking its not part of this bug report to adjust the stack size. > > If you fix the GetLastError issue, I don't need another look. > Thanks, Thomas @tstuefe Do the changes I made look good? If so I'll go ahead and integrate. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From plevart at openjdk.org Thu Jul 28 11:23:40 2022 From: plevart at openjdk.org (Peter Levart) Date: Thu, 28 Jul 2022 11:23:40 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions > > > ...I can take this over, unless you want to do it, Aleksey? > > > > > > I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? > > On the other hand, this test is in tier2, so it makes lots of testing with other GCs not clean. I would like to have this fix in, and _then_ do any followups that might make the test more targeted. By removing System.gc() you effectively make the test a NO-OP. It then basically tests just that newly constructed SoftReference is not cleared in the next moment after construction. I would then rather just disable the test until it is fixed properly... ------------- PR: https://git.openjdk.org/jdk/pull/9533 From jwaters at openjdk.org Thu Jul 28 11:35:00 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 28 Jul 2022 11:35:00 GMT Subject: RFR: 8291454: Missing check for JLI C runtime library in CoreLibraries.gmk Message-ID: CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect ------------- Commit messages: - Add missing check in JLI macro definitions Changes: https://git.openjdk.org/jdk/pull/9669/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9669&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291454 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9669.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9669/head:pull/9669 PR: https://git.openjdk.org/jdk/pull/9669 From stuefe at openjdk.org Thu Jul 28 11:41:38 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 28 Jul 2022 11:41:38 GMT Subject: RFR: 8290059: Do not use std::thread in panama tests [v5] In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 14:34:49 GMT, Jorn Vernee wrote: >> This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). >> >> This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). >> >> Testing: Running the affected tests on platforms that implement the linker. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > run_in_new_thread_and_join Looks still good. ------------- PR: https://git.openjdk.org/jdk/pull/9599 From erikj at openjdk.org Thu Jul 28 12:30:02 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 28 Jul 2022 12:30:02 GMT Subject: RFR: 8291454: Missing check for JLI C runtime library in CoreLibraries.gmk In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 02:20:26 GMT, Julian Waters wrote: > CoreLibraries.gmk is missing a check for MSVCR_DLL. This results in a defined, but empty macro in libjli if it is not defined in the build system, which is incorrect Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9669 From plevart at openjdk.org Thu Jul 28 12:35:11 2022 From: plevart at openjdk.org (Peter Levart) Date: Thu, 28 Jul 2022 12:35:11 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 12:30:43 GMT, Aleksey Shipilev wrote: >>> ...I can take this over, unless you want to do it, Aleksey? >> >> I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? > >> > ...I can take this over, unless you want to do it, Aleksey? >> >> I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? > > On the other hand, this test is in tier2, so it makes lots of testing with other GCs not clean. I would like to have this fix in, and *then* do any followups that might make the test more targeted. @shipilev you said that the test fails with some other GCs (Parallel, Shenandoah, ...). Who is responsible to select the GC algorithm? What I'm asking is whether one should explicitly enumerate several @runs of the test with explicit selection of different GCs (which ones?) or is this a matter of some external test infrastructure that runs all the tests in the suite and pre-selects different GCs for them? ------------- PR: https://git.openjdk.org/jdk/pull/9533 From plevart at openjdk.org Thu Jul 28 13:46:39 2022 From: plevart at openjdk.org (Peter Levart) Date: Thu, 28 Jul 2022 13:46:39 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions I managed to construct/fix test that passes on G1, Shenandoah and ZGC... https://github.com/plevart/jdk/commit/2dbce34d678bee995c808f3bb2a021bcc98b5d01 The combination of JVM options: -Xmx10m -XX:SoftRefLRUPolicyMSPerMB=1 ... makes ZGC and Shenandoah very aggressive and practically causes SoftReferences to be treated equally as WeakReferences. By increasing the max. heap size a bit and using defaults for SoftRefLRUPolicyMSPerMB (I believe 1000 ms/MB for G1 and 200 ms/MB for Shenandoah and ZGC), G1 and Shenandoah were happy with the changed test. For ZGC I also had to make sure that the CacheEffectiveness test is executed as 1st test in VM instance, followed by CacheReleaseUnderMemoryPressure. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From rriggs at openjdk.org Thu Jul 28 13:59:42 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 28 Jul 2022 13:59:42 GMT Subject: RFR: 8288732: Reduce runtime of java.util.concurrent microbenchmarks In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 10:47:35 GMT, Claes Redestad wrote: > - Refactor so that various baseline micros are not run repeatedly with different parameter values that does not affect the baseline > - Tune iteration times, counts, forks.. > > Reduces runtime of java.util.concurrent micros from an estimated 14h43m to 1h21m LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9214 From plevart at openjdk.org Thu Jul 28 14:26:49 2022 From: plevart at openjdk.org (Peter Levart) Date: Thu, 28 Jul 2022 14:26:49 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 12:30:43 GMT, Aleksey Shipilev wrote: >>> ...I can take this over, unless you want to do it, Aleksey? >> >> I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? > >> > ...I can take this over, unless you want to do it, Aleksey? >> >> I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? > > On the other hand, this test is in tier2, so it makes lots of testing with other GCs not clean. I would like to have this fix in, and *then* do any followups that might make the test more targeted. So how do we proceed @shipilev ? I open another issue or are you willing to accept my changes into your issue? ------------- PR: https://git.openjdk.org/jdk/pull/9533 From shade at openjdk.org Thu Jul 28 14:35:42 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 28 Jul 2022 14:35:42 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 12:30:43 GMT, Aleksey Shipilev wrote: >>> ...I can take this over, unless you want to do it, Aleksey? >> >> I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? > >> > ...I can take this over, unless you want to do it, Aleksey? >> >> I find it dubious to try and guess what GCs would do with non-strong refs, but feel free. Don't reassign the bug yet, just see how messy that would be? > > On the other hand, this test is in tier2, so it makes lots of testing with other GCs not clean. I would like to have this fix in, and *then* do any followups that might make the test more targeted. > So how do we proceed @shipilev ? I open another issue or are you willing to accept my changes into your issue? I prefer to commit the simpler (mine) version first, and the follow up with any more sophisticated attempt to fix it. > It then basically tests just that newly constructed SoftReference is not cleared in the next moment after construction. Yes, but not really. There is still a 100ms sleep and reference processing involved, which somewhat verifies that the cache is not blown away immediately/accidentally. > Who is responsible to select the GC algorithm? CIs routinely test existing suites with different GCs. The PR body contains a sample reproducer how that happens. If you are doing the separate `@run` statements, you need to also check for `@requires vm.gc.XXX`, etc. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From jvernee at openjdk.org Thu Jul 28 14:55:58 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 28 Jul 2022 14:55:58 GMT Subject: Integrated: 8290059: Do not use std::thread in panama tests In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote: > This patch removes the use of std::thread from the `java.lang.foreign` tests, and switches to the OS specific thread APIs, in order to change things such as the stack size on some platforms where this is required in the future (see the JBS issue). > > This is done by adding a small header-only library that exposes a function to run code in freshly spawned threads (`run_async`). > > Testing: Running the affected tests on platforms that implement the linker. This pull request has now been integrated. Changeset: 54a2c5a6 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/54a2c5a6d148fecbe87f861933e4ae9459bacf65 Stats: 179 lines in 7 files changed: 131 ins; 7 del; 41 mod 8290059: Do not use std::thread in panama tests Reviewed-by: mcimadamore, stuefe, erikj ------------- PR: https://git.openjdk.org/jdk/pull/9599 From naoto at openjdk.org Thu Jul 28 16:22:31 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 28 Jul 2022 16:22:31 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: <0dcA7IfbHxn9XCjncuVEVSoA6jcygKHckFumifkPmuM=.adf1d4ff-dfc0-4f23-bfd2-94b03d773624@github.com> References: <0dcA7IfbHxn9XCjncuVEVSoA6jcygKHckFumifkPmuM=.adf1d4ff-dfc0-4f23-bfd2-94b03d773624@github.com> Message-ID: On Thu, 28 Jul 2022 10:29:07 GMT, Ichiroh Takiguchi wrote: >> @takiguc Sure. Appreciate it. > > Many thanks @naotoj . > > I checked the latest IBM-864 mapping table. > (I assume current OpenJDK's IBM864 may refer older mapping table) > https://raw.githubusercontent.com/unicode-org/icu/main/icu4c/source/data/mappings/ibm-864_X110-1999.ucm > .ucm file format is as follows: > https://unicode-org.github.io/icu/userguide/conversion/data.html#ucm-file-format > > I checked roundtrip mapping > (Roundtrip entries have `|0` at the end of line) > | IBM864.map | ibm-864_X110-1999.ucm | > | --- | --- | > | 0x1a U+001a | 0x1a U+001c | > | 0x1c U+001c | 0x1c U+007f | > | **0x25 U+066a** | **0x25 U+0025** | > | 0x7f U+007f | 0x7f U+001a | > | 0x9f U+fffd | 0x9f U+200b | > | 0xd7 U+fec1 | 0xd7 U+fec3 | > | 0xd8 U+fec5 | 0xd8 U+fec7 | > | 0xf1 U+0651 | 0xf1 U+fe7c | > > **Note**: 0x1a <-> U+001c / 0x1c <-> U+007f / 0x7f <-> U+001a entries are control character rotation for DOS. > I think it should be ignored. > > I think, roundtrip side should be changed. > 0x25 entry should be U+0025 on IBM864.map > Add `0x25 U+066a` into IBM864.c2b > > Modify test/jdk/sun/nio/cs/mapping/Cp864.b2c for `0025 0025` > Add `0025 066a` into test/jdk/sun/nio/cs/mapping/Cp864.c2b-irreversible > > This issue just for U+0025, but f possible, please add `0x9f, 0xd7, 0xd8, 0xf1` entries. Thanks for trying it out @takiguc. However, I am not planning to change any existing mappings because of the obvious compatibility issues. The fix I proposed is safe because it is additional, which used to be unmappable (thus turned into a replacement '?'). ------------- PR: https://git.openjdk.org/jdk/pull/9661 From plevart at openjdk.org Thu Jul 28 17:36:47 2022 From: plevart at openjdk.org (Peter Levart) Date: Thu, 28 Jul 2022 17:36:47 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 14:33:40 GMT, Aleksey Shipilev wrote: > > > It then basically tests just that newly constructed SoftReference is not cleared in the next moment after construction. > > Yes, but not really. There is still a 100ms sleep and reference processing involved, which somewhat verifies that the cache is not blown away immediately/accidentally. Just a 100ms sleep means hardly any chance that reference processing will be involved as VM practically does nothing at that time to trigger GC. If you are referring to this: // to trigger any ReferenceQueue processing... lookupObjectStreamClass(AnotherTestClass.class); ...then the comment is perhaps misleading. Looking up another class just caches another entry and at the same time processes any enqueued References to remove stale cache entries. But for a Reference to be enqueued into a ReferenceQueue, GC threads must 1st clear it and link it into a "pending" list, ReferenceHandler java thread must then unlink it from the "pending" list and enqueue it into Reference's associated ReferenceQueue and only then can the request for another class process it from that ReferenceQueue. But the test is not observing that 3rd part (cleanup of stale cache entries). It observes the 1st part (atomic clearing of all XxxReferences that refer to the same referent) which is performed by GC. So this is hardly going to happen as the sole trigger for that (since System.gc() was removed) remains allocation of new objects and not enough may be allocated to trigger GC. But if your purpose was to shut up the failing test, then this is one way to do it. > > > Who is responsible to select the GC algorithm? > > CIs routinely test existing suites with different GCs. The PR body contains a sample reproducer how that happens. If you are doing the separate `@run` statements, you need to also check for `@requires vm.gc.XXX`, etc. Thanks for the hint. I'll add that. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From plevart at openjdk.org Thu Jul 28 17:48:38 2022 From: plevart at openjdk.org (Peter Levart) Date: Thu, 28 Jul 2022 17:48:38 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions What I was trying to say above is that without System.gc() the test would succeed even if caching was not actually there and lookup always constructed new ObjectStreamClass instance. There's not enough allocation activity to clear the WeakReference constructed in the test with the ObjectStreamClass referent even if that referent was only weakly reachable... ------------- PR: https://git.openjdk.org/jdk/pull/9533 From mr at openjdk.org Thu Jul 28 17:51:25 2022 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 28 Jul 2022 17:51:25 GMT Subject: [jdk19] RFR: 8291512: Snippetize modules API examples Message-ID: The specification of the modules API contains several non-normative code examples. We should convert them to use snippets, per [JEP 413](https://openjdk.org/jeps/413). ------------- Commit messages: - 8291512: Snippetize modules API examples Changes: https://git.openjdk.org/jdk19/pull/156/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=156&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291512 Stats: 22 lines in 4 files changed: 2 ins; 9 del; 11 mod Patch: https://git.openjdk.org/jdk19/pull/156.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/156/head:pull/156 PR: https://git.openjdk.org/jdk19/pull/156 From darcy at openjdk.org Thu Jul 28 17:56:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 28 Jul 2022 17:56:45 GMT Subject: [jdk19] RFR: 8291512: Snippetize modules API examples In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 17:41:31 GMT, Mark Reinhold wrote: > The specification of the modules API contains several non-normative code examples. We should convert them to use snippets, per [JEP 413](https://openjdk.org/jeps/413). Looks fine; may want to change this issue to be a subtask of JDK-8289774. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk19/pull/156 From joehw at openjdk.org Thu Jul 28 18:07:33 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 28 Jul 2022 18:07:33 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote: > Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9661 From shade at openjdk.org Thu Jul 28 18:14:38 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 28 Jul 2022 18:14:38 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions All right, fine. This bug takes too much time. Take the bug, but problem-list the test first. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From shade at openjdk.org Thu Jul 28 18:14:39 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 28 Jul 2022 18:14:39 GMT Subject: Withdrawn: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote: > Test appears to pass fine with G1. But it fails with other GCs, for example Parallel, Shenandoah, etc, it fails: > > > $ CONF=linux-x86_64-server-fastdebug make test TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java TEST_VM_OPTS="-XX:+UseParallelGC" > > test ObjectStreamClassCaching.testCacheReleaseUnderMemoryPressure(): success > test ObjectStreamClassCaching.testCachingEffectiveness(): failure > java.lang.AssertionError: Cache lost entry although memory was not under pressure expected [false] but found [true] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertFalse(Assert.java:67) > > > I believe this is because `System.gc()` is not that reliable about what happens with weak references. As seen with other GCs, they can clear the weakrefs on Full GC. In fact, the test fails with G1 if we do a second System.gc() in this test. So the test itself is flaky. The fix is to avoid doing `System.gc()` altogether in that subtest. The test is still retained to see that reference is not cleared for a while. > > Additional testing: > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseSerialGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseParallelGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseG1GC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseShenandoahGC`, 100 repetitions > - [x] Linux x86_64 fastdebug, affected test with `-XX:+UseZGC`, 100 repetitions This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9533 From mr at openjdk.org Thu Jul 28 18:15:07 2022 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 28 Jul 2022 18:15:07 GMT Subject: [jdk19] RFR: 8291512: Snippetize modules API examples [v2] In-Reply-To: References: Message-ID: <5zV334U9pSrfGbO9HB49yqCDiu9h3lwQUBF3Z8jPXVk=.5ad0bd05-e7d3-4e13-84db-412338312dca@github.com> > The specification of the modules API contains several non-normative code examples. We should convert them to use snippets, per [JEP 413](https://openjdk.org/jeps/413). Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Fix header in ModuleLayer ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/156/files - new: https://git.openjdk.org/jdk19/pull/156/files/22efa8cb..4a79fe11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=156&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=156&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/156.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/156/head:pull/156 PR: https://git.openjdk.org/jdk19/pull/156 From mr at openjdk.org Thu Jul 28 18:19:35 2022 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 28 Jul 2022 18:19:35 GMT Subject: [jdk19] RFR: 8291512: Snippetize modules API examples [v2] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 17:54:33 GMT, Joe Darcy wrote: > Looks fine; may want to change this issue to be a subtask of JDK-8289774. Thanks. Converted to subtask. ------------- PR: https://git.openjdk.org/jdk19/pull/156 From mr at openjdk.org Thu Jul 28 18:26:12 2022 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 28 Jul 2022 18:26:12 GMT Subject: [jdk19] Integrated: 8291512: Snippetize modules API examples In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 17:41:31 GMT, Mark Reinhold wrote: > The specification of the modules API contains several non-normative code examples. We should convert them to use snippets, per [JEP 413](https://openjdk.org/jeps/413). This pull request has now been integrated. Changeset: 1d16c91b Author: Mark Reinhold URL: https://git.openjdk.org/jdk19/commit/1d16c91ba7733d07ce609b83b9d01c5ae74f965d Stats: 23 lines in 4 files changed: 2 ins; 9 del; 12 mod 8291512: Snippetize modules API examples Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk19/pull/156 From duke at openjdk.org Thu Jul 28 19:43:04 2022 From: duke at openjdk.org (Gaurav Chaudhari) Date: Thu, 28 Jul 2022 19:43:04 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v4] In-Reply-To: References: Message-ID: > This is a REDO of the Fix that was incompletely implemented earlier: > [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660) > > Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days. > > I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works: > _(where 7200 represents 7200 seconds -> +2 hour offset)_ > Sample output: > ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png) Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: 8288377: Adjusted length check for returned gmt-offset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9312/files - new: https://git.openjdk.org/jdk/pull/9312/files/8ca0a727..b09df3d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9312&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9312.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9312/head:pull/9312 PR: https://git.openjdk.org/jdk/pull/9312 From holo3146 at gmail.com Thu Jul 28 20:11:17 2022 From: holo3146 at gmail.com (Holo The Sage Wolf) Date: Thu, 28 Jul 2022 23:11:17 +0300 Subject: Coupling in ExtentLocal Message-ID: Hello core-libs devs, The ExtentLocal proposal adds a new way to transfer arguments to methods, e.g. (taken from project?s loom git ) private static final ExtentLocal CREDENTIALS = ExtentLocal.newInstance(); Credentials creds = ... ExtentLocal.where(CREDENTIALS, creds).run(() -> { ... Connection connection = connectDatabase(); ... }); ... Connection connectDatabase() { Credentials credentials = CREDENTIALS.get(); ... } I have a question about the proposal, why not allow try-with-resources with this API? private static final ExtentLocal CREDENTIALS = ExtentLocal.newInstance(); Credentials creds = ...// Hopefully one day Java will support anonymous variables in "try-with-resource" to get rid of the "var _ =" part// note that we still can introduce several binding with chaining ".where" without introducing several dummy variablestry(var _ = ExtentLocal.where(CREDENTIALS, creds)) { // maybe have a new method instead of "where" that returns some wrapper class, so ExtentLocal.Carrier won't need to implement AutoClosable ... Connection connection = connectDatabase(); ... } ... Connection connectDatabase() { Credentials credentials = CREDENTIALS.get(); ... } The syntax of .where(...)....where(...).run(...) is nice, but it is weird that we ?introduce variables? from a different clause then the run (I know it is only bindings, but it acts similar enough), the syntax of try-with-resources is already well known to introduce new variables. Another advantage is the ability of ?catch? block without increasing nesting: try { ExtentLocal.where(CREDENTIALS, creds).run(() -> { Connection connection = connectDatabase(); }); } catch (...) { ... } versus try(var _ = ExtentLocal.where(CREDENTIALS, creds)) { Connection connection = connectDatabase(); } catch (...) { ... } (Another solution to this is too add .catch method to ExtentLocal.Carrier to handle exceptions, but this will cause problems with call vs run) Further furthermore, one can combine it with structured concurrency : public Response handle(Credentials creds) throws ExecutionException, InterruptedException { try (var scope = new StructuredTaskScope.ShutdownOnFailure(); var _ = ExtentLocal.where(CREDENTIALS, creds)) { // functionally this binding is part of the scope Future user = scope.fork(() -> findUser()); Future order = scope.fork(() -> fetchOrder()); scope.join().throwIfFailed(); return new Response(user.resultNow(), order.resultNow()); } } Instead of doing something like: // If this solution is possible at all, if the Credentials are a field in the object then you need to introduce some method to use "handle()" with the correct Extent binding, or wrap the body of "handle()" inside of the method "handle()" which needlessly increase nestingspublic Response handle(Credentials creds) throws ExecutionException, InterruptedException { return ExtentLocal.where(CREDENTIALS, creds).call(this::handle) } public Response handle() throws ExecutionException, InterruptedException { try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { Future user = scope.fork(() -> findUser()); Future order = scope.fork(() -> fetchOrder()); scope.join(); scope.throwIfFailed(); return new Response(user.resultNow(), order.resultNow()); } } Before saying that I shouldn?t couple handle() to CREDENTIALS, note that findUser and fetchOrder are already coupled to it, in fact the use of private ExtentLocal variable introduce coupling pretty much by definition (which is the intended use case , although I can think on some use cases with public ExtentLocal). Now, I do really like the where-run syntax, but I see a lot of merits in allowing also try-with-resources as well. Thanks for the read, Yuval Paz -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Thu Jul 28 20:37:30 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 28 Jul 2022 20:37:30 GMT Subject: RFR: JDK-8289106: Add model of class file versions to core reflection [v4] In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> Message-ID: > JDK-8289106: Add model of class file versions to core reflection Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Finish more precise versioned location support; udpate tests. - Partial implementation of version-depdendent locations() with tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9299/files - new: https://git.openjdk.org/jdk/pull/9299/files/998b6f6b..f747eb41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=02-03 Stats: 470 lines in 4 files changed: 439 ins; 4 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/9299.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9299/head:pull/9299 PR: https://git.openjdk.org/jdk/pull/9299 From darcy at openjdk.org Thu Jul 28 20:43:31 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 28 Jul 2022 20:43:31 GMT Subject: RFR: JDK-8289106: Add model of class file versions to core reflection [v5] In-Reply-To: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> Message-ID: > JDK-8289106: Add model of class file versions to core reflection Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Appease jcheck. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9299/files - new: https://git.openjdk.org/jdk/pull/9299/files/f747eb41..34aa4f42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9299&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9299.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9299/head:pull/9299 PR: https://git.openjdk.org/jdk/pull/9299 From darcy at openjdk.org Thu Jul 28 20:43:35 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 28 Jul 2022 20:43:35 GMT Subject: RFR: JDK-8289106: Add model of class file versions to core reflection [v4] In-Reply-To: References: <2rl1Ry8M5LCeb1Rq8XJ8V04ZC6R5c5DroxDXXjLkTUs=.d5f8ddc4-6f64-4779-b8e9-a8296aa53f88@github.com> Message-ID: On Thu, 28 Jul 2022 20:37:30 GMT, Joe Darcy wrote: >> JDK-8289106: Add model of class file versions to core reflection > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Finish more precise versioned location support; udpate tests. > - Partial implementation of version-depdendent locations() with tests. Updated the PR with implementations and tests for the version-specific location method. CSR ready for review. ------------- PR: https://git.openjdk.org/jdk/pull/9299 From naoto at openjdk.org Thu Jul 28 20:54:21 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 28 Jul 2022 20:54:21 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 20:31:44 GMT, Alisen Chung wrote: >> open l10n msg drop >> All tests passed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed localized files from base - src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_US.properties: this should not be moved from `java.base` module - I still need some comments explaining `XXX=XXX` in the root bundle of `CurrencyNames`. Something like These currency symbol entries are for the root bundle only to avoid throwing a MissingResourceException. Should not be copied into each localized resource bundle. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: CNY=\uffe5 Do not remove the original translation. ------------- Changes requested by naoto (Reviewer). PR: https://git.openjdk.org/jdk19/pull/154 From duke at openjdk.org Fri Jul 29 01:47:22 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 29 Jul 2022 01:47:22 GMT Subject: Integrated: 8289511: Improve test coverage for XPath Axes: child In-Reply-To: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> References: <4t8ezFStxJDZtrmqC9KgtJZyxUfHZGTi2nRxwRY3Ykw=.dfc6f1de-3b2b-45cc-9578-25aabb94f850@github.com> Message-ID: On Wed, 13 Jul 2022 21:04:11 GMT, Bill Huang wrote: > This is a subtask of [JDK-8286091](https://bugs.openjdk.org/browse/JDK-8286091) which is aiming to improve XPath expression test coverage. The goal of this subtask is validating the XPath child axis specifier in various ways. This pull request has now been integrated. Changeset: cfe9026f Author: Bill Huang Committer: Joe Wang URL: https://git.openjdk.org/jdk/commit/cfe9026fe0506488cc0f0557299cfa585811d194 Stats: 237 lines in 1 file changed: 237 ins; 0 del; 0 mod 8289511: Improve test coverage for XPath Axes: child Reviewed-by: joehw ------------- PR: https://git.openjdk.org/jdk/pull/9484 From joehw at openjdk.org Fri Jul 29 02:47:05 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 29 Jul 2022 02:47:05 GMT Subject: RFR: 8290740: Catalog not used when the handler is null Message-ID: Patch to make sure the Catalog is used even when the handler is null. ------------- Commit messages: - 8290740: Catalog not used when the handler is null Changes: https://git.openjdk.org/jdk/pull/9682/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9682&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290740 Stats: 76 lines in 3 files changed: 22 ins; 9 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/9682.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9682/head:pull/9682 PR: https://git.openjdk.org/jdk/pull/9682 From xgong at openjdk.org Fri Jul 29 04:09:05 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 29 Jul 2022 04:09:05 GMT Subject: RFR: 8291118: [vectorapi] Optimize the implementation of lanewise FIRST_NONZERO Message-ID: Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a != 0 ? a : b`", which can be implemented with existing APIs like "`compare + blend`". The current implementation is more complex especially for the floating point type vectors. The main idea is: 1) mask = a.compare(0, ne); 2) b = b.blend(0, mask); 3) result = a | b; And for the floating point types, it needs the vector reinterpretation between the floating point type and the relative integral type, since the final "`OR`" operation is only valid for bitwise integral types. A simpler implementation is: 1) mask = a.compare(0, eq); 2) result = a.blend(b, mask); This could save the final "`OR`" operation and the related reinterpretation between FP and integral types. Here are the performance data of the "`FIRST_NONZERO`" benchmarks (please see the benchmark details for byte vector from [1]) on ARM NEON system: Benchmark (size) Mode Cnt Before After Units ByteMaxVector.FIRST_NONZERO 1024 thrpt 15 12107.422 18385.157 ops/ms ByteMaxVector.FIRST_NONZEROMasked 1024 thrpt 15 9765.282 14739.775 ops/ms DoubleMaxVector.FIRST_NONZERO 1024 thrpt 15 1798.545 2331.214 ops/ms DoubleMaxVector.FIRST_NONZEROMasked 1024 thrpt 15 1211.838 1810.644 ops/ms FloatMaxVector.FIRST_NONZERO 1024 thrpt 15 3491.924 4377.167 ops/ms FloatMaxVector.FIRST_NONZEROMasked 1024 thrpt 15 2307.085 3606.576 ops/ms IntMaxVector.FIRST_NONZERO 1024 thrpt 15 3602.727 5610.258 ops/ms IntMaxVector.FIRST_NONZEROMasked 1024 thrpt 15 2726.843 4210.741 ops/ms LongMaxVector.FIRST_NONZERO 1024 thrpt 15 1819.886 2974.655 ops/ms LongMaxVector.FIRST_NONZEROMasked 1024 thrpt 15 1337.737 2315.094 ops/ms ShortMaxVector.FIRST_NONZERO 1024 thrpt 15 6603.642 9586.320 ops/ms ShortMaxVector.FIRST_NONZEROMasked 1024 thrpt 15 5222.006 7991.443 ops/ms We can also observe the similar improvement on x86 system. [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L266 ------------- Commit messages: - 8291118: [vectorapi] Optimize the implementation of lanewise FIRST_NONZERO Changes: https://git.openjdk.org/jdk/pull/9683/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9683&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291118 Stats: 86 lines in 7 files changed: 9 ins; 38 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/9683.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9683/head:pull/9683 PR: https://git.openjdk.org/jdk/pull/9683 From itakiguchi at openjdk.org Fri Jul 29 05:19:31 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Fri, 29 Jul 2022 05:19:31 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: <0dcA7IfbHxn9XCjncuVEVSoA6jcygKHckFumifkPmuM=.adf1d4ff-dfc0-4f23-bfd2-94b03d773624@github.com> Message-ID: On Thu, 28 Jul 2022 16:18:51 GMT, Naoto Sato wrote: >> Many thanks @naotoj . >> >> I checked the latest IBM-864 mapping table. >> (I assume current OpenJDK's IBM864 may refer older mapping table) >> https://raw.githubusercontent.com/unicode-org/icu/main/icu4c/source/data/mappings/ibm-864_X110-1999.ucm >> .ucm file format is as follows: >> https://unicode-org.github.io/icu/userguide/conversion/data.html#ucm-file-format >> >> I checked roundtrip mapping >> (Roundtrip entries have `|0` at the end of line) >> | IBM864.map | ibm-864_X110-1999.ucm | >> | --- | --- | >> | 0x1a U+001a | 0x1a U+001c | >> | 0x1c U+001c | 0x1c U+007f | >> | **0x25 U+066a** | **0x25 U+0025** | >> | 0x7f U+007f | 0x7f U+001a | >> | 0x9f U+fffd | 0x9f U+200b | >> | 0xd7 U+fec1 | 0xd7 U+fec3 | >> | 0xd8 U+fec5 | 0xd8 U+fec7 | >> | 0xf1 U+0651 | 0xf1 U+fe7c | >> >> **Note**: 0x1a <-> U+001c / 0x1c <-> U+007f / 0x7f <-> U+001a entries are control character rotation for DOS. >> I think it should be ignored. >> >> I think, roundtrip side should be changed. >> 0x25 entry should be U+0025 on IBM864.map >> Add `0x25 U+066a` into IBM864.c2b >> >> Modify test/jdk/sun/nio/cs/mapping/Cp864.b2c for `0025 0025` >> Add `0025 066a` into test/jdk/sun/nio/cs/mapping/Cp864.c2b-irreversible >> >> This issue just for U+0025, but f possible, please add `0x9f, 0xd7, 0xd8, 0xf1` entries. > > Thanks for trying it out @takiguc. However, I am not planning to change any existing mappings because of the obvious compatibility issues. The fix I proposed is safe because it is additional, which used to be unmappable (thus turned into a replacement '?'). Hello @naotoj . I checked [JDK-8290488](https://bugs.openjdk.org/browse/JDK-8290488). This issue was tested by Windows 10. I think we need to confirm expected result for b2c side to reporter. I checked MS's 864 via following test program on my Windows 10. >type b2c_1.ps1 param($code, $hex) $h = [string]$hex $enc_r = [Text.Encoding]::GetEncoding([int]$code) [byte[]]$ba = @() for($i = 0; $i -lt $h.length; $i+=2) { $ba += ([System.Convert]::ToInt32($h.SubString($i,2), 16)) } $s = "" $enc_r.GetChars($ba) | foreach {$s += [System.Convert]::ToInt32($_).ToString("X4")} $s >powershell -NoProfile -ExecutionPolicy Unrestricted .\b2c_1.ps1 864 25 0025 Please ignore about 0xD7,0xD8,0xF1 if the target platform is Windows. Note: Test result for c2b side. >type c2b_1.ps1 param($code, $hex) $enc_r = [Text.Encoding]::GetEncoding([int]$code) [char[]]$ca = @() $ca += ([System.Convert]::ToInt32([string]$hex, 16)) $s = "" $enc_r.GetBytes($ca) | foreach {$s += [System.Convert]::ToInt32($_).ToString("X2")} $s >powershell -NoProfile -ExecutionPolicy Unrestricted .\c2b_1.ps1 864 0025 25 >powershell -NoProfile -ExecutionPolicy Unrestricted .\c2b_1.ps1 864 066A 25 ------------- PR: https://git.openjdk.org/jdk/pull/9661 From kasperni at gmail.com Fri Jul 29 09:15:38 2022 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 29 Jul 2022 11:15:38 +0200 Subject: Coupling in ExtentLocal In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 at 22:11, Holo The Sage Wolf wrote: > I have a question about the proposal, why not allow try-with-resources > with this API? > Hi, For Loom related questions, loom-dev at openjdk.org is probably a better fit. The main problem with TWR is that it cannot guard against non-nested use. Because there are no way to force the user to call close(). See more here [1] /Kasper [1] https://mail.openjdk.org/pipermail/loom-dev/2021-June/002558.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From plevart at openjdk.org Fri Jul 29 09:16:17 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 29 Jul 2022 09:16:17 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs Message-ID: This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods: - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1. The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah. ------------- Commit messages: - ObjectStreamClassCaching test rework - run with various GCs Changes: https://git.openjdk.org/jdk/pull/9684/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9684&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283276 Stats: 89 lines in 1 file changed: 62 ins; 11 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9684.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9684/head:pull/9684 PR: https://git.openjdk.org/jdk/pull/9684 From plevart at openjdk.org Fri Jul 29 10:39:57 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 29 Jul 2022 10:39:57 GMT Subject: RFR: 8283276: java/io/ObjectStreamClass/ObjectStreamClassCaching.java fails with various GCs In-Reply-To: References: Message-ID: <9ppqXJbR1YpxBqvS98bN9dbYe6FMacnmMUIV4JmXrkc=.66fd6cba-9a76-4006-abb3-61784ce9b7cc@github.com> On Fri, 29 Jul 2022 09:05:53 GMT, Peter Levart wrote: > This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching test which is failing with various GCs != G1. The test class contains 2 test methods: > - test2CacheReleaseUnderMemoryPressure - this one was not logically changed at all - just one method was inlined > - test1CacheEffectiveness - this one now uses a different strategy which doesn't involve calling System.gc() in order to trigger reference processing in GC which is, as test failures reveal, sometimes to aggressive and triggers processing not only WeakReference(s) but also SoftReference(s). Instead, the test now gradually builds up memory pressure while checking what's happening to two WeakReference(s): ref1 - wrapping a cached ObjectStreamClass instance; and: ref2 - wrapping a new Object() instance. The "effectiveness" of caching is confirmed by verifying that weakly reachable new Object() referent of ref2 is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1. > The test now contains several @run(s) with explicitly selected set of GC algorithms: G1, Parallel, ZGC, Shenandoah. I can make another PR/issue to just problem-list the test if you feel that reviewing this PR might take some time. But as this is a test-only fix with noreg-self label and is intended to be backported to JDK 19, this would just duplicate the administrative effort... ------------- PR: https://git.openjdk.org/jdk/pull/9684 From holo3146 at gmail.com Fri Jul 29 14:35:30 2022 From: holo3146 at gmail.com (Holo The Sage Wolf) Date: Fri, 29 Jul 2022 17:35:30 +0300 Subject: Coupling in ExtentLocal In-Reply-To: References: Message-ID: Hi, Thanks for the response Kasper, the reason I sent the mail to core-libs is because JDK-8263012 is assigned to "core-libs". I added loom-devs to the chain. What Andrew Haley wrote is correct, it is also correct pretty much for every implementation of `AutoClosable` (although, unlike ExtentLocals, most implementations of AutoClosable will cause resource leak, and ExtentLocal can cause a big logical bug). The idea of `strong try-with-resources` seems to solve the problem (and can force better APIs in other places), is there a conversation about this feature? Yuval Paz On Fri, Jul 29, 2022 at 12:15 PM Kasper Nielsen wrote: > > On Thu, 28 Jul 2022 at 22:11, Holo The Sage Wolf > wrote: > >> I have a question about the proposal, why not allow try-with-resources >> with this API? >> > Hi, > > For Loom related questions, loom-dev at openjdk.org is probably a better > fit. > > The main problem with TWR is that it cannot guard against non-nested use. > Because there are no way to force the user to call close(). See more here > [1] > > /Kasper > > [1] https://mail.openjdk.org/pipermail/loom-dev/2021-June/002558.html > -- Holo The Wise Wolf Of Yoitsu -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Fri Jul 29 16:05:15 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 29 Jul 2022 16:05:15 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for ":" at last index [v3] In-Reply-To: References: Message-ID: <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com> On Thu, 21 Jul 2022 19:58:50 GMT, Brian Burkhalter wrote: >> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check >> >> int pos = syntaxAndInput.indexOf(':'); >> if (pos <= 0 || pos == syntaxAndInput.length()) >> >> to >> >> if (pos <= 0) > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290047: Remove IAE message in JrtFileSystem.getPathMatcher() Is there anything else to be done in this PR? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From naoto at openjdk.org Fri Jul 29 16:17:56 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 29 Jul 2022 16:17:56 GMT Subject: RFR: 8290488: IBM864 character encoding implementation bug In-Reply-To: References: Message-ID: <5TntCtdD8Fbjx1IdZZLmaBFwHiQlFwqP9GX62Wqs-NM=.1dc8c55d-373b-490d-93c1-be18ef2b7847@github.com> On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote: > Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM. Sorry, but I don't have any intention to change the current roundtrip behavior of 0x25 <-> U+066A in Cp/IBM864 converter. Changing it to something else will introduce an incompatible behavior with prior JDKs. ------------- PR: https://git.openjdk.org/jdk/pull/9661 From rriggs at openjdk.org Fri Jul 29 16:55:25 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 29 Jul 2022 16:55:25 GMT Subject: RFR: 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fail: More or fewer pipes than expected Message-ID: The test java/lang/ProcessBuilder/PipelineLeaksFD.java fails intermittently, usually associated with fastdebug and -Xcomp. It reports extra file descriptors are open that not expected. The test of pipelines did not explicitly use or close the stderr streams of each stream except the last. The intermittent nature of the failure is due to the non-deterministic GC interactions that close the streams when they become un-referenced. The solution in this case is to redirect the error stream to the stdout stream for each pipeline stage except the last. The test is removed from the ProblemList-Xcomp. ------------- Commit messages: - Merge branch '8290885-Pipeline-leaks2' of https://github.com/RogerRiggs/jdk into 8290885-Pipeline-leaks2 - 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fails - 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fail: More or fewer pipes than expected Changes: https://git.openjdk.org/jdk/pull/9687/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9687&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290885 Stats: 12 lines in 2 files changed: 7 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9687.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9687/head:pull/9687 PR: https://git.openjdk.org/jdk/pull/9687 From lancea at openjdk.org Fri Jul 29 16:57:36 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 29 Jul 2022 16:57:36 GMT Subject: RFR: 8290740: Catalog not used when the handler is null In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 02:38:25 GMT, Joe Wang wrote: > Patch to make sure the Catalog is used even when the handler is null. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9682 From bpb at openjdk.org Fri Jul 29 17:07:39 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 29 Jul 2022 17:07:39 GMT Subject: RFR: 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fail: More or fewer pipes than expected In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 16:49:36 GMT, Roger Riggs wrote: > The test java/lang/ProcessBuilder/PipelineLeaksFD.java fails intermittently, usually associated with fastdebug and -Xcomp. > It reports extra file descriptors are open that not expected. > The test of pipelines did not explicitly use or close the stderr streams of each stream except the last. > The intermittent nature of the failure is due to the non-deterministic GC interactions that close the streams when they become un-referenced. > > The solution in this case is to redirect the error stream to the stdout stream for each pipeline stage except the last. > > The test is removed from the ProblemList-Xcomp. Looks reasonable. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9687 From hseigel at openjdk.org Fri Jul 29 18:12:38 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 29 Jul 2022 18:12:38 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information Message-ID: Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. Thanks, Harold ------------- Commit messages: - 8291360: Create entry points to expose low-level class file information Changes: https://git.openjdk.org/jdk/pull/9688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291360 Stats: 704 lines in 9 files changed: 703 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9688.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9688/head:pull/9688 PR: https://git.openjdk.org/jdk/pull/9688 From achung at openjdk.org Fri Jul 29 18:13:25 2022 From: achung at openjdk.org (Alisen Chung) Date: Fri, 29 Jul 2022 18:13:25 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: > open l10n msg drop > All tests passed. Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/154/files - new: https://git.openjdk.org/jdk19/pull/154/files/6776bd0f..737b253f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=02-03 Stats: 4 lines in 3 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/154.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154 PR: https://git.openjdk.org/jdk19/pull/154 From darcy at openjdk.org Fri Jul 29 18:15:15 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 29 Jul 2022 18:15:15 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:02:46 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold src/java.base/share/classes/java/lang/Class.java line 4700: > 4698: * returned. If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. > 4699: */ > 4700: private int getClassAccessFlagsRaw() { For a "raw" method, it might be better to return the flags on the array class object itself rather than loop down to the component type. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From naoto at openjdk.org Fri Jul 29 18:19:42 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 29 Jul 2022 18:19:42 GMT Subject: RFR: 8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable [v4] In-Reply-To: References: Message-ID: <6yHp_l2cal4zIoIm22BPUjI4yEMRf_DEL4Hzx5UsGbA=.28f5f6ee-f163-4066-a7b7-d333bc17ffe8@github.com> On Thu, 28 Jul 2022 19:43:04 GMT, Gaurav Chaudhari wrote: >> This is a REDO of the Fix that was incompletely implemented earlier: >> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660) >> >> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days. >> >> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works: >> _(where 7200 represents 7200 seconds -> +2 hour offset)_ >> Sample output: >> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png) > > Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision: > > 8288377: Adjusted length check for returned gmt-offset Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9312 From naoto at openjdk.org Fri Jul 29 18:36:35 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 29 Jul 2022 18:36:35 GMT Subject: RFR: 8290740: Catalog not used when the handler is null In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 02:38:25 GMT, Joe Wang wrote: > Patch to make sure the Catalog is used even when the handler is null. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9682 From iris at openjdk.org Fri Jul 29 18:49:47 2022 From: iris at openjdk.org (Iris Clark) Date: Fri, 29 Jul 2022 18:49:47 GMT Subject: RFR: 8290740: Catalog not used when the handler is null In-Reply-To: References: Message-ID: <5yb02z4cXkFNktMP_9gW7Fp56lfoUQawRMq-UgXyaHU=.64345910-6b52-43ac-9462-ad9470f4695e@github.com> On Fri, 29 Jul 2022 02:38:25 GMT, Joe Wang wrote: > Patch to make sure the Catalog is used even when the handler is null. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9682 From hseigel at openjdk.org Fri Jul 29 19:56:51 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 29 Jul 2022 19:56:51 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:12:22 GMT, Joe Darcy wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > src/java.base/share/classes/java/lang/Class.java line 4700: > >> 4698: * returned. If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. >> 4699: */ >> 4700: private int getClassAccessFlagsRaw() { > > For a "raw" method, it might be better to return the flags on the array class object itself rather than loop down to the component type. There's no bytecode stream for arrays. It's created using anewarray with a dimension operand and a cp pointer to the component type. So there are no flags for the array object. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From ron.pressler at oracle.com Fri Jul 29 20:37:23 2022 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 29 Jul 2022 20:37:23 +0000 Subject: Coupling in ExtentLocal In-Reply-To: References: Message-ID: Hi. The difference between ExtentLocals and other TwR constructs is that we?d like to use it for critical, foundational, things where we want guarantees we can rely on, and we haven?t been able to find a way to guarantee them as well as we?d like with TwR, even dynamically. Yes, we are thinking about a "strong? TwR, but we?re busy with so many things so it might take a while. Until then, we might introduce a weaker, or less trustworthy version of ExtentLocals that uses the existing TwR and wouldn?t be used for critical things, but we think that it?s best to start incubation with just the lambda API and then see what problems are most common/annoying and how we can best address them. ? Ron On 29 Jul 2022, at 15:35, Holo The Sage Wolf > wrote: Hi, Thanks for the response Kasper, the reason I sent the mail to core-libs is because JDK-8263012 is assigned to "core-libs". I added loom-devs to the chain. What Andrew Haley wrote is correct, it is also correct pretty much for every implementation of `AutoClosable` (although, unlike ExtentLocals, most implementations of AutoClosable will cause resource leak, and ExtentLocal can cause a big logical bug). The idea of `strong try-with-resources` seems to solve the problem (and can force better APIs in other places), is there a conversation about this feature? Yuval Paz On Fri, Jul 29, 2022 at 12:15 PM Kasper Nielsen > wrote: On Thu, 28 Jul 2022 at 22:11, Holo The Sage Wolf > wrote: I have a question about the proposal, why not allow try-with-resources with this API? Hi, For Loom related questions, loom-dev at openjdk.org is probably a better fit. The main problem with TWR is that it cannot guard against non-nested use. Because there are no way to force the user to call close(). See more here [1] /Kasper [1] https://mail.openjdk.org/pipermail/loom-dev/2021-June/002558.html -- Holo The Wise Wolf Of Yoitsu -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Fri Jul 29 21:25:47 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 29 Jul 2022 21:25:47 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:02:46 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold src/hotspot/share/prims/jvm.cpp line 4059: > 4057: return JVM_CLASSFILE_MAJOR_VERSION; > 4058: } > 4059: assert(!java_lang_Class::as_Klass(mirror)->is_array_klass(), "unexpected array class"); Can this throw IllegalArgumentException instead. Asserts only report problems when built with debug (Right?) test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 59: > 57: // test primitive array. should return ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. > 58: int flags = (int)m.invoke((new int[3]).getClass()); > 59: if (flags != 1041) { Can this be a hex constant, It's easier to understand the bits. Or assemble the flags from java.lang.reflect.Modifier.XXX static fields. test/hotspot/jtreg/runtime/ClassFile/classAccessFlagsRaw.jcod line 25: > 23: */ > 24: > 25: // Class with ACC_SUPER set Can these classes be defined more succinctly either in Java or .asm? ------------- PR: https://git.openjdk.org/jdk/pull/9688 From rriggs at openjdk.org Fri Jul 29 21:25:48 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 29 Jul 2022 21:25:48 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 21:05:19 GMT, Roger Riggs wrote: >> Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. >> >> The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. >> >> Thanks, Harold > > src/hotspot/share/prims/jvm.cpp line 4059: > >> 4057: return JVM_CLASSFILE_MAJOR_VERSION; >> 4058: } >> 4059: assert(!java_lang_Class::as_Klass(mirror)->is_array_klass(), "unexpected array class"); > > Can this throw IllegalArgumentException instead. > Asserts only report problems when built with debug (Right?) Or, Can the VM do this traversal as/more efficiently than doing at the java level? ------------- PR: https://git.openjdk.org/jdk/pull/9688 From naoto at openjdk.org Fri Jul 29 21:47:00 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 29 Jul 2022 21:47:00 GMT Subject: RFR: 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fail: More or fewer pipes than expected In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 16:49:36 GMT, Roger Riggs wrote: > The test java/lang/ProcessBuilder/PipelineLeaksFD.java fails intermittently, usually associated with fastdebug and -Xcomp. > It reports extra file descriptors are open that not expected. > The test of pipelines did not explicitly use or close the stderr streams of each stream except the last. > The intermittent nature of the failure is due to the non-deterministic GC interactions that close the streams when they become un-referenced. > > The solution in this case is to redirect the error stream to the stdout stream for each pipeline stage except the last. > > The test is removed from the ProblemList-Xcomp. Marked as reviewed by naoto (Reviewer). test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 75: > 73: for (int i = 0; i < builders.size() - 1; i++) { > 74: builders.get(i).redirectErrorStream(true); > 75: } This loop could be removed by doing redirects in the data provider. ------------- PR: https://git.openjdk.org/jdk/pull/9687 From rriggs at openjdk.org Fri Jul 29 22:03:01 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 29 Jul 2022 22:03:01 GMT Subject: RFR: 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fail: More or fewer pipes than expected In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 21:43:30 GMT, Naoto Sato wrote: >> The test java/lang/ProcessBuilder/PipelineLeaksFD.java fails intermittently, usually associated with fastdebug and -Xcomp. >> It reports extra file descriptors are open that not expected. >> The test of pipelines did not explicitly use or close the stderr streams of each stream except the last. >> The intermittent nature of the failure is due to the non-deterministic GC interactions that close the streams when they become un-referenced. >> >> The solution in this case is to redirect the error stream to the stdout stream for each pipeline stage except the last. >> >> The test is removed from the ProblemList-Xcomp. > > test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 75: > >> 73: for (int i = 0; i < builders.size() - 1; i++) { >> 74: builders.get(i).redirectErrorStream(true); >> 75: } > > This loop could be removed by doing redirects in the data provider. Thanks for the review. The effect would be the same, though it would distribute the needed constraint to more places in the source and the descriptive comment would need to be duplicated. ------------- PR: https://git.openjdk.org/jdk/pull/9687 From naoto at openjdk.org Fri Jul 29 23:27:53 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 29 Jul 2022 23:27:53 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v5] In-Reply-To: References: Message-ID: <8Qeairg7kL4tlQ_N55Nhf-pTxDvh4lvgjZ-21Pnd5W0=.c17a9286-5ef3-4642-afd2-59ac552136ae@github.com> > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Parse invalid fields correctly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/e24e5dd8..d3242ba9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=03-04 Stats: 29 lines in 3 files changed: 26 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From joehw at openjdk.org Sat Jul 30 01:43:46 2022 From: joehw at openjdk.org (Joe Wang) Date: Sat, 30 Jul 2022 01:43:46 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v5] In-Reply-To: <8Qeairg7kL4tlQ_N55Nhf-pTxDvh4lvgjZ-21Pnd5W0=.c17a9286-5ef3-4642-afd2-59ac552136ae@github.com> References: <8Qeairg7kL4tlQ_N55Nhf-pTxDvh4lvgjZ-21Pnd5W0=.c17a9286-5ef3-4642-afd2-59ac552136ae@github.com> Message-ID: On Fri, 29 Jul 2022 23:27:53 GMT, Naoto Sato wrote: >> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Parse invalid fields correctly test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 190: > 188: } catch (IllformedLocaleException ile) { > 189: // success > 190: System.out.println("IllformedLocaleException thrown correctly: " + ile.getMessage()); Could use assertThrows, but ok if you want to keep it this way. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From joehw at openjdk.org Sat Jul 30 01:45:47 2022 From: joehw at openjdk.org (Joe Wang) Date: Sat, 30 Jul 2022 01:45:47 GMT Subject: RFR: 8290740: Catalog not used when the handler is null In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 02:38:25 GMT, Joe Wang wrote: > Patch to make sure the Catalog is used even when the handler is null. Thanks all! ------------- PR: https://git.openjdk.org/jdk/pull/9682 From joehw at openjdk.org Sat Jul 30 01:45:48 2022 From: joehw at openjdk.org (Joe Wang) Date: Sat, 30 Jul 2022 01:45:48 GMT Subject: Integrated: 8290740: Catalog not used when the handler is null In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 02:38:25 GMT, Joe Wang wrote: > Patch to make sure the Catalog is used even when the handler is null. This pull request has now been integrated. Changeset: 470c0eb2 Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/470c0eb2163a62e5743aefe62c6725e92beea54d Stats: 76 lines in 3 files changed: 22 ins; 9 del; 45 mod 8290740: Catalog not used when the handler is null Reviewed-by: lancea, naoto, iris ------------- PR: https://git.openjdk.org/jdk/pull/9682 From jpai at openjdk.org Sat Jul 30 02:34:56 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 30 Jul 2022 02:34:56 GMT Subject: RFR: 8290885: java/lang/ProcessBuilder/PipelineLeaksFD.java fail: More or fewer pipes than expected In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 16:49:36 GMT, Roger Riggs wrote: > The test java/lang/ProcessBuilder/PipelineLeaksFD.java fails intermittently, usually associated with fastdebug and -Xcomp. > It reports extra file descriptors are open that not expected. > The test of pipelines did not explicitly use or close the stderr streams of each stream except the last. > The intermittent nature of the failure is due to the non-deterministic GC interactions that close the streams when they become un-referenced. > > The solution in this case is to redirect the error stream to the stdout stream for each pipeline stage except the last. > > The test is removed from the ProblemList-Xcomp. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9687 From dholmes at openjdk.org Sat Jul 30 07:32:08 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 30 Jul 2022 07:32:08 GMT Subject: RFR: Merge jdk19 Message-ID: Forward port JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8291512: Snippetize modules API examples The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9692&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9692&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9692/files Stats: 23 lines in 4 files changed: 2 ins; 9 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9692.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9692/head:pull/9692 PR: https://git.openjdk.org/jdk/pull/9692 From dholmes at openjdk.org Sat Jul 30 07:50:19 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 30 Jul 2022 07:50:19 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 21:19:27 GMT, Roger Riggs wrote: >> src/hotspot/share/prims/jvm.cpp line 4059: >> >>> 4057: return JVM_CLASSFILE_MAJOR_VERSION; >>> 4058: } >>> 4059: assert(!java_lang_Class::as_Klass(mirror)->is_array_klass(), "unexpected array class"); >> >> Can this throw IllegalArgumentException instead. >> Asserts only report problems when built with debug (Right?) > > Or, Can the VM do this traversal as/more efficiently than doing at the java level? It is usual for the Java code to do such checks and throw exceptions, so that the VM assumes it is correct and only asserts incase something has been missed on the Java side. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From dholmes at openjdk.org Sat Jul 30 07:50:20 2022 From: dholmes at openjdk.org (David Holmes) Date: Sat, 30 Jul 2022 07:50:20 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Sat, 30 Jul 2022 07:44:11 GMT, David Holmes wrote: >> Or, Can the VM do this traversal as/more efficiently than doing at the java level? > > It is usual for the Java code to do such checks and throw exceptions, so that the VM assumes it is correct and only asserts incase something has been missed on the Java side. Though in this case the Java code has defined behaviour for array types so it is correct for the VM to assume this is not an array type and to assert if it is. ------------- PR: https://git.openjdk.org/jdk/pull/9688 From plevart at openjdk.org Sat Jul 30 11:47:12 2022 From: plevart at openjdk.org (Peter Levart) Date: Sat, 30 Jul 2022 11:47:12 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: <9C59bxoNH8jN0R700F_lWlVmlEgNIcNZSP8iBrs3T7A=.0cd85bfd-1027-43fd-9751-c6ce15edf997@github.com> On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian wrote: >> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner. >> >> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical. >> >> Details of note: >> 1. Some operations need to change the state values (the update() method is probably the most interesting). >> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`. >> >> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency. >> >> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). >> >> Thanks. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > remove some more tabs Changes requested by plevart (Reviewer). src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 82: > 80: public void run() { > 81: // Ensure changes on the main/program thread happens-before cleanup > 82: VarHandle.fullFence(); no need for memory fence as explained in various finally blocks... src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 93: > 91: homeCtx.decEnumCount(); > 92: homeCtx = null; > 93: } Cleaner's task (run() method) is guaranteed to be called at most once. So there's no need for above "idempotent" logic. Unless some of those fields are optional when the instance is constructed.... src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 172: > 170: > 171: // Ensure writes are visible to the Cleaner thread > 172: VarHandle.fullFence(); I don't think any memory fences are needed here. Reachability fence is enough. Cleaner runs in its own thread by polling enqued PhantomReference(s) from the ReferenceQueue. There is a happens-before edge between ReferenceHandler thread enqueue-ing "pending" PhantomReferences and Cleaner thread dequeue-ing them. There is a happens-before edge between GC thread clearing a PhantomReference and linking it into a "pending" list and ReferenceHandler thread unlinking it from the "pending" list and enque-ing it into a ReferenceQueue. There is a happens-before edge before a call to Reference.reachabilityFence(referent) and a GC thread discovering a phantom-reachable referent and clearing the PhantomReference and linking it into a "pending" list. So there you have a happens-before chain which makes all writes before a call to eference.reachabilityFence(this) visible to a Cleaner task that is initialized to observe reachabillity of this.... src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 192: > 190: > 191: // Ensure writes are visible to the Cleaner thread > 192: VarHandle.fullFence(); Same as above. Memory fences are not needed. src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 277: > 275: } finally { > 276: // Ensure writes are visible to the Cleaner thread > 277: VarHandle.fullFence(); The memory fence is not needed (as explained above), but... src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 279: > 277: VarHandle.fullFence(); > 278: // Ensure Cleaner does not run until after this method completes > 279: Reference.reachabilityFence(enumCtx); The reachability fence should take 'this' as a parameter, not enumCtx. Since 'this' reachability is tracked by Cleaner and not 'enumCtx' reachability. src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 296: > 294: } finally { > 295: // Ensure writes are visible to the Cleaner thread > 296: VarHandle.fullFence(); The memory fence is not needed (as explained above), but... src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 298: > 296: VarHandle.fullFence(); > 297: // Ensure Cleaner does not run until after this method completes > 298: Reference.reachabilityFence(enumCtx); The reachability fence should take 'this' as a parameter, not enumCtx. Since 'this' reachability is tracked by Cleaner and not 'enumCtx' reachability. src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 343: > 341: VarHandle.fullFence(); > 342: // Ensure Cleaner does not run until after this method completes > 343: Reference.reachabilityFence(enumCtx); The same as above: no need for memory fence and reachability fence should take 'this' as parameter. src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 382: > 380: VarHandle.fullFence(); > 381: // Ensure Cleaner does not run until after this method completes > 382: Reference.reachabilityFence(enumCtx); Same as above: no need for memory fence and reachability fence should take 'this' as parameter. src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 415: > 413: } finally { > 414: // Ensure writes are visible to the Cleaner thread > 415: VarHandle.fullFence(); No need for memory fence. src/java.naming/share/classes/com/sun/jndi/ldap/LdapBindingEnumeration.java line 107: > 105: } finally { > 106: // Ensure writes are visible to the Cleaner thread > 107: VarHandle.fullFence(); no need for memory fence. src/java.naming/share/classes/com/sun/jndi/ldap/LdapBindingEnumeration.java line 121: > 119: } finally { > 120: // Ensure writes are visible to the Cleaner thread > 121: VarHandle.fullFence(); no need for memory fence. src/java.naming/share/classes/com/sun/jndi/ldap/LdapNamingEnumeration.java line 76: > 74: } finally { > 75: // Ensure writes are visible to the Cleaner thread > 76: VarHandle.fullFence(); no need for memory fence. src/java.naming/share/classes/com/sun/jndi/ldap/LdapNamingEnumeration.java line 90: > 88: } finally { > 89: // Ensure writes are visible to the Cleaner thread > 90: VarHandle.fullFence(); no need for memory fence src/java.naming/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java line 198: > 196: } finally { > 197: // Ensure writes are visible to the Cleaner thread > 198: VarHandle.fullFence(); memory fence is not needed. src/java.naming/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java line 224: > 222: } finally { > 223: // Ensure writes are visible to the Cleaner thread > 224: VarHandle.fullFence(); no need for memory fence. ------------- PR: https://git.openjdk.org/jdk/pull/8311 From plevart at openjdk.org Sat Jul 30 11:47:13 2022 From: plevart at openjdk.org (Peter Levart) Date: Sat, 30 Jul 2022 11:47:13 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v8] In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 21:40:43 GMT, Roger Riggs wrote: > I don't think there is any benefit to the `try{} finally {fence}`. The reachabilityFence has no executable code. Its only purpose is to keep the reference in scope alive. ...reachability fence has no code, but puting it into finally block makes the compiler see it on all possible exit paths from the try block (any possible exceptions, returns, etc.) so the argument 'this' is protected from being GC-ed until every possible code in try block is finished. > Ditto, the try/finally is unnecessary. I think it is necessary for reachability fence since try block has many exit paths and accesses state cleaned up by Cleaner. Memory fence OTOH is not needed. > Ditto try/finally is unnecessary. Perhaps, because there may be only one exit path. But style-wise it is still better to play safe for any possible future changes to this part of code. Memory fence is not needed though as explained above. ------------- PR: https://git.openjdk.org/jdk/pull/8311 From plevart at openjdk.org Sat Jul 30 11:47:13 2022 From: plevart at openjdk.org (Peter Levart) Date: Sat, 30 Jul 2022 11:47:13 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v8] In-Reply-To: References: Message-ID: On Sat, 30 Jul 2022 11:07:25 GMT, Peter Levart wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 216: >> >>> 214: } finally { >>> 215: // Ensure Cleaner does not run until after this method completes >>> 216: Reference.reachabilityFence(this); >> >> I don't think there is any benefit to the `try{} finally {fence}`. >> The reachabilityFence has no executable code. Its only purpose is to keep the reference in scope alive. > >> I don't think there is any benefit to the `try{} finally {fence}`. The reachabilityFence has no executable code. Its only purpose is to keep the reference in scope alive. > > ...reachability fence has no code, but puting it into finally block makes the compiler see it on all possible exit paths from the try block (any possible exceptions, returns, etc.) so the argument 'this' is protected from being GC-ed until every possible code in try block is finished. The memory fence is not needed though (as explained above). ------------- PR: https://git.openjdk.org/jdk/pull/8311 From plevart at openjdk.org Sat Jul 30 12:33:39 2022 From: plevart at openjdk.org (Peter Levart) Date: Sat, 30 Jul 2022 12:33:39 GMT Subject: RFR: 8283660: Convert com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v16] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 05:26:31 GMT, Stuart Marks wrote: > Hans Boehm wrote: > > > I also have concerns about the use of fullFence here. I believe it should be the case that reachabilityFence guarantees visibility of memory operations program-ordered before the reachabilityFence(p) to the Cleaner associated with p. Mutator-collector synchronization should normally ensure that. On rereading, it also appears to me that the current reachabilityFence() documentation does not make that as clear as it should. > > > It appears to me that this is addressing an instance of the problem for which I suggested a more general, though also not completely elegant, solution in https://docs.google.com/document/d/1yMC4VzZobMQTrVAraMy7xBdWPCJ0p7G5r_43yaqsj-s/edit?usp=sharing . > > Hi Hans, thanks for looking at this. In the prior discussions on reachabilityFence and premature finalization, I don't recall seeing any mention of memory model issues. To my mind the discussions here are the first mention of them. (Of course it's possible I could have missed something.) The memory model is quite subtle and it's difficult to be sure of anything. However, as time goes on we've become more confident that there _IS_ an issue here with the memory model that needs to be addressed. > > Then there is a the question of what to do about it. One possibility is to add some memory ordering semantics into reachabilityFence(p), as you suggest. As convenient as it might seem, it's not obvious to me that we want reachability fused with memory order. At least we should discuss them separately before deciding what to do. > > This PR seems to be on a long journey :-) so let me describe some of the background and where I think this ought to go. > > First, like most PRs, this started off as an effort to make some code changes. In this case it's part of Brent's (@bchristi-git) effort to convert finalizers in the JDK to Cleaners. This is related to discovering coding patterns for how to do this effectively. For example, the entire object's state is available to the finalizer. But in order to convert this to a Cleaner, the state available to the cleaning action needs to be refactored into a separate object from the "outer" object. The `EnumCtx` nested class serves this role here. > > Second, we're trying to address the reachability issues. You (Hans) have been writing and speaking about this for some time, mostly in the context of finalization. We in the JDK group haven't prioritized fixing this issue with respect to finalization (since it's old and deprecated and nobody should be using it, yeah right). Now that we're converting things to use Cleaner, which has the same issues, we're forced to confront them. Our working position is that there needs to be a reachabilityFence within a try/finally block in the "right" places; determining the definition of "right" is one of the goals here. > > The third issue is memory ordering. For finalization-based objects, the JLS specifies a happens-before edge between the constructor and the finalizer. (I think this works for objects whose finalizable state is fully initialized in the constructor. But it doesn't work for objects, like this one, whose finalizable state is mutable throughout the lifetime of the object.) There is nothing specified for memory ordering edges for Cleaner or java.lang.ref references at all that I can see. Given the lack of such specifications, we're faced with using the right low-level memory ordering mechanisms to get the memory order we require. We're using VarHandle::fullFence as kind of a placeholder for this. (We've also considered empty synchronized blocks, writes/reads to "junk" variables created expressly for this purpose, and other VarHandle fence operations, but none seem obviously better. I'm sure there are other alternatives we haven't considered.) I'd welcome discussion of the proper alternat ive. > > The fourth issue is, do we really want every programmer who uses Cleaner to have to figure out all this reachabilityFence and VarHandle fence stuff? Of course not. It would be nice to have some higher-level construct (such as a language change like the "Reachability Revisited" proposal), or possibly to create some library APIs to facilitate this. At a minimum, I think we need to adjust various specifications like Cleaner and java.lang.ref to address memory ordering issues. There is certainly more that needs to be done though. > > The difficulty with trying to come up with language changes or library APIs is that I don't think we understand this problem well enough to define what those mechanisms are actually supposed to do. So before we get to that point, I think we should see attempt to write down a correct solution using the existing reachability and memory ordering mechanisms. That's what Brent has done here. We should review and iterate on this and identify the places where the specs need to change, and arrive at a point where the we believe the code, even if ugly and inconvenient, is correct under that spec. > > Maybe at that point we can contemplate a higher-level approach such as a language mechanism or a library API (or both), but I don't think we're quite there yet. Or maybe some alternative path forward might emerge. Hi, Sorry for not reading up to this message before starting reviewing the changes... As I was trying to explain in the comments, I don't think there is any issue about memory ordering here. As Cleaner is implemented currently in OpenJDK, there a 5 threads involved in a typical scenario of a cleanable object: T1 - initializing thread that registers a Cleaner action T2 - some thread that accesses/mutates object state including parts that are accessed/cleaned up by Cleaner action and guards against premature Cleaner action execution with reachability fence T3 - GC thread that discovers a phantom-reachable referent of a PhantomReference that is tracked by the Cleaner and clears the PhantomReference and links it into a "pending" list. T4 - a ReferenceHandler thread that waits for "pending" Reference(s) and enqueues them to ReferenceQueue(s) T5 - a single Cleaner thread that dequeues PhantomReference(s) from the Cleaner's ReferenceQueue and executes cleanup actions There is a synchronization action between T1 and T5, so there is no doubt that writes in the construrctor of a tracked object that typically preced Cleaner registration are visible to Cleaner action. There is a synchronization action between T3 and T4 and there is a synchronization action between T4 and T5 (both can be verified in code). The only question here remaining is whether there is synchronization between threads that mutate object state and GC thread that discovers phantom-reachable referents.. I'm not qualified to answer that question. Especially with the advent of new fully concurrent GC algorithms such as ZGC and Shenandoah. So perhaps this is a question for GC experts. ------------- PR: https://git.openjdk.org/jdk/pull/8311 From naoto at openjdk.org Sat Jul 30 20:52:49 2022 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 30 Jul 2022 20:52:49 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v6] In-Reply-To: References: Message-ID: > This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Use `assertThrows` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9620/files - new: https://git.openjdk.org/jdk/pull/9620/files/d3242ba9..9f60232e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9620&range=04-05 Stats: 16 lines in 1 file changed: 1 ins; 11 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9620/head:pull/9620 PR: https://git.openjdk.org/jdk/pull/9620 From naoto at openjdk.org Sat Jul 30 20:53:13 2022 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 30 Jul 2022 20:53:13 GMT Subject: RFR: 8289227: Support for BCP 47 Extension T - Transformed Content [v5] In-Reply-To: References: <8Qeairg7kL4tlQ_N55Nhf-pTxDvh4lvgjZ-21Pnd5W0=.c17a9286-5ef3-4642-afd2-59ac552136ae@github.com> Message-ID: <2fKzEh3uQMw9TCOsUKq9aCBINE7WzlFAJbPoas80Tzs=.eee6f0b6-b5c0-46ff-9987-786d9a549f31@github.com> On Sat, 30 Jul 2022 01:39:54 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Parse invalid fields correctly > > test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 190: > >> 188: } catch (IllformedLocaleException ile) { >> 189: // success >> 190: System.out.println("IllformedLocaleException thrown correctly: " + ile.getMessage()); > > Could use assertThrows, but ok if you want to keep it this way. Thanks, Joe. Replaced them with `assertThrows`. ------------- PR: https://git.openjdk.org/jdk/pull/9620 From dholmes at openjdk.org Sun Jul 31 22:25:37 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 31 Jul 2022 22:25:37 GMT Subject: RFR: 8291360: Create entry points to expose low-level class file information In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:02:46 GMT, Harold Seigel wrote: > Please review this change to fix JDK-8291360. This fix adds entry points getClassFileVersion() and getClassAccessFlagsRaw() to class java.lang.Class. The new entry points return the current class's class file version and its raw access flags. > > The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 1-3 on Linux x64. Additionally, the JCK lang, vm, and api tests and new regression tests were run locally on Linux x64. > > Thanks, Harold Hi Harold, Generally seems fine. A few nits and comments. Thanks. src/hotspot/share/include/jvm.h line 1163: > 1161: > 1162: /* > 1163: * Value types support. Value types? This is supporting the core reflection work isn't it? src/hotspot/share/prims/jvm.cpp line 4050: > 4048: /* > 4049: * Return the current class's class file version. The low order 16 bits of the > 4050: * the returned jint contains the class's major version. The high order 16 bits typo "the the" across the lines typo s/contains/contain/ src/hotspot/share/prims/jvm.cpp line 4051: > 4049: * Return the current class's class file version. The low order 16 bits of the > 4050: * the returned jint contains the class's major version. The high order 16 bits > 4051: * contains the class's minor version. typo s/contains/contain/ src/hotspot/share/prims/jvm.cpp line 4064: > 4062: assert(c->is_instance_klass(), "must be"); > 4063: InstanceKlass* ik = InstanceKlass::cast(c); > 4064: return (ik->minor_version() << 16) | ik->major_version(); I'm curious why the format is minor:major rather than major:minor ? src/java.base/share/classes/java/lang/Class.java line 4698: > 4696: * > 4697: * If the class is an array type then the access flags of the component type is > 4698: * returned. If the class is a primitive then ACC_ABSTRACT | ACC_FINAL | ACC_PUBLIC. The `ACC_ABSTRACT` seems odd - is that way of indicating this "class" can't be instantiated? Is there some spec document that explains this choice? test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 60: > 58: int flags = (int)m.invoke((new int[3]).getClass()); > 59: if (flags != 1041) { > 60: throw new RuntimeException("expected 1041, got " + flags + " for primitive array"); Hex output would be clearer here too. test/hotspot/jtreg/runtime/ClassFile/ClassAccessFlagsRawTest.java line 66: > 64: flags = (int)m.invoke((new SUPERnotset[2]).getClass()); > 65: if (flags != 1) { > 66: throw new RuntimeException("expected 1, got " + flags + " for object array"); Again hex output would be clearer test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 31: > 29: * @modules java.base/java.lang:open > 30: * @compile classFileVersions.jcod > 31: * @run main/othervm --enable-preview ClassFileVersionTest What preview feature is being used here? test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 45: > 43: if (ver != expectedResult) { > 44: throw new RuntimeException( > 45: "expected " + expectedResult + ", got " + ver + " for class " + className); It would be clearer to show the expected and actual in minor:major format. That way if the test fails we can easily see which bit is wrong. test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 55: > 53: > 54: testIt("Version64", 64); > 55: testIt("Version59", 59); Any particular reason to choose 59? Shouldn't there also be tests for non-zero minor versions? test/hotspot/jtreg/runtime/ClassFile/ClassFileVersionTest.java line 62: > 60: int ver = (int)m.invoke((new int[3]).getClass()); > 61: if (ver != 64) { > 62: throw new RuntimeException("expected 64, got " + ver + " for primitive array"); Again minor:major format. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9688