From mchung at openjdk.java.net Tue Feb 1 00:13:12 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Feb 2022 00:13:12 GMT Subject: Integrated: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote: > `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. > > The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. This pull request has now been integrated. Changeset: 9c0104b9 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/9c0104b9c96f012da1602f503f641824d78f4260 Stats: 193 lines in 3 files changed: 166 ins; 19 del; 8 mod 8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7271 From duke at openjdk.java.net Tue Feb 1 00:58:11 2022 From: duke at openjdk.java.net (duke) Date: Tue, 1 Feb 2022 00:58:11 GMT Subject: Withdrawn: 8003417: WeakHashMap$HashIterator removes wrong entry In-Reply-To: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com> References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com> Message-ID: On Sat, 20 Nov 2021 10:08:41 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8003417? > > The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR. > > The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part. > > A new jtreg test has been added which reproduces the issue as well as verifies the fix. > `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6488 From darcy at openjdk.java.net Tue Feb 1 01:05:36 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Feb 2022 01:05:36 GMT Subject: RFR: JDK-8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix [v2] In-Reply-To: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> References: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> Message-ID: > The original fix to JDK-8280550 contained a typo where r rather than bound was used as the first argument to nextAfter; this PR corrects that issue. 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 three additional commits since the last revision: - Respond to review feedback. - Merge branch 'master' into JDK-8280950 - JDK-8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7292/files - new: https://git.openjdk.java.net/jdk/pull/7292/files/2f25d031..27b442cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7292&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7292&range=00-01 Stats: 1328 lines in 49 files changed: 724 ins; 391 del; 213 mod Patch: https://git.openjdk.java.net/jdk/pull/7292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7292/head:pull/7292 PR: https://git.openjdk.java.net/jdk/pull/7292 From darcy at openjdk.java.net Tue Feb 1 01:31:09 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Feb 2022 01:31:09 GMT Subject: Integrated: JDK-8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix In-Reply-To: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> References: <9evX9y1YteFSaZAg88XWMkmgVp1dXch2loNXc6jSLSg=.d255c850-9869-4bb5-9d02-76a42d6ba8a6@github.com> Message-ID: On Mon, 31 Jan 2022 22:31:03 GMT, Joe Darcy wrote: > The original fix to JDK-8280550 contained a typo where r rather than bound was used as the first argument to nextAfter; this PR corrects that issue. This pull request has now been integrated. Changeset: 0e70d450 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/0e70d4504c267174738485c7da82a2ac0ef09770 Stats: 42 lines in 2 files changed: 39 ins; 0 del; 3 mod 8280950: RandomGenerator:NextDouble() default behavior non conformant after JDK-8280550 fix Reviewed-by: bpb, jlaskey ------------- PR: https://git.openjdk.java.net/jdk/pull/7292 From jpai at openjdk.java.net Tue Feb 1 04:02:08 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 1 Feb 2022 04:02:08 GMT Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry In-Reply-To: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com> References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com> Message-ID: <2vECX1QVxeGmWekPnPZEZH3RPMH90lKOR3SjhFhGpkQ=.bddba72f-bd3f-4f90-8367-2a288f01c86c@github.com> On Sat, 20 Nov 2021 10:08:41 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8003417? > > The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR. > > The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part. > > A new jtreg test has been added which reproduces the issue as well as verifies the fix. > `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please. > Seems like we ought to be able to fix this one. Agreed. I got caught up in a few unrelated things, so haven't been able to get back to this to take into account some of your and Roger's inputs. I'll get back to this shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/6488 From info at j-kuhn.de Tue Feb 1 05:35:46 2022 From: info at j-kuhn.de (Johannes Kuhn) Date: Tue, 1 Feb 2022 06:35:46 +0100 Subject: Integrated: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: References: Message-ID: <69aa0bf5-8ce6-38fb-8046-cbfc5b401af2@j-kuhn.de> Might be a bit late, but wouldn't it be better to check if the package is exported to at least the unnamed module of the system class loader? It is currently not possible to add unconditional exports on the command line, but it is possible to add `--add-exports=some.module/some.pkg=ALL-UNNAMED` to the command line. - Johannes On 01-Feb-22 1:13, Mandy Chung wrote: > On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote: > >> `AccessibleObject::setAccessible` and `trySetAccessible` methods should only allow access to public member of a public type that is unconditionally exported consistent with the access check as described in the class specification, when invoked by JNI code with no Java class on the stack. The current implementation throws NPE when finding the module of the caller class as the caller class is null. >> >> The specification of `canAccess`, `setAccessible` and `trySetAccessible` are updated to specify the behavior when the caller class is null. I consider this spec update as a clarification as the class specification covers this case. > > This pull request has now been integrated. > > Changeset: 9c0104b9 > Author: Mandy Chung > URL: https://git.openjdk.java.net/jdk/commit/9c0104b9c96f012da1602f503f641824d78f4260 > Stats: 193 lines in 3 files changed: 166 ins; 19 del; 8 mod > > 8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack > > Reviewed-by: alanb > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7271 From darcy at openjdk.java.net Tue Feb 1 06:10:15 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Feb 2022 06:10:15 GMT Subject: RFR: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos [v13] In-Reply-To: <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> <_KccZ49xLIX5fJyWhSEMW0D4r4_P0Qj0hI-LDgjdZ74=.1cfa07ce-c8d7-4db1-a621-80b235c2781b@github.com> Message-ID: On Fri, 28 Jan 2022 16:58:55 GMT, Michael McMahon wrote: >> Hi, >> >> This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: >> >> A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. >> >> A test will be added separately to the implementation. >> >> Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 >> >> Thanks, >> Michael > > Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: > > spec update from CSR Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From michaelm at openjdk.java.net Tue Feb 1 07:30:19 2022 From: michaelm at openjdk.java.net (Michael McMahon) Date: Tue, 1 Feb 2022 07:30:19 GMT Subject: Integrated: 8279842: HTTPS Channel Binding support for Java GSS/Kerberos In-Reply-To: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> References: <0NRLXRrLTXVI1xxlaSr8Abqt_refWkNSvjFtYTLsMOc=.776131ae-3dde-4bb9-9893-c234e65d5e99@github.com> Message-ID: On Thu, 13 Jan 2022 12:10:11 GMT, Michael McMahon wrote: > Hi, > > This change adds Channel Binding Token (CBT) support to HTTPS (java.net.HttpsURLConnection) when used with the Negotiate (SPNEGO, Kerberos) authentication scheme. When enabled, the implementation preemptively includes a CBT with authentication requests over Kerberos. The feature is enabled as follows: > > A system property "jdk.spnego.cbt" is defined which can have the values "never" (default), which means the feature is disabled, "always", which means the CBT is included for all https Negotiate authentications, or it can take the form "domain:a,b.c,*.d.com" which is a comma separated list of domains/hosts where the feature is enabled, and disabled everywhere else. In the given example, the CBT would be included in authentication requests for hosts "a", "b.c" and all hosts under the domain "d.com" and all of its sub-domains. > > A test will be added separately to the implementation. > > Bug report: https://bugs.openjdk.java.net/browse/JDK-8279842 > > Thanks, > Michael This pull request has now been integrated. Changeset: de3113b9 Author: Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/de3113b998550021bb502cd6f766036fb8351e7d Stats: 858 lines in 12 files changed: 696 ins; 146 del; 16 mod 8279842: HTTPS Channel Binding support for Java GSS/Kerberos Co-authored-by: Weijun Wang Reviewed-by: dfuchs, weijun, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/7065 From myano at openjdk.java.net Tue Feb 1 07:55:06 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Tue, 1 Feb 2022 07:55:06 GMT Subject: RFR: 8266974: duplicate property key in java.sql.rowset resource bundle In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 11:25:55 GMT, Lance Andersen wrote: >> I have removed the duplicate property keys. >> Could you please review the fix? > > Marked as reviewed by lancea (Reviewer). @LanceAndersen Could you please commit this fix as a sponsor? ------------- PR: https://git.openjdk.java.net/jdk/pull/7212 From rriggs at openjdk.java.net Tue Feb 1 15:06:12 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Feb 2022 15:06:12 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 12:19:03 GMT, Roman Kennke wrote: >> Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete comment LGTM, thanks ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7054 From rkennke at openjdk.java.net Tue Feb 1 15:06:12 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 1 Feb 2022 15:06:12 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: <8JiN0kBi4PrpRcQ6TvVun6_JwjfIjR1B1P78T-eSk78=.f44f3a5b-8e11-4d19-8703-7aaa021fc8d8@github.com> References: <8JiN0kBi4PrpRcQ6TvVun6_JwjfIjR1B1P78T-eSk78=.f44f3a5b-8e11-4d19-8703-7aaa021fc8d8@github.com> Message-ID: <2j82L5017fxOp4M6Z1mpNzxUMEruPgoS_nH0ID_Udsc=.e6492c0d-37a7-43aa-9574-af90ef419fc9@github.com> On Thu, 13 Jan 2022 14:41:51 GMT, Roger Riggs wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove obsolete comment > > @AlanBateman has been doing a lot of work with j.l.Thread and Loom but may not get to review this til next week. Thanks Ping? Can I please get another review? Maybe @RogerRiggs or @plevart, you already have been involved in similar changes in java.io ? Thanks, Roman ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From mandy.chung at oracle.com Tue Feb 1 17:26:10 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 1 Feb 2022 09:26:10 -0800 Subject: Integrated: JDK-8221642: AccessibleObject::setAccessible throws NPE when invoked by JNI code with no java frame on stack In-Reply-To: <69aa0bf5-8ce6-38fb-8046-cbfc5b401af2@j-kuhn.de> References: <69aa0bf5-8ce6-38fb-8046-cbfc5b401af2@j-kuhn.de> Message-ID: We considered that option (i.e. default JNI code with no caller frame to the unnamed module of the system loader). ? It should be very rare for such use case.?? It's the simplest to keep the same access to public members of public classes in packages that are exported unconditionally as method invocation and field access as well as java.lang.invoke public Lookup. If a native thread attaching to the VM with no caller wants to break encapsulation, it will have to workaround it by calling through a Java class. Mandy On 1/31/22 9:35 PM, Johannes Kuhn wrote: > Might be a bit late, but wouldn't it be better to check if the package > is exported to at least the unnamed module of the system class loader? > > It is currently not possible to add unconditional exports on the > command line, but it is possible to add > `--add-exports=some.module/some.pkg=ALL-UNNAMED` to the command line. > > - Johannes > > On 01-Feb-22 1:13, Mandy Chung wrote: >> On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung >> wrote: >> >>> `AccessibleObject::setAccessible` and `trySetAccessible` methods >>> should only allow access to public member of a public type that is >>> unconditionally exported consistent with the access check as >>> described in the class specification, when invoked by JNI code with >>> no Java class on the stack.?? The current implementation throws NPE >>> when finding the module of the caller class as the caller class is >>> null. >>> >>> The specification of `canAccess`, `setAccessible` and >>> `trySetAccessible` are updated to specify the behavior when the >>> caller class is null.?? I consider this spec update as a >>> clarification as the class specification covers this case. >> >> This pull request has now been integrated. >> >> Changeset: 9c0104b9 >> Author:??? Mandy Chung >> URL: >> https://git.openjdk.java.net/jdk/commit/9c0104b9c96f012da1602f503f641824d78f4260 >> Stats:???? 193 lines in 3 files changed: 166 ins; 19 del; 8 mod >> >> 8221642: AccessibleObject::setAccessible throws NPE when invoked by >> JNI code with no java frame on stack >> >> Reviewed-by: alanb >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/7271 From akozlov at azul.com Tue Feb 1 09:11:19 2022 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 1 Feb 2022 12:11:19 +0300 Subject: [crac] RFR: Ensure empty Reference Handler and Cleaners queues In-Reply-To: References: Message-ID: Cross-posting RFR from CRaC Project. The change touches Reference class, so I would be glad to receive any feedback from core-libs-dev. In CRaC project, java code participates in the preparation of the platform state that can be safely stored to the image. The image can be attempted at any time, so the image may capture unprocessed References. Recently I found cases when objects became unreachable during preparation for the checkpoint, and their associated clean-up actions to close external resources (which we don't allow open when the image is stored). So it's become necessary to ensure as many References as possible are processed before the image is created. As a nice additional feature, restored java instances won't start with the same Reference processing. With the change, the image is not created until VM's queue of pending j.l.References are drained, and then, as an example, each j.l.ref.Cleaner queue is drained, only then the VM is called to prepare the image. More Reference handling threads will be changed like Cleaner's ones. I'm looking for possible problems or general comments about this approach. Thanks, Anton On 1/31/22 14:51, Anton Kozlov wrote: > At the time of checkpoint, a set of References may need handling. This change ensures no References pending in ReferenceHandler and in Cleaners. > > System.gc() is a best effort attempt to make GC to look for References. Default VM flags (-DisableExplicitGC, -ExplicitGCInvokesConcurrent) should not block the call, but additional investigation is needed to make sure GC found all references. > > ------------- > > Commit messages: > - Ensure empty Reference Handler and Cleaners queues > > Changes: https://git.openjdk.java.net/crac/pull/13/files > Webrev: https://webrevs.openjdk.java.net/?repo=crac&pr=13&range=00 > Stats: 126 lines in 5 files changed: 124 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/crac/pull/13.diff > Fetch: git fetch https://git.openjdk.java.net/crac pull/13/head:pull/13 > > PR: https://git.openjdk.java.net/crac/pull/13 From jlaskey at openjdk.java.net Tue Feb 1 18:50:13 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 1 Feb 2022 18:50:13 GMT Subject: Integrated: JDK-8279954 - java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails In-Reply-To: References: Message-ID: On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote: > Tests were fatally failing (windows) on Github actions. Pumping up the memory requirements will hopefully alleviate. This pull request has now been integrated. Changeset: bde2b378 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/bde2b3783e0e9787cf2f270fcb3a54c2d4f1e5ab Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8279954: java/lang/StringBuffer(StringBuilder)/HugeCapacity.java intermittently fails Reviewed-by: shade, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7086 From rriggs at openjdk.java.net Tue Feb 1 20:16:13 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Feb 2022 20:16:13 GMT Subject: Integrated: 8280642: ObjectInputStream.readObject should throw InvalidClassException instead of IllegalAccessError In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 21:02:23 GMT, Roger Riggs wrote: > During deserialization of a serialized data stream that contains a proxy descriptor with non-public interfaces > `java.io.ObjectInputStream` checks that the interfaces can be loaded from a single classloader in `ObjectInputStream.resolveProxyClass`. > If the interfaces cannot be loaded from a single classloader, an `IllegalAccessError` is thrown. > When `ObjectInputStream.readObject` encounters this case, it reflects an incompatibility > between the classloaders of the source of the serialized stream and the classloader being used for deserialization. > When a proxy object cannot be created from the interfaces, `ObjectInputStream.readObject` should catch > the `InvalidAccessError` and throw `InvalidObjectException` with the `InvalidAccessError` as the cause. > This allows the application to handle the exception consistently with other errors during deserialization. This pull request has now been integrated. Changeset: fdd9ca74 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/fdd9ca74bd6ca87c30be2bcdcfd22e19b7687a5a Stats: 13 lines in 2 files changed: 5 ins; 0 del; 8 mod 8280642: ObjectInputStream.readObject should throw InvalidClassException instead of IllegalAccessError Reviewed-by: naoto, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7274 From darcy at openjdk.java.net Tue Feb 1 21:18:42 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Feb 2022 21:18:42 GMT Subject: RFR: JDK-8281082: Improve javadoc references to JOSS Message-ID: The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. I'll update copyright years before pushing. ------------- Commit messages: - JDK-8281082: Improve javadoc references to JOSS Changes: https://git.openjdk.java.net/jdk/pull/7315/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7315&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281082 Stats: 11 lines in 6 files changed: 3 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7315/head:pull/7315 PR: https://git.openjdk.java.net/jdk/pull/7315 From iris at openjdk.java.net Tue Feb 1 21:30:08 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 1 Feb 2022 21:30:08 GMT Subject: RFR: JDK-8281082: Improve javadoc references to JOSS In-Reply-To: References: Message-ID: <0A1mLhnXMU55jCHgniAz9Ap7i3f94mQsUtxARd7bEcY=.a8cf6306-236e-48b5-8aa2-b8cbc284f71c@github.com> On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote: > The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7315 From rriggs at openjdk.java.net Tue Feb 1 21:35:07 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Feb 2022 21:35:07 GMT Subject: RFR: JDK-8281082: Improve javadoc references to JOSS In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote: > The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7315 From naoto at openjdk.java.net Tue Feb 1 21:48:11 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 1 Feb 2022 21:48:11 GMT Subject: RFR: JDK-8281082: Improve javadoc references to JOSS In-Reply-To: References: Message-ID: <9KMYQNCC0C_K7XN-QTMUMA1QoE7vMznJdd9j6lmeSco=.79472129-a1b5-4a1e-a736-82c18e0cc527@github.com> On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote: > The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7315 From lancea at openjdk.java.net Tue Feb 1 22:25:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 1 Feb 2022 22:25:06 GMT Subject: RFR: JDK-8281082: Improve javadoc references to JOSS In-Reply-To: References: Message-ID: <-pJCfTKW1eOsAryuQlNdvp7XHYs9N-0ohk2qCV0L7y0=.5bba56c9-e38b-4f89-b24c-84acf723941d@github.com> On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote: > The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7315 From darcy at openjdk.java.net Tue Feb 1 22:33:46 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Feb 2022 22:33:46 GMT Subject: RFR: JDK-8281082: Improve javadoc references to JOSS [v2] In-Reply-To: References: Message-ID: > The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyrights. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7315/files - new: https://git.openjdk.java.net/jdk/pull/7315/files/3eb97175..a4e1eb79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7315&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7315&range=00-01 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7315/head:pull/7315 PR: https://git.openjdk.java.net/jdk/pull/7315 From darcy at openjdk.java.net Tue Feb 1 22:33:47 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Feb 2022 22:33:47 GMT Subject: Integrated: JDK-8281082: Improve javadoc references to JOSS In-Reply-To: References: Message-ID: <52u-IKK3Awj6GaFWKhxtKcxbdjigBhKm22BFWPUA2H0=.f82d7961-271e-4f5d-b9e2-4a4649b30a2d@github.com> On Tue, 1 Feb 2022 21:11:39 GMT, Joe Darcy wrote: > The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. > > I'll update copyright years before pushing. This pull request has now been integrated. Changeset: 9ca7ff3e Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/9ca7ff3e4f0a944bacf38da7e5426082d64c52bd Stats: 16 lines in 6 files changed: 3 ins; 0 del; 13 mod 8281082: Improve javadoc references to JOSS Reviewed-by: iris, rriggs, naoto, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7315 From alanb at openjdk.java.net Wed Feb 2 06:43:11 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Feb 2022 06:43:11 GMT Subject: RFR: JDK-8281082: Improve javadoc references to JOSS [v2] In-Reply-To: References: Message-ID: On Tue, 1 Feb 2022 22:33:46 GMT, Joe Darcy wrote: >> The references to JOSS, the Java Object Serialization Specification, are not done consistently in the API javadoc. This should be improved. >> >> I'll update copyright years before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Update copyrights. src/java.base/share/classes/java/io/ObjectOutputStream.java line 659: > 657: * customize the way in which class descriptors are written to the > 658: * serialization stream. The corresponding method in ObjectInputStream, > 659: * {@link ObjectInputStream#readClassDescriptor readClassDescriptor}, should then be overridden to This makes the line lengths in this paragraph a bit inconsistent, maybe it can be re-formatted so that this one line doesn't stick out so much. ------------- PR: https://git.openjdk.java.net/jdk/pull/7315 From Alan.Bateman at oracle.com Wed Feb 2 14:48:33 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Feb 2022 14:48:33 +0000 Subject: [crac] RFR: Ensure empty Reference Handler and Cleaners queues In-Reply-To: References: Message-ID: <1c2136a0-90c2-cabc-a948-bc4a02f1533b@oracle.com> On 01/02/2022 09:11, Anton Kozlov wrote: > Cross-posting RFR from CRaC Project. The change touches Reference > class, so I > would be glad to receive any feedback from core-libs-dev. > > In CRaC project, java code participates in the preparation of the > platform > state that can be safely stored to the image. The image can be > attempted at any > time, so the image may capture unprocessed References. Recently I > found cases > when objects became unreachable during preparation for the checkpoint, > and > their associated clean-up actions to close external resources (which > we don't > allow open when the image is stored). So it's become necessary to > ensure as > many References as possible are processed before the image is created. > As a > nice additional feature, restored java instances won't start with the > same > Reference processing. > > With the change, the image is not created until VM's queue of pending > j.l.References are drained, and then, as an example, each > j.l.ref.Cleaner queue > is drained, only then the VM is called to prepare the image. More > Reference > handling threads will be changed like Cleaner's ones. I'm looking for > possible > problems or general comments about this approach. At a high level it should be okay to provide a JDK-internal way to await quiescent. You've added it as a public API which might be okay for the current exploration but I don't think it would be exposed in its current form. Once the method returns then there is no guarantee that the number of waiters hasn't changed, but I think you know that. -Alan. From rkennke at openjdk.java.net Wed Feb 2 15:00:14 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 15:00:14 GMT Subject: Integrated: 8279917: Refactor subclassAudits in Thread to use ClassValue In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 19:39:29 GMT, Roman Kennke wrote: > Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. > > Testing: > - [x] tier1 > - [x] tier2 > - [x] tier3 This pull request has now been integrated. Changeset: ce71e8b2 Author: Roman Kennke URL: https://git.openjdk.java.net/jdk/commit/ce71e8b281176d39cc879ae4ecf95f3d643ebd29 Stats: 86 lines in 1 file changed: 1 ins; 78 del; 7 mod 8279917: Refactor subclassAudits in Thread to use ClassValue Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From rkennke at openjdk.java.net Wed Feb 2 15:00:14 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 2 Feb 2022 15:00:14 GMT Subject: RFR: 8279917: Refactor subclassAudits in Thread to use ClassValue [v2] In-Reply-To: References: Message-ID: <7BlokzIZTzUk0SMuSoXFV_bkrPdDTiVGG-bjjtjLob4=.8f6a5043-602a-4e5b-bf74-ca04b04aed86@github.com> On Thu, 13 Jan 2022 12:19:03 GMT, Roman Kennke wrote: >> Thread.java would benefit from a refactoring similar to JDK-8278065 to use ClassValue instead of the somewhat problematic WeakClassKey mechanism. >> >> Testing: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove obsolete comment Thank you all! ------------- PR: https://git.openjdk.java.net/jdk/pull/7054 From psandoz at openjdk.java.net Wed Feb 2 17:16:11 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Feb 2022 17:16:11 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v9] In-Reply-To: <9lT4l0k6ne9HRhgOwC0shZoz-s0jiBfoUCKLpVIDCco=.a118b244-d037-4daa-a991-9b6850c49498@github.com> References: <9lT4l0k6ne9HRhgOwC0shZoz-s0jiBfoUCKLpVIDCco=.a118b244-d037-4daa-a991-9b6850c49498@github.com> Message-ID: <9jf4MG7TceVl-Z97RBRZBGh2YFP5VWp59N29n9DS6U0=.9bd4b730-0c87-4552-9673-b3880ed766e3@github.com> On Fri, 28 Jan 2022 19:03:39 GMT, kabutz wrote: >> kabutz has updated the pull request incrementally with one additional commit since the last revision: >> >> Benchmark for testing the effectiveness of BigInteger.parallelMultiply() > > I have added a benchmark for checking performance difference between sequential and parallel multiply of very large Mersenne primes using BigInteger. We want to measure real time, user time, system time and the amount of memory allocated. To calculate this, we create our own thread factory for the common ForkJoinPool and then use that to measure user time, cpu time and bytes allocated. > > We use reflection to discover all methods that match "*ultiply", and use them to multiply two very large Mersenne primes together. > > ### Results on a 1-6-2 machine running Ubuntu linux > > Memory allocation increased from 83.9GB to 84GB, for both the sequential and parallel versions. This is an increase of just 0.1%. On this machine, the parallel version was 3.8x faster in latency (real time), but it used 2.7x more CPU resources. > > Testing multiplying Mersenne primes of 2^57885161-1 and 2^82589933-1 > > #### openjdk version "18-internal" 2022-03-15 > > BigInteger.parallelMultiply() > real 0m6.288s > user 1m3.010s > sys 0m0.027s > mem 84.0GB > BigInteger.multiply() > real 0m23.682s > user 0m23.530s > sys 0m0.004s > mem 84.0GB > > > #### openjdk version "1.8.0_302" > > BigInteger.multiply() > real 0m25.657s > user 0m25.390s > sys 0m0.001s > mem 83.9GB > > > #### openjdk version "9.0.7.1" > > BigInteger.multiply() > real 0m24.907s > user 0m24.700s > sys 0m0.001s > mem 83.9GB > > > #### openjdk version "10.0.2" 2018-07-17 > > BigInteger.multiply() > real 0m24.632s > user 0m24.380s > sys 0m0.004s > mem 83.9GB > > > #### openjdk version "11.0.12" 2021-07-20 LTS > > BigInteger.multiply() > real 0m22.114s > user 0m21.930s > sys 0m0.001s > mem 83.9GB > > > #### openjdk version "12.0.2" 2019-07-16 > > BigInteger.multiply() > real 0m23.015s > user 0m22.830s > sys 0m0.000s > mem 83.9GB > > > #### openjdk version "13.0.9" 2021-10-19 > > BigInteger.multiply() > real 0m23.548s > user 0m23.350s > sys 0m0.005s > mem 83.9GB > > > #### openjdk version "14.0.2" 2020-07-14 > > BigInteger.multiply() > real 0m22.918s > user 0m22.530s > sys 0m0.131s > mem 83.9GB > > > > #### openjdk version "15.0.5" 2021-10-19 > > BigInteger.multiply() > real 0m22.038s > user 0m21.750s > sys 0m0.003s > mem 83.9GB > > > #### openjdk version "16.0.2" 2021-07-20 > > BigInteger.multiply() > real 0m23.049s > user 0m22.760s > sys 0m0.006s > mem 83.9GB > > > #### openjdk version "17" 2021-09-14 > > BigInteger.multiply() > real 0m22.580s > user 0m22.310s > sys 0m0.001s > mem 83.9GB @kabutz thanks for the additional testing, kind of what we intuitively expected. Can you please update the specification in response to Joe's [comment](https://bugs.openjdk.java.net/browse/JDK-8278886?focusedCommentId=14470153&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14470153)? Generally for parallel constructs we try to say as little as possible with regards to latency, CPU time, and memory. The first two are sort of obvious, the later less so for the developer. >From your results I think can say a little more. Here a suggestive update addressing Joe's comments: /** * Returns a BigInteger whose value is {@code (this * val)}. * When both {@code this} and {@code val} are large, typically * in the thousands of bits, parallel multiply might be used. * This method returns the exact same mathematical result as {@link #multiply}. * * @implNote This implementation may offer better algorithmic * performance when {@code val == this}. * * @implNote Compared to {@link #multiply} this implementation's parallel multiplication algorithm * will use more CPU resources to compute the result faster, with a relatively small increase memory * consumption. * * @param val value to be multiplied by this BigInteger. * @return {@code this * val} * @see #multiply */ ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From darcy at openjdk.java.net Wed Feb 2 18:01:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 2 Feb 2022 18:01:10 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v9] In-Reply-To: <9lT4l0k6ne9HRhgOwC0shZoz-s0jiBfoUCKLpVIDCco=.a118b244-d037-4daa-a991-9b6850c49498@github.com> References: <9lT4l0k6ne9HRhgOwC0shZoz-s0jiBfoUCKLpVIDCco=.a118b244-d037-4daa-a991-9b6850c49498@github.com> Message-ID: On Fri, 28 Jan 2022 19:03:39 GMT, kabutz wrote: >> kabutz has updated the pull request incrementally with one additional commit since the last revision: >> >> Benchmark for testing the effectiveness of BigInteger.parallelMultiply() > > I have added a benchmark for checking performance difference between sequential and parallel multiply of very large Mersenne primes using BigInteger. We want to measure real time, user time, system time and the amount of memory allocated. To calculate this, we create our own thread factory for the common ForkJoinPool and then use that to measure user time, cpu time and bytes allocated. > > We use reflection to discover all methods that match "*ultiply", and use them to multiply two very large Mersenne primes together. > > ### Results on a 1-6-2 machine running Ubuntu linux > > Memory allocation increased from 83.9GB to 84GB, for both the sequential and parallel versions. This is an increase of just 0.1%. On this machine, the parallel version was 3.8x faster in latency (real time), but it used 2.7x more CPU resources. > > Testing multiplying Mersenne primes of 2^57885161-1 and 2^82589933-1 > > #### openjdk version "18-internal" 2022-03-15 > > BigInteger.parallelMultiply() > real 0m6.288s > user 1m3.010s > sys 0m0.027s > mem 84.0GB > BigInteger.multiply() > real 0m23.682s > user 0m23.530s > sys 0m0.004s > mem 84.0GB > > > #### openjdk version "1.8.0_302" > > BigInteger.multiply() > real 0m25.657s > user 0m25.390s > sys 0m0.001s > mem 83.9GB > > > #### openjdk version "9.0.7.1" > > BigInteger.multiply() > real 0m24.907s > user 0m24.700s > sys 0m0.001s > mem 83.9GB > > > #### openjdk version "10.0.2" 2018-07-17 > > BigInteger.multiply() > real 0m24.632s > user 0m24.380s > sys 0m0.004s > mem 83.9GB > > > #### openjdk version "11.0.12" 2021-07-20 LTS > > BigInteger.multiply() > real 0m22.114s > user 0m21.930s > sys 0m0.001s > mem 83.9GB > > > #### openjdk version "12.0.2" 2019-07-16 > > BigInteger.multiply() > real 0m23.015s > user 0m22.830s > sys 0m0.000s > mem 83.9GB > > > #### openjdk version "13.0.9" 2021-10-19 > > BigInteger.multiply() > real 0m23.548s > user 0m23.350s > sys 0m0.005s > mem 83.9GB > > > #### openjdk version "14.0.2" 2020-07-14 > > BigInteger.multiply() > real 0m22.918s > user 0m22.530s > sys 0m0.131s > mem 83.9GB > > > > #### openjdk version "15.0.5" 2021-10-19 > > BigInteger.multiply() > real 0m22.038s > user 0m21.750s > sys 0m0.003s > mem 83.9GB > > > #### openjdk version "16.0.2" 2021-07-20 > > BigInteger.multiply() > real 0m23.049s > user 0m22.760s > sys 0m0.006s > mem 83.9GB > > > #### openjdk version "17" 2021-09-14 > > BigInteger.multiply() > real 0m22.580s > user 0m22.310s > sys 0m0.001s > mem 83.9GB > @kabutz thanks for the additional testing, kind of what we intuitively expected. > > Can you please update the specification in response to Joe's [comment](https://bugs.openjdk.java.net/browse/JDK-8278886?focusedCommentId=14470153&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14470153)? > > Generally for parallel constructs we try to say as little as possible with regards to latency, CPU time, and memory. The first two are sort of obvious, the later less so for the developer. > > From your results I think can say a little more. Here a suggestive update addressing Joe's comments: > > ```java > /** > * Returns a BigInteger whose value is {@code (this * val)}. > * When both {@code this} and {@code val} are large, typically > * in the thousands of bits, parallel multiply might be used. > * This method returns the exact same mathematical result as {@link #multiply}. > * > * @implNote This implementation may offer better algorithmic > * performance when {@code val == this}. > * > * @implNote Compared to {@link #multiply} this implementation's parallel multiplication algorithm > * will use more CPU resources to compute the result faster, with a relatively small increase memory > * consumption. > * > * @param val value to be multiplied by this BigInteger. > * @return {@code this * val} > * @see #multiply > */ > ``` Yes, my intention is that the parallelMultiply spec give some guidance to the user on when to use it and warning about the consequences of doing so (same answer, should be in less time, but more compute and possibly a bit more memory). ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From albest512 at hotmail.com Wed Feb 2 19:27:43 2022 From: albest512 at hotmail.com (=?iso-8859-1?Q?Alberto_Otero_Rodr=EDguez?=) Date: Wed, 2 Feb 2022 19:27:43 +0000 Subject: Constant methods in Java Message-ID: I have a suggestion. I think it would be interesting creating constant methods in Java. I mean methods declared like this: public const String myMethod() { String a = "a"; a = a + "b"; return a; } So that the response of the method is forced to be assigned to a final variable. This would be ok: final String b = myMethod(); But this would throw a compilation error: String c = myMethod(); What do you think? It's just an idea. From raffaello.giulietti at gmail.com Wed Feb 2 20:08:38 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 2 Feb 2022 21:08:38 +0100 Subject: Constant methods in Java In-Reply-To: References: Message-ID: <8c104005-fda0-01f9-5fe8-577bd1dfc9e9@gmail.com> Hello, I don't get why the author of myMethod() would/should be interested in forcing the caller of the method to declare the variable b to be final. Stated otherwise, what is the problem addressed by this suggestion? Have you some specific case in mind? Greetings Raffaello On 2022-02-02 20:27, Alberto Otero Rodr?guez wrote: > I have a suggestion. I think it would be interesting creating constant methods in Java. > > I mean methods declared like this: > > public const String myMethod() { > String a = "a"; > a = a + "b"; > return a; > } > > So that the response of the method is forced to be assigned to a final variable. > > This would be ok: > final String b = myMethod(); > > But this would throw a compilation error: > String c = myMethod(); > > What do you think? It's just an idea. From talden at gmail.com Wed Feb 2 20:30:23 2022 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Thu, 3 Feb 2022 09:30:23 +1300 Subject: Constant methods in Java In-Reply-To: <8c104005-fda0-01f9-5fe8-577bd1dfc9e9@gmail.com> References: <8c104005-fda0-01f9-5fe8-577bd1dfc9e9@gmail.com> Message-ID: There's this, and the fact that it's effectively unenforceable. String t = ((Supplier) () -> { final String s = myMethod(); return s; }).get(); So you keep the compiler happy but the desire to force only final retention of the reference (which, like Raffaello, I don't understand the use-case for) can be trivially circumvented. -- Aaron Scott-Boddendijk On Thu, Feb 3, 2022 at 9:09 AM Raffaello Giulietti < raffaello.giulietti at gmail.com> wrote: > Hello, > > I don't get why the author of myMethod() would/should be interested in > forcing the caller of the method to declare the variable b to be final. > Stated otherwise, what is the problem addressed by this suggestion? > Have you some specific case in mind? > > > Greetings > Raffaello > > > On 2022-02-02 20:27, Alberto Otero Rodr?guez wrote: > > I have a suggestion. I think it would be interesting creating constant > methods in Java. > > > > I mean methods declared like this: > > > > public const String myMethod() { > > String a = "a"; > > a = a + "b"; > > return a; > > } > > > > So that the response of the method is forced to be assigned to a final > variable. > > > > This would be ok: > > final String b = myMethod(); > > > > But this would throw a compilation error: > > String c = myMethod(); > > > > What do you think? It's just an idea. > From myano at openjdk.java.net Wed Feb 2 21:06:12 2022 From: myano at openjdk.java.net (Masanori Yano) Date: Wed, 2 Feb 2022 21:06:12 GMT Subject: Integrated: 8266974: duplicate property key in java.sql.rowset resource bundle In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 10:47:41 GMT, Masanori Yano wrote: > I have removed the duplicate property keys. > Could you please review the fix? This pull request has now been integrated. Changeset: e3d5c9e7 Author: Masanori Yano Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/e3d5c9e7c4ab210ae7a4417a47632603910744a1 Stats: 22 lines in 11 files changed: 0 ins; 11 del; 11 mod 8266974: duplicate property key in java.sql.rowset resource bundle Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7212 From minqi at openjdk.java.net Thu Feb 3 02:51:13 2022 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 3 Feb 2022 02:51:13 GMT Subject: RFR: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin Since no further update, I will integrate tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From duke at openjdk.java.net Thu Feb 3 05:29:51 2022 From: duke at openjdk.java.net (kabutz) Date: Thu, 3 Feb 2022 05:29:51 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v10] In-Reply-To: References: Message-ID: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> > BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. > > The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. > > We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. > > Some benchmark results, run on my 1-6-2 server: > > > Benchmark (n) Mode Cnt Score Error Units > BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op > BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op > BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op > BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op > BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op > BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op > > > We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. kabutz has updated the pull request incrementally with one additional commit since the last revision: Updated comment to include information about performance ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6409/files - new: https://git.openjdk.java.net/jdk/pull/6409/files/fc7b844a..ef74878e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=08-09 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6409/head:pull/6409 PR: https://git.openjdk.java.net/jdk/pull/6409 From duke at openjdk.java.net Thu Feb 3 05:37:12 2022 From: duke at openjdk.java.net (kabutz) Date: Thu, 3 Feb 2022 05:37:12 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v10] In-Reply-To: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> References: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> Message-ID: <1kij84fM01EmZ3tQ8aQhx-bnnnD-C2z8mo9-i0E7pOQ=.0e7678c3-2e7d-48d4-a432-bfed1c07ebda@github.com> On Thu, 3 Feb 2022 05:29:51 GMT, kabutz wrote: >> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. >> >> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. >> >> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. >> >> Some benchmark results, run on my 1-6-2 server: >> >> >> Benchmark (n) Mode Cnt Score Error Units >> BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op >> BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op >> BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op >> BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op >> BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op >> BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op >> >> >> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment to include information about performance The multiply() and parallelMultiply() use the exact same amount of memory now. However, they both use a little bit more than the previous multiply() method when the numbers are very large. We tried various approaches to keep the memory usage the same for non-parallel multiply(), but the solutions were not elegant. Since the small memory increase is only when the object allocation is huge, the extra memory did not make a difference. For small numbers, multiply() and parallelMultiply() are exactly the same as the old multiply(). multiply() thus has the same latency and CPU consumption as before. A question about wording of the @implNote. In multiply() they say: "An implementation may offer better algorithmic ...", but we changed this to "This implementation may offer better algorithmic ..." I've kept it as "This implementation may ...", but what is the better way of writing such implementation notes? ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From darcy at openjdk.java.net Thu Feb 3 06:39:11 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 3 Feb 2022 06:39:11 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v10] In-Reply-To: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> References: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> Message-ID: <5M4d9wsxupT34r9kSkXgRDxdi3gLo9IqzGJtTWmM3I4=.f841d343-eb9e-49fb-8f57-efd911a0bb2d@github.com> On Thu, 3 Feb 2022 05:29:51 GMT, kabutz wrote: >> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. >> >> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. >> >> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. >> >> Some benchmark results, run on my 1-6-2 server: >> >> >> Benchmark (n) Mode Cnt Score Error Units >> BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op >> BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op >> BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op >> BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op >> BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op >> BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op >> >> >> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment to include information about performance src/java.base/share/classes/java/math/BigInteger.java line 1603: > 1601: * parallel multiplication algorithm will use more CPU resources > 1602: * to compute the result faster, with no increase in memory > 1603: * consumption. The implNote should cover a space of possible parallel multiply implementations so it doesn't have to be updated as often as the implementation is tuned or adjusted. So I'd prefer to have a statement like "may use more memory" even if the current implementation doesn't actually use more memory. If there are any "contraindications" on when to use the method, they could be listed here too. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From shade at openjdk.java.net Thu Feb 3 07:28:34 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Feb 2022 07:28:34 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter Message-ID: I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`. There is direct VarHandle benchmark in our corpus: $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint" Benchmark Mode Cnt Score Error Units # -Xint # Baseline VarHandleExact.exact_exactInvocation avgt 30 714.041 ? 5.882 ns/op VarHandleExact.generic_exactInvocation avgt 30 641.570 ? 11.681 ns/op VarHandleExact.generic_genericInvocation avgt 30 1336.571 ? 11.873 ns/op # -Xint # Patched VarHandleExact.exact_exactInvocation avgt 30 678.495 ? 10.752 ns/op ; +5% VarHandleExact.generic_exactInvocation avgt 30 573.320 ? 5.100 ns/op ; +11% VarHandleExact.generic_genericInvocation avgt 30 1338.593 ? 14.275 ns/op # (server, default) # Baseline VarHandleExact.exact_exactInvocation avgt 30 0.620 ? 0.079 ns/op VarHandleExact.generic_exactInvocation avgt 30 0.602 ? 0.063 ns/op VarHandleExact.generic_genericInvocation avgt 30 10.521 ? 0.065 ns/op # (server, default) # Patched VarHandleExact.exact_exactInvocation avgt 30 0.621 ? 0.070 ns/op VarHandleExact.generic_exactInvocation avgt 30 0.601 ? 0.061 ns/op VarHandleExact.generic_genericInvocation avgt 30 10.499 ? 0.070 ns/op Additional testing: - [x] Linux x86_64 fastdebug `tier1` - [x] Linux x86_64 fastdebug `tier2` - [x] Linux x86_64 fastdebug `tier3` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/7333/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7333&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281168 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7333/head:pull/7333 PR: https://git.openjdk.java.net/jdk/pull/7333 From akozlov at azul.com Thu Feb 3 10:18:59 2022 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 3 Feb 2022 13:18:59 +0300 Subject: [crac] RFR: Ensure empty Reference Handler and Cleaners queues In-Reply-To: <1c2136a0-90c2-cabc-a948-bc4a02f1533b@oracle.com> References: <1c2136a0-90c2-cabc-a948-bc4a02f1533b@oracle.com> Message-ID: On 2/2/22 17:48, Alan Bateman wrote:> At a high level it should be okay to provide a JDK-internal way to await quiescent. You've added it as a public API which might be okay for the current exploration but I don't think it would be exposed in its current form. Once the method returns then there is no guarantee that the number of waiters hasn't changed, but I think you know that I thought about blocking waiters regardless of References available in the Queue. This would leave threads in the quiescent state but References would pile up in the pendingReferenceQueue exposed by the VM. So I stopped on the method being a synchronization, rather than a blocking point. I hoped to guarantee all Queues are empty by waiting a sufficient number of waiters for each Queue, in the order of Queues passing References between each other (for a single thread). But now even there, I see handling of a Reference later in the order may make another one pending, filling up a Queue that was supposed to be empty. For a strong guarantee that all Queues are empty, some sort of iteration may be required, that will check no Queue had a new reference since the last check. I think a public API is needed as users may have the same problem as we do. But the current code does not support this (we need to allow user code after JDK Queues are emptied). Interesting... Thanks! Anton From jai.forums2013 at gmail.com Thu Feb 3 13:01:40 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 3 Feb 2022 18:31:40 +0530 Subject: Source file launch with security manager enabled fails Message-ID: I'm unsure if core-libs is the right place for this or compiler-dev, sending this to core-libs for now. Please consider this trivial Java source file: public class HelloWorld { ?? ?public static void main(final String[] args) throws Exception { ?? ???? System.out.println("Hello World"); ?? ?} } Running this in source file launcher mode as follows: java HelloWorld.java returns the expected result. However when running in source file launcher mode *and* with security manager enabled, it throws the following exception: java -Djava.security.manager=default HelloWorld.java WARNING: A command line option has enabled the Security Manager WARNING: The Security Manager is deprecated and will be removed in a future release Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.misc") ?? ?at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485) ?? ?at java.base/java.security.AccessController.checkPermission(AccessController.java:1068) ?? ?at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416) ?? ?at java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1332) ?? ?at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:184) ?? ?at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) ?? ?at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) This happens in Java 17 as well as latest master branch. I haven't checked older releases but I guess it's reproducible there too. Are users expected to use an explicit policy file to add this permission in source file launch mode or is this missing an internal doPrivileged call in the JDK? As an additional input, compiling this file first using javac and then launching it in traditional mode with security manager enabled works fine: javac HelloWorld.java java -Djava.security.manager=default HelloWorld WARNING: A command line option has enabled the Security Manager WARNING: The Security Manager is deprecated and will be removed in a future release Hello World -Jaikiran From sean.mullan at oracle.com Thu Feb 3 13:25:22 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 3 Feb 2022 08:25:22 -0500 Subject: Source file launch with security manager enabled fails In-Reply-To: References: Message-ID: <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com> I only took a quick look, but it looks like a bug. The jdk.compiler module needs to be granted that permission in the default.policy file. Please file a bug, or if you like I can file one on your behalf. Thanks, Sean On 2/3/22 8:01 AM, Jaikiran Pai wrote: > I'm unsure if core-libs is the right place for this or compiler-dev, > sending this to core-libs for now. > > Please consider this trivial Java source file: > > public class HelloWorld { > ?? ?public static void main(final String[] args) throws Exception { > ?? ???? System.out.println("Hello World"); > ?? ?} > } > > Running this in source file launcher mode as follows: > > java HelloWorld.java > > returns the expected result. However when running in source file > launcher mode *and* with security manager enabled, it throws the > following exception: > > java -Djava.security.manager=default HelloWorld.java > > WARNING: A command line option has enabled the Security Manager > WARNING: The Security Manager is deprecated and will be removed in a > future release > Exception in thread "main" java.security.AccessControlException: access > denied ("java.lang.RuntimePermission" > "accessClassInPackage.jdk.internal.misc") > ?? ?at > java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485) > ?? ?at > java.base/java.security.AccessController.checkPermission(AccessController.java:1068) > ?? ?at > java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416) > ?? ?at > java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1332) > ?? ?at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:184) > ?? ?at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) > ?? ?at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) > > > This happens in Java 17 as well as latest master branch. I haven't > checked older releases but I guess it's reproducible there too. > > Are users expected to use an explicit policy file to add this permission > in source file launch mode or is this missing an internal doPrivileged > call in the JDK? > > As an additional input, compiling this file first using javac and then > launching it in traditional mode with security manager enabled works fine: > > javac HelloWorld.java > > java -Djava.security.manager=default HelloWorld > WARNING: A command line option has enabled the Security Manager > WARNING: The Security Manager is deprecated and will be removed in a > future release > Hello World > > > -Jaikiran > > > From jai.forums2013 at gmail.com Thu Feb 3 13:32:05 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 3 Feb 2022 19:02:05 +0530 Subject: Source file launch with security manager enabled fails In-Reply-To: <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com> References: <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com> Message-ID: Thank you Sean for the confirmation. I just filed https://bugs.openjdk.java.net/browse/JDK-8281217 to track this. -Jaikiran On 03/02/22 6:55 pm, Sean Mullan wrote: > I only took a quick look, but it looks like a bug. The jdk.compiler > module needs to be granted that permission in the default.policy file. > > Please file a bug, or if you like I can file one on your behalf. > > Thanks, > Sean > > On 2/3/22 8:01 AM, Jaikiran Pai wrote: >> I'm unsure if core-libs is the right place for this or compiler-dev, >> sending this to core-libs for now. >> >> Please consider this trivial Java source file: >> >> public class HelloWorld { >> ? ?? ?public static void main(final String[] args) throws Exception { >> ? ?? ???? System.out.println("Hello World"); >> ? ?? ?} >> } >> >> Running this in source file launcher mode as follows: >> >> java HelloWorld.java >> >> returns the expected result. However when running in source file >> launcher mode *and* with security manager enabled, it throws the >> following exception: >> >> java -Djava.security.manager=default HelloWorld.java >> >> WARNING: A command line option has enabled the Security Manager >> WARNING: The Security Manager is deprecated and will be removed in a >> future release >> Exception in thread "main" java.security.AccessControlException: access >> denied ("java.lang.RuntimePermission" >> "accessClassInPackage.jdk.internal.misc") >> ? ?? ?at >> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485) >> >> ? ?? ?at >> java.base/java.security.AccessController.checkPermission(AccessController.java:1068) >> >> ? ?? ?at >> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416) >> >> ? ?? ?at >> java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1332) >> >> ? ?? ?at >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:184) >> >> ? ?? ?at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) >> ? ?? ?at >> jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) >> >> >> This happens in Java 17 as well as latest master branch. I haven't >> checked older releases but I guess it's reproducible there too. >> >> Are users expected to use an explicit policy file to add this permission >> in source file launch mode or is this missing an internal doPrivileged >> call in the JDK? >> >> As an additional input, compiling this file first using javac and then >> launching it in traditional mode with security manager enabled works >> fine: >> >> javac HelloWorld.java >> >> java -Djava.security.manager=default HelloWorld >> WARNING: A command line option has enabled the Security Manager >> WARNING: The Security Manager is deprecated and will be removed in a >> future release >> Hello World >> >> >> -Jaikiran >> >> >> From Alan.Bateman at oracle.com Thu Feb 3 13:37:06 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Feb 2022 13:37:06 +0000 Subject: Source file launch with security manager enabled fails In-Reply-To: <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com> References: <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com> Message-ID: <1a7b61fc-4c31-862a-25be-4bb407633e84@oracle.com> I think it would be useful to hear from Jon Gibbons or someone else working on javac first. It would be a bit unusual to run the compiler with a security manager and I thought it was deliberate to not grant permissions to jdk.compiler in the default policy. Also the source code launcher is aimed at the early stages of learning Java where there shouldn't be advanced options or exotic execution modes. -Alan On 03/02/2022 13:25, Sean Mullan wrote: > I only took a quick look, but it looks like a bug. The jdk.compiler > module needs to be granted that permission in the default.policy file. > > Please file a bug, or if you like I can file one on your behalf. > > Thanks, > Sean > > On 2/3/22 8:01 AM, Jaikiran Pai wrote: >> I'm unsure if core-libs is the right place for this or compiler-dev, >> sending this to core-libs for now. >> >> Please consider this trivial Java source file: >> >> public class HelloWorld { >> ? ?? ?public static void main(final String[] args) throws Exception { >> ? ?? ???? System.out.println("Hello World"); >> ? ?? ?} >> } >> >> Running this in source file launcher mode as follows: >> >> java HelloWorld.java >> >> returns the expected result. However when running in source file >> launcher mode *and* with security manager enabled, it throws the >> following exception: >> >> java -Djava.security.manager=default HelloWorld.java >> >> WARNING: A command line option has enabled the Security Manager >> WARNING: The Security Manager is deprecated and will be removed in a >> future release >> Exception in thread "main" java.security.AccessControlException: access >> denied ("java.lang.RuntimePermission" >> "accessClassInPackage.jdk.internal.misc") >> ? ?? ?at >> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485) >> >> ? ?? ?at >> java.base/java.security.AccessController.checkPermission(AccessController.java:1068) >> >> ? ?? ?at >> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416) >> >> ? ?? ?at >> java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1332) >> >> ? ?? ?at >> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:184) >> >> ? ?? ?at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) >> ? ?? ?at >> jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132) >> >> >> This happens in Java 17 as well as latest master branch. I haven't >> checked older releases but I guess it's reproducible there too. >> >> Are users expected to use an explicit policy file to add this permission >> in source file launch mode or is this missing an internal doPrivileged >> call in the JDK? >> >> As an additional input, compiling this file first using javac and then >> launching it in traditional mode with security manager enabled works >> fine: >> >> javac HelloWorld.java >> >> java -Djava.security.manager=default HelloWorld >> WARNING: A command line option has enabled the Security Manager >> WARNING: The Security Manager is deprecated and will be removed in a >> future release >> Hello World >> >> >> -Jaikiran >> >> >> From jai.forums2013 at gmail.com Thu Feb 3 13:43:28 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 3 Feb 2022 19:13:28 +0530 Subject: Source file launch with security manager enabled fails In-Reply-To: <1a7b61fc-4c31-862a-25be-4bb407633e84@oracle.com> References: <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com> <1a7b61fc-4c31-862a-25be-4bb407633e84@oracle.com> Message-ID: <67da05c0-2578-2231-3ba0-e9db95b649a1@gmail.com> On 03/02/22 7:07 pm, Alan Bateman wrote: > > I think it would be useful to hear from Jon Gibbons or someone else > working on javac first. It would be a bit unusual to run the compiler > with a security manager and I thought it was deliberate to not grant > permissions to jdk.compiler in the default policy. Also the source > code launcher is aimed at the early stages of learning Java where > there shouldn't be advanced options or exotic execution modes. To add some context on where I ran into this - I was experimenting with security manager itself to see how the SocketChannel.bind() API behaves when security manager was enabled. Something like this trivial code: import java.nio.channels.*; import java.net.*; public class SecManager { ?? ?public static void main(final String[] args) throws Exception { ?? ???? SocketChannel sc = SocketChannel.open(); ?? ???? System.out.println("Opened socket channel " + sc); ?? ???? sc.bind(new InetSocketAddress("127.0.0.1", 23452)); ?? ???? System.out.println("Bound socket channel " + sc); ?? ???? sc.close(); ?? ???? System.out.println("Closed socket channel " + sc); ?? ?} } I decided to use source launcher mode here and since I was experimenting with security manager itself, I had to enable security manager. I had a look at the JEP-330 https://openjdk.java.net/jeps/330 where this feature was introduced but couldn't see a mention of whether using/enabling security manager with this feature was allowed/supported. -Jaikiran From cstein at openjdk.java.net Thu Feb 3 16:27:36 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Thu, 3 Feb 2022 16:27:36 GMT Subject: RFR: 8281104: jar --create should create missing parent directories Message-ID: Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. ------------- Commit messages: - Expect at least jar file's name in error message - Use provided error writer - Use LF as line separator - 8281104: Add happy-path and expected-to-fail tests - 8281104: jar --create should create missing parent directories Changes: https://git.openjdk.java.net/jdk/pull/7327/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7327&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281104 Stats: 124 lines in 2 files changed: 119 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7327/head:pull/7327 PR: https://git.openjdk.java.net/jdk/pull/7327 From weijun at openjdk.java.net Thu Feb 3 17:21:32 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 3 Feb 2022 17:21:32 GMT Subject: RFR: 8281175: Add a -providerPath option to jarsigner Message-ID: Add the `-providerPath` option to jarsigner to be consistent with keytool. ------------- Commit messages: - 8281175: Add a -providerPath option to jarsigner Changes: https://git.openjdk.java.net/jdk/pull/7338/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7338&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281175 Stats: 39 lines in 3 files changed: 24 ins; 5 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7338.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7338/head:pull/7338 PR: https://git.openjdk.java.net/jdk/pull/7338 From minqi at openjdk.java.net Thu Feb 3 18:07:12 2022 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 3 Feb 2022 18:07:12 GMT Subject: Integrated: 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call In-Reply-To: References: Message-ID: <3dNFLZSlmP3oTlqhbEvQrTbVPUmh43zxnRHqXoUxCR8=.da8cdf20-6b08-4c58-ba75-cb4981cd80ad@github.com> On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote: > Please review, > When jlink with --compress=2, zip is used to compress the files while doing copy. The user case failed to load zip.dll, since zip.dll is not set in PATH. This failure is after we get NULL from GetModuleHandle("zip.dll"), then do LoadLibrary("zip.dll") will have same result. > The fix is calling load_zip_library of ClassLoader first --- if zip library already loaded just return the cached handle for following usage, if not, load zip library and cached the handle. > > Tests: tier1,4,7 in test > Manually tested user case, and checked output of jimage list for jlinked files using --compress=2. > > Thanks > Yumin This pull request has now been integrated. Changeset: cda9c301 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/cda9c3011beeec8df68e78e096132e712255ce1b Stats: 49 lines in 6 files changed: 18 ins; 14 del; 17 mod 8278753: Runtime crashes with access violation during JNI_CreateJavaVM call Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/7206 From lancea at openjdk.java.net Thu Feb 3 18:14:13 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 3 Feb 2022 18:14:13 GMT Subject: RFR: 8281104: jar --create should create missing parent directories In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote: > Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. Thank you for taking this on. Overall looks good. A few comments below. Also, we should update jar.properties to indicate that the directory path will be created as needed in the help section for jar. Best, Lance src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 468: > 466: if (parent != null) { > 467: Files.createDirectories(parent); > 468: } Would be good to move the creation after validating the arguments as this would fail after creating the temp zip file. Be good to do via another PR test/jdk/tools/jar/CreateMissingParentDirectories.java line 38: > 36: import java.util.stream.Stream; > 37: > 38: public class CreateMissingParentDirectories { Understand why you used went this route for the test given some of the older tests use this framework. I might have gone the route of using TestNG as the newer tests (such as in MultiRelease) use it. test/jdk/tools/jar/CreateMissingParentDirectories.java line 78: > 76: > 77: private static void doHappyPathTest(Path jar, Path entry) throws Throwable { > 78: String[] jarArgs = new String[]{"cf", jar.toString(), entry.toString()}; I might consider also using --create --file in addition to "cf" in a run for an extra sanity check ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From cstein at openjdk.java.net Thu Feb 3 19:45:12 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Thu, 3 Feb 2022 19:45:12 GMT Subject: RFR: 8281104: jar --create should create missing parent directories In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote: > Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. Thanks for the review, Lance. I didn't change order of creation, validation, and movement of the temporary JAR file in order to keep existing behaviour consistent. A reason to use the main-based testing approach was also the ability to run the test via JEP 330: `java CreateMissingParentDirectories.java` > Also, we should update jar.properties to indicate that the directory path will be created as needed in the help section for jar. That's a good point. Where would we put that information? - [ ] Extend the descriptions of option `c`/`--create` and/or option `f`/`--file`? - [ ] As a post scriptum note below the options? https://github.com/openjdk/jdk/blob/master/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties#L309-L317 ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From duke at openjdk.java.net Thu Feb 3 20:50:14 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Thu, 3 Feb 2022 20:50:14 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v3] In-Reply-To: References: Message-ID: On Sat, 29 Jan 2022 16:13:46 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - fix missing periods > - Use final on initialized variable Since everyone agrees that using Random.from() seems like a better idea, should i keep this PR open and redo the patch at Random class or do another PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From rriggs at openjdk.java.net Thu Feb 3 21:36:08 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 3 Feb 2022 21:36:08 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v3] In-Reply-To: References: Message-ID: On Sat, 29 Jan 2022 16:13:46 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - fix missing periods > - Use final on initialized variable Either is fine. A new PR might just look a bit cleaner; your choice. All the code changes would be in Random plus the test, and an informational note in RandomGenerator or @ see to the method in Random would be a good cross reference. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From lancea at openjdk.java.net Thu Feb 3 21:46:09 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 3 Feb 2022 21:46:09 GMT Subject: RFR: 8281104: jar --create should create missing parent directories In-Reply-To: References: Message-ID: <0aVktv5u2S4HJeVzXxJkr2O4jE5SlOv2J73sFwEJf2A=.3af0f5f4-28b0-474f-b1a7-4502b41bd983@github.com> On Thu, 3 Feb 2022 19:42:25 GMT, Christian Stein wrote: > Thanks for the review, Lance. > > I didn't change order of creation, validation, and movement of the temporary JAR file in order to keep existing behaviour consistent. I do think we are better served with the validation check earlier on. In the case of a failure, we do not make the tmp file name known so it could be easy to miss. I think it makes sense to report the issue before erring out after creating the jar.. If the behavior stays as is, it would be best to document that the tmp file would still be there. Let's see what others think. Either way we can accomplish the additional change if we reach consensus via a separate PR. > > A reason to use the main-based testing approach was also the ability to run the test via JEP 330: `java CreateMissingParentDirectories.java` For me personally, I would not use that means to run the tests as typically would from an IDE. Plus there is a benefit of leveraging the test framework in TestNG. I totally understand everyone has a personal preference. A discussion for another day I guess ;-). > > > Also, we should update jar.properties to indicate that the directory path will be created as needed in the help section for jar. > > That's a good point. Where would we put that information? > > * [ ] Extend the descriptions of option `c`/`--create` and/or option `f`/`--file`? I think this would be the appropriate place for documenting the behavior. > * [ ] As a post scriptum note below the options? > https://github.com/openjdk/jdk/blob/master/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties#L309-L317 Also we will need to update the MD file which represents the jar man page via a separate PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From smarks at openjdk.java.net Thu Feb 3 22:04:08 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 3 Feb 2022 22:04:08 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v3] In-Reply-To: References: Message-ID: On Sat, 29 Jan 2022 16:13:46 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - fix missing periods > - Use final on initialized variable I think pushing more commits into the same PR should be fine. It's basically moving the same code into a different place and making some minor adjustments. (While we're on that topic, the wrapper might be better expressed as a nested class of j.u.Random. It might also be an opportunity to call a new constructor that avoids the hack workaround for setSeed.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From jlaskey at openjdk.java.net Thu Feb 3 22:14:11 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 3 Feb 2022 22:14:11 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v3] In-Reply-To: References: Message-ID: <4E1rjwUvS-Ut2Cm7igTbIfGghSaMrnVvMgvQtpYOAF8=.1e775a68-f5d4-4416-a788-9f4550fe9903@github.com> On Sat, 29 Jan 2022 16:13:46 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - fix missing periods > - Use final on initialized variable Using the same PR also keeps the discussion in one spot. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From naoto at openjdk.java.net Fri Feb 4 00:11:20 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Feb 2022 00:11:20 GMT Subject: RFR: 8176706: Additional Date-Time Formats Message-ID: Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html ------------- Commit messages: - Removed trailing space - Merge branch 'master' into skeleton - Tidying up - Some more tests - Brought back the part that was mistakenly removed - Merge branch 'master' into skeleton - Reverted IllegalArgumentException back - Further cleanups - Removed exceptions from ofLocalizedPattern() method, as they are lazily thrown on format() - Cleanup - ... and 19 more: https://git.openjdk.java.net/jdk/compare/cda9c301...f9311dce Changes: https://git.openjdk.java.net/jdk/pull/7340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8176706 Stats: 777 lines in 12 files changed: 733 ins; 9 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/7340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7340/head:pull/7340 PR: https://git.openjdk.java.net/jdk/pull/7340 From djelinski at openjdk.java.net Fri Feb 4 10:25:44 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 4 Feb 2022 10:25:44 GMT Subject: RFR: 8281259: MutableBigInteger subtraction could be simplified Message-ID: The proposed form of borrow bit handling is [already used in BigInteger class](https://github.com/djelinski/jdk/blob/ce26a19be5e907c11164b46f1bcb370b534d5bf6/src/java.base/share/classes/java/math/BigInteger.java#L1558). JMH results without the patch: Benchmark (maxNumbits) Mode Cnt Score Error Units BigIntegers.testGcd 256 avgt 25 3181205,367 ? 155272,427 ns/op JMH results with the patch applied: Benchmark (maxNumbits) Mode Cnt Score Error Units BigIntegers.testGcd 256 avgt 25 2696030,849 ? 14141,940 ns/op ------------- Commit messages: - Remove unnecessary looping - Simplify borrow bit handling - Add gcd microbenchmark Changes: https://git.openjdk.java.net/jdk/pull/7342/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7342&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281259 Stats: 16 lines in 2 files changed: 11 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7342.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7342/head:pull/7342 PR: https://git.openjdk.java.net/jdk/pull/7342 From xenoamess at gmail.com Fri Feb 4 10:42:52 2022 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 4 Feb 2022 18:42:52 +0800 Subject: HashMap.putAll can cause redundant space waste Message-ID: import java.lang.reflect.Array; import java.lang.reflect.Field; import java.util.HashMap; import java.util.Map; public class TestMap { public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { HashMap a = new HashMap<>(); fill12(a); HashMap b = new HashMap<>(12); fill12(b); HashMap c = new HashMap<>(a); HashMap d = new HashMap<>(); d.putAll(a); System.out.println("a : " + getArrayLength(a)); System.out.println("b : " + getArrayLength(b)); System.out.println("c : " + getArrayLength(c)); System.out.println("d : " + getArrayLength(d)); } public static void fill12(Map map) { for (int i = 0; i < 12; i++) { map.put(i, i); } } public static int getArrayLength(Map map) throws NoSuchFieldException, IllegalAccessException { Field field = HashMap.class.getDeclaredField("table"); field.setAccessible(true); Object table = field.get(map); return Array.getLength(table); } } run this and we get the output: a : 16 b : 16 c : 32 d : 32 So I go see the codes. /** * Implements Map.putAll and Map constructor. * * @param m the map * @param evict false when initially constructing this map, else * true (relayed to method afterNodeInsertion). */ final void putMapEntries(Map m, boolean evict) { int s = m.size(); if (s > 0) { if (table == null) { // pre-size float ft = ((float)s / loadFactor) + 1.0F; int t = ((ft < (float)MAXIMUM_CAPACITY) ? (int)ft : MAXIMUM_CAPACITY); if (t > threshold) threshold = tableSizeFor(t); } else { // Because of linked-list bucket constraints, we cannot // expand all at once, but can reduce total resize // effort by repeated doubling now vs later while (s > threshold && table.length < MAXIMUM_CAPACITY) resize(); } for (Map.Entry e : m.entrySet()) { K key = e.getKey(); V value = e.getValue(); putVal(hash(key), key, value, false, evict); } } } yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. It should be *Math.ceil((float)s / loadFactor)* So I wish to generate a pull request. Anyone interested? From xenoamess at gmail.com Fri Feb 4 10:45:21 2022 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 4 Feb 2022 18:45:21 +0800 Subject: HashMap.putAll can cause redundant space waste In-Reply-To: References: Message-ID: also find some other places have same problem. If some of your already-in people aggree, I would create a pr, but according to the rules seems I should wait for now. Xeno Amess ?2022?2?4??? 18:42??? > import java.lang.reflect.Array; > import java.lang.reflect.Field; > import java.util.HashMap; > import java.util.Map; > > public class TestMap { > > public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { > HashMap a = new HashMap<>(); > fill12(a); > HashMap b = new HashMap<>(12); > fill12(b); > HashMap c = new HashMap<>(a); > HashMap d = new HashMap<>(); > d.putAll(a); > System.out.println("a : " + getArrayLength(a)); > System.out.println("b : " + getArrayLength(b)); > System.out.println("c : " + getArrayLength(c)); > System.out.println("d : " + getArrayLength(d)); > } > > public static void fill12(Map map) { > for (int i = 0; i < 12; i++) { > map.put(i, i); > } > } > > public static int getArrayLength(Map map) throws NoSuchFieldException, IllegalAccessException { > Field field = HashMap.class.getDeclaredField("table"); > field.setAccessible(true); > Object table = field.get(map); > return Array.getLength(table); > } > > } > > run this and we get the output: > > a : 16 > b : 16 > c : 32 > d : 32 > > So I go see the codes. > > /** > * Implements Map.putAll and Map constructor. > * > * @param m the map > * @param evict false when initially constructing this map, else > * true (relayed to method afterNodeInsertion). > */ > final void putMapEntries(Map m, boolean evict) { > int s = m.size(); > if (s > 0) { > if (table == null) { // pre-size > float ft = ((float)s / loadFactor) + 1.0F; > int t = ((ft < (float)MAXIMUM_CAPACITY) ? > (int)ft : MAXIMUM_CAPACITY); > if (t > threshold) > threshold = tableSizeFor(t); > } else { > // Because of linked-list bucket constraints, we cannot > // expand all at once, but can reduce total resize > // effort by repeated doubling now vs later > while (s > threshold && table.length < MAXIMUM_CAPACITY) > resize(); > } > > for (Map.Entry e : m.entrySet()) { > K key = e.getKey(); > V value = e.getValue(); > putVal(hash(key), key, value, false, evict); > } > } > } > > yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. > > It should be *Math.ceil((float)s / loadFactor)* > > So I wish to generate a pull request. > > Anyone interested? > > From robm at openjdk.java.net Fri Feb 4 13:10:15 2022 From: robm at openjdk.java.net (Rob McKenna) Date: Fri, 4 Feb 2022 13:10:15 GMT Subject: Integrated: JDK-8277795: ldap connection timeout not honoured under contention In-Reply-To: References: Message-ID: On Thu, 25 Nov 2021 23:54:18 GMT, Rob McKenna wrote: > This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences. > > Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR. This pull request has now been integrated. Changeset: 3d926dd6 Author: Rob McKenna URL: https://git.openjdk.java.net/jdk/commit/3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a Stats: 467 lines in 5 files changed: 324 ins; 72 del; 71 mod 8277795: ldap connection timeout not honoured under contention Reviewed-by: dfuchs, aefimov ------------- PR: https://git.openjdk.java.net/jdk/pull/6568 From xenoamess at gmail.com Fri Feb 4 13:39:35 2022 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 4 Feb 2022 21:39:35 +0800 Subject: HashMap.putAll can cause redundant space waste In-Reply-To: References: Message-ID: patch applied. Index: src/java.base/share/classes/java/lang/Module.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/src/java.base/share/classes/java/lang/Module.java b/src/java.base/share/classes/java/lang/Module.java --- a/src/java.base/share/classes/java/lang/Module.java (revision 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) +++ b/src/java.base/share/classes/java/lang/Module.java (revision deeba25d15398fea8bc971ac915e348878b2c27a) @@ -1133,7 +1133,7 @@ boolean isBootLayer = (ModuleLayer.boot() == null); int numModules = cf.modules().size(); - int cap = (int)(numModules / 0.75f + 1.0f); + int cap = (int)Math.ceil(numModules / 0.75f); Map nameToModule = new HashMap<>(cap); // to avoid repeated lookups and reduce iteration overhead, we create Index: src/java.base/share/classes/java/util/HashMap.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/src/java.base/share/classes/java/util/HashMap.java b/src/java.base/share/classes/java/util/HashMap.java --- a/src/java.base/share/classes/java/util/HashMap.java (revision 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) +++ b/src/java.base/share/classes/java/util/HashMap.java (revision deeba25d15398fea8bc971ac915e348878b2c27a) @@ -495,9 +495,9 @@ int s = m.size(); if (s > 0) { if (table == null) { // pre-size - float ft = ((float)s / loadFactor) + 1.0F; - int t = ((ft < (float)MAXIMUM_CAPACITY) ? - (int)ft : MAXIMUM_CAPACITY); + double dt = Math.ceil(s / loadFactor); + int t = ((dt < (double)MAXIMUM_CAPACITY) ? + (int)dt : MAXIMUM_CAPACITY); if (t > threshold) threshold = tableSizeFor(t); } else { @@ -1527,12 +1527,12 @@ } else if (mappings == 0) { // use defaults } else if (mappings > 0) { - float fc = (float)mappings / lf + 1.0f; - int cap = ((fc < DEFAULT_INITIAL_CAPACITY) ? + double dc = Math.ceil(mappings / lf); + int cap = ((dc < DEFAULT_INITIAL_CAPACITY) ? DEFAULT_INITIAL_CAPACITY : - (fc >= MAXIMUM_CAPACITY) ? + (dc >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : - tableSizeFor((int)fc)); + tableSizeFor((int)dc)); float ft = (float)cap * lf; threshold = ((cap < MAXIMUM_CAPACITY && ft < MAXIMUM_CAPACITY) ? (int)ft : Integer.MAX_VALUE); Index: src/java.base/share/classes/java/util/WeakHashMap.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/src/java.base/share/classes/java/util/WeakHashMap.java b/src/java.base/share/classes/java/util/WeakHashMap.java --- a/src/java.base/share/classes/java/util/WeakHashMap.java (revision 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) +++ b/src/java.base/share/classes/java/util/WeakHashMap.java (revision deeba25d15398fea8bc971ac915e348878b2c27a) @@ -251,7 +251,7 @@ * @since 1.3 */ public WeakHashMap(Map m) { - this(Math.max((int) ((float)m.size() / DEFAULT_LOAD_FACTOR + 1.0F), + this(Math.max((int) Math.ceil(m.size() / DEFAULT_LOAD_FACTOR), DEFAULT_INITIAL_CAPACITY), DEFAULT_LOAD_FACTOR); putAll(m); Xeno Amess ?2022?2?4??? 18:45??? > also find some other places have same problem. > If some of your already-in people aggree, I would create a pr, but > according to the rules seems I should wait for now. > > Xeno Amess ?2022?2?4??? 18:42??? > >> import java.lang.reflect.Array; >> import java.lang.reflect.Field; >> import java.util.HashMap; >> import java.util.Map; >> >> public class TestMap { >> >> public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { >> HashMap a = new HashMap<>(); >> fill12(a); >> HashMap b = new HashMap<>(12); >> fill12(b); >> HashMap c = new HashMap<>(a); >> HashMap d = new HashMap<>(); >> d.putAll(a); >> System.out.println("a : " + getArrayLength(a)); >> System.out.println("b : " + getArrayLength(b)); >> System.out.println("c : " + getArrayLength(c)); >> System.out.println("d : " + getArrayLength(d)); >> } >> >> public static void fill12(Map map) { >> for (int i = 0; i < 12; i++) { >> map.put(i, i); >> } >> } >> >> public static int getArrayLength(Map map) throws NoSuchFieldException, IllegalAccessException { >> Field field = HashMap.class.getDeclaredField("table"); >> field.setAccessible(true); >> Object table = field.get(map); >> return Array.getLength(table); >> } >> >> } >> >> run this and we get the output: >> >> a : 16 >> b : 16 >> c : 32 >> d : 32 >> >> So I go see the codes. >> >> /** >> * Implements Map.putAll and Map constructor. >> * >> * @param m the map >> * @param evict false when initially constructing this map, else >> * true (relayed to method afterNodeInsertion). >> */ >> final void putMapEntries(Map m, boolean evict) { >> int s = m.size(); >> if (s > 0) { >> if (table == null) { // pre-size >> float ft = ((float)s / loadFactor) + 1.0F; >> int t = ((ft < (float)MAXIMUM_CAPACITY) ? >> (int)ft : MAXIMUM_CAPACITY); >> if (t > threshold) >> threshold = tableSizeFor(t); >> } else { >> // Because of linked-list bucket constraints, we cannot >> // expand all at once, but can reduce total resize >> // effort by repeated doubling now vs later >> while (s > threshold && table.length < MAXIMUM_CAPACITY) >> resize(); >> } >> >> for (Map.Entry e : m.entrySet()) { >> K key = e.getKey(); >> V value = e.getValue(); >> putVal(hash(key), key, value, false, evict); >> } >> } >> } >> >> yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. >> >> It should be *Math.ceil((float)s / loadFactor)* >> >> So I wish to generate a pull request. >> >> Anyone interested? >> >> From xenoamess at gmail.com Fri Feb 4 13:40:15 2022 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 4 Feb 2022 21:40:15 +0800 Subject: HashMap.putAll can cause redundant space waste In-Reply-To: References: Message-ID: Besides, is it worthy to develop a public float Math.ceil(float) function? Xeno Amess ?2022?2?4??? 21:39??? > patch applied. > > Index: src/java.base/share/classes/java/lang/Module.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > diff --git a/src/java.base/share/classes/java/lang/Module.java > b/src/java.base/share/classes/java/lang/Module.java > --- a/src/java.base/share/classes/java/lang/Module.java (revision > 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) > +++ b/src/java.base/share/classes/java/lang/Module.java (revision > deeba25d15398fea8bc971ac915e348878b2c27a) > @@ -1133,7 +1133,7 @@ > boolean isBootLayer = (ModuleLayer.boot() == null); > > int numModules = cf.modules().size(); > - int cap = (int)(numModules / 0.75f + 1.0f); > + int cap = (int)Math.ceil(numModules / 0.75f); > Map nameToModule = new HashMap<>(cap); > > // to avoid repeated lookups and reduce iteration overhead, we > create > Index: src/java.base/share/classes/java/util/HashMap.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > diff --git a/src/java.base/share/classes/java/util/HashMap.java > b/src/java.base/share/classes/java/util/HashMap.java > --- a/src/java.base/share/classes/java/util/HashMap.java (revision > 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) > +++ b/src/java.base/share/classes/java/util/HashMap.java (revision > deeba25d15398fea8bc971ac915e348878b2c27a) > @@ -495,9 +495,9 @@ > int s = m.size(); > if (s > 0) { > if (table == null) { // pre-size > - float ft = ((float)s / loadFactor) + 1.0F; > - int t = ((ft < (float)MAXIMUM_CAPACITY) ? > - (int)ft : MAXIMUM_CAPACITY); > + double dt = Math.ceil(s / loadFactor); > + int t = ((dt < (double)MAXIMUM_CAPACITY) ? > + (int)dt : MAXIMUM_CAPACITY); > if (t > threshold) > threshold = tableSizeFor(t); > } else { > @@ -1527,12 +1527,12 @@ > } else if (mappings == 0) { > // use defaults > } else if (mappings > 0) { > - float fc = (float)mappings / lf + 1.0f; > - int cap = ((fc < DEFAULT_INITIAL_CAPACITY) ? > + double dc = Math.ceil(mappings / lf); > + int cap = ((dc < DEFAULT_INITIAL_CAPACITY) ? > DEFAULT_INITIAL_CAPACITY : > - (fc >= MAXIMUM_CAPACITY) ? > + (dc >= MAXIMUM_CAPACITY) ? > MAXIMUM_CAPACITY : > - tableSizeFor((int)fc)); > + tableSizeFor((int)dc)); > float ft = (float)cap * lf; > threshold = ((cap < MAXIMUM_CAPACITY && ft < > MAXIMUM_CAPACITY) ? > (int)ft : Integer.MAX_VALUE); > Index: src/java.base/share/classes/java/util/WeakHashMap.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > diff --git a/src/java.base/share/classes/java/util/WeakHashMap.java > b/src/java.base/share/classes/java/util/WeakHashMap.java > --- a/src/java.base/share/classes/java/util/WeakHashMap.java (revision > 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) > +++ b/src/java.base/share/classes/java/util/WeakHashMap.java (revision > deeba25d15398fea8bc971ac915e348878b2c27a) > @@ -251,7 +251,7 @@ > * @since 1.3 > */ > public WeakHashMap(Map m) { > - this(Math.max((int) ((float)m.size() / DEFAULT_LOAD_FACTOR + > 1.0F), > + this(Math.max((int) Math.ceil(m.size() / DEFAULT_LOAD_FACTOR), > DEFAULT_INITIAL_CAPACITY), > DEFAULT_LOAD_FACTOR); > putAll(m); > > Xeno Amess ?2022?2?4??? 18:45??? > >> also find some other places have same problem. >> If some of your already-in people aggree, I would create a pr, but >> according to the rules seems I should wait for now. >> >> Xeno Amess ?2022?2?4??? 18:42??? >> >>> import java.lang.reflect.Array; >>> import java.lang.reflect.Field; >>> import java.util.HashMap; >>> import java.util.Map; >>> >>> public class TestMap { >>> >>> public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { >>> HashMap a = new HashMap<>(); >>> fill12(a); >>> HashMap b = new HashMap<>(12); >>> fill12(b); >>> HashMap c = new HashMap<>(a); >>> HashMap d = new HashMap<>(); >>> d.putAll(a); >>> System.out.println("a : " + getArrayLength(a)); >>> System.out.println("b : " + getArrayLength(b)); >>> System.out.println("c : " + getArrayLength(c)); >>> System.out.println("d : " + getArrayLength(d)); >>> } >>> >>> public static void fill12(Map map) { >>> for (int i = 0; i < 12; i++) { >>> map.put(i, i); >>> } >>> } >>> >>> public static int getArrayLength(Map map) throws NoSuchFieldException, IllegalAccessException { >>> Field field = HashMap.class.getDeclaredField("table"); >>> field.setAccessible(true); >>> Object table = field.get(map); >>> return Array.getLength(table); >>> } >>> >>> } >>> >>> run this and we get the output: >>> >>> a : 16 >>> b : 16 >>> c : 32 >>> d : 32 >>> >>> So I go see the codes. >>> >>> /** >>> * Implements Map.putAll and Map constructor. >>> * >>> * @param m the map >>> * @param evict false when initially constructing this map, else >>> * true (relayed to method afterNodeInsertion). >>> */ >>> final void putMapEntries(Map m, boolean evict) { >>> int s = m.size(); >>> if (s > 0) { >>> if (table == null) { // pre-size >>> float ft = ((float)s / loadFactor) + 1.0F; >>> int t = ((ft < (float)MAXIMUM_CAPACITY) ? >>> (int)ft : MAXIMUM_CAPACITY); >>> if (t > threshold) >>> threshold = tableSizeFor(t); >>> } else { >>> // Because of linked-list bucket constraints, we cannot >>> // expand all at once, but can reduce total resize >>> // effort by repeated doubling now vs later >>> while (s > threshold && table.length < MAXIMUM_CAPACITY) >>> resize(); >>> } >>> >>> for (Map.Entry e : m.entrySet()) { >>> K key = e.getKey(); >>> V value = e.getValue(); >>> putVal(hash(key), key, value, false, evict); >>> } >>> } >>> } >>> >>> yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. >>> >>> It should be *Math.ceil((float)s / loadFactor)* >>> >>> So I wish to generate a pull request. >>> >>> Anyone interested? >>> >>> From lancea at openjdk.java.net Fri Feb 4 14:01:48 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Feb 2022 14:01:48 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() Message-ID: Hi all, Please review the attached patch to address - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs Best Lance ------------- Commit messages: - Update copyright year - Address Zip/JarFile::getInputStream Exception handling Changes: https://git.openjdk.java.net/jdk/pull/7348/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280409 Stats: 1081 lines in 3 files changed: 1026 ins; 26 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348 From alanb at openjdk.java.net Fri Feb 4 15:14:16 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 4 Feb 2022 15:14:16 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen wrote: > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance src/java.base/share/classes/java/util/jar/JarFile.java line 840: > 838: throws IOException > 839: { > 840: Objects.requireNonNull(ze, "ze"); Is the NPE specified? src/java.base/share/classes/java/util/jar/JarFile.java line 866: > 864: } catch (Exception e2) { > 865: // Any other Exception should be a ZipException > 866: throw (ZipException) new ZipException("Zip file format error").initCause(e2); If there is ZIP format error then I would expect ZipException or the more general IOException is already thrown. So I think this is catching other cases, maybe broken manifests or signed JAR files, in which case a JarException may be better. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Fri Feb 4 15:22:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Feb 2022 15:22:06 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 15:06:59 GMT, Alan Bateman wrote: >> Hi all, >> >> Please review the attached patch to address >> >> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter >> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs >> >> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs >> >> Best >> Lance > > src/java.base/share/classes/java/util/jar/JarFile.java line 840: > >> 838: throws IOException >> 839: { >> 840: Objects.requireNonNull(ze, "ze"); > > Is the NPE specified? Yes it is specified in the JarFile main paragraph `Unless otherwise noted, passing a null argument to a constructor or method in this class will cause a NullPointerException to be thrown.` ZipFile::getInputStream validates the argument as soon as it is passed to getInputStream. > src/java.base/share/classes/java/util/jar/JarFile.java line 866: > >> 864: } catch (Exception e2) { >> 865: // Any other Exception should be a ZipException >> 866: throw (ZipException) new ZipException("Zip file format error").initCause(e2); > > If there is ZIP format error then I would expect ZipException or the more general IOException is already thrown. So I think this is catching other cases, maybe broken manifests or signed JAR files, in which case a JarException may be better. JarFile::getInputStream. mentions ZipException but not JarException which is why I chose this. If we change this to JarException, I would need to update the javadoc and create a CSR. Please let me know your preference ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From aefimov at openjdk.java.net Fri Feb 4 15:43:42 2022 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Fri, 4 Feb 2022 15:43:42 GMT Subject: RFR: 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled Message-ID: Hi, JNDI's `DnsClient` can fail with `UncheckedIOException` during `connect` or `disconnect` method calls. It is a [know behavior](https://bugs.openjdk.java.net/browse/JDK-8236076) of `DatagramSocket`. Currently, `DnsClient` method is fast-fails when `UncheckedIOException` is observed during connect attempt. But it supposed to mark such server as invalid and continue checking other servers. Testing: tier1, tier2, tier3 and existing JCK tests show no failures relevant to the proposed changed ------------- Commit messages: - 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled Changes: https://git.openjdk.java.net/jdk/pull/7353/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7353&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272996 Stats: 19 lines in 1 file changed: 11 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7353.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7353/head:pull/7353 PR: https://git.openjdk.java.net/jdk/pull/7353 From dfuchs at openjdk.java.net Fri Feb 4 15:48:08 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Feb 2022 15:48:08 GMT Subject: RFR: 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled In-Reply-To: References: Message-ID: <_33-KB_PvwADPOVOk3bsKgIkRPZ-fGYO5Oxa9wueHl4=.38bfb8f3-97f2-44be-b8c8-9dd6982873b3@github.com> On Fri, 4 Feb 2022 15:36:35 GMT, Aleksei Efimov wrote: > Hi, > > JNDI's `DnsClient` can fail with `UncheckedIOException` during `connect` or `disconnect` method calls. It is a [know behavior](https://bugs.openjdk.java.net/browse/JDK-8236076) of `DatagramSocket`. > > Currently, `DnsClient` method is fast-fails when `UncheckedIOException` is observed during connect attempt. But it supposed to mark such server as invalid and continue checking other servers. > > Testing: tier1, tier2, tier3 and existing JCK tests show no failures relevant to the proposed changed LGTM - and a good cleanup to boot! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7353 From mullan at openjdk.java.net Fri Feb 4 15:58:16 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 4 Feb 2022 15:58:16 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen wrote: > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance Could these unexpected exceptions also occur when using the `JarInputStream` API? ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Fri Feb 4 16:10:11 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Feb 2022 16:10:11 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 15:55:33 GMT, Sean Mullan wrote: > Could these unexpected exceptions also occur when using the `JarInputStream` API? It's a different code path as Zip/JarFile leverage the CEN where Zip/JarInputStream leverage the LOC. I can give it a go and if there is an issue will create a separate issue ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Fri Feb 4 16:43:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Feb 2022 16:43:06 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 16:06:34 GMT, Lance Andersen wrote: > > Could these unexpected exceptions also occur when using the `JarInputStream` API? > > It's a different code path as Zip/JarFile leverage the CEN where Zip/JarInputStream leverage the LOC. I can give it a go and if there is an issue will create a separate issue Not an issue given how Zip/JarInputStream work ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From daniel.fuchs at oracle.com Fri Feb 4 17:25:00 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Feb 2022 17:25:00 +0000 Subject: Seeking inputs on 8224794: ZipFile/JarFile should open zip/JAR file with FILE_SHARE_DELETE sharing mode on Windows In-Reply-To: <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com> References: <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com> Message-ID: Hi Jaikiran, Thanks for working on this and apologies for the long silence. I believe your analysis of the issue is very valuable. Unless there is some clever trick we could do to allow to unlink the file from the file system before deleting it, so that the file path can be reused, it seems indeed that using FILE_SHARE_DELETE doesn't buy us much benefit. It is a pity, but IMO it was well worth the investigation. Unless others on this list disagree, or can suggest other tricks, I would suggest shelving this work for now. best regards, -- daniel On 18/12/2021 06:00, Jaikiran Pai wrote: > Would there be interest in moving this forward? Enabling that > FILE_SHARE_DELETE option has opened up some questions that I noted in my > previous mail below. So in order to move forward I would need some > inputs. If we don't want to do this at this time, I'll close the draft > PR that's currently open https://github.com/openjdk/jdk/pull/6477. > > -Jaikiran > From xenoamess at gmail.com Fri Feb 4 18:39:42 2022 From: xenoamess at gmail.com (Xeno Amess) Date: Sat, 5 Feb 2022 02:39:42 +0800 Subject: HashMap.putAll can cause redundant space waste In-Reply-To: References: Message-ID: Sorry for my mistake. After a more throughout dig in, this thing has already fixed several years ago, at year 2015. Issue close. Xeno Amess ?2022?2?4??? 21:40??? > Besides, is it worthy to develop a public float Math.ceil(float) function? > > Xeno Amess ?2022?2?4??? 21:39??? > >> patch applied. >> >> Index: src/java.base/share/classes/java/lang/Module.java >> IDEA additional info: >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> <+>UTF-8 >> =================================================================== >> diff --git a/src/java.base/share/classes/java/lang/Module.java >> b/src/java.base/share/classes/java/lang/Module.java >> --- a/src/java.base/share/classes/java/lang/Module.java (revision >> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >> +++ b/src/java.base/share/classes/java/lang/Module.java (revision >> deeba25d15398fea8bc971ac915e348878b2c27a) >> @@ -1133,7 +1133,7 @@ >> boolean isBootLayer = (ModuleLayer.boot() == null); >> >> int numModules = cf.modules().size(); >> - int cap = (int)(numModules / 0.75f + 1.0f); >> + int cap = (int)Math.ceil(numModules / 0.75f); >> Map nameToModule = new HashMap<>(cap); >> >> // to avoid repeated lookups and reduce iteration overhead, we >> create >> Index: src/java.base/share/classes/java/util/HashMap.java >> IDEA additional info: >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> <+>UTF-8 >> =================================================================== >> diff --git a/src/java.base/share/classes/java/util/HashMap.java >> b/src/java.base/share/classes/java/util/HashMap.java >> --- a/src/java.base/share/classes/java/util/HashMap.java (revision >> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >> +++ b/src/java.base/share/classes/java/util/HashMap.java (revision >> deeba25d15398fea8bc971ac915e348878b2c27a) >> @@ -495,9 +495,9 @@ >> int s = m.size(); >> if (s > 0) { >> if (table == null) { // pre-size >> - float ft = ((float)s / loadFactor) + 1.0F; >> - int t = ((ft < (float)MAXIMUM_CAPACITY) ? >> - (int)ft : MAXIMUM_CAPACITY); >> + double dt = Math.ceil(s / loadFactor); >> + int t = ((dt < (double)MAXIMUM_CAPACITY) ? >> + (int)dt : MAXIMUM_CAPACITY); >> if (t > threshold) >> threshold = tableSizeFor(t); >> } else { >> @@ -1527,12 +1527,12 @@ >> } else if (mappings == 0) { >> // use defaults >> } else if (mappings > 0) { >> - float fc = (float)mappings / lf + 1.0f; >> - int cap = ((fc < DEFAULT_INITIAL_CAPACITY) ? >> + double dc = Math.ceil(mappings / lf); >> + int cap = ((dc < DEFAULT_INITIAL_CAPACITY) ? >> DEFAULT_INITIAL_CAPACITY : >> - (fc >= MAXIMUM_CAPACITY) ? >> + (dc >= MAXIMUM_CAPACITY) ? >> MAXIMUM_CAPACITY : >> - tableSizeFor((int)fc)); >> + tableSizeFor((int)dc)); >> float ft = (float)cap * lf; >> threshold = ((cap < MAXIMUM_CAPACITY && ft < >> MAXIMUM_CAPACITY) ? >> (int)ft : Integer.MAX_VALUE); >> Index: src/java.base/share/classes/java/util/WeakHashMap.java >> IDEA additional info: >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> <+>UTF-8 >> =================================================================== >> diff --git a/src/java.base/share/classes/java/util/WeakHashMap.java >> b/src/java.base/share/classes/java/util/WeakHashMap.java >> --- a/src/java.base/share/classes/java/util/WeakHashMap.java (revision >> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >> +++ b/src/java.base/share/classes/java/util/WeakHashMap.java (revision >> deeba25d15398fea8bc971ac915e348878b2c27a) >> @@ -251,7 +251,7 @@ >> * @since 1.3 >> */ >> public WeakHashMap(Map m) { >> - this(Math.max((int) ((float)m.size() / DEFAULT_LOAD_FACTOR + >> 1.0F), >> + this(Math.max((int) Math.ceil(m.size() / DEFAULT_LOAD_FACTOR), >> DEFAULT_INITIAL_CAPACITY), >> DEFAULT_LOAD_FACTOR); >> putAll(m); >> >> Xeno Amess ?2022?2?4??? 18:45??? >> >>> also find some other places have same problem. >>> If some of your already-in people aggree, I would create a pr, but >>> according to the rules seems I should wait for now. >>> >>> Xeno Amess ?2022?2?4??? 18:42??? >>> >>>> import java.lang.reflect.Array; >>>> import java.lang.reflect.Field; >>>> import java.util.HashMap; >>>> import java.util.Map; >>>> >>>> public class TestMap { >>>> >>>> public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { >>>> HashMap a = new HashMap<>(); >>>> fill12(a); >>>> HashMap b = new HashMap<>(12); >>>> fill12(b); >>>> HashMap c = new HashMap<>(a); >>>> HashMap d = new HashMap<>(); >>>> d.putAll(a); >>>> System.out.println("a : " + getArrayLength(a)); >>>> System.out.println("b : " + getArrayLength(b)); >>>> System.out.println("c : " + getArrayLength(c)); >>>> System.out.println("d : " + getArrayLength(d)); >>>> } >>>> >>>> public static void fill12(Map map) { >>>> for (int i = 0; i < 12; i++) { >>>> map.put(i, i); >>>> } >>>> } >>>> >>>> public static int getArrayLength(Map map) throws NoSuchFieldException, IllegalAccessException { >>>> Field field = HashMap.class.getDeclaredField("table"); >>>> field.setAccessible(true); >>>> Object table = field.get(map); >>>> return Array.getLength(table); >>>> } >>>> >>>> } >>>> >>>> run this and we get the output: >>>> >>>> a : 16 >>>> b : 16 >>>> c : 32 >>>> d : 32 >>>> >>>> So I go see the codes. >>>> >>>> /** >>>> * Implements Map.putAll and Map constructor. >>>> * >>>> * @param m the map >>>> * @param evict false when initially constructing this map, else >>>> * true (relayed to method afterNodeInsertion). >>>> */ >>>> final void putMapEntries(Map m, boolean evict) { >>>> int s = m.size(); >>>> if (s > 0) { >>>> if (table == null) { // pre-size >>>> float ft = ((float)s / loadFactor) + 1.0F; >>>> int t = ((ft < (float)MAXIMUM_CAPACITY) ? >>>> (int)ft : MAXIMUM_CAPACITY); >>>> if (t > threshold) >>>> threshold = tableSizeFor(t); >>>> } else { >>>> // Because of linked-list bucket constraints, we cannot >>>> // expand all at once, but can reduce total resize >>>> // effort by repeated doubling now vs later >>>> while (s > threshold && table.length < MAXIMUM_CAPACITY) >>>> resize(); >>>> } >>>> >>>> for (Map.Entry e : m.entrySet()) { >>>> K key = e.getKey(); >>>> V value = e.getValue(); >>>> putVal(hash(key), key, value, false, evict); >>>> } >>>> } >>>> } >>>> >>>> yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. >>>> >>>> It should be *Math.ceil((float)s / loadFactor)* >>>> >>>> So I wish to generate a pull request. >>>> >>>> Anyone interested? >>>> >>>> From xenoamess at gmail.com Fri Feb 4 18:48:05 2022 From: xenoamess at gmail.com (Xeno Amess) Date: Sat, 5 Feb 2022 02:48:05 +0800 Subject: HashMap.putAll can cause redundant space waste In-Reply-To: References: Message-ID: wait, things get interesting now. We do have such a test named ConstantDirectoryOptimalCapacity to make sure this does not happen, but my tests still fill under the idea debugger. Is there any specialist for help? I would dig in but it is a little complicated. [image: image.png] Xeno Amess ?2022?2?5??? 02:39??? > Sorry for my mistake. > After a more throughout dig in, this thing has already fixed several years > ago, at year 2015. > Issue close. > > Xeno Amess ?2022?2?4??? 21:40??? > >> Besides, is it worthy to develop a public float Math.ceil(float) function? >> >> Xeno Amess ?2022?2?4??? 21:39??? >> >>> patch applied. >>> >>> Index: src/java.base/share/classes/java/lang/Module.java >>> IDEA additional info: >>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>> <+>UTF-8 >>> =================================================================== >>> diff --git a/src/java.base/share/classes/java/lang/Module.java >>> b/src/java.base/share/classes/java/lang/Module.java >>> --- a/src/java.base/share/classes/java/lang/Module.java (revision >>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >>> +++ b/src/java.base/share/classes/java/lang/Module.java (revision >>> deeba25d15398fea8bc971ac915e348878b2c27a) >>> @@ -1133,7 +1133,7 @@ >>> boolean isBootLayer = (ModuleLayer.boot() == null); >>> >>> int numModules = cf.modules().size(); >>> - int cap = (int)(numModules / 0.75f + 1.0f); >>> + int cap = (int)Math.ceil(numModules / 0.75f); >>> Map nameToModule = new HashMap<>(cap); >>> >>> // to avoid repeated lookups and reduce iteration overhead, we >>> create >>> Index: src/java.base/share/classes/java/util/HashMap.java >>> IDEA additional info: >>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>> <+>UTF-8 >>> =================================================================== >>> diff --git a/src/java.base/share/classes/java/util/HashMap.java >>> b/src/java.base/share/classes/java/util/HashMap.java >>> --- a/src/java.base/share/classes/java/util/HashMap.java (revision >>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >>> +++ b/src/java.base/share/classes/java/util/HashMap.java (revision >>> deeba25d15398fea8bc971ac915e348878b2c27a) >>> @@ -495,9 +495,9 @@ >>> int s = m.size(); >>> if (s > 0) { >>> if (table == null) { // pre-size >>> - float ft = ((float)s / loadFactor) + 1.0F; >>> - int t = ((ft < (float)MAXIMUM_CAPACITY) ? >>> - (int)ft : MAXIMUM_CAPACITY); >>> + double dt = Math.ceil(s / loadFactor); >>> + int t = ((dt < (double)MAXIMUM_CAPACITY) ? >>> + (int)dt : MAXIMUM_CAPACITY); >>> if (t > threshold) >>> threshold = tableSizeFor(t); >>> } else { >>> @@ -1527,12 +1527,12 @@ >>> } else if (mappings == 0) { >>> // use defaults >>> } else if (mappings > 0) { >>> - float fc = (float)mappings / lf + 1.0f; >>> - int cap = ((fc < DEFAULT_INITIAL_CAPACITY) ? >>> + double dc = Math.ceil(mappings / lf); >>> + int cap = ((dc < DEFAULT_INITIAL_CAPACITY) ? >>> DEFAULT_INITIAL_CAPACITY : >>> - (fc >= MAXIMUM_CAPACITY) ? >>> + (dc >= MAXIMUM_CAPACITY) ? >>> MAXIMUM_CAPACITY : >>> - tableSizeFor((int)fc)); >>> + tableSizeFor((int)dc)); >>> float ft = (float)cap * lf; >>> threshold = ((cap < MAXIMUM_CAPACITY && ft < >>> MAXIMUM_CAPACITY) ? >>> (int)ft : Integer.MAX_VALUE); >>> Index: src/java.base/share/classes/java/util/WeakHashMap.java >>> IDEA additional info: >>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>> <+>UTF-8 >>> =================================================================== >>> diff --git a/src/java.base/share/classes/java/util/WeakHashMap.java >>> b/src/java.base/share/classes/java/util/WeakHashMap.java >>> --- a/src/java.base/share/classes/java/util/WeakHashMap.java (revision >>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >>> +++ b/src/java.base/share/classes/java/util/WeakHashMap.java (revision >>> deeba25d15398fea8bc971ac915e348878b2c27a) >>> @@ -251,7 +251,7 @@ >>> * @since 1.3 >>> */ >>> public WeakHashMap(Map m) { >>> - this(Math.max((int) ((float)m.size() / DEFAULT_LOAD_FACTOR + >>> 1.0F), >>> + this(Math.max((int) Math.ceil(m.size() / DEFAULT_LOAD_FACTOR), >>> DEFAULT_INITIAL_CAPACITY), >>> DEFAULT_LOAD_FACTOR); >>> putAll(m); >>> >>> Xeno Amess ?2022?2?4??? 18:45??? >>> >>>> also find some other places have same problem. >>>> If some of your already-in people aggree, I would create a pr, but >>>> according to the rules seems I should wait for now. >>>> >>>> Xeno Amess ?2022?2?4??? 18:42??? >>>> >>>>> import java.lang.reflect.Array; >>>>> import java.lang.reflect.Field; >>>>> import java.util.HashMap; >>>>> import java.util.Map; >>>>> >>>>> public class TestMap { >>>>> >>>>> public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { >>>>> HashMap a = new HashMap<>(); >>>>> fill12(a); >>>>> HashMap b = new HashMap<>(12); >>>>> fill12(b); >>>>> HashMap c = new HashMap<>(a); >>>>> HashMap d = new HashMap<>(); >>>>> d.putAll(a); >>>>> System.out.println("a : " + getArrayLength(a)); >>>>> System.out.println("b : " + getArrayLength(b)); >>>>> System.out.println("c : " + getArrayLength(c)); >>>>> System.out.println("d : " + getArrayLength(d)); >>>>> } >>>>> >>>>> public static void fill12(Map map) { >>>>> for (int i = 0; i < 12; i++) { >>>>> map.put(i, i); >>>>> } >>>>> } >>>>> >>>>> public static int getArrayLength(Map map) throws NoSuchFieldException, IllegalAccessException { >>>>> Field field = HashMap.class.getDeclaredField("table"); >>>>> field.setAccessible(true); >>>>> Object table = field.get(map); >>>>> return Array.getLength(table); >>>>> } >>>>> >>>>> } >>>>> >>>>> run this and we get the output: >>>>> >>>>> a : 16 >>>>> b : 16 >>>>> c : 32 >>>>> d : 32 >>>>> >>>>> So I go see the codes. >>>>> >>>>> /** >>>>> * Implements Map.putAll and Map constructor. >>>>> * >>>>> * @param m the map >>>>> * @param evict false when initially constructing this map, else >>>>> * true (relayed to method afterNodeInsertion). >>>>> */ >>>>> final void putMapEntries(Map m, boolean evict) { >>>>> int s = m.size(); >>>>> if (s > 0) { >>>>> if (table == null) { // pre-size >>>>> float ft = ((float)s / loadFactor) + 1.0F; >>>>> int t = ((ft < (float)MAXIMUM_CAPACITY) ? >>>>> (int)ft : MAXIMUM_CAPACITY); >>>>> if (t > threshold) >>>>> threshold = tableSizeFor(t); >>>>> } else { >>>>> // Because of linked-list bucket constraints, we cannot >>>>> // expand all at once, but can reduce total resize >>>>> // effort by repeated doubling now vs later >>>>> while (s > threshold && table.length < MAXIMUM_CAPACITY) >>>>> resize(); >>>>> } >>>>> >>>>> for (Map.Entry e : m.entrySet()) { >>>>> K key = e.getKey(); >>>>> V value = e.getValue(); >>>>> putVal(hash(key), key, value, false, evict); >>>>> } >>>>> } >>>>> } >>>>> >>>>> yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. >>>>> >>>>> It should be *Math.ceil((float)s / loadFactor)* >>>>> >>>>> So I wish to generate a pull request. >>>>> >>>>> Anyone interested? >>>>> >>>>> From cstein at openjdk.java.net Fri Feb 4 21:36:07 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Fri, 4 Feb 2022 21:36:07 GMT Subject: RFR: 8281104: jar --create should create missing parent directories In-Reply-To: <0aVktv5u2S4HJeVzXxJkr2O4jE5SlOv2J73sFwEJf2A=.3af0f5f4-28b0-474f-b1a7-4502b41bd983@github.com> References: <0aVktv5u2S4HJeVzXxJkr2O4jE5SlOv2J73sFwEJf2A=.3af0f5f4-28b0-474f-b1a7-4502b41bd983@github.com> Message-ID: On Thu, 3 Feb 2022 21:43:30 GMT, Lance Andersen wrote: > I think this would be the appropriate place for documenting the behavior. Like this? -c, --create Create the archive. When the path specified by -f, --file contains a path, missing parent directories will also be created ... -f, --file=FILE The archive file name. When omitted, either stdin or stdout is used based on the operation. Missing parent directories of the file name path will be created Perhaps, only adding it to `-c, --create` suffices. Having it also on `-f, --file` may confuse users, as this option is used all operation modes. > Also we will need to update the MD file which represents the jar man page via a separate PR. Yes. Will create PR for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From lancea at openjdk.java.net Fri Feb 4 21:40:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Feb 2022 21:40:06 GMT Subject: RFR: 8281104: jar --create should create missing parent directories In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote: > Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. > > I think this would be the appropriate place for documenting the behavior. > > Like this? > > ``` > -c, --create Create the archive. When the path specified by -f, --file > contains a path, missing parent directories will also be created > ... > -f, --file=FILE The archive file name. When omitted, either stdin or > stdout is used based on the operation. Missing parent > directories of the file name path will be created > ``` > > Perhaps, only adding it to `-c, --create` suffices. Having it also on `-f, --file` may confuse users, as this option is used all operation modes. I think just having the verbiage when creating the jar should suffice as if we were updating it, the path would need to exist already. > > > Also we will need to update the MD file which represents the jar man page via a separate PR. > > Yes. Will create PR for this. Great, thank you. Have a good weekend! ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From lancea at openjdk.java.net Fri Feb 4 21:58:50 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Feb 2022 21:58:50 GMT Subject: RFR: 8281104: jar --create should create missing parent directories [v2] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 21:55:28 GMT, Christian Stein wrote: >> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Extend help text for option `-c, --create` The current changes look good overall ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7327 From cstein at openjdk.java.net Fri Feb 4 21:58:49 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Fri, 4 Feb 2022 21:58:49 GMT Subject: RFR: 8281104: jar --create should create missing parent directories [v2] In-Reply-To: References: Message-ID: > Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Extend help text for option `-c, --create` ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7327/files - new: https://git.openjdk.java.net/jdk/pull/7327/files/f34e767a..65105a36 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7327&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7327&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7327/head:pull/7327 PR: https://git.openjdk.java.net/jdk/pull/7327 From cstein at openjdk.java.net Fri Feb 4 21:58:51 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Fri, 4 Feb 2022 21:58:51 GMT Subject: RFR: 8281104: jar --create should create missing parent directories In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote: > Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. Should I also extend this "usage.compat" help message block? When and where is it displayed? ?? https://github.com/openjdk/jdk/blob/48523b090886f7b24ed4009f0c150efaa6f7b056/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties#L167-L173 ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From lancea at openjdk.java.net Fri Feb 4 22:12:12 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Feb 2022 22:12:12 GMT Subject: RFR: 8281104: jar --create should create missing parent directories In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 21:47:16 GMT, Christian Stein wrote: > Should I also extend this "usage.compat" help message block? When and where is it displayed? ?? > > https://github.com/openjdk/jdk/blob/48523b090886f7b24ed4009f0c150efaa6f7b056/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties#L167-L173 I guess that makes sense. Not sure how often anyone looks at this but good for consistency. Thanks for the reminder of the help message for compat ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From cstein at openjdk.java.net Fri Feb 4 22:29:45 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Fri, 4 Feb 2022 22:29:45 GMT Subject: RFR: 8281104: jar --create should create missing parent directories [v3] In-Reply-To: References: Message-ID: > Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update help text of Compatibility Interface ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7327/files - new: https://git.openjdk.java.net/jdk/pull/7327/files/65105a36..f810c810 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7327&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7327&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7327.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7327/head:pull/7327 PR: https://git.openjdk.java.net/jdk/pull/7327 From duke at openjdk.java.net Sat Feb 5 15:40:33 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sat, 5 Feb 2022 15:40:33 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts Message-ID: Hi, This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. Thank you very much. ------------- Commit messages: - unsigned cast intrinsics Changes: https://git.openjdk.java.net/jdk/pull/7358/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7358&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278173 Stats: 494 lines in 16 files changed: 435 ins; 24 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/7358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7358/head:pull/7358 PR: https://git.openjdk.java.net/jdk/pull/7358 From darcy at openjdk.java.net Sun Feb 6 00:46:31 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 6 Feb 2022 00:46:31 GMT Subject: RFR: JDK-8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 Message-ID: Third time should be the charm to get this issue of out-of-bounds random numbers fully fixed; sorry for the noise. ------------- Commit messages: - JDK-8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 Changes: https://git.openjdk.java.net/jdk/pull/7360/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7360&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281183 Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7360.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7360/head:pull/7360 PR: https://git.openjdk.java.net/jdk/pull/7360 From jlaskey at openjdk.java.net Sun Feb 6 01:47:10 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Sun, 6 Feb 2022 01:47:10 GMT Subject: RFR: JDK-8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 In-Reply-To: References: Message-ID: <-TEYDSmVH95NKJZ8u3kOIi1oPa3ecMmoZCgjlD4PhyM=.65f0f20e-2573-482b-88e3-f52cf6aa4cf9@github.com> On Sun, 6 Feb 2022 00:41:06 GMT, Joe Darcy wrote: > Third time should be the charm to get this issue of out-of-bounds random numbers fully fixed; sorry for the noise. Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7360 From darcy at openjdk.java.net Sun Feb 6 02:23:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 6 Feb 2022 02:23:06 GMT Subject: Integrated: JDK-8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 In-Reply-To: References: Message-ID: On Sun, 6 Feb 2022 00:41:06 GMT, Joe Darcy wrote: > Third time should be the charm to get this issue of out-of-bounds random numbers fully fixed; sorry for the noise. This pull request has now been integrated. Changeset: 77b0240d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/77b0240d44fd356711d75bc241e198f6f89ada8f Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod 8281183: RandomGenerator:NextDouble() default behavior partially fixed by JDK-8280950 Reviewed-by: jlaskey ------------- PR: https://git.openjdk.java.net/jdk/pull/7360 From aefimov at openjdk.java.net Mon Feb 7 12:14:09 2022 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Mon, 7 Feb 2022 12:14:09 GMT Subject: Integrated: 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 15:36:35 GMT, Aleksei Efimov wrote: > Hi, > > JNDI's `DnsClient` can fail with `UncheckedIOException` during `connect` or `disconnect` method calls. It is a [know behavior](https://bugs.openjdk.java.net/browse/JDK-8236076) of `DatagramSocket`. > > Currently, `DnsClient` method fast-fails when `UncheckedIOException` is observed during connect attempt. But it supposed to mark such server as invalid and continue checking other servers. > > Testing: tier1, tier2, tier3 and existing JCK tests show no failures relevant to the proposed changed This pull request has now been integrated. Changeset: 4c169495 Author: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/4c169495a2c4bfdcbc82e94e9ca1ee0cc050daf9 Stats: 19 lines in 1 file changed: 11 ins; 6 del; 2 mod 8272996: JNDI DNS provider fails to resolve SRV entries when IPV6 stack is enabled Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7353 From redestad at openjdk.java.net Mon Feb 7 13:37:04 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 7 Feb 2022 13:37:04 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 07:20:28 GMT, Aleksey Shipilev wrote: > I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`. > > There is direct VarHandle benchmark in our corpus: > > > $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint" > > Benchmark Mode Cnt Score Error Units > > # -Xint > # Baseline > VarHandleExact.exact_exactInvocation avgt 30 714.041 ? 5.882 ns/op > VarHandleExact.generic_exactInvocation avgt 30 641.570 ? 11.681 ns/op > VarHandleExact.generic_genericInvocation avgt 30 1336.571 ? 11.873 ns/op > > # -Xint > # Patched > VarHandleExact.exact_exactInvocation avgt 30 678.495 ? 10.752 ns/op ; +5% > VarHandleExact.generic_exactInvocation avgt 30 573.320 ? 5.100 ns/op ; +11% > VarHandleExact.generic_genericInvocation avgt 30 1338.593 ? 14.275 ns/op > > # (server, default) > # Baseline > VarHandleExact.exact_exactInvocation avgt 30 0.620 ? 0.079 ns/op > VarHandleExact.generic_exactInvocation avgt 30 0.602 ? 0.063 ns/op > VarHandleExact.generic_genericInvocation avgt 30 10.521 ? 0.065 ns/op > > # (server, default) > # Patched > VarHandleExact.exact_exactInvocation avgt 30 0.621 ? 0.070 ns/op > VarHandleExact.generic_exactInvocation avgt 30 0.601 ? 0.061 ns/op > VarHandleExact.generic_genericInvocation avgt 30 10.499 ? 0.070 ns/op > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Looks reasonable. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7333 From mullan at openjdk.java.net Mon Feb 7 15:20:12 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 7 Feb 2022 15:20:12 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 15:19:11 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/jar/JarFile.java line 866: >> >>> 864: } catch (Exception e2) { >>> 865: // Any other Exception should be a ZipException >>> 866: throw (ZipException) new ZipException("Zip file format error").initCause(e2); >> >> If there is ZIP format error then I would expect ZipException or the more general IOException is already thrown. So I think this is catching other cases, maybe broken manifests or signed JAR files, in which case a JarException may be better. > > JarFile::getInputStream. mentions ZipException but not JarException which is why I chose this. If we change this to JarException, I would need to update the javadoc and create a CSR. > > Please let me know your preference `JarException` is a subclass of `ZipException` though, so I think this would be ok to throw and still be compliant with the specification. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Mon Feb 7 16:55:10 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Feb 2022 16:55:10 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 15:16:43 GMT, Sean Mullan wrote: >> JarFile::getInputStream. mentions ZipException but not JarException which is why I chose this. If we change this to JarException, I would need to update the javadoc and create a CSR. >> >> Please let me know your preference > > `JarException` is a subclass of `ZipException` though, so I think this would be ok to throw and still be compliant with the specification. Looking at this a bit more, it looks like `JariFile::initializeVerifier` is the only place currently in `JarFile` that could throw a `JarException` and that method could be called from `JarFile::getInputStream` As `verifiableEntry` is only called from `JarFile::getInputStream `and this change validates the `ZipEntry` for being null, which is should, the only other possible error would be in the unlikely event. `ZipEntry` was subclassed passed into `JarFile::getInputStream` resulting in the call to `ZipEntry::getName` returning null(in which case `ZipFile::getEntry` will return a `NullPointerException`) or the name being invalid resulting once again in a possible null value for the returned `ZipEntry` from `JarFile::getJarEntry` (which calls `ZipFile::getEntry`) I am still leaning towards a `ZipException`, not a `JarException`, thrown from `verifiableEntry`. That being said, I will go with whatever the consensus is. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From mullan at openjdk.java.net Mon Feb 7 18:47:09 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 7 Feb 2022 18:47:09 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 16:52:07 GMT, Lance Andersen wrote: >> `JarException` is a subclass of `ZipException` though, so I think this would be ok to throw and still be compliant with the specification. > > Looking at this a bit more, it looks like `JariFile::initializeVerifier` is the only place currently in `JarFile` that could throw a `JarException` and that method could be called from `JarFile::getInputStream` > > As `verifiableEntry` is only called from `JarFile::getInputStream `and this change validates the `ZipEntry` for being null, which is should, the only other possible error would be in the unlikely event. `ZipEntry` was subclassed passed into `JarFile::getInputStream` resulting in the call to `ZipEntry::getName` returning null(in which case `ZipFile::getEntry` will return a `NullPointerException`) or the name being invalid resulting once again in a possible null value for the returned `ZipEntry` from `JarFile::getJarEntry` (which calls `ZipFile::getEntry`) > > > I am still leaning towards a `ZipException`, not a `JarException`, thrown from `verifiableEntry`. > > That being said, I will go with whatever the consensus is. If you are pretty sure the only other case are as above, I wonder if a simpler fix would be to change `verifiableEntry()` to check for these null cases and throw a `ZipException` which will get directly propagated by `getInputStream()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From stuart.marks at oracle.com Mon Feb 7 20:06:48 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 7 Feb 2022 12:06:48 -0800 Subject: HashMap.putAll can cause redundant space waste In-Reply-To: References: Message-ID: <0dd3c438-2dca-f0dd-cab0-842a9f06ee13@oracle.com> Hi, I'm not sure where you ended up in this succession of messages. I do think there are some things going on that are worthy of discussion and possibly fixing. Let me try to break them down. 1) With the default load factor of 0.75, it's possible to have 12 entries in a map whose table length is 16. This works as expected if the entries are added individually using the put() method. However, adding 12 entries into a map via the copy constructor or via putAll() results in a table length of 32. That seems wrong. Well, if not exactly wrong, it's suboptimal, in that it uses more space than necessary. 2) The root cause of the problem is with expressions such as these: (int) (expected / 0.75f + 1.0f) or (int) (expected / 0.75f) + 1 (where "expected" is the expected number of entries). They attempt to round the division result up to the nearest int by adding 1 or 1.0f. This results in a value that's one too large if the result of the division exactly equals an integer. So, when "expected" is 12, this results in 17 instead of 16. This in turn is inflated to the next power-of-two, which is 32. 3) This was discussed previously in a different context. [1] I agree that it would be preferable for the expression to be something like this: (int) Math.ceil(expected / 0.75) [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066258.html This uses doubles instead of floats. But I think this is a fairly low-frequency operation, so I don't think using doubles is a problem. Thus I don't think we need to add a Math.ceil(float) overload. ** So what should be done about this? Possibly, the computations in HashMap and related classes should be adjusted to use Math.ceil() instead. Some tests use the suboptimal calculation as well; those might need to be adjusted also. There are a variety of places around the JDK that use a similar expression in order to pre-size HashMaps and HashSets. We could go around and fix all them, but it might be worth considering adding an API that creates a HashMap (or LinkedHashMap) that is pre-sized for the expected number of elements. Guava has such an API, Maps.newHashMapWithExpectedSize [2]. But note that it tries (but does not guarantee) to size the map such that it can accommodate the expected number of elements without resizing, but it doesn't promise that the map isn't oversized. [2] https://guava.dev/releases/31.0.1-jre/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize(int) (Also note that the ConcurrentHashMap(int) constructor takes the expected number of elements, not the initial table length like HashMap(int). CHM does what probably most users want, but it's confusing that its behavior differs from HashMap in this regard.) If we don't add a Java SE utility like "newHashMapWithExpectedSize", fallbacks would be to introduce an internal JDK utility method that is called from various places, or just to update the individual call sites to use the more precise calculation. s'marks On 2/4/22 10:48 AM, Xeno Amess wrote: > wait, things get interesting now. > We do have such a test named ConstantDirectoryOptimalCapacity to make sure > this does not happen, but my tests still fill under the idea debugger. > Is there any specialist for help? I would dig in but it is a little > complicated. > [image: image.png] > > Xeno Amess ?2022?2?5??? 02:39??? > >> Sorry for my mistake. >> After a more throughout dig in, this thing has already fixed several years >> ago, at year 2015. >> Issue close. >> >> Xeno Amess ?2022?2?4??? 21:40??? >> >>> Besides, is it worthy to develop a public float Math.ceil(float) function? >>> >>> Xeno Amess ?2022?2?4??? 21:39??? >>> >>>> patch applied. >>>> >>>> Index: src/java.base/share/classes/java/lang/Module.java >>>> IDEA additional info: >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>>> <+>UTF-8 >>>> =================================================================== >>>> diff --git a/src/java.base/share/classes/java/lang/Module.java >>>> b/src/java.base/share/classes/java/lang/Module.java >>>> --- a/src/java.base/share/classes/java/lang/Module.java (revision >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >>>> +++ b/src/java.base/share/classes/java/lang/Module.java (revision >>>> deeba25d15398fea8bc971ac915e348878b2c27a) >>>> @@ -1133,7 +1133,7 @@ >>>> boolean isBootLayer = (ModuleLayer.boot() == null); >>>> >>>> int numModules = cf.modules().size(); >>>> - int cap = (int)(numModules / 0.75f + 1.0f); >>>> + int cap = (int)Math.ceil(numModules / 0.75f); >>>> Map nameToModule = new HashMap<>(cap); >>>> >>>> // to avoid repeated lookups and reduce iteration overhead, we >>>> create >>>> Index: src/java.base/share/classes/java/util/HashMap.java >>>> IDEA additional info: >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>>> <+>UTF-8 >>>> =================================================================== >>>> diff --git a/src/java.base/share/classes/java/util/HashMap.java >>>> b/src/java.base/share/classes/java/util/HashMap.java >>>> --- a/src/java.base/share/classes/java/util/HashMap.java (revision >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >>>> +++ b/src/java.base/share/classes/java/util/HashMap.java (revision >>>> deeba25d15398fea8bc971ac915e348878b2c27a) >>>> @@ -495,9 +495,9 @@ >>>> int s = m.size(); >>>> if (s > 0) { >>>> if (table == null) { // pre-size >>>> - float ft = ((float)s / loadFactor) + 1.0F; >>>> - int t = ((ft < (float)MAXIMUM_CAPACITY) ? >>>> - (int)ft : MAXIMUM_CAPACITY); >>>> + double dt = Math.ceil(s / loadFactor); >>>> + int t = ((dt < (double)MAXIMUM_CAPACITY) ? >>>> + (int)dt : MAXIMUM_CAPACITY); >>>> if (t > threshold) >>>> threshold = tableSizeFor(t); >>>> } else { >>>> @@ -1527,12 +1527,12 @@ >>>> } else if (mappings == 0) { >>>> // use defaults >>>> } else if (mappings > 0) { >>>> - float fc = (float)mappings / lf + 1.0f; >>>> - int cap = ((fc < DEFAULT_INITIAL_CAPACITY) ? >>>> + double dc = Math.ceil(mappings / lf); >>>> + int cap = ((dc < DEFAULT_INITIAL_CAPACITY) ? >>>> DEFAULT_INITIAL_CAPACITY : >>>> - (fc >= MAXIMUM_CAPACITY) ? >>>> + (dc >= MAXIMUM_CAPACITY) ? >>>> MAXIMUM_CAPACITY : >>>> - tableSizeFor((int)fc)); >>>> + tableSizeFor((int)dc)); >>>> float ft = (float)cap * lf; >>>> threshold = ((cap < MAXIMUM_CAPACITY && ft < >>>> MAXIMUM_CAPACITY) ? >>>> (int)ft : Integer.MAX_VALUE); >>>> Index: src/java.base/share/classes/java/util/WeakHashMap.java >>>> IDEA additional info: >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >>>> <+>UTF-8 >>>> =================================================================== >>>> diff --git a/src/java.base/share/classes/java/util/WeakHashMap.java >>>> b/src/java.base/share/classes/java/util/WeakHashMap.java >>>> --- a/src/java.base/share/classes/java/util/WeakHashMap.java (revision >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >>>> +++ b/src/java.base/share/classes/java/util/WeakHashMap.java (revision >>>> deeba25d15398fea8bc971ac915e348878b2c27a) >>>> @@ -251,7 +251,7 @@ >>>> * @since 1.3 >>>> */ >>>> public WeakHashMap(Map m) { >>>> - this(Math.max((int) ((float)m.size() / DEFAULT_LOAD_FACTOR + >>>> 1.0F), >>>> + this(Math.max((int) Math.ceil(m.size() / DEFAULT_LOAD_FACTOR), >>>> DEFAULT_INITIAL_CAPACITY), >>>> DEFAULT_LOAD_FACTOR); >>>> putAll(m); >>>> >>>> Xeno Amess ?2022?2?4??? 18:45??? >>>> >>>>> also find some other places have same problem. >>>>> If some of your already-in people aggree, I would create a pr, but >>>>> according to the rules seems I should wait for now. >>>>> >>>>> Xeno Amess ?2022?2?4??? 18:42??? >>>>> >>>>>> import java.lang.reflect.Array; >>>>>> import java.lang.reflect.Field; >>>>>> import java.util.HashMap; >>>>>> import java.util.Map; >>>>>> >>>>>> public class TestMap { >>>>>> >>>>>> public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { >>>>>> HashMap a = new HashMap<>(); >>>>>> fill12(a); >>>>>> HashMap b = new HashMap<>(12); >>>>>> fill12(b); >>>>>> HashMap c = new HashMap<>(a); >>>>>> HashMap d = new HashMap<>(); >>>>>> d.putAll(a); >>>>>> System.out.println("a : " + getArrayLength(a)); >>>>>> System.out.println("b : " + getArrayLength(b)); >>>>>> System.out.println("c : " + getArrayLength(c)); >>>>>> System.out.println("d : " + getArrayLength(d)); >>>>>> } >>>>>> >>>>>> public static void fill12(Map map) { >>>>>> for (int i = 0; i < 12; i++) { >>>>>> map.put(i, i); >>>>>> } >>>>>> } >>>>>> >>>>>> public static int getArrayLength(Map map) throws NoSuchFieldException, IllegalAccessException { >>>>>> Field field = HashMap.class.getDeclaredField("table"); >>>>>> field.setAccessible(true); >>>>>> Object table = field.get(map); >>>>>> return Array.getLength(table); >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> run this and we get the output: >>>>>> >>>>>> a : 16 >>>>>> b : 16 >>>>>> c : 32 >>>>>> d : 32 >>>>>> >>>>>> So I go see the codes. >>>>>> >>>>>> /** >>>>>> * Implements Map.putAll and Map constructor. >>>>>> * >>>>>> * @param m the map >>>>>> * @param evict false when initially constructing this map, else >>>>>> * true (relayed to method afterNodeInsertion). >>>>>> */ >>>>>> final void putMapEntries(Map m, boolean evict) { >>>>>> int s = m.size(); >>>>>> if (s > 0) { >>>>>> if (table == null) { // pre-size >>>>>> float ft = ((float)s / loadFactor) + 1.0F; >>>>>> int t = ((ft < (float)MAXIMUM_CAPACITY) ? >>>>>> (int)ft : MAXIMUM_CAPACITY); >>>>>> if (t > threshold) >>>>>> threshold = tableSizeFor(t); >>>>>> } else { >>>>>> // Because of linked-list bucket constraints, we cannot >>>>>> // expand all at once, but can reduce total resize >>>>>> // effort by repeated doubling now vs later >>>>>> while (s > threshold && table.length < MAXIMUM_CAPACITY) >>>>>> resize(); >>>>>> } >>>>>> >>>>>> for (Map.Entry e : m.entrySet()) { >>>>>> K key = e.getKey(); >>>>>> V value = e.getValue(); >>>>>> putVal(hash(key), key, value, false, evict); >>>>>> } >>>>>> } >>>>>> } >>>>>> >>>>>> yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. >>>>>> >>>>>> It should be *Math.ceil((float)s / loadFactor)* >>>>>> >>>>>> So I wish to generate a pull request. >>>>>> >>>>>> Anyone interested? >>>>>> >>>>>> From lancea at openjdk.java.net Mon Feb 7 20:20:05 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Feb 2022 20:20:05 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: <4Z4KMKwU2HO_ZDgoDG0maJaYDyr-NYxyN413b0Ipxjw=.bbb8869b-dfeb-4b13-9384-cc54dfce268b@github.com> On Mon, 7 Feb 2022 18:44:10 GMT, Sean Mullan wrote: >> Looking at this a bit more, it looks like `JariFile::initializeVerifier` is the only place currently in `JarFile` that could throw a `JarException` and that method could be called from `JarFile::getInputStream` >> >> As `verifiableEntry` is only called from `JarFile::getInputStream `and this change validates the `ZipEntry` for being null, which is should, the only other possible error would be in the unlikely event. `ZipEntry` was subclassed passed into `JarFile::getInputStream` resulting in the call to `ZipEntry::getName` returning null(in which case `ZipFile::getEntry` will return a `NullPointerException`) or the name being invalid resulting once again in a possible null value for the returned `ZipEntry` from `JarFile::getJarEntry` (which calls `ZipFile::getEntry`) >> >> >> I am still leaning towards a `ZipException`, not a `JarException`, thrown from `verifiableEntry`. >> >> That being said, I will go with whatever the consensus is. > > If you are pretty sure the only other case are as above, I wonder if a simpler fix would be to change `verifiableEntry()` to check for these null cases and throw a `ZipException` which will get directly propagated by `getInputStream()`? I can certainly throw a ZipException from `verifiableEntry`. I am a bit reluctant to not catch any other `Exception` and then throw a `ZipException` from `getInputStream()` as it is certainly possible of encountering some other issue due to some stray value in the CEN. So I will update `verifiableEntry` to validate `ZipEntry` and` ZipEntry::getName()` potential issues ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Mon Feb 7 23:02:54 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Feb 2022 23:02:54 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Reduce Exception checking to JarFile::verifiableEntry ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/b50ebf05..6c75384a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=00-01 Stats: 162 lines in 3 files changed: 90 ins; 21 del; 51 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Mon Feb 7 23:11:07 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Feb 2022 23:11:07 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: <4Z4KMKwU2HO_ZDgoDG0maJaYDyr-NYxyN413b0Ipxjw=.bbb8869b-dfeb-4b13-9384-cc54dfce268b@github.com> References: <4Z4KMKwU2HO_ZDgoDG0maJaYDyr-NYxyN413b0Ipxjw=.bbb8869b-dfeb-4b13-9384-cc54dfce268b@github.com> Message-ID: On Mon, 7 Feb 2022 20:16:43 GMT, Lance Andersen wrote: >> If you are pretty sure the only other case are as above, I wonder if a simpler fix would be to change `verifiableEntry()` to check for these null cases and throw a `ZipException` which will get directly propagated by `getInputStream()`? > > I can certainly throw a ZipException from `verifiableEntry`. I am a bit reluctant to not catch any other `Exception` and then throw a `ZipException` from `getInputStream()` as it is certainly possible of encountering some other issue due to some stray value in the CEN. > > So I will update `verifiableEntry` to validate `ZipEntry` and` ZipEntry::getName()` potential issues Per an offline-discussion with Sean, I narrowed the Exception checking to JarFile::verifiableEntry. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From rriggs at openjdk.java.net Mon Feb 7 23:27:04 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Feb 2022 23:27:04 GMT Subject: RFR: 8176706: Additional Date-Time Formats In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 23:29:54 GMT, Naoto Sato wrote: > Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5115: > 5113: > 5114: private LocalizedPrinterParser(FormatStyle dateStyle, FormatStyle timeStyle, String requestedTemplate) { > 5115: this.dateStyle = dateStyle; Drop this constructor; it opens up the possibility of ambiguity between the modes. Keep only the two constructors with disjoint checking and initialization. src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5151: > 5149: */ > 5150: private DateTimeFormatter formatter(Locale locale, Chronology chrono) { > 5151: var dtStyle = dateStyle !=null || timeStyle != null; Switch to using requestedTemplate == null or != null as the discriminator. src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5162: > 5160: > 5161: formatter = new DateTimeFormatterBuilder().appendPattern(pattern).toFormatter(locale); > 5162: DateTimeFormatter old = FORMATTER_CACHE.putIfAbsent(key, formatter); .computeIfAbsent(key, () -> {....}) might be a bit cleaner/clearer here and avoid the race a few lines of code below. (a slight improvement in old code). src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java line 606: > 604: var matcher = VALID_SKELETON_PATTERN.matcher(skeleton); > 605: if (!matcher.matches()) { > 606: throw new IllegalArgumentException("Requested template is invalid: " + requestedTemplate); The substitutions are not going to be visible in the exception message. That might make it harder to identify and fix the cause of the exception. Perhaps the message can make it clear that the matching was done after substitutions and show the 'skeleton'. ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From joehw at openjdk.java.net Tue Feb 8 01:06:07 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 8 Feb 2022 01:06:07 GMT Subject: RFR: 8176706: Additional Date-Time Formats In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 23:29:54 GMT, Naoto Sato wrote: > Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 254: > 252: public static String getLocalizedDateTimePattern(String requestedTemplate, > 253: Chronology chrono, Locale locale) { > 254: Objects.requireNonNull(locale, "requestedTemplate"); Typo, "locale" should have been requestedTemplate. src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java line 77: > 75: LocaleProviderAdapter lpa = LocaleProviderAdapter.getResourceBundleBased(); > 76: // CLDR's 'u'/'U' are not supported in the JDK. Replace them with 'y' instead > 77: final var modifiedSkeleton = requestedTemplate.replaceAll("[uU]", "y"); Seems to me requestedTemplate needs to be validated when it gets passed to getLocalizedDateTimePattern, similar as to appendLocalized ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From shade at openjdk.java.net Tue Feb 8 07:22:13 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Feb 2022 07:22:13 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 13:34:24 GMT, Claes Redestad wrote: > Looks reasonable. Thanks. Any more reviews needed, or I am pushing? ------------- PR: https://git.openjdk.java.net/jdk/pull/7333 From sgehwolf at openjdk.java.net Tue Feb 8 09:52:12 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 8 Feb 2022 09:52:12 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 01:23:11 GMT, Martin Balao wrote: >> Hi @AlekseiEfimov >> >> Can you please review the CSR [1]? >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8276959 > >> @martinuy This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! > > Please do not close, waiting for CSR approval. @martinuy The CSR is approved, fwiw. ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From duke at openjdk.java.net Tue Feb 8 10:01:11 2022 From: duke at openjdk.java.net (Suminda Sirinath Salpitikorala Dharmasena) Date: Tue, 8 Feb 2022 10:01:11 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Mon, 15 Nov 2021 19:31:09 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results > > Enhanced intervals in MathUtils. > Updated references to Schubfach v4. Can someone look into this please. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From redestad at openjdk.java.net Tue Feb 8 13:32:02 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Feb 2022 13:32:02 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 07:19:16 GMT, Aleksey Shipilev wrote: > Thanks. Any more reviews needed, or I am pushing? I think you're good to push. I suspect some might question making the code ever so little less obvious/maintainable on behalf of interpreter performance, but I think it's well-motivated since startup speed is where MHs/VHs continue to feel a bit lackluster. ------------- PR: https://git.openjdk.java.net/jdk/pull/7333 From mbalao at openjdk.java.net Tue Feb 8 13:44:13 2022 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 8 Feb 2022 13:44:13 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 01:23:11 GMT, Martin Balao wrote: >> Hi @AlekseiEfimov >> >> Can you please review the CSR [1]? >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8276959 > >> @martinuy This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! > > Please do not close, waiting for CSR approval. > @martinuy Also your Compatibility Risk talks about KDCs, but this is about directory servers. Not sure how this relates here. Correct, it was an unconscious mistake :) I will try to get this fixed (as the CSR was approved, I'll ask before editing directly). ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From mbalao at openjdk.java.net Tue Feb 8 13:55:13 2022 From: mbalao at openjdk.java.net (Martin Balao) Date: Tue, 8 Feb 2022 13:55:13 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 13:41:28 GMT, Martin Balao wrote: >>> @martinuy This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! >> >> Please do not close, waiting for CSR approval. > >> @martinuy Also your Compatibility Risk talks about KDCs, but this is about directory servers. Not sure how this relates here. > > Correct, it was an unconscious mistake :) I will try to get this fixed (as the CSR was approved, I'll ask before editing directly). > @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't everything protocol related a fail-fast issue? E.g., if the socket is up and running, but the LDAP message is rejected can we assume that all subsequent servers for the same resolution will reject the request as well before authentication has happened? It looks to me that it's not only a fail-fast issue because the state on the directory side might be altered by each try, as it happened in the reported case. In other words, the client might cause a denial-of-service blocking an account by trying multiple times the same incorrect authentication credentials on each resolved server. In regards to the 2nd question, I guess that we cannot assume that. But the revert is intended for failed authentication only. Is there a risk that you foresee by reverting the failed-authentication behavior back to pre-JDK-8160768? ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From vlivanov at openjdk.java.net Tue Feb 8 14:20:05 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 8 Feb 2022 14:20:05 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 07:20:28 GMT, Aleksey Shipilev wrote: > I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`. > > There is direct VarHandle benchmark in our corpus: > > > $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint" > > Benchmark Mode Cnt Score Error Units > > # -Xint > # Baseline > VarHandleExact.exact_exactInvocation avgt 30 714.041 ? 5.882 ns/op > VarHandleExact.generic_exactInvocation avgt 30 641.570 ? 11.681 ns/op > VarHandleExact.generic_genericInvocation avgt 30 1336.571 ? 11.873 ns/op > > # -Xint > # Patched > VarHandleExact.exact_exactInvocation avgt 30 678.495 ? 10.752 ns/op ; +5% > VarHandleExact.generic_exactInvocation avgt 30 573.320 ? 5.100 ns/op ; +11% > VarHandleExact.generic_genericInvocation avgt 30 1338.593 ? 14.275 ns/op > > # (server, default) > # Baseline > VarHandleExact.exact_exactInvocation avgt 30 0.620 ? 0.079 ns/op > VarHandleExact.generic_exactInvocation avgt 30 0.602 ? 0.063 ns/op > VarHandleExact.generic_genericInvocation avgt 30 10.521 ? 0.065 ns/op > > # (server, default) > # Patched > VarHandleExact.exact_exactInvocation avgt 30 0.621 ? 0.070 ns/op > VarHandleExact.generic_exactInvocation avgt 30 0.601 ? 0.061 ns/op > VarHandleExact.generic_genericInvocation avgt 30 10.499 ? 0.070 ns/op > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Marked as reviewed by vlivanov (Reviewer). src/java.base/share/classes/java/lang/invoke/VarForm.java line 112: > 110: @ForceInline > 111: final MemberName getMemberName(int mode) { > 112: MemberName mn = memberName_table[mode]; It makes sense to leave a comment here why inlining `getMemberNameOrNull()` makes sense. Otherwise, looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7333 From mullan at openjdk.java.net Tue Feb 8 15:41:21 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Feb 2022 15:41:21 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 23:02:54 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the attached patch to address >> >> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter >> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs >> >> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Reduce Exception checking to JarFile::verifiableEntry Marked as reviewed by mullan (Reviewer). src/java.base/share/classes/java/util/jar/JarFile.java line 871: > 869: } > 870: // ZipEntry::getName should not return null > 871: if(ze.getName() != null) { Nit, add space after "if" src/java.base/share/classes/java/util/jar/JarFile.java line 874: > 872: ze = getJarEntry(ze.getName()); > 873: } else { > 874: throw new ZipException("Error: ZipEntry::getName returned null!"); I'd probably leave out the "Error:" and the "!". src/java.base/share/classes/java/util/jar/JarFile.java line 877: > 875: } > 876: // ZipEntry returned from JarFile::getJarEntry should not be null > 877: if(ze == null) { Nit, add space after "if" ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From alanb at openjdk.java.net Tue Feb 8 16:02:11 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Feb 2022 16:02:11 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: Message-ID: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> On Tue, 8 Feb 2022 15:27:46 GMT, Sean Mullan wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduce Exception checking to JarFile::verifiableEntry > > src/java.base/share/classes/java/util/jar/JarFile.java line 871: > >> 869: } >> 870: // ZipEntry::getName should not return null >> 871: if(ze.getName() != null) { > > Nit, add space after "if" if ZipEntry is extended and getName() overridden then you can't trust the name. So I think you'll have extract the name rather than calling ZipEntry::getName twice. I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry is null. > src/java.base/share/classes/java/util/jar/JarFile.java line 877: > >> 875: } >> 876: // ZipEntry returned from JarFile::getJarEntry should not be null >> 877: if(ze == null) { > > Nit, add space after "if" ze can't be null here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From mullan at openjdk.java.net Tue Feb 8 16:18:05 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 8 Feb 2022 16:18:05 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> Message-ID: On Tue, 8 Feb 2022 15:57:00 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/util/jar/JarFile.java line 871: >> >>> 869: } >>> 870: // ZipEntry::getName should not return null >>> 871: if(ze.getName() != null) { >> >> Nit, add space after "if" > > if ZipEntry is extended and getName() overridden then you can't trust the name. So I think you'll have extract the name rather than calling ZipEntry::getName twice. I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null. Ah, yes - good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From shade at openjdk.java.net Tue Feb 8 17:11:45 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Feb 2022 17:11:45 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter [v2] In-Reply-To: References: Message-ID: > I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`. > > There is direct VarHandle benchmark in our corpus: > > > $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint" > > Benchmark Mode Cnt Score Error Units > > # -Xint > # Baseline > VarHandleExact.exact_exactInvocation avgt 30 714.041 ? 5.882 ns/op > VarHandleExact.generic_exactInvocation avgt 30 641.570 ? 11.681 ns/op > VarHandleExact.generic_genericInvocation avgt 30 1336.571 ? 11.873 ns/op > > # -Xint > # Patched > VarHandleExact.exact_exactInvocation avgt 30 678.495 ? 10.752 ns/op ; +5% > VarHandleExact.generic_exactInvocation avgt 30 573.320 ? 5.100 ns/op ; +11% > VarHandleExact.generic_genericInvocation avgt 30 1338.593 ? 14.275 ns/op > > # (server, default) > # Baseline > VarHandleExact.exact_exactInvocation avgt 30 0.620 ? 0.079 ns/op > VarHandleExact.generic_exactInvocation avgt 30 0.602 ? 0.063 ns/op > VarHandleExact.generic_genericInvocation avgt 30 10.521 ? 0.065 ns/op > > # (server, default) > # Patched > VarHandleExact.exact_exactInvocation avgt 30 0.621 ? 0.070 ns/op > VarHandleExact.generic_exactInvocation avgt 30 0.601 ? 0.061 ns/op > VarHandleExact.generic_genericInvocation avgt 30 10.499 ? 0.070 ns/op > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Comment - Merge branch 'master' into JDK-8281168-int-varform - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7333/files - new: https://git.openjdk.java.net/jdk/pull/7333/files/62028379..a84a4e7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7333&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7333&range=00-01 Stats: 6290 lines in 289 files changed: 3892 ins; 1334 del; 1064 mod Patch: https://git.openjdk.java.net/jdk/pull/7333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7333/head:pull/7333 PR: https://git.openjdk.java.net/jdk/pull/7333 From shade at openjdk.java.net Tue Feb 8 17:11:48 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Feb 2022 17:11:48 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 14:16:15 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Comment >> - Merge branch 'master' into JDK-8281168-int-varform >> - Fix > > src/java.base/share/classes/java/lang/invoke/VarForm.java line 112: > >> 110: @ForceInline >> 111: final MemberName getMemberName(int mode) { >> 112: MemberName mn = memberName_table[mode]; > > It makes sense to leave a comment here why inlining `getMemberNameOrNull()` makes sense. Otherwise, looks good. Added comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7333 From vlivanov at openjdk.java.net Tue Feb 8 17:20:11 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 8 Feb 2022 17:20:11 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 17:11:45 GMT, Aleksey Shipilev wrote: >> I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`. >> >> There is direct VarHandle benchmark in our corpus: >> >> >> $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint" >> >> Benchmark Mode Cnt Score Error Units >> >> # -Xint >> # Baseline >> VarHandleExact.exact_exactInvocation avgt 30 714.041 ? 5.882 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 641.570 ? 11.681 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 1336.571 ? 11.873 ns/op >> >> # -Xint >> # Patched >> VarHandleExact.exact_exactInvocation avgt 30 678.495 ? 10.752 ns/op ; +5% >> VarHandleExact.generic_exactInvocation avgt 30 573.320 ? 5.100 ns/op ; +11% >> VarHandleExact.generic_genericInvocation avgt 30 1338.593 ? 14.275 ns/op >> >> # (server, default) >> # Baseline >> VarHandleExact.exact_exactInvocation avgt 30 0.620 ? 0.079 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 0.602 ? 0.063 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 10.521 ? 0.065 ns/op >> >> # (server, default) >> # Patched >> VarHandleExact.exact_exactInvocation avgt 30 0.621 ? 0.070 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 0.601 ? 0.061 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 10.499 ? 0.070 ns/op >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Comment > - Merge branch 'master' into JDK-8281168-int-varform > - Fix Thanks, looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7333 From mchung at openjdk.java.net Tue Feb 8 17:43:11 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Feb 2022 17:43:11 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 17:11:45 GMT, Aleksey Shipilev wrote: >> I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`. >> >> There is direct VarHandle benchmark in our corpus: >> >> >> $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint" >> >> Benchmark Mode Cnt Score Error Units >> >> # -Xint >> # Baseline >> VarHandleExact.exact_exactInvocation avgt 30 714.041 ? 5.882 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 641.570 ? 11.681 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 1336.571 ? 11.873 ns/op >> >> # -Xint >> # Patched >> VarHandleExact.exact_exactInvocation avgt 30 678.495 ? 10.752 ns/op ; +5% >> VarHandleExact.generic_exactInvocation avgt 30 573.320 ? 5.100 ns/op ; +11% >> VarHandleExact.generic_genericInvocation avgt 30 1338.593 ? 14.275 ns/op >> >> # (server, default) >> # Baseline >> VarHandleExact.exact_exactInvocation avgt 30 0.620 ? 0.079 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 0.602 ? 0.063 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 10.521 ? 0.065 ns/op >> >> # (server, default) >> # Patched >> VarHandleExact.exact_exactInvocation avgt 30 0.621 ? 0.070 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 0.601 ? 0.061 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 10.499 ? 0.070 ns/op >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Comment > - Merge branch 'master' into JDK-8281168-int-varform > - Fix This change looks okay. One biggest cold startup overhead we measured for JEP 416 is due to the overhead of spinning and loading classes of MH/VH. This micro-optimization focuses on the performance of VH invocation. Do you see class spinning and loading from your benchmark? Maybe in the generic invocation case? ------------- PR: https://git.openjdk.java.net/jdk/pull/7333 From shade at openjdk.java.net Tue Feb 8 17:48:16 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Feb 2022 17:48:16 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 17:39:37 GMT, Mandy Chung wrote: > This change looks okay. One biggest cold startup overhead we measured for JEP 416 is due to the overhead of spinning and loading classes of MH/VH. This micro-optimization focuses on the performance of VH invocation. Do you see class spinning and loading from your benchmark? Maybe in the generic invocation case? Not really, I am trying to see that `-Xint` does not have easy to fix impediments to cold performance. In this benchmark, bootstrapping stuff had already happened at warmup, it measures the overheads of doing all the MH/VH without the optimizing compiler assistance. ------------- PR: https://git.openjdk.java.net/jdk/pull/7333 From lancea at openjdk.java.net Tue Feb 8 17:54:11 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Feb 2022 17:54:11 GMT Subject: RFR: 8281104: jar --create should create missing parent directories [v3] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 22:29:45 GMT, Christian Stein wrote: >> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Update help text of Compatibility Interface Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From cstein at openjdk.java.net Tue Feb 8 17:57:11 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 8 Feb 2022 17:57:11 GMT Subject: Integrated: 8281104: jar --create should create missing parent directories In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein wrote: > Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory. This pull request has now been integrated. Changeset: 92f4f40d Author: Christian Stein Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/92f4f40da6c4ff55c7ed334007c9c6ca0dc15d99 Stats: 128 lines in 3 files changed: 121 ins; 0 del; 7 mod 8281104: jar --create should create missing parent directories Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7327 From lancea at openjdk.java.net Tue Feb 8 18:15:05 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Feb 2022 18:15:05 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> Message-ID: On Tue, 8 Feb 2022 16:15:20 GMT, Sean Mullan wrote: >> if ZipEntry is extended and getName() overridden then you can't trust the name. So I think you'll have extract the name rather than calling ZipEntry::getName twice. I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null. > > Ah, yes - good catch! Will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Tue Feb 8 18:15:05 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Feb 2022 18:15:05 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> Message-ID: On Tue, 8 Feb 2022 18:06:52 GMT, Lance Andersen wrote: >> Ah, yes - good catch! > > Will do. > I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null. I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream, aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere, there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Tue Feb 8 18:15:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Feb 2022 18:15:06 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 15:31:51 GMT, Sean Mullan wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduce Exception checking to JarFile::verifiableEntry > > src/java.base/share/classes/java/util/jar/JarFile.java line 874: > >> 872: ze = getJarEntry(ze.getName()); >> 873: } else { >> 874: throw new ZipException("Error: ZipEntry::getName returned null!"); > > I'd probably leave out the "Error:" and the "!". OK, I can do that if you prefer. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Tue Feb 8 18:15:07 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Feb 2022 18:15:07 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> Message-ID: On Tue, 8 Feb 2022 15:55:50 GMT, Alan Bateman wrote: > ze can't be null here. Actually it can be: Consider the following: try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(), true)) { var ze = new ZipEntry("org/gotham/Batcave.class"); var ex= expectThrows(ZipException.class, () -> jf.getInputStream(ze) ); // Validate that we receive the expected message from // JarFile::verifiableEntry when ZipEntry::getName returns null assertTrue( ex != null && ex.getMessage().equals("Error: ZipEntry should not be null!")); } The above code does generate the error. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Tue Feb 8 18:15:07 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Feb 2022 18:15:07 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> Message-ID: <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com> On Tue, 8 Feb 2022 18:05:25 GMT, Lance Andersen wrote: >> ze can't be null here. > >> ze can't be null here. > > Actually it can be: Consider the following: > > > try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(), true)) { > var ze = new ZipEntry("org/gotham/Batcave.class"); > var ex= expectThrows(ZipException.class, > () -> jf.getInputStream(ze) ); > // Validate that we receive the expected message from > // JarFile::verifiableEntry when ZipEntry::getName returns null > assertTrue( ex != null && ex.getMessage().equals("Error: ZipEntry should not be null!")); > } > > > The above code does generate the error. > Nit, add space after "if" will fix ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From naoto at openjdk.java.net Tue Feb 8 18:40:40 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Feb 2022 18:40:40 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v2] In-Reply-To: References: Message-ID: > Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Modified per suggestions on the PR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7340/files - new: https://git.openjdk.java.net/jdk/pull/7340/files/f9311dce..059132f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=00-01 Stats: 80 lines in 4 files changed: 23 ins; 37 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/7340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7340/head:pull/7340 PR: https://git.openjdk.java.net/jdk/pull/7340 From naoto at openjdk.java.net Tue Feb 8 18:47:06 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Feb 2022 18:47:06 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 00:39:04 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Modified per suggestions on the PR > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 254: > >> 252: public static String getLocalizedDateTimePattern(String requestedTemplate, >> 253: Chronology chrono, Locale locale) { >> 254: Objects.requireNonNull(locale, "requestedTemplate"); > > Typo, "locale" should have been requestedTemplate. Good catch! > src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java line 77: > >> 75: LocaleProviderAdapter lpa = LocaleProviderAdapter.getResourceBundleBased(); >> 76: // CLDR's 'u'/'U' are not supported in the JDK. Replace them with 'y' instead >> 77: final var modifiedSkeleton = requestedTemplate.replaceAll("[uU]", "y"); > > Seems to me requestedTemplate needs to be validated when it gets passed to getLocalizedDateTimePattern, similar as to appendLocalized This was a left over which should be removed. In fact, CLDR specific pattern symbols should not be accepted as the requested template. Removed the substitutions. As to the validation, it will be performed in the following `LocaleResources.getLocalizedPattern()` method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From naoto at openjdk.java.net Tue Feb 8 18:47:07 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Feb 2022 18:47:07 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v2] In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 21:22:12 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Modified per suggestions on the PR > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5162: > >> 5160: >> 5161: formatter = new DateTimeFormatterBuilder().appendPattern(pattern).toFormatter(locale); >> 5162: DateTimeFormatter old = FORMATTER_CACHE.putIfAbsent(key, formatter); > > .computeIfAbsent(key, () -> {....}) might be a bit cleaner/clearer here and avoid the race a few lines of code below. (a slight improvement in old code). Good point. Changed to `computeIfAbsent()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From alanb at openjdk.java.net Tue Feb 8 18:59:07 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Feb 2022 18:59:07 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> Message-ID: On Tue, 8 Feb 2022 18:11:38 GMT, Lance Andersen wrote: > I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream, aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere, there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called. I think the scenario that we are discussing is where the parameter is not null. It's the case where getInputStream(ZipEntry) is called with a ZipEntry that reports its name as null. I don't think it is covered by existing javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From naoto at openjdk.java.net Tue Feb 8 19:08:45 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Feb 2022 19:08:45 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v3] In-Reply-To: References: Message-ID: > Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7340/files - new: https://git.openjdk.java.net/jdk/pull/7340/files/059132f5..41408ff3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7340/head:pull/7340 PR: https://git.openjdk.java.net/jdk/pull/7340 From lancea at openjdk.java.net Tue Feb 8 19:20:10 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Feb 2022 19:20:10 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> Message-ID: On Tue, 8 Feb 2022 18:56:02 GMT, Alan Bateman wrote: >>> I'm almost tempted to have getInputStream(ZipEntry) be re-specified to throw IAE if the zip entry name is null. >> >> I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream, aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere, there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called. > >> I personally think it is best to continue throw the NPE as that provides symmetry with ZipFile::getInputStream, aligns with the current javadoc where a null parameter will throw an NPE unless specified elsewhere, there are existing tests which check for an NPE if JarFile::getInpuStream(null) is called. > > I think the scenario that we are discussing is where the parameter is not null. It's the case where getInputStream(ZipEntry) is called with a ZipEntry that reports its name as null. I don't think it is covered by existing javadoc. Ah, OK, sorry I was focused on the NPE and uber focused on the `ZipEntry` passed to `getInputStream`. If you *prefer* an IAE, I can change that when `ZipEntry::getName` returns null. I do think we are technically covered via `ZipException` which is defined : ` if a zip file format error has occurred` and unless something has gone amiss with the Zip/Jar LOC/CEN, you should expect a non-null value. Please let me know your preference as if we go the IAE route, I will need to create a CSR which I was hoping to avoid ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From bpb at openjdk.java.net Tue Feb 8 19:27:12 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 19:27:12 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 11 Jan 2022 09:30:49 GMT, Raffaello Giulietti wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 4511638: Double.toString(double) sometimes produces incorrect results >> >> Enhanced intervals in MathUtils. >> Updated references to Schubfach v4. > > En attendant go! go! @rgiulietti Should we expect any more commits from you in this PR? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From mchung at openjdk.java.net Tue Feb 8 19:32:09 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 8 Feb 2022 19:32:09 GMT Subject: RFR: 8281168: Micro-optimize VarForm.getMemberName for interpreter [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 17:11:45 GMT, Aleksey Shipilev wrote: >> I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`. >> >> There is direct VarHandle benchmark in our corpus: >> >> >> $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint" >> >> Benchmark Mode Cnt Score Error Units >> >> # -Xint >> # Baseline >> VarHandleExact.exact_exactInvocation avgt 30 714.041 ? 5.882 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 641.570 ? 11.681 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 1336.571 ? 11.873 ns/op >> >> # -Xint >> # Patched >> VarHandleExact.exact_exactInvocation avgt 30 678.495 ? 10.752 ns/op ; +5% >> VarHandleExact.generic_exactInvocation avgt 30 573.320 ? 5.100 ns/op ; +11% >> VarHandleExact.generic_genericInvocation avgt 30 1338.593 ? 14.275 ns/op >> >> # (server, default) >> # Baseline >> VarHandleExact.exact_exactInvocation avgt 30 0.620 ? 0.079 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 0.602 ? 0.063 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 10.521 ? 0.065 ns/op >> >> # (server, default) >> # Patched >> VarHandleExact.exact_exactInvocation avgt 30 0.621 ? 0.070 ns/op >> VarHandleExact.generic_exactInvocation avgt 30 0.601 ? 0.061 ns/op >> VarHandleExact.generic_genericInvocation avgt 30 10.499 ? 0.070 ns/op >> >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` >> - [x] Linux x86_64 fastdebug `tier2` >> - [x] Linux x86_64 fastdebug `tier3` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Comment > - Merge branch 'master' into JDK-8281168-int-varform > - Fix Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7333 From duke at openjdk.java.net Tue Feb 8 19:45:13 2022 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Tue, 8 Feb 2022 19:45:13 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 8 Feb 2022 19:23:54 GMT, Brian Burkhalter wrote: >> En attendant go! go! > > @rgiulietti Should we expect any more commits from you in this PR? Thanks. @bplb The last commit was pushed on Nov 15. I guess I would have to merge against the latest master because of test/langtools/tools/javac/sym/ElementStructureTest.java and the intervening switch from JDK18 to JDK19. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From duke at openjdk.java.net Tue Feb 8 20:06:06 2022 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Tue, 8 Feb 2022 20:06:06 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 8 Feb 2022 19:47:25 GMT, Brian Burkhalter wrote: >> @bplb The last commit was pushed on Nov 15. >> I guess I would have to merge against the latest master because of >> test/langtools/tools/javac/sym/ElementStructureTest.java >> and the intervening switch from JDK18 to JDK19. > > @rgiulietti Also the copyright year. So no further substantive updates needed? @bplb Why the copyright year? Nothing is expected to change, except for the test mentioned. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From bpb at openjdk.java.net Tue Feb 8 20:06:06 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 20:06:06 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 8 Feb 2022 19:41:48 GMT, Raffaello Giulietti wrote: >> @rgiulietti Should we expect any more commits from you in this PR? Thanks. > > @bplb The last commit was pushed on Nov 15. > I guess I would have to merge against the latest master because of > test/langtools/tools/javac/sym/ElementStructureTest.java > and the intervening switch from JDK18 to JDK19. @rgiulietti Also the copyright year. So no further substantive updates needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From duke at openjdk.java.net Tue Feb 8 20:10:09 2022 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Tue, 8 Feb 2022 20:10:09 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Mon, 15 Nov 2021 19:31:09 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results > > Enhanced intervals in MathUtils. > Updated references to Schubfach v4. The work (the code) has been published here on GitHub, so afaik the copyright year cannot be simply changed without modifying something (beside the year itself, which would be self-justifying) ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From bpb at openjdk.java.net Tue Feb 8 20:06:07 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 20:06:07 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 8 Feb 2022 19:51:53 GMT, Raffaello Giulietti wrote: >> @rgiulietti Also the copyright year. So no further substantive updates needed? > > @bplb Why the copyright year? Nothing is expected to change, except for the test mentioned. @rgiulietti Well you know I am not sure about the year. I'll ask. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From dcubed at openjdk.java.net Tue Feb 8 20:20:23 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 8 Feb 2022 20:20:23 GMT Subject: Integrated: 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java Message-ID: A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java. ------------- Commit messages: - 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java Changes: https://git.openjdk.java.net/jdk/pull/7390/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7390&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281476 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7390/head:pull/7390 PR: https://git.openjdk.java.net/jdk/pull/7390 From azvegint at openjdk.java.net Tue Feb 8 20:20:23 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 8 Feb 2022 20:20:23 GMT Subject: Integrated: 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7390 From bpb at openjdk.java.net Tue Feb 8 20:20:24 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 20:20:24 GMT Subject: Integrated: 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7390 From lancea at openjdk.java.net Tue Feb 8 20:20:24 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Feb 2022 20:20:24 GMT Subject: Integrated: 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7390 From dcubed at openjdk.java.net Tue Feb 8 20:20:24 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 8 Feb 2022 20:20:24 GMT Subject: Integrated: 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 20:10:38 GMT, Alexander Zvegintsev wrote: >> A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java. > > Marked as reviewed by azvegint (Reviewer). @azvegint and @bplb - Thanks for the lightning fast reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/7390 From dcubed at openjdk.java.net Tue Feb 8 20:20:24 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 8 Feb 2022 20:20:24 GMT Subject: Integrated: 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 20:09:30 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jar/CreateMissingParentDirectories.java. This pull request has now been integrated. Changeset: 5fb56dbb Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/5fb56dbb0b4e3345ca6f48ba9c01bd467f04aa6f Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8281476: ProblemList tools/jar/CreateMissingParentDirectories.java Reviewed-by: azvegint, bpb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7390 From bpb at openjdk.java.net Tue Feb 8 20:21:23 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 8 Feb 2022 20:21:23 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 8 Feb 2022 20:06:38 GMT, Raffaello Giulietti wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> 4511638: Double.toString(double) sometimes produces incorrect results >> >> Enhanced intervals in MathUtils. >> Updated references to Schubfach v4. > > The work (the code) has been published here on GitHub, so afaik the copyright year cannot be simply changed without modifying something (beside the year itself, which would be self-justifying) @rgiulietti You are correct: no year update needed unless there's a change to the file. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From duke at openjdk.java.net Tue Feb 8 20:26:10 2022 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Tue, 8 Feb 2022 20:26:10 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v5] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 8 Feb 2022 20:18:22 GMT, Brian Burkhalter wrote: >> The work (the code) has been published here on GitHub, so afaik the copyright year cannot be simply changed without modifying something (beside the year itself, which would be self-justifying) > > @rgiulietti You are correct: no year update needed unless there's a change to the file. @bplb I'm not even sure that just correcting a typo is considered enough of a change to be entitled to postpone the copyright year. But mileage may vary between jurisdictions ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From duke at openjdk.java.net Tue Feb 8 22:11:34 2022 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Tue, 8 Feb 2022 22:11:34 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v6] In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: > Hello, > > here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. > > The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - 4511638: Double.toString(double) sometimes produces incorrect results Adapted hashes in ElementStructureTest.java - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Enhanced intervals in MathUtils. Updated references to Schubfach v4. - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. - 4511638: Double.toString(double) sometimes produces incorrect results Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results Refactored test classes to better match OpenJDK conventions. Added tests recommended by Guy Steele and Paul Zimmermann. - Changed MAX_CHARS to static - ... and 2 more: https://git.openjdk.java.net/jdk/compare/92f4f40d...c29dff76 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=05 Stats: 23939 lines in 16 files changed: 23809 ins; 54 del; 76 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402 From joehw at openjdk.java.net Tue Feb 8 22:30:05 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 8 Feb 2022 22:30:05 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v3] In-Reply-To: References: Message-ID: <2dgb4gSfu-fI50MrhPVEkdnADRNN66izgUPngz8moKI=.6a74b414-0480-4fac-9bfe-1eefbe8c9256@github.com> On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato wrote: >> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From xenoamess at gmail.com Wed Feb 9 01:51:57 2022 From: xenoamess at gmail.com (Xeno Amess) Date: Wed, 9 Feb 2022 09:51:57 +0800 Subject: HashMap.putAll can cause redundant space waste In-Reply-To: <0dd3c438-2dca-f0dd-cab0-842a9f06ee13@oracle.com> References: <0dd3c438-2dca-f0dd-cab0-842a9f06ee13@oracle.com> Message-ID: > > I agree that it would > be preferable for the expression to be something like this: (int) Math.ceil(expected / 0.75) Agree. If we don't add a Java SE utility like "newHashMapWithExpectedSize", > fallbacks would > be to introduce an internal JDK utility method that is called from various > places, > or just to update the individual call sites to use the more precise > calculation. Both seem acceptable. So what should I do next? Stuart Marks ?2022?2?8??? 04:06??? > Hi, > > I'm not sure where you ended up in this succession of messages. I do think > there are > some things going on that are worthy of discussion and possibly fixing. > Let me try > to break them down. > > 1) With the default load factor of 0.75, it's possible to have 12 entries > in a map > whose table length is 16. This works as expected if the entries are added > individually using the put() method. However, adding 12 entries into a map > via the > copy constructor or via putAll() results in a table length of 32. That > seems wrong. > Well, if not exactly wrong, it's suboptimal, in that it uses more space > than necessary. > > 2) The root cause of the problem is with expressions such as these: > > (int) (expected / 0.75f + 1.0f) > or > (int) (expected / 0.75f) + 1 > > (where "expected" is the expected number of entries). They attempt to > round the > division result up to the nearest int by adding 1 or 1.0f. This results in > a value > that's one too large if the result of the division exactly equals an > integer. So, > when "expected" is 12, this results in 17 instead of 16. This in turn is > inflated to > the next power-of-two, which is 32. > > 3) This was discussed previously in a different context. [1] I agree that > it would > be preferable for the expression to be something like this: > > (int) Math.ceil(expected / 0.75) > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066258.html > > This uses doubles instead of floats. But I think this is a fairly > low-frequency > operation, so I don't think using doubles is a problem. Thus I don't think > we need > to add a Math.ceil(float) overload. > > ** > > So what should be done about this? Possibly, the computations in HashMap > and related > classes should be adjusted to use Math.ceil() instead. Some tests use the > suboptimal > calculation as well; those might need to be adjusted also. > > There are a variety of places around the JDK that use a similar expression > in order > to pre-size HashMaps and HashSets. We could go around and fix all them, > but it might > be worth considering adding an API that creates a HashMap (or > LinkedHashMap) that is > pre-sized for the expected number of elements. Guava has such an API, > Maps.newHashMapWithExpectedSize [2]. But note that it tries (but does not > guarantee) > to size the map such that it can accommodate the expected number of > elements without > resizing, but it doesn't promise that the map isn't oversized. > > [2] > > https://guava.dev/releases/31.0.1-jre/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize(int) > > (Also note that the ConcurrentHashMap(int) constructor takes the expected > number of > elements, not the initial table length like HashMap(int). CHM does what > probably > most users want, but it's confusing that its behavior differs from HashMap > in this > regard.) > > If we don't add a Java SE utility like "newHashMapWithExpectedSize", > fallbacks would > be to introduce an internal JDK utility method that is called from various > places, > or just to update the individual call sites to use the more precise > calculation. > > s'marks > > > On 2/4/22 10:48 AM, Xeno Amess wrote: > > wait, things get interesting now. > > We do have such a test named ConstantDirectoryOptimalCapacity to make > sure > > this does not happen, but my tests still fill under the idea debugger. > > Is there any specialist for help? I would dig in but it is a little > > complicated. > > [image: image.png] > > > > Xeno Amess ?2022?2?5??? 02:39??? > > > >> Sorry for my mistake. > >> After a more throughout dig in, this thing has already fixed several > years > >> ago, at year 2015. > >> Issue close. > >> > >> Xeno Amess ?2022?2?4??? 21:40??? > >> > >>> Besides, is it worthy to develop a public float Math.ceil(float) > function? > >>> > >>> Xeno Amess ?2022?2?4??? 21:39??? > >>> > >>>> patch applied. > >>>> > >>>> Index: src/java.base/share/classes/java/lang/Module.java > >>>> IDEA additional info: > >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > >>>> <+>UTF-8 > >>>> =================================================================== > >>>> diff --git a/src/java.base/share/classes/java/lang/Module.java > >>>> b/src/java.base/share/classes/java/lang/Module.java > >>>> --- a/src/java.base/share/classes/java/lang/Module.java (revision > >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) > >>>> +++ b/src/java.base/share/classes/java/lang/Module.java (revision > >>>> deeba25d15398fea8bc971ac915e348878b2c27a) > >>>> @@ -1133,7 +1133,7 @@ > >>>> boolean isBootLayer = (ModuleLayer.boot() == null); > >>>> > >>>> int numModules = cf.modules().size(); > >>>> - int cap = (int)(numModules / 0.75f + 1.0f); > >>>> + int cap = (int)Math.ceil(numModules / 0.75f); > >>>> Map nameToModule = new HashMap<>(cap); > >>>> > >>>> // to avoid repeated lookups and reduce iteration overhead, > we > >>>> create > >>>> Index: src/java.base/share/classes/java/util/HashMap.java > >>>> IDEA additional info: > >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > >>>> <+>UTF-8 > >>>> =================================================================== > >>>> diff --git a/src/java.base/share/classes/java/util/HashMap.java > >>>> b/src/java.base/share/classes/java/util/HashMap.java > >>>> --- a/src/java.base/share/classes/java/util/HashMap.java (revision > >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) > >>>> +++ b/src/java.base/share/classes/java/util/HashMap.java (revision > >>>> deeba25d15398fea8bc971ac915e348878b2c27a) > >>>> @@ -495,9 +495,9 @@ > >>>> int s = m.size(); > >>>> if (s > 0) { > >>>> if (table == null) { // pre-size > >>>> - float ft = ((float)s / loadFactor) + 1.0F; > >>>> - int t = ((ft < (float)MAXIMUM_CAPACITY) ? > >>>> - (int)ft : MAXIMUM_CAPACITY); > >>>> + double dt = Math.ceil(s / loadFactor); > >>>> + int t = ((dt < (double)MAXIMUM_CAPACITY) ? > >>>> + (int)dt : MAXIMUM_CAPACITY); > >>>> if (t > threshold) > >>>> threshold = tableSizeFor(t); > >>>> } else { > >>>> @@ -1527,12 +1527,12 @@ > >>>> } else if (mappings == 0) { > >>>> // use defaults > >>>> } else if (mappings > 0) { > >>>> - float fc = (float)mappings / lf + 1.0f; > >>>> - int cap = ((fc < DEFAULT_INITIAL_CAPACITY) ? > >>>> + double dc = Math.ceil(mappings / lf); > >>>> + int cap = ((dc < DEFAULT_INITIAL_CAPACITY) ? > >>>> DEFAULT_INITIAL_CAPACITY : > >>>> - (fc >= MAXIMUM_CAPACITY) ? > >>>> + (dc >= MAXIMUM_CAPACITY) ? > >>>> MAXIMUM_CAPACITY : > >>>> - tableSizeFor((int)fc)); > >>>> + tableSizeFor((int)dc)); > >>>> float ft = (float)cap * lf; > >>>> threshold = ((cap < MAXIMUM_CAPACITY && ft < > >>>> MAXIMUM_CAPACITY) ? > >>>> (int)ft : Integer.MAX_VALUE); > >>>> Index: src/java.base/share/classes/java/util/WeakHashMap.java > >>>> IDEA additional info: > >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > >>>> <+>UTF-8 > >>>> =================================================================== > >>>> diff --git a/src/java.base/share/classes/java/util/WeakHashMap.java > >>>> b/src/java.base/share/classes/java/util/WeakHashMap.java > >>>> --- a/src/java.base/share/classes/java/util/WeakHashMap.java (revision > >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) > >>>> +++ b/src/java.base/share/classes/java/util/WeakHashMap.java (revision > >>>> deeba25d15398fea8bc971ac915e348878b2c27a) > >>>> @@ -251,7 +251,7 @@ > >>>> * @since 1.3 > >>>> */ > >>>> public WeakHashMap(Map m) { > >>>> - this(Math.max((int) ((float)m.size() / DEFAULT_LOAD_FACTOR + > >>>> 1.0F), > >>>> + this(Math.max((int) Math.ceil(m.size() / > DEFAULT_LOAD_FACTOR), > >>>> DEFAULT_INITIAL_CAPACITY), > >>>> DEFAULT_LOAD_FACTOR); > >>>> putAll(m); > >>>> > >>>> Xeno Amess ?2022?2?4??? 18:45??? > >>>> > >>>>> also find some other places have same problem. > >>>>> If some of your already-in people aggree, I would create a pr, but > >>>>> according to the rules seems I should wait for now. > >>>>> > >>>>> Xeno Amess ?2022?2?4??? 18:42??? > >>>>> > >>>>>> import java.lang.reflect.Array; > >>>>>> import java.lang.reflect.Field; > >>>>>> import java.util.HashMap; > >>>>>> import java.util.Map; > >>>>>> > >>>>>> public class TestMap { > >>>>>> > >>>>>> public static void main(String[] args) throws > NoSuchFieldException, IllegalAccessException { > >>>>>> HashMap a = new HashMap<>(); > >>>>>> fill12(a); > >>>>>> HashMap b = new HashMap<>(12); > >>>>>> fill12(b); > >>>>>> HashMap c = new HashMap<>(a); > >>>>>> HashMap d = new HashMap<>(); > >>>>>> d.putAll(a); > >>>>>> System.out.println("a : " + getArrayLength(a)); > >>>>>> System.out.println("b : " + getArrayLength(b)); > >>>>>> System.out.println("c : " + getArrayLength(c)); > >>>>>> System.out.println("d : " + getArrayLength(d)); > >>>>>> } > >>>>>> > >>>>>> public static void fill12(Map map) { > >>>>>> for (int i = 0; i < 12; i++) { > >>>>>> map.put(i, i); > >>>>>> } > >>>>>> } > >>>>>> > >>>>>> public static int getArrayLength(Map map) > throws NoSuchFieldException, IllegalAccessException { > >>>>>> Field field = HashMap.class.getDeclaredField("table"); > >>>>>> field.setAccessible(true); > >>>>>> Object table = field.get(map); > >>>>>> return Array.getLength(table); > >>>>>> } > >>>>>> > >>>>>> } > >>>>>> > >>>>>> run this and we get the output: > >>>>>> > >>>>>> a : 16 > >>>>>> b : 16 > >>>>>> c : 32 > >>>>>> d : 32 > >>>>>> > >>>>>> So I go see the codes. > >>>>>> > >>>>>> /** > >>>>>> * Implements Map.putAll and Map constructor. > >>>>>> * > >>>>>> * @param m the map > >>>>>> * @param evict false when initially constructing this map, else > >>>>>> * true (relayed to method afterNodeInsertion). > >>>>>> */ > >>>>>> final void putMapEntries(Map m, boolean > evict) { > >>>>>> int s = m.size(); > >>>>>> if (s > 0) { > >>>>>> if (table == null) { // pre-size > >>>>>> float ft = ((float)s / loadFactor) + 1.0F; > >>>>>> int t = ((ft < (float)MAXIMUM_CAPACITY) ? > >>>>>> (int)ft : MAXIMUM_CAPACITY); > >>>>>> if (t > threshold) > >>>>>> threshold = tableSizeFor(t); > >>>>>> } else { > >>>>>> // Because of linked-list bucket constraints, we cannot > >>>>>> // expand all at once, but can reduce total resize > >>>>>> // effort by repeated doubling now vs later > >>>>>> while (s > threshold && table.length < > MAXIMUM_CAPACITY) > >>>>>> resize(); > >>>>>> } > >>>>>> > >>>>>> for (Map.Entry e : m.entrySet()) > { > >>>>>> K key = e.getKey(); > >>>>>> V value = e.getValue(); > >>>>>> putVal(hash(key), key, value, false, evict); > >>>>>> } > >>>>>> } > >>>>>> } > >>>>>> > >>>>>> yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. > >>>>>> > >>>>>> It should be *Math.ceil((float)s / loadFactor)* > >>>>>> > >>>>>> So I wish to generate a pull request. > >>>>>> > >>>>>> Anyone interested? > >>>>>> > >>>>>> > From shade at openjdk.java.net Wed Feb 9 06:31:07 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 9 Feb 2022 06:31:07 GMT Subject: Integrated: 8281168: Micro-optimize VarForm.getMemberName for interpreter In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 07:20:28 GMT, Aleksey Shipilev wrote: > I was looking for easy things to do to improve `java.lang.invoke` cold performance. One of the things is inlining `VarForm.getMemberName` a bit, so that interpreter does not have to call through `getMemberNameOrNull`. > > There is direct VarHandle benchmark in our corpus: > > > $ CONF=linux-x86_64-server-release make run-test TEST=micro:java.lang.invoke.VarHandleExact MICRO="TIME=200ms;WARMUP_TIME=200ms;VM_OPTIONS=-Xint" > > Benchmark Mode Cnt Score Error Units > > # -Xint > # Baseline > VarHandleExact.exact_exactInvocation avgt 30 714.041 ? 5.882 ns/op > VarHandleExact.generic_exactInvocation avgt 30 641.570 ? 11.681 ns/op > VarHandleExact.generic_genericInvocation avgt 30 1336.571 ? 11.873 ns/op > > # -Xint > # Patched > VarHandleExact.exact_exactInvocation avgt 30 678.495 ? 10.752 ns/op ; +5% > VarHandleExact.generic_exactInvocation avgt 30 573.320 ? 5.100 ns/op ; +11% > VarHandleExact.generic_genericInvocation avgt 30 1338.593 ? 14.275 ns/op > > # (server, default) > # Baseline > VarHandleExact.exact_exactInvocation avgt 30 0.620 ? 0.079 ns/op > VarHandleExact.generic_exactInvocation avgt 30 0.602 ? 0.063 ns/op > VarHandleExact.generic_genericInvocation avgt 30 10.521 ? 0.065 ns/op > > # (server, default) > # Patched > VarHandleExact.exact_exactInvocation avgt 30 0.621 ? 0.070 ns/op > VarHandleExact.generic_exactInvocation avgt 30 0.601 ? 0.061 ns/op > VarHandleExact.generic_genericInvocation avgt 30 10.499 ? 0.070 ns/op > > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux x86_64 fastdebug `tier2` > - [x] Linux x86_64 fastdebug `tier3` This pull request has now been integrated. Changeset: fc772178 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/fc77217814eb1a346d7380299abdc2b01a69b4de Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 8281168: Micro-optimize VarForm.getMemberName for interpreter Reviewed-by: redestad, vlivanov, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7333 From almatvee at openjdk.java.net Wed Feb 9 07:44:32 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Feb 2022 07:44:32 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description Message-ID: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Added ability to override description for additional launchers via "description" property. ------------- Commit messages: - 8279995: jpackage --add-launcher option should allow overriding description Changes: https://git.openjdk.java.net/jdk/pull/7399/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279995 Stats: 18 lines in 5 files changed: 8 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7399/head:pull/7399 PR: https://git.openjdk.java.net/jdk/pull/7399 From duke at openjdk.java.net Wed Feb 9 11:13:06 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Wed, 9 Feb 2022 11:13:06 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 13:51:57 GMT, Martin Balao wrote: > > @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't everything protocol related a fail-fast issue? E.g., if the socket is up and running, but the LDAP message is rejected can we assume that all subsequent servers for the same resolution will reject the request as well before authentication has happened? > > It looks to me that it's not only a fail-fast issue because the state on the directory side might be altered by each try, as it happened in the reported case. In other words, the client might cause a denial-of-service blocking an account by trying multiple times the same incorrect authentication credentials on each resolved server. Let me add a few points for consideration from my usecases, since I don't use any password-based authentication with SASL and Active Directory only: * `SASL EXTERNAL`: What if the certificate is rejected? Trust store is not properly populated, CRL misconfigured, etc. Will an exception also thrown here? * `SASL GSSAPI/GSS-SPNEGO`: Dir server does not manage creds, but KDC does. I am thinking whether fail fast is reasonable. SPN not registered, next server might have. replay/out of sequence, etc. > In regards to the 2nd question, I guess that we cannot assume that. But the revert is intended for failed authentication only. But the auth is part of the LDAP message as well since the auth does not happen out of band. I would expect that any non-transport issue should fail fast. > Is there a risk that you foresee by reverting the failed-authentication behavior back to pre-JDK-8160768? Not really, I virtually never had problems, thought might need annotations when this does not work, see above. ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From cstein at openjdk.java.net Wed Feb 9 11:24:24 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Wed, 9 Feb 2022 11:24:24 GMT Subject: RFR: 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" Message-ID: This PR removes the redundant and failing test-case. It also removes the test class from the problem list. Adds additional test-cases using long form option names of `jar`. ------------- Commit messages: - Only assert non-zero exit code on failure - 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" Changes: https://git.openjdk.java.net/jdk/pull/7397/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7397&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281470 Stats: 11 lines in 2 files changed: 6 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7397.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7397/head:pull/7397 PR: https://git.openjdk.java.net/jdk/pull/7397 From lancea at openjdk.java.net Wed Feb 9 11:31:10 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 9 Feb 2022 11:31:10 GMT Subject: RFR: 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 06:42:51 GMT, Christian Stein wrote: > This PR removes the redundant and failing test-case. > It also removes the test class from the problem list. > > Adds additional test-cases using long form option names of `jar`. Looks good. Thank you for addressing this hiccup! ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7397 From cstein at openjdk.java.net Wed Feb 9 11:38:15 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Wed, 9 Feb 2022 11:38:15 GMT Subject: Integrated: 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 06:42:51 GMT, Christian Stein wrote: > This PR removes the redundant and failing test-case. > It also removes the test class from the problem list. > > Adds additional test-cases using long form option names of `jar`. This pull request has now been integrated. Changeset: 8b384b98 Author: Christian Stein Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/8b384b986a0a6a972c29a2f7a4d9fd40dc479b48 Stats: 11 lines in 2 files changed: 6 ins; 4 del; 1 mod 8281470: tools/jar/CreateMissingParentDirectories.java fails with "Should have failed creating jar file" Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7397 From asemenyuk at openjdk.java.net Wed Feb 9 12:39:04 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 9 Feb 2022 12:39:04 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote: > Added ability to override description for additional launchers via "description" property. I don't quite understand how these changes affect the description of launcher executables on Windows. I'd expect changes at least in https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WindowsAppImageBuilder.java#L97. Can you elaborate, please? test/jdk/tools/jpackage/share/AddLauncherTest.java line 93: > 91: new AdditionalLauncher("Baz2") > 92: .setDefaultArguments() > 93: .addRawProperties(Map.entry("description", "Baz2 Description")) How expected description is verified in the test? ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From kcr at openjdk.java.net Wed Feb 9 12:55:06 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Feb 2022 12:55:06 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote: > Added ability to override description for additional launchers via "description" property. This will need a CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From redestad at openjdk.java.net Wed Feb 9 14:06:48 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Feb 2022 14:06:48 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives Message-ID: I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). ------------- Commit messages: - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral - Simplify changes to encodeUTF8 - Fix little-endian error caught by testing - Reduce jumps in the ascii path - Remove unused tail_mask - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives) - Add more comments, simplify tail branching in AVX512 variant - Resolve issues in the precise implementation - Add shortMixed micros, cleanups - Adjust the countPositives intrinsic to count the bytes exactly. - ... and 11 more: https://git.openjdk.java.net/jdk/compare/cab59051...2a855eb6 Changes: https://git.openjdk.java.net/jdk/pull/7231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281146 Stats: 806 lines in 24 files changed: 586 ins; 84 del; 136 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From mbalao at openjdk.java.net Wed Feb 9 15:08:08 2022 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 9 Feb 2022 15:08:08 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: <9kiPpJdrRpbgfT0fRKL_XVcQF1PZHsAsYeIkTvqUZM4=.c7df12b3-d233-45a3-90b6-28b3ed298755@github.com> On Wed, 9 Feb 2022 11:10:14 GMT, Michael Osipov wrote: >>> @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't everything protocol related a fail-fast issue? E.g., if the socket is up and running, but the LDAP message is rejected can we assume that all subsequent servers for the same resolution will reject the request as well before authentication has happened? >> >> It looks to me that it's not only a fail-fast issue because the state on the directory side might be altered by each try, as it happened in the reported case. In other words, the client might cause a denial-of-service blocking an account by trying multiple times the same incorrect authentication credentials on each resolved server. >> >> In regards to the 2nd question, I guess that we cannot assume that. But the revert is intended for failed authentication only. >> >> Is there a risk that you foresee by reverting the failed-authentication behavior back to pre-JDK-8160768? > >> > @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't everything protocol related a fail-fast issue? E.g., if the socket is up and running, but the LDAP message is rejected can we assume that all subsequent servers for the same resolution will reject the request as well before authentication has happened? >> >> It looks to me that it's not only a fail-fast issue because the state on the directory side might be altered by each try, as it happened in the reported case. In other words, the client might cause a denial-of-service blocking an account by trying multiple times the same incorrect authentication credentials on each resolved server. > > Let me add a few points for consideration from my usecases, since I don't use any password-based authentication with SASL and Active Directory only: > * `SASL EXTERNAL`: What if the certificate is rejected? Trust store is not properly populated, CRL misconfigured, etc. Will an exception also thrown here? > * `SASL GSSAPI/GSS-SPNEGO`: Dir server does not manage creds, but KDC does. I am thinking whether fail fast is reasonable. SPN not registered, next server might have. replay/out of sequence, etc. > >> In regards to the 2nd question, I guess that we cannot assume that. But the revert is intended for failed authentication only. > > But the auth is part of the LDAP message as well since the auth does not happen out of band. I would expect that any non-transport issue should fail fast. > >> Is there a risk that you foresee by reverting the failed-authentication behavior back to pre-JDK-8160768? > > Not really, I virtually never had problems, thought might need annotations when this does not work, see above. Thanks @michael-o for your input. I see the observations that you raised. In my view, we should revert to the previous behavior (as there are users currently affected by the change), and perhaps we can discuss future improvements from there, based on actual cases. @AlekseiEfimov can you please review this change? We need the formal review-approval to move forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From duke at openjdk.java.net Wed Feb 9 15:32:05 2022 From: duke at openjdk.java.net (Michael Osipov) Date: Wed, 9 Feb 2022 15:32:05 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: <9kiPpJdrRpbgfT0fRKL_XVcQF1PZHsAsYeIkTvqUZM4=.c7df12b3-d233-45a3-90b6-28b3ed298755@github.com> References: <9kiPpJdrRpbgfT0fRKL_XVcQF1PZHsAsYeIkTvqUZM4=.c7df12b3-d233-45a3-90b6-28b3ed298755@github.com> Message-ID: On Wed, 9 Feb 2022 15:05:24 GMT, Martin Balao wrote: >>> > @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't everything protocol related a fail-fast issue? E.g., if the socket is up and running, but the LDAP message is rejected can we assume that all subsequent servers for the same resolution will reject the request as well before authentication has happened? >>> >>> It looks to me that it's not only a fail-fast issue because the state on the directory side might be altered by each try, as it happened in the reported case. In other words, the client might cause a denial-of-service blocking an account by trying multiple times the same incorrect authentication credentials on each resolved server. >> >> Let me add a few points for consideration from my usecases, since I don't use any password-based authentication with SASL and Active Directory only: >> * `SASL EXTERNAL`: What if the certificate is rejected? Trust store is not properly populated, CRL misconfigured, etc. Will an exception also thrown here? >> * `SASL GSSAPI/GSS-SPNEGO`: Dir server does not manage creds, but KDC does. I am thinking whether fail fast is reasonable. SPN not registered, next server might have. replay/out of sequence, etc. >> >>> In regards to the 2nd question, I guess that we cannot assume that. But the revert is intended for failed authentication only. >> >> But the auth is part of the LDAP message as well since the auth does not happen out of band. I would expect that any non-transport issue should fail fast. >> >>> Is there a risk that you foresee by reverting the failed-authentication behavior back to pre-JDK-8160768? >> >> Not really, I virtually never had problems, thought might need annotations when this does not work, see above. > > Thanks @michael-o for your input. I see the observations that you raised. In my view, we should revert to the previous behavior (as there are users currently affected by the change), and perhaps we can discuss future improvements from there, based on actual cases. > > @AlekseiEfimov can you please review this change? We need the formal review-approval to move forward. @martinuy Agree ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From dfuchs at openjdk.java.net Wed Feb 9 15:43:18 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 9 Feb 2022 15:43:18 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values). > > No test regressions observed in jdk/com/sun/jndi/ldap. > > -- > [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137 Is the new behavior something that could be tested with a new non regression test? See existing tests in `test/jdk/com/sun/jndi/ldap` ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From aefimov at openjdk.java.net Wed Feb 9 17:26:11 2022 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 9 Feb 2022 17:26:11 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values). > > No test regressions observed in jdk/com/sun/jndi/ldap. > > -- > [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137 Hi Martin, The source changes looks good to me. In case you have an LDAP server that can be used to reproduce this problem then maybe you could try to create a test that uses classes from LDAP test library (`LDAPServer`,`LDAPTestUtils`)? In a nutshell, it could be done by following these steps: - Create a regression tests which uses LDAPServer/LDAPTestUtils similar to tests available in `test/jdk/com/sun/jndi/ldap/blits/AddTests` and `test/jdk/javax/naming/module/src/test/test` - Add `-trace` flag (see test/jdk/com/sun/jndi/ldap/lib/LDAPTestUtils.java for details) as an argument to the test app. When this argument is passed to LDAPTestUtils.initEnv (see first snippet below) '.ldap' trace file is generated by a framework. This is where the real LDAP server is required. - Once `.ldap` trace file is collected use LDAPTestUtils.initEnv and a ServerSocket to create a test server that will replay the collected trace file (see second snippet below). Snippet 1: How trace file can be collected: /* * @test * @library /test/lib ../../lib * @build LDAPServer LDAPTestUtils /javax/naming/module/src/test/test/ * @run main/othervm TraceExampleTest -trace */ public static void collectTrace(String [] args) throws Exception { Hashtable env; // initialize test env = LDAPTestUtils.initEnv(null, "ldap://127.0.0.1:1389", TraceExampleTest.class.getName(), args, true); DirContext ctx = null; // connect to server ctx = new InitialDirContext(env); } Snippet 2: How trace file can be used (note that the trace file name should match the test class name in this example) it can be used to create an instance of the LDAPServer: /* * @test * @library /test/lib ../../lib * @build LDAPServer LDAPTestUtils /javax/naming/module/src/test/test/ * @run main/othervm TraceExampleTest */ public static void runWithTrace(String [] args) throws Exception { // Create unbound server socket ServerSocket serverSocket = new ServerSocket(); // Bind it to the loopback address SocketAddress sockAddr = new InetSocketAddress( InetAddress.getLoopbackAddress(), 0); serverSocket.bind(sockAddr); // Construct the provider URL for LDAPTestUtils String providerURL = URIBuilder.newBuilder() .scheme("ldap") .loopback() .port(serverSocket.getLocalPort()) .buildUnchecked().toString(); Hashtable env; // initialize test env = LDAPTestUtils.initEnv(serverSocket, providerURL, TraceExampleTest.class.getName(), args, true); DirContext ctx = null; // connect to the test LDAP server ctx = new InitialDirContext(env); } ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From plevart at openjdk.java.net Wed Feb 9 17:51:10 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 9 Feb 2022 17:51:10 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v3] In-Reply-To: <0OkhkBgQ-Z47cSwsYJ2dRWR6ubLQcG6gEydgthQJQdg=.bdc36237-2bcc-489d-bc84-a0b275f3491b@github.com> References: <0OkhkBgQ-Z47cSwsYJ2dRWR6ubLQcG6gEydgthQJQdg=.bdc36237-2bcc-489d-bc84-a0b275f3491b@github.com> Message-ID: On Sat, 22 Jan 2022 00:00:18 GMT, liach wrote: >> 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 four additional commits since the last revision: >> >> - Merge branch 'master' into 8261407-reflectionfactory >> - Merge branch '8261407-reflectionfactory' >> - Just use volatile directly to ensure read order >> - 8261407: ReflectionFactory.checkInitted() is not thread-safe > > The addition of `@Stable` seems safe. Here's a comparison for the `checkInitted` method under current patch (volatile) and the stable annotation (stable): https://gist.github.com/b6a1090872e686f31595bcd778893e82 > Under this test setup: https://gist.github.com/96018d7dcaa07763d1c205017a9bd99f > Can any professional review the comparison above, as I am not as acquainted to C assembly and VM internals to confirm there is indeed no unintended side effects? Hi @liach, Your patch seems OK, but is otherwise fixing a not well designed initialization process that has seen many updates in its lifetime. The code is not idiomatic, relies on side-effects triggered from arbitrary code paths (checkInited) which makes it hard to understand and maintain correctly. So why not making the code more "functional-oriented" and limit side-effects to a single well-understood place. For example, like this: https://github.com/plevart/jdk/commit/b62c2ce9673e40b5b051ba5962c6bfa34e172a87 ...using this approach, the initialization is guaranteed to happen when any of the fields in Config class needs to be accessed from wherever it may be without making sure that checkInitted() is called at appropriate time. This is, IMHO, more robust than current approach and less prone to bugs. And you get guaranteed visibility of final fields in Config as a bonus without relying on ordering of writes/reads with volatile boolean initted.. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From aturbanov at openjdk.java.net Wed Feb 9 18:29:13 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 9 Feb 2022 18:29:13 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v6] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: <4PdhPOXLnyVI8oc7h_wiqj5EHwF0P66mVGC29v8DJ0I=.91eacfc6-26a1-4b3b-8638-bac791c66cc1@github.com> On Tue, 8 Feb 2022 22:11:34 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - 4511638: Double.toString(double) sometimes produces incorrect results > > Adapted hashes in ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > > Enhanced intervals in MathUtils. > Updated references to Schubfach v4. > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > > Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. > - 4511638: Double.toString(double) sometimes produces incorrect results > > Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > - 4511638: Double.toString(double) sometimes produces incorrect results > > Refactored test classes to better match OpenJDK conventions. > Added tests recommended by Guy Steele and Paul Zimmermann. > - Changed MAX_CHARS to static > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/92f4f40d...c29dff76 Marked as reviewed by aturbanov (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From mbalao at openjdk.java.net Wed Feb 9 18:53:12 2022 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 9 Feb 2022 18:53:12 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values). > > No test regressions observed in jdk/com/sun/jndi/ldap. > > -- > [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137 Unfortunately I don't have access to the environment where this problem reproduces and will be difficult/impossible for me to get a real trace from there. What I can say, though, is that the fail-fast authentication behavior previous to the changes in JDK-8160768 was working fine in such environment. Besides that, we didn't have any users reporting issues regarding authentication. The change to revert to the previous behavior is, in my view, trivial. I can try to build a whole new environment that reproduces this problem or see if it's feasible to mock something, but before getting into that I need to understand what the concerns or motivation for that are. This would require more time than originally planned and might postpone this for a while. Martin.- ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From almatvee at openjdk.java.net Wed Feb 9 18:57:06 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Feb 2022 18:57:06 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description In-Reply-To: References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: <7hwhEZvd149mKT-zp7EdWTXjgi2xO1oARmbYdwY7zgc=.9e9c8940-f5ce-4cb8-95c8-843b975c5097@github.com> On Wed, 9 Feb 2022 12:35:59 GMT, Alexey Semenyuk wrote: >> Added ability to override description for additional launchers via "description" property. > > test/jdk/tools/jpackage/share/AddLauncherTest.java line 93: > >> 91: new AdditionalLauncher("Baz2") >> 92: .setDefaultArguments() >> 93: .addRawProperties(Map.entry("description", "Baz2 Description")) > > How expected description is verified in the test? I do not think that we have ability to check description on executable files. I added it for manual verification. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From almatvee at openjdk.java.net Wed Feb 9 19:04:09 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 9 Feb 2022 19:04:09 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote: > Added ability to override description for additional launchers via "description" property. AddLauncherArguments.java class reads parameters for additional launcher from property file and if this class contains particular property we will prefer it when generating additional launchers. Thus I do not think that anything else needs to be change. I tested it and it works fine. Testing was done manually. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From dfuchs at openjdk.java.net Wed Feb 9 19:16:14 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 9 Feb 2022 19:16:14 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values). > > No test regressions observed in jdk/com/sun/jndi/ldap. > > -- > [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137 The concerns are two folds: - without a regression test, you have to trust that the source changes actually work, and there's typically no verification possible - without a regression test, the next refactoring change in this area two years from now could undo the fix and nobody would notice I agree that the changes seem safe and given the history seem to be doing what the fix/PR says they do, so I'd be more concerned with the latter. So if it's practical to add a test I'd rather have one. If the behavior is too hard to test - then the appropriate keyword would be `noreg-hard` rather than `noreg-trivial` (I am not sure trivial actually qualifies here - I can see no obvious flaw but I'm not sure we can say that there are obviously no flaws - or that a flaw would become obvious to future maintainers if that code was refactored in a way that removed the fix). ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From cstein at openjdk.java.net Wed Feb 9 19:18:38 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Wed, 9 Feb 2022 19:18:38 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used Message-ID: A number of modules declare that the "provide" ToolProvider. These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. ------------- Commit messages: - Separate service type and description text into distinct blocks - 8280825: Modules that "provide" ToolProvider should document the name that can be used Changes: https://git.openjdk.java.net/jdk/pull/7406/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7406&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280825 Stats: 26 lines in 6 files changed: 21 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7406.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7406/head:pull/7406 PR: https://git.openjdk.java.net/jdk/pull/7406 From jjg at openjdk.java.net Wed Feb 9 19:18:39 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 9 Feb 2022 19:18:39 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote: > A number of modules declare that the "provide" ToolProvider. > > These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. Minor format suggestion: add a newline after the service name, to start the description on its own line, as in: @provides This form would extend well to any modules that provide the service in different ways ... i.e. with different names for `TP.findFirst` to obtain different instances. ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From asemenyuk at openjdk.java.net Wed Feb 9 19:34:12 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 9 Feb 2022 19:34:12 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description In-Reply-To: <7hwhEZvd149mKT-zp7EdWTXjgi2xO1oARmbYdwY7zgc=.9e9c8940-f5ce-4cb8-95c8-843b975c5097@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> <7hwhEZvd149mKT-zp7EdWTXjgi2xO1oARmbYdwY7zgc=.9e9c8940-f5ce-4cb8-95c8-843b975c5097@github.com> Message-ID: <-Iv1W6KKHsYem9FdcmJbuGCAe59bPfHNpO0GacoplKs=.ebbdb074-ac2d-4760-a919-b671f2c0e89b@github.com> On Wed, 9 Feb 2022 18:53:35 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/share/AddLauncherTest.java line 93: >> >>> 91: new AdditionalLauncher("Baz2") >>> 92: .setDefaultArguments() >>> 93: .addRawProperties(Map.entry("description", "Baz2 Description")) >> >> How expected description is verified in the test? > > I do not think that we have ability to check description on executable files. I added it for manual verification. Powershell can be used to extract the description from an executable. E.g.: $ powershell -NoLogo -NoProfile -Command "(Get-Item build\\windows-x64\\images\\jdk\\bin\\java.exe).VersionInfo | select FileDescription" FileDescription --------------- Java(TM) Platform SE binary You can create jdk.jpackage.test.AdditionalLauncher.verifyDescription() function that will call this script and call this function from jdk.jpackage.test.AdditionalLauncher.verify(). ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From lancea at openjdk.java.net Wed Feb 9 19:34:13 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 9 Feb 2022 19:34:13 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote: > A number of modules declare that the "provide" ToolProvider. > > These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From duke at openjdk.java.net Wed Feb 9 19:42:04 2022 From: duke at openjdk.java.net (liach) Date: Wed, 9 Feb 2022 19:42:04 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v4] In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 00:05:49 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Include the stable annotation may i just apply your patch? i am tempted to put the default config instance into the config class to delay (or avoid) loading if no reflection-based invocations happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From asemenyuk at openjdk.java.net Wed Feb 9 19:48:08 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 9 Feb 2022 19:48:08 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote: > Added ability to override description for additional launchers via "description" property. Unfortunately, manual testing adds zero value to automated test runs. This feature can be covered with automated tests so it should be. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From mbalao at openjdk.java.net Wed Feb 9 19:50:11 2022 From: mbalao at openjdk.java.net (Martin Balao) Date: Wed, 9 Feb 2022 19:50:11 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 19:12:34 GMT, Daniel Fuchs wrote: > The concerns are two folds: > > * without a regression test, you have to trust that the source changes actually work, and there's typically no verification possible > * without a regression test, the next refactoring change in this area two years from now could undo the fix and nobody would notice > Thanks, that was what I initially thought but wanted to check if I was missing something else given the previous discussion. I should be able to generate a build for the user and ask him to test in his real environment. As for the other concern, I'll evaluate options and let you know. ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From jjg at openjdk.java.net Wed Feb 9 20:24:10 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 9 Feb 2022 20:24:10 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: <6kBOt7R1nPvpcwNdZ5FmmB9ZbhwOw2daNlg_kyf1JSQ=.31dc4ce2-23f5-401e-ab6a-0dab5e7d2c23@github.com> On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote: > A number of modules declare that the "provide" ToolProvider. > > These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. Would it be more pedantically accurate to talk about getting an instance of the _tool provider_ (not just _tool_)? ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7406 From cstein at openjdk.java.net Wed Feb 9 20:35:10 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Wed, 9 Feb 2022 20:35:10 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote: > A number of modules declare that the "provide" ToolProvider. > > These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. > Would it be more pedantically accurate to talk about getting an instance of the tool provider (not just tool)? Yes. That would be more correct. My wording was aligned to the one used in the main description block, which also talks about "tool(s)". For example: *

Instances of the tools can be obtained by calling * {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst} * or the {@linkplain java.util.ServiceLoader service loader} with the name * {@code "javac"}. _Here, it should read "Instances of the tool can be..." and not "Instances of the tools can be..." - right? As there's only a single one provided by this module._ ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From alanb at openjdk.java.net Wed Feb 9 20:35:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 9 Feb 2022 20:35:10 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote: > A number of modules declare that the "provide" ToolProvider. > > These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. src/jdk.jartool/share/classes/module-info.java line 45: > 43: * Pass {@code "jar"} as the name to > 44: * {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst} > 45: * in order to obtain an instance of the tool. I'm not sure about the wording. It might be better to say that it provides a tool named "jar". Invoke findFirst("jar") to create an instance of this tool. ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From mchung at openjdk.java.net Wed Feb 9 20:36:17 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Feb 2022 20:36:17 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v4] In-Reply-To: References: Message-ID: On Sat, 22 Jan 2022 00:05:49 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Include the stable annotation > [plevart at b62c2ce](https://github.com/plevart/jdk/commit/b62c2ce9673e40b5b051ba5962c6bfa34e172a87) > ...using this approach, the initialization is guaranteed to happen when any of the fields in Config class needs to be accessed from wherever it may be without making sure that checkInitted() is called at appropriate time. This is, IMHO, more robust than current approach and less prone to bugs. And you get guaranteed visibility of final fields in Config as a bonus without relying on ordering of writes/reads with volatile boolean initted.. I like this approach, more reliable and cleaner. Nit: instead of calling `config().noInflation`, it can just call the static `noInflation()` method. Similar for other fields. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From lancea at openjdk.java.net Wed Feb 9 21:19:05 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 9 Feb 2022 21:19:05 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com> References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com> Message-ID: On Tue, 8 Feb 2022 18:06:04 GMT, Lance Andersen wrote: >>> ze can't be null here. >> >> Actually it can be: Consider the following: >> >> >> try (JarFile jf = new JarFile(SIGNED_VALID_ENTRY_NAME_JAR.toFile(), true)) { >> var ze = new ZipEntry("org/gotham/Batcave.class"); >> var ex= expectThrows(ZipException.class, >> () -> jf.getInputStream(ze) ); >> // Validate that we receive the expected message from >> // JarFile::verifiableEntry when ZipEntry::getName returns null >> assertTrue( ex != null && ex.getMessage().equals("Error: ZipEntry should not be null!")); >> } >> >> >> The above code does generate the error. > >> Nit, add space after "if" > > will fix So a bit more on this. If the ZipEntry passed to `ZipFile::getInputStream` does not represent an entry within the current Zip/Jar, `ZipFile::getInputStream` will return a null for the InputStream: @Test public static void ZipFileZipEntryNullGetInputStreamTest() throws Exception { try (ZipFile zf = new ZipFile(VALID_ENTRY_NAME_JAR.toFile())) { var ze = new ZipEntry("org/gotham/Batcave.class"); var is = zf.getInputStream(ze); // As the ZipEntry cannot be found, the returned InpuStream is null assertNull(is); } } JarFile::getInputStream will also return null when the jar is not signed or we are not verifying the jar: @Test public static void JarFileZipEntryNullGetInputStreamTest() throws Exception { try (JarFile jf = new JarFile(VALID_ENTRY_NAME_JAR.toFile())) { var ze = new ZipEntry("org/gotham/Batcave.class"); var is = jf.getInputStream(ze); // As the ZipEntry cannot be found, the returned InpuStream is null assertNull(is); } try (JarFile jf = new JarFile(SIGNED_INVALID_ENTRY_NAME_JAR.toFile(), false)) { var ze = new ZipEntry("org/gotham/Batcave.class"); var is = jf.getInputStream(ze); // As the ZipEntry cannot be found, the returned InpuStream is null assertNull(is); } } This behavior dates back to at least JDK 1.3 So I think we should return null instead of throwing an Exception when the resulting ZipEntry is null that is returned from the call to`JarFile::getJarEntry` (which calls `ZipFile::getEntry`) for consistency with ZipFile and when the Jar is not signed or not verified. I also noticed that `ZipFile::getInputStream` and `JarFile::getInputStream` do not mention that a null will be returned if the specified ZipEntry is not found within the Jar/Zip. I guess I could open a CSR as part of this fix to clarify this 20+ year behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From psandoz at openjdk.java.net Wed Feb 9 22:09:51 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Feb 2022 22:09:51 GMT Subject: RFR: 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors Message-ID: <3pdqZiPGR8RhbesW_Ffz-2N5HP8tCmKrtV71-A2NecU=.68633237-3317-4703-b1bb-dee21e3a85d6@github.com> ?ArgumentExcept on zero vectors This PR fixes issues for reduction using FIRST_NONZERO and add tests. The testing infrastructure is generalized to reduction functions and tests for min/max reductions are updated to use that. ------------- Commit messages: - 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors Changes: https://git.openjdk.java.net/jdk/pull/7410/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7410&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281294 Stats: 3725 lines in 54 files changed: 2742 ins; 407 del; 576 mod Patch: https://git.openjdk.java.net/jdk/pull/7410.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7410/head:pull/7410 PR: https://git.openjdk.java.net/jdk/pull/7410 From stuart.marks at oracle.com Wed Feb 9 22:32:11 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 9 Feb 2022 14:32:11 -0800 Subject: [External] : Re: HashMap.putAll can cause redundant space waste In-Reply-To: References: <0dd3c438-2dca-f0dd-cab0-842a9f06ee13@oracle.com> Message-ID: On 2/8/22 5:51 PM, Xeno Amess wrote: > I agree that it would > be preferable for the expression to be something like this: > > ? ? ?(int) Math.ceil(expected / 0.75) > > Agree. > > If we don't add a Java SE utility like "newHashMapWithExpectedSize", fallbacks would > be to introduce an internal JDK utility method that is called from various places, > or just to update the individual call sites to use the more precise calculation. > > > Both seem?acceptable. > So what should I do next? OK. I'd say the first thing is to file a bug at bugs.java.com. Include the test cases from your message at the start of the thread. I think they illustrate the issue pretty nicely. At some point this will show up in the main bug database, though with a different number from the one it was initially assigned. Then, make a fork of the OpenJDK repo on GitHub and start a pull request. I'd suggest initially just changing the internal computations of HashMap et. al. Adding a new API and updating all the callers is a bigger deal and is probably better handled separately. In the PR, include the reference number from the bug you filed. This is helpful, even though we know it will be different from the eventual bug ID. A bot will wake up and tell you to sign the OCA if you haven't already done so. This will all take a little time. After that, I can help make sure the PR is linked up properly to the bug report, and then we can go from there. Further info about the development process is in the Developers' Guide: http://openjdk.java.net/guide/ Thanks, s'marks From psandoz at openjdk.java.net Wed Feb 9 22:46:14 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Feb 2022 22:46:14 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v10] In-Reply-To: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> References: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> Message-ID: On Thu, 3 Feb 2022 05:29:51 GMT, kabutz wrote: >> BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. >> >> The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. >> >> We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. >> >> Some benchmark results, run on my 1-6-2 server: >> >> >> Benchmark (n) Mode Cnt Score Error Units >> BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op >> BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op >> BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op >> BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op >> BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op >> BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op >> >> >> We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment to include information about performance Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From psandoz at openjdk.java.net Wed Feb 9 22:46:14 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Feb 2022 22:46:14 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v10] In-Reply-To: <5M4d9wsxupT34r9kSkXgRDxdi3gLo9IqzGJtTWmM3I4=.f841d343-eb9e-49fb-8f57-efd911a0bb2d@github.com> References: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> <5M4d9wsxupT34r9kSkXgRDxdi3gLo9IqzGJtTWmM3I4=.f841d343-eb9e-49fb-8f57-efd911a0bb2d@github.com> Message-ID: On Thu, 3 Feb 2022 06:35:47 GMT, Joe Darcy wrote: >> kabutz has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated comment to include information about performance > > src/java.base/share/classes/java/math/BigInteger.java line 1603: > >> 1601: * parallel multiplication algorithm will use more CPU resources >> 1602: * to compute the result faster, with no increase in memory >> 1603: * consumption. > > The implNote should cover a space of possible parallel multiply implementations so it doesn't have to be updated as often as the implementation is tuned or adjusted. So I'd prefer to have a statement like "may use more memory" even if the current implementation doesn't actually use more memory. If there are any "contraindications" on when to use the method, they could be listed here too. @kabutz I approved, but can you address Joe's comment, then i will update the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From jrose at openjdk.java.net Wed Feb 9 22:50:07 2022 From: jrose at openjdk.java.net (John R Rose) Date: Wed, 9 Feb 2022 22:50:07 GMT Subject: RFR: 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors In-Reply-To: <3pdqZiPGR8RhbesW_Ffz-2N5HP8tCmKrtV71-A2NecU=.68633237-3317-4703-b1bb-dee21e3a85d6@github.com> References: <3pdqZiPGR8RhbesW_Ffz-2N5HP8tCmKrtV71-A2NecU=.68633237-3317-4703-b1bb-dee21e3a85d6@github.com> Message-ID: On Wed, 9 Feb 2022 21:36:01 GMT, Paul Sandoz wrote: > ?ArgumentExcept on zero vectors > > This PR fixes issues for reduction using FIRST_NONZERO and adds tests. The testing infrastructure is generalized to reduction functions and tests for min/max reductions are updated to use that. Wow good catch. A single vector operation is almost never a whole algorithmic step, but rather a part of a larger one, across an array, for which the vector is a "window" viewing part of the the array, either VLEN elements, or (in the case of masking) a lesser number. Put another way, doing a task on VLENGTH>2 elements should always be refactorable as a pair of similar tasks on a pair of shorter VLENGTH/2 vectors and vice versa. Put yet another way, vector operations should support grouping and ungrouping transformations. In the case of reductions, a longer reduction of the form `R[op](a,b?,c,d?)` should always decompose into shorter ones, as `R[op](a,b?) op R[op](c,d?)`, and vice versa. Suppose VLENGTH=8; a reduction over a 13-element array should always be vectorizable as an 8-way reduction followed by a masked reduction of the remainder, followed by a scalar reduction. That goes for `FIRST_NONZERO` as well as (most) other ops. (Some ops like float add are only approximately associative.) You can consider this a public service announcement reminding us why throwing on an edge condition from a vector operation is probably always wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/7410 From psandoz at openjdk.java.net Wed Feb 9 22:52:09 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Feb 2022 22:52:09 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v10] In-Reply-To: <1kij84fM01EmZ3tQ8aQhx-bnnnD-C2z8mo9-i0E7pOQ=.0e7678c3-2e7d-48d4-a432-bfed1c07ebda@github.com> References: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> <1kij84fM01EmZ3tQ8aQhx-bnnnD-C2z8mo9-i0E7pOQ=.0e7678c3-2e7d-48d4-a432-bfed1c07ebda@github.com> Message-ID: On Thu, 3 Feb 2022 05:33:52 GMT, kabutz wrote: > A question about wording of the @implNote. In multiply() they say: "An implementation may offer better algorithmic ...", but we changed this to "This implementation may offer better algorithmic ..." I've kept it as "This implementation may ...", but what is the better way of writing such implementation notes? I usually refer to "This implementation or this method" mostly out of habit of writing a bunch of these notes in `java.util`. I am fine with either approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From jrose at openjdk.java.net Wed Feb 9 22:57:05 2022 From: jrose at openjdk.java.net (John R Rose) Date: Wed, 9 Feb 2022 22:57:05 GMT Subject: RFR: 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors In-Reply-To: <3pdqZiPGR8RhbesW_Ffz-2N5HP8tCmKrtV71-A2NecU=.68633237-3317-4703-b1bb-dee21e3a85d6@github.com> References: <3pdqZiPGR8RhbesW_Ffz-2N5HP8tCmKrtV71-A2NecU=.68633237-3317-4703-b1bb-dee21e3a85d6@github.com> Message-ID: <5N2n4FMudE3bCIm68ugvIfOtVEkHLZcC95qXbPOu-bA=.cf2f26c6-77b6-42a0-9ce9-3737d7771972@github.com> On Wed, 9 Feb 2022 21:36:01 GMT, Paul Sandoz wrote: > ?ArgumentExcept on zero vectors > > This PR fixes issues for reduction using FIRST_NONZERO and adds tests. The testing infrastructure is generalized to reduction functions and tests for min/max reductions are updated to use that. Marked as reviewed by jrose (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7410 From sviswanathan at openjdk.java.net Wed Feb 9 23:27:07 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 9 Feb 2022 23:27:07 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts In-Reply-To: References: Message-ID: On Sat, 5 Feb 2022 15:34:08 GMT, Quan Anh Mai wrote: > Hi, > > This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. > > Thank you very much. src/hotspot/cpu/x86/assembler_x86.cpp line 4782: > 4780: vector_len == AVX_256bit? VM_Version::supports_avx2() : > 4781: vector_len == AVX_512bit? VM_Version::supports_evex() : 0, " "); > 4782: InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true); legacy_mode should be false here instead of _legacy_mode_bw. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From jjg at openjdk.java.net Thu Feb 10 02:23:11 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Feb 2022 02:23:11 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 20:33:02 GMT, Alan Bateman wrote: >> A number of modules declare that the "provide" ToolProvider. >> >> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. > > src/jdk.jartool/share/classes/module-info.java line 45: > >> 43: * Pass {@code "jar"} as the name to >> 44: * {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst} >> 45: * in order to obtain an instance of the tool. > > I'm not sure about the wording. It might be better to say that it provides a tool named "jar". Invoke findFirst("jar") to create an instance of this tool. What is "it" in "it provides..." ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From duke at openjdk.java.net Thu Feb 10 02:24:43 2022 From: duke at openjdk.java.net (liach) Date: Thu, 10 Feb 2022 02:24:43 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5] In-Reply-To: References: Message-ID: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. > > This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) 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 seven additional commits since the last revision: - use peter's model of separate data object - Merge branch 'master' into 8261407-reflectionfactory - Include the stable annotation - Merge branch 'master' into 8261407-reflectionfactory - Merge branch '8261407-reflectionfactory' - Just use volatile directly to ensure read order - 8261407: ReflectionFactory.checkInitted() is not thread-safe ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6889/files - new: https://git.openjdk.java.net/jdk/pull/6889/files/f237cf50..12086557 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=03-04 Stats: 18301 lines in 782 files changed: 12300 ins; 3056 del; 2945 mod Patch: https://git.openjdk.java.net/jdk/pull/6889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889 PR: https://git.openjdk.java.net/jdk/pull/6889 From cstein at openjdk.java.net Thu Feb 10 03:08:10 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Thu, 10 Feb 2022 03:08:10 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 02:19:36 GMT, Jonathan Gibbons wrote: >> src/jdk.jartool/share/classes/module-info.java line 45: >> >>> 43: * Pass {@code "jar"} as the name to >>> 44: * {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst} >>> 45: * in order to obtain an instance of the tool. >> >> I'm not sure about the wording. It might be better to say that it provides a tool named "jar". Invoke findFirst("jar") to create an instance of this tool. > > What is "it" in "it provides..." ? Perhaps like this? /** * ... * @provides java.util.spi.ToolProvider * Module {@code jdk.jartool} provides a tool named {@code "jar"}. * Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")} * to create an instance of this tool. * ... */ ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From tvaleev at openjdk.java.net Thu Feb 10 03:22:42 2022 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Thu, 10 Feb 2022 03:22:42 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v4] In-Reply-To: References: Message-ID: > See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. > > No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. > > I added a simple test using an artificial collector to ensure that at least two non-empty parts are created when parallelizing Stream.iterate source. More testing ideas are welcome. Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: Benchmark to demonstrate the patch usefulness ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7279/files - new: https://git.openjdk.java.net/jdk/pull/7279/files/726e73e3..fbe8a704 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=02-03 Stats: 80 lines in 1 file changed: 80 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7279/head:pull/7279 PR: https://git.openjdk.java.net/jdk/pull/7279 From tvaleev at openjdk.java.net Thu Feb 10 04:30:34 2022 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Thu, 10 Feb 2022 04:30:34 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v5] In-Reply-To: References: Message-ID: > See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. > > No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. > > I added a simple test using an artificial collector to ensure that at least two non-empty parts are created when parallelizing Stream.iterate source. More testing ideas are welcome. Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year - Cosmetic fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7279/files - new: https://git.openjdk.java.net/jdk/pull/7279/files/fbe8a704..5306e212 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7279&range=03-04 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7279/head:pull/7279 PR: https://git.openjdk.java.net/jdk/pull/7279 From tvaleev at openjdk.java.net Thu Feb 10 04:30:36 2022 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Thu, 10 Feb 2022 04:30:36 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v4] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 03:22:42 GMT, Tagir F. Valeev wrote: >> See the bug description for details. >> >> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. >> >> No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. >> >> I added a simple test using an artificial collector to ensure that at least two non-empty parts are created when parallelizing Stream.iterate source. More testing ideas are welcome. > > Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: > > Benchmark to demonstrate the patch usefulness I added a microbenchmark to demonstrate the speed improvement achievable by this patch. For demonstration, I used `Pattern.splitAsStream` source (though as listed in JDK-8280915, many other standard sources are also affected). For downstream operation I selected `BigInteger.pow(1000)` which is moderately CPU-intensive (takes ~10us on my machine for input numbers within 1000..2000). The benchmarking results are as follows (my machine has 8 cores). Here's non-patched version: Benchmark (size) Mode Cnt Score Error Units sumOf1000thPowers 10 avgt 30 100.367 ? 0.793 us/op sumOf1000thPowers 100 avgt 30 963.857 ? 6.252 us/op sumOf1000thPowers 1000 avgt 30 10012.923 ? 81.091 us/op sumOf1000thPowers 10000 avgt 30 99546.370 ? 625.105 us/op sumOf1000thPowersParallel 10 avgt 30 104.561 ? 1.118 us/op sumOf1000thPowersParallel 100 avgt 30 995.400 ? 26.116 us/op sumOf1000thPowersParallel 1000 avgt 30 9969.296 ? 85.166 us/op sumOf1000thPowersParallel 10000 avgt 30 55856.516 ? 2315.530 us/op We observe that the results depend on the input size linearly for sequential run, which is quite expected. Parallel doesn't help at all for size = 10, 100, and 1000, which validates my claim that these spliterators cannot split at all for sizes <= 1024. For size = 10000, parallel version starts performing somewhat better (1.78x), though it's not nearly close to the available machine parallelism. Here's patched version: Benchmark (size) Mode Cnt Score Error Units sumOf1000thPowers 10 avgt 30 101.380 ? 0.961 us/op sumOf1000thPowers 100 avgt 30 970.843 ? 8.360 us/op sumOf1000thPowers 1000 avgt 30 9837.397 ? 93.656 us/op sumOf1000thPowers 10000 avgt 30 97741.823 ? 1276.116 us/op sumOf1000thPowersParallel 10 avgt 30 41.597 ? 0.910 us/op sumOf1000thPowersParallel 100 avgt 30 189.735 ? 1.911 us/op sumOf1000thPowersParallel 1000 avgt 30 1776.337 ? 31.034 us/op sumOf1000thPowersParallel 10000 avgt 30 17685.723 ? 127.846 us/op We observe no regression for sequential run and drastic improvement for parallel. Even for size = 10, we see 2.46x speedup and 41 us total time. For bigger sizes, we see 5.11x..5.54x speedup. Please review my patch. I'll be happy to discuss any concerns about this optimization you may have. Thanks in advance! ------------- PR: https://git.openjdk.java.net/jdk/pull/7279 From darcy at openjdk.java.net Thu Feb 10 05:57:21 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Feb 2022 05:57:21 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input Message-ID: Two changes to the toString output for annotations to give better source fidelity: 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) Various existing regression tests are updated to accommodate the changes. Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8281568 ------------- Commit messages: - JDK-8281462: Annotation toString output for enum not reusable for source input Changes: https://git.openjdk.java.net/jdk/pull/7418/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7418&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281462 Stats: 76 lines in 8 files changed: 29 ins; 0 del; 47 mod Patch: https://git.openjdk.java.net/jdk/pull/7418.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7418/head:pull/7418 PR: https://git.openjdk.java.net/jdk/pull/7418 From duke at openjdk.java.net Thu Feb 10 07:07:45 2022 From: duke at openjdk.java.net (kabutz) Date: Thu, 10 Feb 2022 07:07:45 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v11] In-Reply-To: References: Message-ID: > BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. > > The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. > > We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. > > Some benchmark results, run on my 1-6-2 server: > > > Benchmark (n) Mode Cnt Score Error Units > BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op > BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op > BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op > BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op > BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op > BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op > > > We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. kabutz has updated the pull request incrementally with one additional commit since the last revision: Made comment more general to cover other implementations of parallelMultiply() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6409/files - new: https://git.openjdk.java.net/jdk/pull/6409/files/ef74878e..2eec2e9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6409&range=09-10 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6409/head:pull/6409 PR: https://git.openjdk.java.net/jdk/pull/6409 From duke at openjdk.java.net Thu Feb 10 07:07:47 2022 From: duke at openjdk.java.net (kabutz) Date: Thu, 10 Feb 2022 07:07:47 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v10] In-Reply-To: References: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> <1kij84fM01EmZ3tQ8aQhx-bnnnD-C2z8mo9-i0E7pOQ=.0e7678c3-2e7d-48d4-a432-bfed1c07ebda@github.com> Message-ID: On Wed, 9 Feb 2022 22:48:57 GMT, Paul Sandoz wrote: > > A question about wording of the @implNote. In multiply() they say: "An implementation may offer better algorithmic ...", but we changed this to "This implementation may offer better algorithmic ..." I've kept it as "This implementation may ...", but what is the better way of writing such implementation notes? > > I usually refer to "This implementation or this method" mostly out of habit of writing a bunch of these notes in `java.util`. I am fine with either approach. That makes sense - thank you so much for your patience :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From duke at openjdk.java.net Thu Feb 10 07:07:48 2022 From: duke at openjdk.java.net (kabutz) Date: Thu, 10 Feb 2022 07:07:48 GMT Subject: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v10] In-Reply-To: References: <9X1BwDVqOAktntRPYdg839VvFRcHBWMFuAv3e3vEf9o=.9912442c-8a4c-47f0-a936-7f89ffda4a8d@github.com> <5M4d9wsxupT34r9kSkXgRDxdi3gLo9IqzGJtTWmM3I4=.f841d343-eb9e-49fb-8f57-efd911a0bb2d@github.com> Message-ID: On Wed, 9 Feb 2022 22:42:50 GMT, Paul Sandoz wrote: >> src/java.base/share/classes/java/math/BigInteger.java line 1603: >> >>> 1601: * parallel multiplication algorithm will use more CPU resources >>> 1602: * to compute the result faster, with no increase in memory >>> 1603: * consumption. >> >> The implNote should cover a space of possible parallel multiply implementations so it doesn't have to be updated as often as the implementation is tuned or adjusted. So I'd prefer to have a statement like "may use more memory" even if the current implementation doesn't actually use more memory. If there are any "contraindications" on when to use the method, they could be listed here too. > > @kabutz I approved, but can you address Joe's comment, then i will update the CSR. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From duke at openjdk.java.net Thu Feb 10 07:13:06 2022 From: duke at openjdk.java.net (kabutz) Date: Thu, 10 Feb 2022 07:13:06 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() Still wondering whether this can ever join the JDK ------------- PR: https://git.openjdk.java.net/jdk/pull/6275 From forax at univ-mlv.fr Thu Feb 10 11:14:51 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 10 Feb 2022 12:14:51 +0100 (CET) Subject: Sequenced Collections Message-ID: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> I've read the draft of the JEP on sequenced collection, and i think the proposed design can be improved. https://bugs.openjdk.java.net/browse/JDK-8280836 I agree with the motivation, there is a need for an API to consider the element of a list, a sorted set and a linked hash set as an ordered sequence of elements with a simple way to access/add/remove the first/last element and also reverse the elements as view. I disagree about the conclusion that we need to introduce 4 new interfaces for that matter. Here are the reasons 1/ Usually an ordered collection is called a list. Introducing an interface SequencedCollection for something which is usually called a list will cause more harm than good. Or maybe we should rename LISP to SEQP :) 2/ There is already an interface List in Java, that represents an ordered sequence of elements, with LinkedList being the name of the the double linked list implementation. You can argue that there is a slight difference between the semantics of java.util.List and the proposed syntax of java.util.SequencedCollection, but given that people already have difficulties to understand basic data structure concepts, as a teacher i dread to have a discussion on those slight differences that are only true in Java. If the collection API was not already existing, we may discuss about having the same interface java.util.List to both indexed collection and ordered collection, but that boat has sailed a long time ago. So in first approach, we should refactor sorted set and linked hash set to directly implement java.util.List and all the proposed methods into java.util.List. But as you hint in the Risks and Assumptions section, this will cause regression due to inference and also we will have trouble with LinkedHashMap (see below). 3/ LinkedHashMap mixes 3 implementations in one class, some of these implementations does not conform to the semantics of SequencedMap. - You can opt-out having the key sequentially ordered as defined by SequencedMap by using the constructor LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) and passing true as last parameter. - You can opt-out having the key sequentially ordered as defined by SequencedMap by overriding removeEldestEntry(), removing the first entry at the same time you add a new one. Because all these reasons, i think we should move to another design, using delegation instead of inheritance, which for the collection framework means exposing new way to access/modify sorted set and linked hash set through java.util.List views. The concept of views is not a new concept, it's used in Arrays.asList(), List.subList() or Map.keySet()/values()/entrySet() (and more). The idea is not that a sorted set is a list but that it provides a method to see it as a list. It solves our problem of compatibility by not adding super types to existing type and also the problem of the semantics of LinkedHashMap because a view keeps the semantics of the data structure it originated. Here is the proposed new methods in List, SortedSet and SortedMap. interface List extends Collection { // new methods void addFirst(); void addLast(); E getFirst(); E getLast(); E removeFirst(); E removeLast(); List reversedList(); // or descendingList() ?? } interface SortedSet implements Set { // new methods List asList(); } interface SortedMap implements Map { // new methods List keyList(); // do not use covariant return type List> entryList(); // same } I believe this design is objectively better than the one proposed because as a user being able to use new interfaces is a slow process, the libraries/dependencies must be updated to take the new interfaces as parameter before the new types can be used. By contrast, the proposed design only enhance existing interfaces so people will enjoy the new methods directly when introduced. R?mi From lancea at openjdk.java.net Thu Feb 10 11:27:09 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 10 Feb 2022 11:27:09 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com> On Thu, 10 Feb 2022 03:04:43 GMT, Christian Stein wrote: >> What is "it" in "it provides..." ? > > Perhaps like this? > > > /** > * ... > * @provides java.util.spi.ToolProvider > * Module {@code jdk.jartool} provides a tool named {@code "jar"}. > * Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")} > * to create an instance of this tool. > * ... > */ > Perhaps like this? > > ```java > /** > * ... > * @provides java.util.spi.ToolProvider > * Module {@code jdk.jartool} provides a tool named {@code "jar"}. > * Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")} > * to create an instance of this tool. > * ... > */ > ``` What about `Module {@code jdk.jartool) provides the equivalent of command-line access to the {@code "jar"} tool` ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From jbhateja at openjdk.java.net Thu Feb 10 12:24:14 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 10 Feb 2022 12:24:14 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts In-Reply-To: References: Message-ID: <1EkBcO28e83W0erDN6flFX6eR88aovKxVIGJqOiF40I=.5db87001-570d-4679-9b3a-7937b72233ed@github.com> On Sat, 5 Feb 2022 15:34:08 GMT, Quan Anh Mai wrote: > Hi, > > This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. > > Thank you very much. src/hotspot/cpu/x86/x86.ad line 7288: > 7286: break; > 7287: default: assert(false, "%s", type2name(to_elem_bt)); > 7288: } Please move this into a macro assembly routine. src/hotspot/cpu/x86/x86.ad line 7310: > 7308: default: assert(false, "%s", type2name(to_elem_bt)); > 7309: } > 7310: %} Same as above. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From jai.forums2013 at gmail.com Thu Feb 10 13:27:42 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 10 Feb 2022 18:57:42 +0530 Subject: Seeking inputs on 8224794: ZipFile/JarFile should open zip/JAR file with FILE_SHARE_DELETE sharing mode on Windows In-Reply-To: References: <352c3fdb-e6e6-d03c-cea5-91ad2309b3f2@gmail.com> Message-ID: <0b20ce60-4d96-83e4-533f-5393e5cd759c@gmail.com> Thank you Daniel for your inputs. I'll stop any further investigation/work on this one and update the JBS issue with the details of the investigation so far. -Jaikiran On 04/02/22 10:55 pm, Daniel Fuchs wrote: > Hi Jaikiran, > > Thanks for working on this and apologies for the long silence. > > I believe your analysis of the issue is very valuable. > > Unless there is some clever trick we could do to allow to unlink > the file from the file system before deleting it, so that the file > path can be reused, it seems indeed that using FILE_SHARE_DELETE > doesn't buy us much benefit. > It is a pity, but IMO it was well worth the investigation. > > Unless others on this list disagree, or can suggest other tricks, > I would suggest shelving this work for now. > > best regards, > > -- daniel > > > On 18/12/2021 06:00, Jaikiran Pai wrote: >> Would there be interest in moving this forward? Enabling that >> FILE_SHARE_DELETE option has opened up some questions that I noted in >> my previous mail below. So in order to move forward I would need some >> inputs. If we don't want to do this at this time, I'll close the >> draft PR that's currently open https://github.com/openjdk/jdk/pull/6477. >> >> -Jaikiran >> > From duke at openjdk.java.net Thu Feb 10 13:39:09 2022 From: duke at openjdk.java.net (liach) Date: Thu, 10 Feb 2022 13:39:09 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 02:24:43 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > 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 seven additional commits since the last revision: > > - use peter's model of separate data object > - Merge branch 'master' into 8261407-reflectionfactory > - Include the stable annotation > - Merge branch 'master' into 8261407-reflectionfactory > - Merge branch '8261407-reflectionfactory' > - Just use volatile directly to ensure read order > - 8261407: ReflectionFactory.checkInitted() is not thread-safe Updated per suggestion of peter and mandy. Requesting another round of review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From jpai at openjdk.java.net Thu Feb 10 14:07:05 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 10 Feb 2022 14:07:05 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 05:49:47 GMT, Joe Darcy wrote: > Two changes to the toString output for annotations to give better source fidelity: > > 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. > > 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) > > Various existing regression tests are updated to accommodate the changes. > > Please also review the CSR: > https://bugs.openjdk.java.net/browse/JDK-8281568 src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 197: > 195: // Predicate above covers enum constants, including > 196: // those with specialized class bodies. > 197: return toSourceString((Enum) value); Hello Joe, would it be better to use the new syntax for `instanceof` here to avoid the subsequent cast? else if (value instanceof Enum v) .... return toSourceString(v); ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From duke at openjdk.java.net Thu Feb 10 15:00:12 2022 From: duke at openjdk.java.net (Sam Brannen) Date: Thu, 10 Feb 2022 15:00:12 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 05:49:47 GMT, Joe Darcy wrote: > Two changes to the toString output for annotations to give better source fidelity: > > 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. > > 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) > > Various existing regression tests are updated to accommodate the changes. > > Please also review the CSR: > https://bugs.openjdk.java.net/browse/JDK-8281568 Changes requested by sbrannen at github.com (no known OpenJDK username). src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 256: > 254: return Objects.toString(finalComponent.getCanonicalName(), > 255: "") + > 256: arrayBrackets.toString() + ".class"; Since we're using the canonical name now (which takes the array brackets into account), can't the whole method be simplified down to the following? Suggestion: return Objects.toString(clazz.getCanonicalName(), "") + ".class"; ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From duke at openjdk.java.net Thu Feb 10 15:14:44 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 10 Feb 2022 15:14:44 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. > > Thank you very much. Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision: - minor rename - address reviews ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7358/files - new: https://git.openjdk.java.net/jdk/pull/7358/files/22a70fe1..8028be52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7358&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7358&range=00-01 Stats: 81 lines in 4 files changed: 32 ins; 44 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7358/head:pull/7358 PR: https://git.openjdk.java.net/jdk/pull/7358 From duke at openjdk.java.net Thu Feb 10 15:14:46 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 10 Feb 2022 15:14:46 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v2] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 22:52:47 GMT, Sandhya Viswanathan wrote: >> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision: >> >> - minor rename >> - address reviews > > src/hotspot/cpu/x86/assembler_x86.cpp line 4782: > >> 4780: vector_len == AVX_256bit? VM_Version::supports_avx2() : >> 4781: vector_len == AVX_512bit? VM_Version::supports_evex() : 0, " "); >> 4782: InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true); > > legacy_mode should be false here instead of _legacy_mode_bw. Fixed, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From duke at openjdk.java.net Thu Feb 10 15:14:49 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 10 Feb 2022 15:14:49 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v2] In-Reply-To: <1EkBcO28e83W0erDN6flFX6eR88aovKxVIGJqOiF40I=.5db87001-570d-4679-9b3a-7937b72233ed@github.com> References: <1EkBcO28e83W0erDN6flFX6eR88aovKxVIGJqOiF40I=.5db87001-570d-4679-9b3a-7937b72233ed@github.com> Message-ID: <1U-v8HDdffTAyMecRVwaQhZUi3mmITIGDpuXsbHni5o=.b0bc2c3f-ac7f-4c0d-831c-7586673d5aea@github.com> On Thu, 10 Feb 2022 05:05:05 GMT, Jatin Bhateja wrote: >> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision: >> >> - minor rename >> - address reviews > > src/hotspot/cpu/x86/x86.ad line 7288: > >> 7286: break; >> 7287: default: assert(false, "%s", type2name(to_elem_bt)); >> 7288: } > > Please move this into a macro assembly routine. Fixed, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From aefimov at openjdk.java.net Thu Feb 10 15:28:06 2022 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Thu, 10 Feb 2022 15:28:06 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: <9I_lPjLJlxrQ8aeRxrpPWejELAtMQhHxXJm4UIzTozM=.1919bc6c-65b4-474f-9261-fd74d234346b@github.com> On Wed, 9 Feb 2022 19:47:19 GMT, Martin Balao wrote: > Thanks, that was what I initially thought but wanted to check if I was missing something else given the previous discussion. I should be able to generate a build for the user and ask him to test in his real environment. As for the other concern, I'll evaluate options and let you know. Thanks for the update, Martin. I'm ok with pushing the fix without a test given that the user will verify it in his real environment. Maybe, you could also log a bug for a test addition and describe in it an environment, and sort of a high-level scenario of how JDK-8275535 can be reproduced. ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From lkorinth at openjdk.java.net Thu Feb 10 15:47:23 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Thu, 10 Feb 2022 15:47:23 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc Message-ID: Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. ------------- Commit messages: - 8281585: Remove unused imports under test/lib and jtreg/gc Changes: https://git.openjdk.java.net/jdk/pull/7426/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281585 Stats: 92 lines in 60 files changed: 0 ins; 92 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7426/head:pull/7426 PR: https://git.openjdk.java.net/jdk/pull/7426 From psandoz at openjdk.java.net Thu Feb 10 17:16:09 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 10 Feb 2022 17:16:09 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v4] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 04:22:34 GMT, Tagir F. Valeev wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Benchmark to demonstrate the patch usefulness > > I added a microbenchmark to demonstrate the speed improvement achievable by this patch. For demonstration, I used `Pattern.splitAsStream` source (though as listed in JDK-8280915, many other standard sources are also affected). For downstream operation I selected `BigInteger.pow(1000)` which is moderately CPU-intensive (takes ~10us on my machine for input numbers within 1000..2000). The benchmarking results are as follows (my machine has 8 cores). Here's non-patched version: > > > Benchmark (size) Mode Cnt Score Error Units > sumOf1000thPowers 10 avgt 30 100.367 ? 0.793 us/op > sumOf1000thPowers 100 avgt 30 963.857 ? 6.252 us/op > sumOf1000thPowers 1000 avgt 30 10012.923 ? 81.091 us/op > sumOf1000thPowers 10000 avgt 30 99546.370 ? 625.105 us/op > sumOf1000thPowersParallel 10 avgt 30 104.561 ? 1.118 us/op > sumOf1000thPowersParallel 100 avgt 30 995.400 ? 26.116 us/op > sumOf1000thPowersParallel 1000 avgt 30 9969.296 ? 85.166 us/op > sumOf1000thPowersParallel 10000 avgt 30 55856.516 ? 2315.530 us/op > > > We observe that the results depend on the input size linearly for sequential run, which is quite expected. Parallel doesn't help at all for size = 10, 100, and 1000, which validates my claim that these spliterators cannot split at all for sizes <= 1024. For size = 10000, parallel version starts performing somewhat better (1.78x), though it's not nearly close to the available machine parallelism. > > Here's patched version: > > > Benchmark (size) Mode Cnt Score Error Units > sumOf1000thPowers 10 avgt 30 101.380 ? 0.961 us/op > sumOf1000thPowers 100 avgt 30 970.843 ? 8.360 us/op > sumOf1000thPowers 1000 avgt 30 9837.397 ? 93.656 us/op > sumOf1000thPowers 10000 avgt 30 97741.823 ? 1276.116 us/op > sumOf1000thPowersParallel 10 avgt 30 41.597 ? 0.910 us/op > sumOf1000thPowersParallel 100 avgt 30 189.735 ? 1.911 us/op > sumOf1000thPowersParallel 1000 avgt 30 1776.337 ? 31.034 us/op > sumOf1000thPowersParallel 10000 avgt 30 17685.723 ? 127.846 us/op > > > We observe no regression for sequential run and drastic improvement for parallel. Even for size = 10, we see 2.46x speedup and 41 us total time. For bigger sizes, we see 5.11x..5.54x speedup. > > Please review my patch. I'll be happy to discuss any concerns about this optimization you may have. Thanks in advance! @amaembo It's on my queue to review, i may get to it tomorrow, otherwise next week. ------------- PR: https://git.openjdk.java.net/jdk/pull/7279 From bpb at openjdk.java.net Thu Feb 10 17:25:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Feb 2022 17:25:04 GMT Subject: RFR: 8281259: MutableBigInteger subtraction could be simplified In-Reply-To: References: Message-ID: <07o4rVXTYmqnccpbkBcihg8KAiIllLsq4JBJ3WGo-vg=.fb9b6f15-52f2-4300-ab73-f5adb9f55696@github.com> On Fri, 4 Feb 2022 10:13:28 GMT, Daniel Jeli?ski wrote: > The proposed form of borrow bit handling is [already used in BigInteger class](https://github.com/djelinski/jdk/blob/ce26a19be5e907c11164b46f1bcb370b534d5bf6/src/java.base/share/classes/java/math/BigInteger.java#L1558). > > JMH results without the patch: > > Benchmark (maxNumbits) Mode Cnt Score Error Units > BigIntegers.testGcd 256 avgt 25 3181205,367 ? 155272,427 ns/op > > JMH results with the patch applied: > > Benchmark (maxNumbits) Mode Cnt Score Error Units > BigIntegers.testGcd 256 avgt 25 2696030,849 ? 14141,940 ns/op Presumably existing regression tests pass and no new ones are needed. Probably a `noreg-*` label is in order on the issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7342 From jjg at openjdk.java.net Thu Feb 10 17:30:08 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Feb 2022 17:30:08 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com> References: <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com> Message-ID: <6DQ5_BAMP-bV8XkY9txYZBRnXzc3ypCXV9b0YdgvAkk=.7bc88afb-4f9d-4659-9b33-153977afbb34@github.com> On Thu, 10 Feb 2022 11:24:23 GMT, Lance Andersen wrote: >> Perhaps like this? >> >> >> /** >> * ... >> * @provides java.util.spi.ToolProvider >> * Module {@code jdk.jartool} provides a tool named {@code "jar"}. >> * Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")} >> * to create an instance of this tool. >> * ... >> */ > >> Perhaps like this? >> >> ```java >> /** >> * ... >> * @provides java.util.spi.ToolProvider >> * Module {@code jdk.jartool} provides a tool named {@code "jar"}. >> * Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")} >> * to create an instance of this tool. >> * ... >> */ >> ``` > > What about > > `Module {@code jdk.jartool) provides the equivalent of command-line access to the {@code "jar"} tool` The focus should be to document the service specified in the `@provides` directive, and how to access to access an instance of the service. How about: Use `TP.findFirst("NAME")` to obtain an instance of a `ToolProvider` that provides the equivalent of command-line access to the {@code "NAME"} tool. ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From mdoerr at openjdk.java.net Thu Feb 10 17:46:08 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 10 Feb 2022 17:46:08 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 12:51:31 GMT, Claes Redestad wrote: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Hi Claes, it can get implemented similarly on PPC64: https://github.com/openjdk/jdk/pull/7430 You can integrate it if you prefer that, but better after it got a Review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From plevart at openjdk.java.net Thu Feb 10 18:10:10 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 10 Feb 2022 18:10:10 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5] In-Reply-To: References: Message-ID: <1vUMDZU-mvqplXFvyk8IfVvG66Y2dH7GYc6DGpE45po=.9ac7f090-f3dc-4b46-b6ad-5ebc8abe5c24@github.com> On Thu, 10 Feb 2022 13:36:11 GMT, liach wrote: >> 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 seven additional commits since the last revision: >> >> - use peter's model of separate data object >> - Merge branch 'master' into 8261407-reflectionfactory >> - Include the stable annotation >> - Merge branch 'master' into 8261407-reflectionfactory >> - Merge branch '8261407-reflectionfactory' >> - Just use volatile directly to ensure read order >> - 8261407: ReflectionFactory.checkInitted() is not thread-safe > > Updated per suggestion of peter and mandy. Requesting another round of review. Hi @liach , This looks good. Maybe we could even make these configuration parameters constant-foldable so they are basically constants if/when JIT compiles the code. 1st, you would have to mark the static `config` field as `@Stable` and move the fast-path check above the check for `VM.isModuleSystemInited()` like this: private static @Stable Config config; private static Config config() { Config c = config; if (c != null) { return c; } // Defer initialization until module system is initialized so as // to avoid inflation and spinning bytecode in unnamed modules // during early startup. if (!VM.isModuleSystemInited()) { return Config.fallback; } config = c = new Config(true); return c; } And that's basically it. The instance final fields in Config class are trusted by VM since they live in trusted package `jdk.internal.reflect` (see: s[rc/hotspot/share/ci/ciField.cpp:227](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciField.cpp#L227), so JIT should constant-fold their values when it compiles the code given that VM has probably already initialized the module system by that time and the `config` field has a non-null reference. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From xenoamess at gmail.com Thu Feb 10 18:14:26 2022 From: xenoamess at gmail.com (Xeno Amess) Date: Fri, 11 Feb 2022 02:14:26 +0800 Subject: HashMap.putAll can cause redundant space waste In-Reply-To: References: <0dd3c438-2dca-f0dd-cab0-842a9f06ee13@oracle.com> Message-ID: bug reported as 9072610 pr open at https://github.com/openjdk/jdk/pull/7431 I investigated most of the usages. They just give a size, and get a capacity, even not change the 0.75 So maybe we can use some int calculation to replace the 0.75, thus replace Math.ceil for such situations. The only problem is that need adding some public api to HashMap or Collections. Yep, sounds like a better version of guava.newHashMap. Xeno Amess ?2022?2?9??? 09:51??? > I agree that it would >> be preferable for the expression to be something like this: > > (int) Math.ceil(expected / 0.75) > > > Agree. > > If we don't add a Java SE utility like "newHashMapWithExpectedSize", >> fallbacks would >> be to introduce an internal JDK utility method that is called from >> various places, >> or just to update the individual call sites to use the more precise >> calculation. > > > Both seem acceptable. > > So what should I do next? > > Stuart Marks ?2022?2?8??? 04:06??? > >> Hi, >> >> I'm not sure where you ended up in this succession of messages. I do >> think there are >> some things going on that are worthy of discussion and possibly fixing. >> Let me try >> to break them down. >> >> 1) With the default load factor of 0.75, it's possible to have 12 entries >> in a map >> whose table length is 16. This works as expected if the entries are added >> individually using the put() method. However, adding 12 entries into a >> map via the >> copy constructor or via putAll() results in a table length of 32. That >> seems wrong. >> Well, if not exactly wrong, it's suboptimal, in that it uses more space >> than necessary. >> >> 2) The root cause of the problem is with expressions such as these: >> >> (int) (expected / 0.75f + 1.0f) >> or >> (int) (expected / 0.75f) + 1 >> >> (where "expected" is the expected number of entries). They attempt to >> round the >> division result up to the nearest int by adding 1 or 1.0f. This results >> in a value >> that's one too large if the result of the division exactly equals an >> integer. So, >> when "expected" is 12, this results in 17 instead of 16. This in turn is >> inflated to >> the next power-of-two, which is 32. >> >> 3) This was discussed previously in a different context. [1] I agree that >> it would >> be preferable for the expression to be something like this: >> >> (int) Math.ceil(expected / 0.75) >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066258.html >> >> This uses doubles instead of floats. But I think this is a fairly >> low-frequency >> operation, so I don't think using doubles is a problem. Thus I don't >> think we need >> to add a Math.ceil(float) overload. >> >> ** >> >> So what should be done about this? Possibly, the computations in HashMap >> and related >> classes should be adjusted to use Math.ceil() instead. Some tests use the >> suboptimal >> calculation as well; those might need to be adjusted also. >> >> There are a variety of places around the JDK that use a similar >> expression in order >> to pre-size HashMaps and HashSets. We could go around and fix all them, >> but it might >> be worth considering adding an API that creates a HashMap (or >> LinkedHashMap) that is >> pre-sized for the expected number of elements. Guava has such an API, >> Maps.newHashMapWithExpectedSize [2]. But note that it tries (but does not >> guarantee) >> to size the map such that it can accommodate the expected number of >> elements without >> resizing, but it doesn't promise that the map isn't oversized. >> >> [2] >> >> https://guava.dev/releases/31.0.1-jre/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize(int) >> >> (Also note that the ConcurrentHashMap(int) constructor takes the expected >> number of >> elements, not the initial table length like HashMap(int). CHM does what >> probably >> most users want, but it's confusing that its behavior differs from >> HashMap in this >> regard.) >> >> If we don't add a Java SE utility like "newHashMapWithExpectedSize", >> fallbacks would >> be to introduce an internal JDK utility method that is called from >> various places, >> or just to update the individual call sites to use the more precise >> calculation. >> >> s'marks >> >> >> On 2/4/22 10:48 AM, Xeno Amess wrote: >> > wait, things get interesting now. >> > We do have such a test named ConstantDirectoryOptimalCapacity to make >> sure >> > this does not happen, but my tests still fill under the idea debugger. >> > Is there any specialist for help? I would dig in but it is a little >> > complicated. >> > [image: image.png] >> > >> > Xeno Amess ?2022?2?5??? 02:39??? >> > >> >> Sorry for my mistake. >> >> After a more throughout dig in, this thing has already fixed several >> years >> >> ago, at year 2015. >> >> Issue close. >> >> >> >> Xeno Amess ?2022?2?4??? 21:40??? >> >> >> >>> Besides, is it worthy to develop a public float Math.ceil(float) >> function? >> >>> >> >>> Xeno Amess ?2022?2?4??? 21:39??? >> >>> >> >>>> patch applied. >> >>>> >> >>>> Index: src/java.base/share/classes/java/lang/Module.java >> >>>> IDEA additional info: >> >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> >>>> <+>UTF-8 >> >>>> =================================================================== >> >>>> diff --git a/src/java.base/share/classes/java/lang/Module.java >> >>>> b/src/java.base/share/classes/java/lang/Module.java >> >>>> --- a/src/java.base/share/classes/java/lang/Module.java (revision >> >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >> >>>> +++ b/src/java.base/share/classes/java/lang/Module.java (revision >> >>>> deeba25d15398fea8bc971ac915e348878b2c27a) >> >>>> @@ -1133,7 +1133,7 @@ >> >>>> boolean isBootLayer = (ModuleLayer.boot() == null); >> >>>> >> >>>> int numModules = cf.modules().size(); >> >>>> - int cap = (int)(numModules / 0.75f + 1.0f); >> >>>> + int cap = (int)Math.ceil(numModules / 0.75f); >> >>>> Map nameToModule = new HashMap<>(cap); >> >>>> >> >>>> // to avoid repeated lookups and reduce iteration >> overhead, we >> >>>> create >> >>>> Index: src/java.base/share/classes/java/util/HashMap.java >> >>>> IDEA additional info: >> >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> >>>> <+>UTF-8 >> >>>> =================================================================== >> >>>> diff --git a/src/java.base/share/classes/java/util/HashMap.java >> >>>> b/src/java.base/share/classes/java/util/HashMap.java >> >>>> --- a/src/java.base/share/classes/java/util/HashMap.java (revision >> >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >> >>>> +++ b/src/java.base/share/classes/java/util/HashMap.java (revision >> >>>> deeba25d15398fea8bc971ac915e348878b2c27a) >> >>>> @@ -495,9 +495,9 @@ >> >>>> int s = m.size(); >> >>>> if (s > 0) { >> >>>> if (table == null) { // pre-size >> >>>> - float ft = ((float)s / loadFactor) + 1.0F; >> >>>> - int t = ((ft < (float)MAXIMUM_CAPACITY) ? >> >>>> - (int)ft : MAXIMUM_CAPACITY); >> >>>> + double dt = Math.ceil(s / loadFactor); >> >>>> + int t = ((dt < (double)MAXIMUM_CAPACITY) ? >> >>>> + (int)dt : MAXIMUM_CAPACITY); >> >>>> if (t > threshold) >> >>>> threshold = tableSizeFor(t); >> >>>> } else { >> >>>> @@ -1527,12 +1527,12 @@ >> >>>> } else if (mappings == 0) { >> >>>> // use defaults >> >>>> } else if (mappings > 0) { >> >>>> - float fc = (float)mappings / lf + 1.0f; >> >>>> - int cap = ((fc < DEFAULT_INITIAL_CAPACITY) ? >> >>>> + double dc = Math.ceil(mappings / lf); >> >>>> + int cap = ((dc < DEFAULT_INITIAL_CAPACITY) ? >> >>>> DEFAULT_INITIAL_CAPACITY : >> >>>> - (fc >= MAXIMUM_CAPACITY) ? >> >>>> + (dc >= MAXIMUM_CAPACITY) ? >> >>>> MAXIMUM_CAPACITY : >> >>>> - tableSizeFor((int)fc)); >> >>>> + tableSizeFor((int)dc)); >> >>>> float ft = (float)cap * lf; >> >>>> threshold = ((cap < MAXIMUM_CAPACITY && ft < >> >>>> MAXIMUM_CAPACITY) ? >> >>>> (int)ft : Integer.MAX_VALUE); >> >>>> Index: src/java.base/share/classes/java/util/WeakHashMap.java >> >>>> IDEA additional info: >> >>>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> >>>> <+>UTF-8 >> >>>> =================================================================== >> >>>> diff --git a/src/java.base/share/classes/java/util/WeakHashMap.java >> >>>> b/src/java.base/share/classes/java/util/WeakHashMap.java >> >>>> --- a/src/java.base/share/classes/java/util/WeakHashMap.java >> (revision >> >>>> 3d926dd66ef6551e91a4ebbbc59dcff58f5ede5a) >> >>>> +++ b/src/java.base/share/classes/java/util/WeakHashMap.java >> (revision >> >>>> deeba25d15398fea8bc971ac915e348878b2c27a) >> >>>> @@ -251,7 +251,7 @@ >> >>>> * @since 1.3 >> >>>> */ >> >>>> public WeakHashMap(Map m) { >> >>>> - this(Math.max((int) ((float)m.size() / DEFAULT_LOAD_FACTOR + >> >>>> 1.0F), >> >>>> + this(Math.max((int) Math.ceil(m.size() / >> DEFAULT_LOAD_FACTOR), >> >>>> DEFAULT_INITIAL_CAPACITY), >> >>>> DEFAULT_LOAD_FACTOR); >> >>>> putAll(m); >> >>>> >> >>>> Xeno Amess ?2022?2?4??? 18:45??? >> >>>> >> >>>>> also find some other places have same problem. >> >>>>> If some of your already-in people aggree, I would create a pr, but >> >>>>> according to the rules seems I should wait for now. >> >>>>> >> >>>>> Xeno Amess ?2022?2?4??? 18:42??? >> >>>>> >> >>>>>> import java.lang.reflect.Array; >> >>>>>> import java.lang.reflect.Field; >> >>>>>> import java.util.HashMap; >> >>>>>> import java.util.Map; >> >>>>>> >> >>>>>> public class TestMap { >> >>>>>> >> >>>>>> public static void main(String[] args) throws >> NoSuchFieldException, IllegalAccessException { >> >>>>>> HashMap a = new HashMap<>(); >> >>>>>> fill12(a); >> >>>>>> HashMap b = new HashMap<>(12); >> >>>>>> fill12(b); >> >>>>>> HashMap c = new HashMap<>(a); >> >>>>>> HashMap d = new HashMap<>(); >> >>>>>> d.putAll(a); >> >>>>>> System.out.println("a : " + getArrayLength(a)); >> >>>>>> System.out.println("b : " + getArrayLength(b)); >> >>>>>> System.out.println("c : " + getArrayLength(c)); >> >>>>>> System.out.println("d : " + getArrayLength(d)); >> >>>>>> } >> >>>>>> >> >>>>>> public static void fill12(Map map) { >> >>>>>> for (int i = 0; i < 12; i++) { >> >>>>>> map.put(i, i); >> >>>>>> } >> >>>>>> } >> >>>>>> >> >>>>>> public static int getArrayLength(Map map) >> throws NoSuchFieldException, IllegalAccessException { >> >>>>>> Field field = HashMap.class.getDeclaredField("table"); >> >>>>>> field.setAccessible(true); >> >>>>>> Object table = field.get(map); >> >>>>>> return Array.getLength(table); >> >>>>>> } >> >>>>>> >> >>>>>> } >> >>>>>> >> >>>>>> run this and we get the output: >> >>>>>> >> >>>>>> a : 16 >> >>>>>> b : 16 >> >>>>>> c : 32 >> >>>>>> d : 32 >> >>>>>> >> >>>>>> So I go see the codes. >> >>>>>> >> >>>>>> /** >> >>>>>> * Implements Map.putAll and Map constructor. >> >>>>>> * >> >>>>>> * @param m the map >> >>>>>> * @param evict false when initially constructing this map, else >> >>>>>> * true (relayed to method afterNodeInsertion). >> >>>>>> */ >> >>>>>> final void putMapEntries(Map m, boolean >> evict) { >> >>>>>> int s = m.size(); >> >>>>>> if (s > 0) { >> >>>>>> if (table == null) { // pre-size >> >>>>>> float ft = ((float)s / loadFactor) + 1.0F; >> >>>>>> int t = ((ft < (float)MAXIMUM_CAPACITY) ? >> >>>>>> (int)ft : MAXIMUM_CAPACITY); >> >>>>>> if (t > threshold) >> >>>>>> threshold = tableSizeFor(t); >> >>>>>> } else { >> >>>>>> // Because of linked-list bucket constraints, we >> cannot >> >>>>>> // expand all at once, but can reduce total resize >> >>>>>> // effort by repeated doubling now vs later >> >>>>>> while (s > threshold && table.length < >> MAXIMUM_CAPACITY) >> >>>>>> resize(); >> >>>>>> } >> >>>>>> >> >>>>>> for (Map.Entry e : >> m.entrySet()) { >> >>>>>> K key = e.getKey(); >> >>>>>> V value = e.getValue(); >> >>>>>> putVal(hash(key), key, value, false, evict); >> >>>>>> } >> >>>>>> } >> >>>>>> } >> >>>>>> >> >>>>>> yep I do think *((float)s / loadFactor) + 1.0F* here is wrong. >> >>>>>> >> >>>>>> It should be *Math.ceil((float)s / loadFactor)* >> >>>>>> >> >>>>>> So I wish to generate a pull request. >> >>>>>> >> >>>>>> Anyone interested? >> >>>>>> >> >>>>>> >> > From psandoz at openjdk.java.net Thu Feb 10 18:31:05 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 10 Feb 2022 18:31:05 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 15:14:44 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision: > > - minor rename > - address reviews Running some tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From psandoz at openjdk.java.net Thu Feb 10 18:41:13 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 10 Feb 2022 18:41:13 GMT Subject: Integrated: 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors In-Reply-To: <3pdqZiPGR8RhbesW_Ffz-2N5HP8tCmKrtV71-A2NecU=.68633237-3317-4703-b1bb-dee21e3a85d6@github.com> References: <3pdqZiPGR8RhbesW_Ffz-2N5HP8tCmKrtV71-A2NecU=.68633237-3317-4703-b1bb-dee21e3a85d6@github.com> Message-ID: On Wed, 9 Feb 2022 21:36:01 GMT, Paul Sandoz wrote: > ?ArgumentExcept on zero vectors > > This PR fixes issues for reduction using FIRST_NONZERO and adds tests. The testing infrastructure is generalized to reduction functions and tests for min/max reductions are updated to use that. This pull request has now been integrated. Changeset: 83b6e4bc Author: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/83b6e4bc04db89a846a1b6c2d0666efe139f8f61 Stats: 3725 lines in 54 files changed: 2742 ins; 407 del; 576 mod 8281294: [vectorapi] FIRST_NONZERO reduction operation throws IllegalArgumentExcept on zero vectors Reviewed-by: jrose ------------- PR: https://git.openjdk.java.net/jdk/pull/7410 From psandoz at openjdk.java.net Thu Feb 10 18:59:05 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 10 Feb 2022 18:59:05 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 15:14:44 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision: > > - minor rename > - address reviews Observing the following failures on CPUs with "Intel_R__Xeon_R__Gold_6354_CPU___3.00GHz" with HotSpot flags: -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation TestVectorCastAVX512.java: Failed IR Rules (1) ------------------ - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUI256toL512(int[],long[])": * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastI2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" - counts: Graph contains wrong number of nodes: Regex 1: (\\d+(\\s){2}(VectorUCastI2X.*)+(\\s){2}===.*) Expected 1 but found 0 nodes. TestVectorCastAVX1.java: - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toS64(byte[],short[])": * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" - counts: Graph contains wrong number of nodes: Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*) Expected 1 but found 0 nodes. - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toI128(byte[],int[])": * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" - counts: Graph contains wrong number of nodes: Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*) Expected 1 but found 0 nodes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From dfuchs at openjdk.java.net Thu Feb 10 19:18:13 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 10 Feb 2022 19:18:13 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: <9I_lPjLJlxrQ8aeRxrpPWejELAtMQhHxXJm4UIzTozM=.1919bc6c-65b4-474f-9261-fd74d234346b@github.com> References: <9I_lPjLJlxrQ8aeRxrpPWejELAtMQhHxXJm4UIzTozM=.1919bc6c-65b4-474f-9261-fd74d234346b@github.com> Message-ID: <21tODQUvF9JWwvstIOYuP8Sou71Ht3Pwa1p2csgDqUw=.30365c8e-adac-4e39-9fb4-0d70b65c6d90@github.com> On Thu, 10 Feb 2022 15:25:09 GMT, Aleksei Efimov wrote: > I'm ok with pushing the fix without a test given that the user will verify it in his real environment. > Maybe, you could also log a bug for a test addition and describe in it an environment, and sort of a high-level scenario of how JDK-8275535 can be reproduced. Right - I would be fine with that too. ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From mchung at openjdk.java.net Thu Feb 10 20:01:30 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Feb 2022 20:01:30 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 02:24:43 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > 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 seven additional commits since the last revision: > > - use peter's model of separate data object > - Merge branch 'master' into 8261407-reflectionfactory > - Include the stable annotation > - Merge branch 'master' into 8261407-reflectionfactory > - Merge branch '8261407-reflectionfactory' > - Just use volatile directly to ensure read order > - 8261407: ReflectionFactory.checkInitted() is not thread-safe This looks good. I have a couple of small suggestions. src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 621: > 619: java.lang.reflect.AccessibleObject) causes this class's to be > 620: run, before the system properties are set up. */ > 621: private static Config config; This can be made `@Stable` as this is initialized only once. src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 643: > 641: */ > 642: private static final class Config { > 643: private static final Config fallback = new Config(false); Suggestion: private static final Config DEFAULT = new Config(false); I suggest to rename `fallback` to `DEFAULT`. src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 672: > 670: private final boolean disableSerialConstructorChecks; > 671: > 672: private Config(boolean getProperties) { I suggest to make this a static `Config.getInstance()` method to return a `Config` instance and that should assert if this is called after the module system is initialized. The `Config` constructor is a simple constructor taking one parameter for each field and just set all fields to the parameter value. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From djelinski at openjdk.java.net Thu Feb 10 20:34:25 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 10 Feb 2022 20:34:25 GMT Subject: RFR: 8281259: MutableBigInteger subtraction could be simplified In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 10:13:28 GMT, Daniel Jeli?ski wrote: > The proposed form of borrow bit handling is [already used in BigInteger class](https://github.com/djelinski/jdk/blob/ce26a19be5e907c11164b46f1bcb370b534d5bf6/src/java.base/share/classes/java/math/BigInteger.java#L1558). > > JMH results without the patch: > > Benchmark (maxNumbits) Mode Cnt Score Error Units > BigIntegers.testGcd 256 avgt 25 3181205,367 ? 155272,427 ns/op > > JMH results with the patch applied: > > Benchmark (maxNumbits) Mode Cnt Score Error Units > BigIntegers.testGcd 256 avgt 25 2696030,849 ? 14141,940 ns/op Yessir! Tier1 and tier2 passed. Added noreg-perf label. ------------- PR: https://git.openjdk.java.net/jdk/pull/7342 From mullan at openjdk.java.net Thu Feb 10 20:41:34 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 10 Feb 2022 20:41:34 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com> Message-ID: On Wed, 9 Feb 2022 21:16:08 GMT, Lance Andersen wrote: >>> Nit, add space after "if" >> >> will fix > > So a bit more on this. If the ZipEntry passed to `ZipFile::getInputStream` does not represent an entry within the current Zip/Jar, `ZipFile::getInputStream` will return a null for the InputStream: > > > @Test > public static void ZipFileZipEntryNullGetInputStreamTest() throws Exception { > try (ZipFile zf = new ZipFile(VALID_ENTRY_NAME_JAR.toFile())) { > var ze = new ZipEntry("org/gotham/Batcave.class"); > var is = zf.getInputStream(ze); > // As the ZipEntry cannot be found, the returned InpuStream is null > assertNull(is); > } > } > > > JarFile::getInputStream will also return null when the jar is not signed or we are not verifying the jar: > > > @Test > public static void JarFileZipEntryNullGetInputStreamTest() throws Exception { > try (JarFile jf = new JarFile(VALID_ENTRY_NAME_JAR.toFile())) { > var ze = new ZipEntry("org/gotham/Batcave.class"); > var is = jf.getInputStream(ze); > // As the ZipEntry cannot be found, the returned InpuStream is null > assertNull(is); > } > > try (JarFile jf = new JarFile(SIGNED_INVALID_ENTRY_NAME_JAR.toFile(), false)) { > var ze = new ZipEntry("org/gotham/Batcave.class"); > var is = jf.getInputStream(ze); > // As the ZipEntry cannot be found, the returned InpuStream is null > assertNull(is); > } > } > > > > This behavior dates back to at least JDK 1.3 > > So I think we should return null instead of throwing an Exception when the resulting ZipEntry is null that is returned from the call to`JarFile::getJarEntry` (which calls `ZipFile::getEntry`) for consistency with ZipFile and when the Jar is not signed or not verified. > > I also noticed that `ZipFile::getInputStream` and `JarFile::getInputStream` do not mention that a null will be returned if the specified ZipEntry is not found within the Jar/Zip. I guess I could open a CSR as part of this fix to clarify this 20+ year behavior. Agree on returning null to maintain current behavior. I would also lean towards amending the specification to specify what has been long-standing behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From mullan at openjdk.java.net Thu Feb 10 20:41:35 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Thu, 10 Feb 2022 20:41:35 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com> Message-ID: On Thu, 10 Feb 2022 20:35:19 GMT, Sean Mullan wrote: >> So a bit more on this. If the ZipEntry passed to `ZipFile::getInputStream` does not represent an entry within the current Zip/Jar, `ZipFile::getInputStream` will return a null for the InputStream: >> >> >> @Test >> public static void ZipFileZipEntryNullGetInputStreamTest() throws Exception { >> try (ZipFile zf = new ZipFile(VALID_ENTRY_NAME_JAR.toFile())) { >> var ze = new ZipEntry("org/gotham/Batcave.class"); >> var is = zf.getInputStream(ze); >> // As the ZipEntry cannot be found, the returned InpuStream is null >> assertNull(is); >> } >> } >> >> >> JarFile::getInputStream will also return null when the jar is not signed or we are not verifying the jar: >> >> >> @Test >> public static void JarFileZipEntryNullGetInputStreamTest() throws Exception { >> try (JarFile jf = new JarFile(VALID_ENTRY_NAME_JAR.toFile())) { >> var ze = new ZipEntry("org/gotham/Batcave.class"); >> var is = jf.getInputStream(ze); >> // As the ZipEntry cannot be found, the returned InpuStream is null >> assertNull(is); >> } >> >> try (JarFile jf = new JarFile(SIGNED_INVALID_ENTRY_NAME_JAR.toFile(), false)) { >> var ze = new ZipEntry("org/gotham/Batcave.class"); >> var is = jf.getInputStream(ze); >> // As the ZipEntry cannot be found, the returned InpuStream is null >> assertNull(is); >> } >> } >> >> >> >> This behavior dates back to at least JDK 1.3 >> >> So I think we should return null instead of throwing an Exception when the resulting ZipEntry is null that is returned from the call to`JarFile::getJarEntry` (which calls `ZipFile::getEntry`) for consistency with ZipFile and when the Jar is not signed or not verified. >> >> I also noticed that `ZipFile::getInputStream` and `JarFile::getInputStream` do not mention that a null will be returned if the specified ZipEntry is not found within the Jar/Zip. I guess I could open a CSR as part of this fix to clarify this 20+ year behavior. > > Agree on returning null to maintain current behavior. I would also lean towards amending the specification to specify what has been long-standing behavior. If we had to do it over again, I do think throwing IAE is more appropriate because this case would probably be due to a bug in the application code. Now code has to defensively check for a null return value. I don't know, maybe we don't want to modify the specification at this point and leave this as undefined behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From bpb at openjdk.java.net Thu Feb 10 20:48:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Feb 2022 20:48:05 GMT Subject: RFR: 8281259: MutableBigInteger subtraction could be simplified In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 10:13:28 GMT, Daniel Jeli?ski wrote: > The proposed form of borrow bit handling is [already used in BigInteger class](https://github.com/djelinski/jdk/blob/ce26a19be5e907c11164b46f1bcb370b534d5bf6/src/java.base/share/classes/java/math/BigInteger.java#L1558). > > JMH results without the patch: > > Benchmark (maxNumbits) Mode Cnt Score Error Units > BigIntegers.testGcd 256 avgt 25 3181205,367 ? 155272,427 ns/op > > JMH results with the patch applied: > > Benchmark (maxNumbits) Mode Cnt Score Error Units > BigIntegers.testGcd 256 avgt 25 2696030,849 ? 14141,940 ns/op Thanks for the update. Approved. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7342 From rriggs at openjdk.java.net Thu Feb 10 21:35:11 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 10 Feb 2022 21:35:11 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v3] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato wrote: >> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 113: > 111: // DateFormatItem prefix > 112: final static String DATEFORMATITEM_KEY_PREFIX = "DateFormatItem."; > 113: final static String DATEFORMATITEM_INPUT_REGIONS_PREFIX = "DateFormatItemInputRegions."; The canonical order of modifiers is "static final". ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From lancea at openjdk.java.net Thu Feb 10 21:35:56 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 10 Feb 2022 21:35:56 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v3] In-Reply-To: References: Message-ID: <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com> > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with two additional commits since the last revision: - Return a null InputStream when the ZipEntry is not found in the Jar - Address formatting and message feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/6c75384a..32f6c284 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=01-02 Stats: 95 lines in 3 files changed: 41 ins; 20 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Thu Feb 10 21:35:57 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 10 Feb 2022 21:35:57 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v2] In-Reply-To: References: <7ZQvMR4-9GMWVIHoMu0l_t4rbBj5RjGOHpUpvimqIQ8=.6c361067-f229-43be-a580-6eadb3ddb572@github.com> <5pQGp2439k9y0EzSQ7VNZ6ZceIvXrYZgQVc2zSbIiLo=.88f1ef6c-8e43-4741-a217-dc3e2e099369@github.com> Message-ID: On Thu, 10 Feb 2022 20:37:50 GMT, Sean Mullan wrote: >> Agree on returning null to maintain current behavior. I would also lean towards amending the specification to specify what has been long-standing behavior. > > If we had to do it over again, I do think throwing IAE is more appropriate because this case would probably be due to a bug in the application code. Now code has to defensively check for a null return value. I don't know, maybe we don't want to modify the specification at this point and leave this as undefined behavior. > Agree on returning null to maintain current behavior. I would also lean towards amending the specification to specify what has been long-standing behavior. I just updated the PR to return null ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From darcy at openjdk.java.net Thu Feb 10 22:12:57 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Feb 2022 22:12:57 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v2] In-Reply-To: References: Message-ID: > Two changes to the toString output for annotations to give better source fidelity: > > 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. > > 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) > > Various existing regression tests are updated to accommodate the changes. > > Please also review the CSR: > https://bugs.openjdk.java.net/browse/JDK-8281568 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7418/files - new: https://git.openjdk.java.net/jdk/pull/7418/files/fdbfbfea..2989ff11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7418&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7418&range=00-01 Stats: 13 lines in 1 file changed: 0 ins; 9 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7418.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7418/head:pull/7418 PR: https://git.openjdk.java.net/jdk/pull/7418 From darcy at openjdk.java.net Thu Feb 10 22:12:57 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Feb 2022 22:12:57 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 14:04:01 GMT, Jaikiran Pai wrote: > Hello Joe, would it be better to use the new syntax for `instanceof` here to avoid the subsequent cast? > > ``` > else if (value instanceof Enum v) > .... > return toSourceString(v); > ``` Fair point; updated in subsequent push. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From darcy at openjdk.java.net Thu Feb 10 22:12:58 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Feb 2022 22:12:58 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 14:56:46 GMT, Sam Brannen wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 256: > >> 254: return Objects.toString(finalComponent.getCanonicalName(), >> 255: "") + >> 256: arrayBrackets.toString() + ".class"; > > Since we're using the canonical name now (which takes the array brackets into account), can't the whole method be simplified down to the following? > > Suggestion: > > return Objects.toString(clazz.getCanonicalName(), "") + ".class"; The getCanonicalName is not specified to behave that way, should be a RFE I suppose, but appears to in practice; changed as suggested in subsequent push. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From duke at openjdk.java.net Thu Feb 10 22:25:15 2022 From: duke at openjdk.java.net (liach) Date: Thu, 10 Feb 2022 22:25:15 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 19:45:24 GMT, Mandy Chung wrote: >> 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 seven additional commits since the last revision: >> >> - use peter's model of separate data object >> - Merge branch 'master' into 8261407-reflectionfactory >> - Include the stable annotation >> - Merge branch 'master' into 8261407-reflectionfactory >> - Merge branch '8261407-reflectionfactory' >> - Just use volatile directly to ensure read order >> - 8261407: ReflectionFactory.checkInitted() is not thread-safe > > src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 672: > >> 670: private final boolean disableSerialConstructorChecks; >> 671: >> 672: private Config(boolean getProperties) { > > I suggest to make this a static `Config.getInstance()` method to return a `Config` instance and that should assert if this is called after the module system is initialized. The `Config` constructor is a simple constructor taking one parameter for each field and just set all fields to the parameter value. Can I just write the config class as a record, or does it generate too much boilerplate? ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From rriggs at openjdk.java.net Thu Feb 10 22:26:30 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 10 Feb 2022 22:26:30 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v3] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 19:08:45 GMT, Naoto Sato wrote: >> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 742: > 740: * All pattern symbols are optional, and each pattern symbol represents the field it is in, > 741: * e.g., 'M' represents the Month field. The number of the pattern symbol letters follows the > 742: * same presentation, such as "number" or "text" as in the Patterns for I would reword as: * All pattern symbols are optional, and each pattern symbol represents a field, * for example, 'M' represents the Month field. The number of the pattern symbol letters follows the src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 753: > 751: *

> 752: * The locale is determined from the formatter. The formatter returned directly by > 753: * this method will use the {@link Locale#getDefault() default FORMAT locale}. Editorial suggestion: * this method uses the {https://github.com/link Locale#getDefault() default FORMAT locale}. src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 231: > 229: > 230: /** > 231: * Gets the formatting pattern for the requested template for a locale and chronology. "Returns" is more conventional (than "Gets; though it is consistent within the file) src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 246: > 244: * @param locale the locale, non-null > 245: * @return the locale and Chronology specific formatting pattern > 246: * @throws IllegalArgumentException if {@code requestedTemplate} is invalid The meaning "Invalid" should be clearly defined; repeating or refering to the template regex. src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1485: > 1483: *

  • the {@code requestedTemplate} specified to this method > 1484: *
  • the {@code Locale} of the {@code DateTimeFormatter} > 1485: *
  • the {@code Chronology}, selecting the best available Perhaps "best available" should be well defined, or just drop "best". or ... "of the {@code DateTimeFormatter} unless overridden" src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1513: > 1511: * } > 1512: * All pattern symbols are optional, and each pattern symbol represents the field it is in, > 1513: * e.g., 'M' represents the Month field. The number of the pattern symbol letters follows the Ditto above: * All pattern symbols are optional, and each pattern symbol represents the field, * for example, 'M' represents the Month field. The number of the pattern symbol letters follows the src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5148: > 5146: var useRequestedTemplate = requestedTemplate != null; > 5147: String key = chrono.getId() + '|' + locale.toString() + '|' + > 5148: (useRequestedTemplate ? requestedTemplate : Objects.toString(dateStyle) + timeStyle); The boolean `useRequestedTemplate` isn't necessary, replace with `requestedTemplate != null`. src/java.base/share/classes/sun/text/spi/JavaTimeDateTimePatternProvider.java line 64: > 62: > 63: /** > 64: * Gets the formatting pattern for the requested template, calendarType, and locale. "Returns" is more conventional. src/java.base/share/classes/sun/util/locale/provider/JavaTimeDateTimePatternImpl.java line 69: > 67: public String getJavaTimeDateTimePattern(int timeStyle, int dateStyle, String calType, Locale locale) { > 68: LocaleResources lr = LocaleProviderAdapter.getResourceBundleBased().getLocaleResources(locale); > 69: return lr.getJavaTimeDateTimePattern( Fold the parameters onto a single line. src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java line 690: > 688: private String resolveInputSkeleton(String type) { > 689: var regionToSkeletonMap = inputSkeletons.get(type); > 690: return regionToSkeletonMap.getOrDefault(locale.getLanguage() + "-" + locale.getCountry(), This structure computes all the defaults even if the value isn't needed (because the value has to be passed to the `getOrDefault` method. Perhaps performance isn't an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From duke at openjdk.java.net Thu Feb 10 22:53:56 2022 From: duke at openjdk.java.net (liach) Date: Thu, 10 Feb 2022 22:53:56 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v6] In-Reply-To: References: Message-ID: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. > > This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) liach has updated the pull request incrementally with one additional commit since the last revision: Make config a pojo, move loading code into config class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6889/files - new: https://git.openjdk.java.net/jdk/pull/6889/files/12086557..f32ff988 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=04-05 Stats: 138 lines in 1 file changed: 66 ins; 48 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/6889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889 PR: https://git.openjdk.java.net/jdk/pull/6889 From mchung at openjdk.java.net Thu Feb 10 22:53:57 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Feb 2022 22:53:57 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 22:21:32 GMT, liach wrote: >> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 672: >> >>> 670: private final boolean disableSerialConstructorChecks; >>> 671: >>> 672: private Config(boolean getProperties) { >> >> I suggest to make this a static `Config.getInstance()` method to return a `Config` instance and that should assert if this is called after the module system is initialized. The `Config` constructor is a simple constructor taking one parameter for each field and just set all fields to the parameter value. > > Can I just write the config class as a record, or does it generate too much boilerplate? Or is this class initialized too early to use records (such as indy is not yet ready)? Worth a try. Even the regular class, the constructor taking 5 fields isn't too bad to me. In a near future, I hope to remove the old core reflection implementation, `noInflation` and `inflationThreshold` will be removed and fewer fields. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From dholmes at openjdk.java.net Thu Feb 10 23:24:11 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Feb 2022 23:24:11 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth wrote: > Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. Looks fine. The proof of these changes is in compiling the files - how did you test the non-gc-test changes? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7426 From dholmes at openjdk.java.net Thu Feb 10 23:33:09 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Feb 2022 23:33:09 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth wrote: > Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. Forgot to mention copyright years need updating before integrating! Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7426 From mchung at openjdk.java.net Thu Feb 10 23:34:43 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Feb 2022 23:34:43 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library Message-ID: This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. ------------- Commit messages: - Allow raw libraries to be loaded even if it's loaded via System::loadLibrary Changes: https://git.openjdk.java.net/jdk/pull/7435/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7435&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281335 Stats: 324 lines in 4 files changed: 191 ins; 115 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7435/head:pull/7435 PR: https://git.openjdk.java.net/jdk/pull/7435 From naoto at openjdk.java.net Fri Feb 11 00:03:50 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Feb 2022 00:03:50 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v4] In-Reply-To: References: Message-ID: > Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7340/files - new: https://git.openjdk.java.net/jdk/pull/7340/files/41408ff3..af3c0d62 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=02-03 Stats: 33 lines in 5 files changed: 1 ins; 2 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/7340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7340/head:pull/7340 PR: https://git.openjdk.java.net/jdk/pull/7340 From naoto at openjdk.java.net Fri Feb 11 00:03:52 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Feb 2022 00:03:52 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v3] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 22:20:48 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed LocalizedPrinterParser.toString() to reflect requestedTemplate > > src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java line 690: > >> 688: private String resolveInputSkeleton(String type) { >> 689: var regionToSkeletonMap = inputSkeletons.get(type); >> 690: return regionToSkeletonMap.getOrDefault(locale.getLanguage() + "-" + locale.getCountry(), > > This structure computes all the defaults even if the value isn't needed (because the value has to be passed to the `getOrDefault` method. Perhaps performance isn't an issue. Indeed, yes. I thought this was simple enough, and as you said, not performance-critical. ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From duke at openjdk.java.net Fri Feb 11 02:12:15 2022 From: duke at openjdk.java.net (liach) Date: Fri, 11 Feb 2022 02:12:15 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 22:49:38 GMT, Mandy Chung wrote: >> Can I just write the config class as a record, or does it generate too much boilerplate? Or is this class initialized too early to use records (such as indy is not yet ready)? > > Worth a try. Even the regular class, the constructor taking 5 fields isn't too bad to me. In a near future, I hope to remove the old core reflection implementation, `noInflation` and `inflationThreshold` will be removed and fewer fields. I made a commit with the config class converted into a record. Apparently the tests are passing, and I would assume it would be feasible. Should I apply it? https://github.com/liachmodded/jdk/commit/8cf5af417a6f906e9fc0c878d60731d6f026b528 ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From sundar at openjdk.java.net Fri Feb 11 02:43:09 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 11 Feb 2022 02:43:09 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library In-Reply-To: References: Message-ID: <2KWOlwNVNx3SnHYXFAxdbOaVklKpLHVAhL5uYSr_05g=.22b498be-797f-4d72-a0f9-b79b522ac244@github.com> On Thu, 10 Feb 2022 23:27:49 GMT, Mandy Chung wrote: > This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. > > The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. LGTM src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 58: > 56: * will fail. > 57: */ > 58: public abstract class NativeLibraries { could this be sealed with only two specific subtypes defined here? src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 251: > 249: // do not search java.library.path > 250: super(loader, loader != null ? null : NativeLibraries.class, > 251: loader != null ? true : false); The last argument expression of the super class could be just loader != null ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7435 From mchung at openjdk.java.net Fri Feb 11 03:49:49 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Feb 2022 03:49:49 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v2] In-Reply-To: <2KWOlwNVNx3SnHYXFAxdbOaVklKpLHVAhL5uYSr_05g=.22b498be-797f-4d72-a0f9-b79b522ac244@github.com> References: <2KWOlwNVNx3SnHYXFAxdbOaVklKpLHVAhL5uYSr_05g=.22b498be-797f-4d72-a0f9-b79b522ac244@github.com> Message-ID: On Fri, 11 Feb 2022 02:38:08 GMT, Athijegannathan Sundararajan wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 58: > >> 56: * will fail. >> 57: */ >> 58: public abstract class NativeLibraries { > > could this be sealed with only two specific subtypes defined here? It could. It's just an internal class and not so much of a concern of unexpected subclasses. I'll leave it as is. > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 251: > >> 249: // do not search java.library.path >> 250: super(loader, loader != null ? null : NativeLibraries.class, >> 251: loader != null ? true : false); > > The last argument expression of the super class could be just loader != null Updated. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7435 From mchung at openjdk.java.net Fri Feb 11 03:49:45 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Feb 2022 03:49:45 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v2] In-Reply-To: References: Message-ID: <99-oYqMwklU1DZYP5zXTNyqNRLbDMBi366uFH_Ywopc=.996865ad-3bee-413d-a4e8-b76ab9e08979@github.com> > This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. > > The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7435/files - new: https://git.openjdk.java.net/jdk/pull/7435/files/bbb44b6b..6e492d2b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7435&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7435&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7435/head:pull/7435 PR: https://git.openjdk.java.net/jdk/pull/7435 From mchung at openjdk.java.net Fri Feb 11 03:57:07 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Feb 2022 03:57:07 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v5] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 02:08:27 GMT, liach wrote: >> Worth a try. Even the regular class, the constructor taking 5 fields isn't too bad to me. In a near future, I hope to remove the old core reflection implementation, `noInflation` and `inflationThreshold` will be removed and fewer fields. > > I made a commit with the config class converted into a record. Apparently the tests are passing, and I would assume it would be feasible. Should I apply it? > https://github.com/liachmodded/jdk/commit/8cf5af417a6f906e9fc0c878d60731d6f026b528 yes and I can take a closer it. Indy is ready to use very early during VM initialization before initPhase2 where the module system is initialized. AFAIU, indy is needed for the object methods for records i.e. `equals`, `hashCode`, and `toString`. Just record object instantiation and accessing its final fields don't use indy. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From sundar at openjdk.java.net Fri Feb 11 04:12:06 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 11 Feb 2022 04:12:06 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v2] In-Reply-To: <99-oYqMwklU1DZYP5zXTNyqNRLbDMBi366uFH_Ywopc=.996865ad-3bee-413d-a4e8-b76ab9e08979@github.com> References: <99-oYqMwklU1DZYP5zXTNyqNRLbDMBi366uFH_Ywopc=.996865ad-3bee-413d-a4e8-b76ab9e08979@github.com> Message-ID: On Fri, 11 Feb 2022 03:49:45 GMT, Mandy Chung wrote: >> This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. >> >> The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review comment Marked as reviewed by sundar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7435 From jpai at openjdk.java.net Fri Feb 11 07:38:09 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 11 Feb 2022 07:38:09 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 22:08:27 GMT, Joe Darcy wrote: >> src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 197: >> >>> 195: // Predicate above covers enum constants, including >>> 196: // those with specialized class bodies. >>> 197: return toSourceString((Enum) value); >> >> Hello Joe, would it be better to use the new syntax for `instanceof` here to avoid the subsequent cast? >> >> >> else if (value instanceof Enum v) >> .... >> return toSourceString(v); > >> Hello Joe, would it be better to use the new syntax for `instanceof` here to avoid the subsequent cast? >> >> ``` >> else if (value instanceof Enum v) >> .... >> return toSourceString(v); >> ``` > > Fair point; updated in subsequent push. Thanks. Thank you for this change, Joe. Looks fine to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From plevart at openjdk.java.net Fri Feb 11 08:09:11 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 11 Feb 2022 08:09:11 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v6] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 22:53:56 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Make config a pojo, move loading code into config class Changes requested by plevart (Reviewer). src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 685: > 683: instance = c = load(); > 684: } > 685: return c; If you do that the "old" way, you loose the ability for JIT to constant-fold the `instance` and by transitivity the Config instance fields, since the check for `VM.isModuleSystemInited()` can't be elided. As suggested, the fast-path check should be done 1st, like: private static @Stable Config instance; private static Config instance() { Config c = instance; if (c != null) { return c; } // Defer initialization until module system is initialized so as // to avoid inflation and spinning bytecode in unnamed modules // during early startup. if (!VM.isModuleSystemInited()) { return DEFAULT; } instance = c = load(); return c; } ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From plevart at openjdk.java.net Fri Feb 11 08:28:09 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 11 Feb 2022 08:28:09 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v6] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:05:30 GMT, Peter Levart wrote: >> liach has updated the pull request incrementally with one additional commit since the last revision: >> >> Make config a pojo, move loading code into config class > > src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 685: > >> 683: instance = c = load(); >> 684: } >> 685: return c; > > If you do that the "old" way, you loose the ability for JIT to constant-fold the `instance` and by transitivity the Config instance fields, since the check for `VM.isModuleSystemInited()` can't be elided. As suggested, the fast-path check should be done 1st, like: > > > private static @Stable Config instance; > > private static Config instance() { > Config c = instance; > if (c != null) { > return c; > } > > // Defer initialization until module system is initialized so as > // to avoid inflation and spinning bytecode in unnamed modules > // during early startup. > if (!VM.isModuleSystemInited()) { > return DEFAULT; > } > > instance = c = load(); > return c; > } ...having suggested that rearrangement, perhaps the right way to do it is to enable some VM.isXXX queries themselves to be constant-foldable so that other callers too may benefit. Like this: https://github.com/plevart/jdk/commit/e918ccc52bbc288f6721af5fa66d8f7a8cc880cf WDYT? ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From lkorinth at openjdk.java.net Fri Feb 11 08:54:51 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 11 Feb 2022 08:54:51 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: > Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: updating copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7426/files - new: https://git.openjdk.java.net/jdk/pull/7426/files/6aaa1a3a..7d3e7a1b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7426&range=00-01 Stats: 59 lines in 59 files changed: 0 ins; 0 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/7426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7426/head:pull/7426 PR: https://git.openjdk.java.net/jdk/pull/7426 From duke at openjdk.java.net Fri Feb 11 09:00:31 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 09:00:31 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Thu, 10 Feb 2022 17:46:36 GMT, XenoAmess wrote: > 8281631: HashMap.putAll can cause redundant space waste According to the discussion at mailing list, we decide to try only change the calculation inside HashMap and WeakHashMap, and see what would happen. The next step is fixing all such **size/0.75+1** in jdk (expected several hundreds places...) I investigated most of the usages. They just give a size, and get a capacity, even not change the 0.75 So maybe we can use some int calculation to replace the 0.75, thus replace Math.ceil for such situations. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From lkorinth at openjdk.java.net Fri Feb 11 09:01:06 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 11 Feb 2022 09:01:06 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote: >> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > updating copyright I have a maven project that compiles test/lib and jtreg/gc, so everything changed does compile, I should have mentioned that. I have updated copyright year on all files now as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7426 From duke at openjdk.java.net Fri Feb 11 09:00:30 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 09:00:30 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste Message-ID: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> 8281631: HashMap.putAll can cause redundant space waste ------------- Commit messages: - 9072610: HashMap.putAll can cause redundant space waste Changes: https://git.openjdk.java.net/jdk/pull/7431/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281631 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From sspitsyn at openjdk.java.net Fri Feb 11 10:14:09 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 11 Feb 2022 10:14:09 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote: >> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > updating copyright Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7426 From mcimadamore at openjdk.java.net Fri Feb 11 10:15:08 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 11 Feb 2022 10:15:08 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v2] In-Reply-To: <99-oYqMwklU1DZYP5zXTNyqNRLbDMBi366uFH_Ywopc=.996865ad-3bee-413d-a4e8-b76ab9e08979@github.com> References: <99-oYqMwklU1DZYP5zXTNyqNRLbDMBi366uFH_Ywopc=.996865ad-3bee-413d-a4e8-b76ab9e08979@github.com> Message-ID: On Fri, 11 Feb 2022 03:49:45 GMT, Mandy Chung wrote: >> This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. >> >> The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > review comment Looks good. I like the fact that the factory for raw library now takes a MH.lookup instead of a class. And I also like that the paths for loading a library in raw mode vs. JNI mode are more clearly separated, I think this should help Panama, thanks! One fly-by comment is that there is still residual common logic in how clients are expected to load libraries (e.g. either using a file name/absolute path, or using a library name, without file separator chars). These assumption seem very heavily influenced by how System::load/loadLibrary do things, I believe - and I wonder if they can, in the future, create other obstacles for a raw kind of library loading (which expects to be mostly a wrapper around dlopen/LoadLibrary). But that's a question/problem for another day. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7435 From redestad at openjdk.java.net Fri Feb 11 11:40:07 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Feb 2022 11:40:07 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 12:51:31 GMT, Claes Redestad wrote: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > Hi Claes, it can get implemented similarly on PPC64: #7430 You can integrate it if you prefer that, but better after it got a Review. Hi Martin, perfect! Ideally we can get all platforms that has a `hasNegatives` intrinsic moved over so we can just switch it over big-bang style: remove the `@IntrinsicCandidate`, avoid contortions to pick the "right" implementation on the Java level based on which intrinsic is available and drop all VM-internal scaffolding for `hasNegatives`. Then it makes perfect sense to fold your patch into this PR, rather than have a tail of follow-ups. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From duke at openjdk.java.net Fri Feb 11 11:58:09 2022 From: duke at openjdk.java.net (stefan-zobel) Date: Fri, 11 Feb 2022 11:58:09 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Thu, 10 Feb 2022 18:09:19 GMT, XenoAmess wrote: > I investigated most of the usages. They just give a size, and get a capacity, even not change the 0.75 So maybe we can use some int calculation to replace the 0.75, thus replace Math.ceil for such situations. FWIW, `(int) Math.ceil(expected / 0.75)` and `(int) ((expected * 4L + 2L) / 3L)` would be equivalent. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From redestad at openjdk.java.net Fri Feb 11 12:11:54 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Feb 2022 12:11:54 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v2] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad 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: - Merge branch 'master' into count_positives - Restore partial vector checks in AVX2 and SSE intrinsic variants - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral - Simplify changes to encodeUTF8 - Fix little-endian error caught by testing - Reduce jumps in the ascii path - Remove unused tail_mask - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives) - Add more comments, simplify tail branching in AVX512 variant - Resolve issues in the precise implementation - ... and 13 more: https://git.openjdk.java.net/jdk/compare/42073fce...c4bb3612 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/2a855eb6..c4bb3612 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=00-01 Stats: 18287 lines in 533 files changed: 12765 ins; 2983 del; 2539 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From duke at openjdk.java.net Fri Feb 11 12:29:05 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 12:29:05 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Feb 2022 11:55:13 GMT, stefan-zobel wrote: > > I investigated most of the usages. They just give a size, and get a capacity, even not change the 0.75 So maybe we can use some int calculation to replace the 0.75, thus replace Math.ceil for such situations. > > FWIW, `(int) Math.ceil(expected / 0.75)` and `(int) ((expected * 4L + 2L) / 3L)` would be equivalent. Yes, and `(int) ((expected * 4L + 2L) / 3L)` actually equals `(expected + (expected + 2) / 3)` IMO, thus even avoid cast to long. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 12:58:52 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 12:58:52 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v2] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap.putAll can cause redundant space waste XenoAmess 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: 9072610: HashMap.putAll can cause redundant space waste ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/b4098ac6..f18fc5e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=00-01 Stats: 14 lines in 3 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From dholmes at openjdk.java.net Fri Feb 11 13:01:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Feb 2022 13:01:04 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote: >> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > updating copyright Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7426 From duke at openjdk.java.net Fri Feb 11 13:04:38 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 13:04:38 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap.putAll can cause redundant space waste XenoAmess 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: 9072610: HashMap.putAll can cause redundant space waste ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/f18fc5e4..bb42df9c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 13:45:05 2022 From: duke at openjdk.java.net (liach) Date: Fri, 11 Feb 2022 13:45:05 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v6] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:25:16 GMT, Peter Levart wrote: >> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 685: >> >>> 683: instance = c = load(); >>> 684: } >>> 685: return c; >> >> If you do that the "old" way, you loose the ability for JIT to constant-fold the `instance` and by transitivity the Config instance fields, since the check for `VM.isModuleSystemInited()` can't be elided. As suggested, the fast-path check should be done 1st, like: >> >> >> private static @Stable Config instance; >> >> private static Config instance() { >> Config c = instance; >> if (c != null) { >> return c; >> } >> >> // Defer initialization until module system is initialized so as >> // to avoid inflation and spinning bytecode in unnamed modules >> // during early startup. >> if (!VM.isModuleSystemInited()) { >> return DEFAULT; >> } >> >> instance = c = load(); >> return c; >> } > > ...having suggested that rearrangement, perhaps the right way to do it is to enable some VM.isXXX queries themselves to be constant-foldable so that other callers too may benefit. Like this: > https://github.com/plevart/jdk/commit/e918ccc52bbc288f6721af5fa66d8f7a8cc880cf > WDYT? I believe your patch to fold these methods is a good choice: for example, `FileSystems.getDefault()` will be constant-foldable as a result. For shutdown, the benefit may look negligible, but a consistency in style is beneficial. To make this more efficient, I recommend looking at the callers to `VM.initLevel()` and replace with such boolean checks if possible: for example, `ClassLoader.getSystemClassLoader` may be constant-foldable if its default branch of switch on init level become a dedicated fast path. Since this change affects multiple components and beyond the reflection factory itself, I don't think I will include it here; I will just use the right arrangement. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From alanb at openjdk.java.net Fri Feb 11 13:49:09 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 11 Feb 2022 13:49:09 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v3] In-Reply-To: <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com> References: <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com> Message-ID: On Thu, 10 Feb 2022 21:35:56 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the attached patch to address >> >> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter >> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs >> >> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with two additional commits since the last revision: > > - Return a null InputStream when the ZipEntry is not found in the Jar > - Address formatting and message feedback src/java.base/share/classes/java/util/jar/JarFile.java line 881: > 879: ze = getJarEntry(entryName); > 880: } else { > 881: throw new ZipException("ZipEntry::getName returned null"); Throwing ZipException when ZipEntry::getName returns null is still surprising but not terrible. The spec for getInputStream specifies ZipException for when a zip file format occurs so we might have to extend that to add "or the zip entry name is null". ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From duke at openjdk.java.net Fri Feb 11 13:51:38 2022 From: duke at openjdk.java.net (liach) Date: Fri, 11 Feb 2022 13:51:38 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v7] In-Reply-To: References: Message-ID: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. > > This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) liach has updated the pull request incrementally with two additional commits since the last revision: - The fast path should always come first. good lesson learned! restore config field comments - Try making the config a record and see if it works ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6889/files - new: https://git.openjdk.java.net/jdk/pull/6889/files/f32ff988..affda902 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=05-06 Stats: 55 lines in 1 file changed: 9 ins; 19 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/6889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889 PR: https://git.openjdk.java.net/jdk/pull/6889 From rriggs at openjdk.java.net Fri Feb 11 15:07:08 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 11 Feb 2022 15:07:08 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> On Fri, 11 Feb 2022 13:04:38 GMT, XenoAmess wrote: >> 8281631: HashMap.putAll can cause redundant space waste > > XenoAmess 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: > > 9072610: HashMap.putAll can cause redundant space waste src/java.base/share/classes/java/util/WeakHashMap.java line 247: > 245: */ > 246: private static int calculateHashMapCapacity(int size){ > 247: return size + (size + 2) / 3; Consider integer overflow; if size were Integer.MAX_VALUE / 2; the computation would overflow. The negative result would eventually throw an exception. Using Long for the computation would avoid that and keep the expression simple. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 15:28:10 2022 From: duke at openjdk.java.net (Sam Brannen) Date: Fri, 11 Feb 2022 15:28:10 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 22:12:57 GMT, Joe Darcy wrote: >> Two changes to the toString output for annotations to give better source fidelity: >> >> 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. >> >> 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) >> >> Various existing regression tests are updated to accommodate the changes. >> >> Please also review the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8281568 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 148: > 146: StringBuilder result = new StringBuilder(128); > 147: result.append('@'); > 148: // Guard against shouldn't-happen NPE for a missing canonical name NIT: A NPE would not be thrown. Rather, `"null"` would be appended to the buffer. Right? ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From duke at openjdk.java.net Fri Feb 11 15:34:06 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 15:34:06 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> Message-ID: On Fri, 11 Feb 2022 15:04:03 GMT, Roger Riggs wrote: > if size were Integer.MAX_VALUE / 2; the computation would overflow Actually will not, it must be slightly larger. it will only overflow when it be larger than Integer.MAX_VALUE * 0.75 But yes, it can overflow when there be a map as large as that. > Using Long for the computation would avoid that and keep the expression simple. but it be slower. I do think a int check can do same thing, and would add it . Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 15:36:13 2022 From: duke at openjdk.java.net (Sam Brannen) Date: Fri, 11 Feb 2022 15:36:13 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v2] In-Reply-To: References: Message-ID: <8vjwyu44CD0O9u5iexvOaRgtZ5BPLWm9CiZHs7qBEfY=.456c485c-8e81-4de5-9716-3d99b0ceeff6@github.com> On Thu, 10 Feb 2022 22:09:16 GMT, Joe Darcy wrote: >> src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 256: >> >>> 254: return Objects.toString(finalComponent.getCanonicalName(), >>> 255: "") + >>> 256: arrayBrackets.toString() + ".class"; >> >> Since we're using the canonical name now (which takes the array brackets into account), can't the whole method be simplified down to the following? >> >> Suggestion: >> >> return Objects.toString(clazz.getCanonicalName(), "") + ".class"; > > The getCanonicalName is not specified to behave that way, should be a RFE I suppose, but appears to in practice; changed as suggested in subsequent push. Thanks. Thanks, Joe. Regarding the RFE, do you plan to open an issue to address the documentation for `getCanonicalName`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From duke at openjdk.java.net Fri Feb 11 15:36:12 2022 From: duke at openjdk.java.net (Sam Brannen) Date: Fri, 11 Feb 2022 15:36:12 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 22:12:57 GMT, Joe Darcy wrote: >> Two changes to the toString output for annotations to give better source fidelity: >> >> 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. >> >> 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) >> >> Various existing regression tests are updated to accommodate the changes. >> >> Please also review the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8281568 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by sbrannen at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From mdoerr at openjdk.java.net Fri Feb 11 15:38:16 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 11 Feb 2022 15:38:16 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 12:11:54 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad 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: > > - Merge branch 'master' into count_positives > - Restore partial vector checks in AVX2 and SSE intrinsic variants > - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral > - Simplify changes to encodeUTF8 > - Fix little-endian error caught by testing > - Reduce jumps in the ascii path > - Remove unused tail_mask > - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives) > - Add more comments, simplify tail branching in AVX512 variant > - Resolve issues in the precise implementation > - ... and 13 more: https://git.openjdk.java.net/jdk/compare/811eb365...c4bb3612 Hi Claes, doing it for all platforms and cleaning it up sounds good. My PPC64 contribution is already tested and reviewed. I'll try to find a volunteer for s390 which uses exactly the same algorithm as PPC64. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Fri Feb 11 15:45:10 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Feb 2022 15:45:10 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 12:11:54 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad 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: > > - Merge branch 'master' into count_positives > - Restore partial vector checks in AVX2 and SSE intrinsic variants > - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral > - Simplify changes to encodeUTF8 > - Fix little-endian error caught by testing > - Reduce jumps in the ascii path > - Remove unused tail_mask > - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives) > - Add more comments, simplify tail branching in AVX512 variant > - Resolve issues in the precise implementation > - ... and 13 more: https://git.openjdk.java.net/jdk/compare/690b05fa...c4bb3612 Good! I'm currently reading up on aarch64 asm and trying to port that intrinsic over. It might take some time.. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From duke at openjdk.java.net Fri Feb 11 15:46:39 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 15:46:39 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v4] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap.putAll can cause redundant space waste XenoAmess has updated the pull request incrementally with one additional commit since the last revision: 9072610: HashMap.putAll can cause redundant space waste ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/bb42df9c..2a1bf274 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=02-03 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 15:53:07 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 15:53:07 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> Message-ID: On Fri, 11 Feb 2022 15:04:03 GMT, Roger Riggs wrote: >> XenoAmess 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: >> >> 9072610: HashMap.putAll can cause redundant space waste > > src/java.base/share/classes/java/util/WeakHashMap.java line 247: > >> 245: */ >> 246: private static int calculateHashMapCapacity(int size){ >> 247: return size + (size + 2) / 3; > > Consider integer overflow; if size were Integer.MAX_VALUE / 2; the computation would overflow. > The negative result would eventually throw an exception. Using Long for the computation would avoid that and keep the expression simple. @RogerRiggs Hi. I added a overflow check. The check makes sure it cannot overflow now. I wrote a test to show this overflow check be correct. public class A { /** * use for calculate HashMap capacity, using default load factor 0.75 * * @param size size * @return HashMap capacity under default load factor */ private static int calculateHashMapCapacity(int size) { if (size > (int) (Integer.MAX_VALUE * 0.75)) { return Integer.MAX_VALUE; } return size + (size + 2) / 3; } public static void main(String[] args) { for (int i = 1; i < Integer.MAX_VALUE ; ++i) { if (calculateHashMapCapacity(i) <= 0) { System.err.println(i); return; } } } } I also see the compiled result to make sure the `(int) (Integer.MAX_VALUE * 0.75)` calculation is made at compiling but not runtime, which will not make this function too much slower. please review again, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From djelinski at openjdk.java.net Fri Feb 11 16:28:08 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 11 Feb 2022 16:28:08 GMT Subject: Integrated: 8281259: MutableBigInteger subtraction could be simplified In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 10:13:28 GMT, Daniel Jeli?ski wrote: > The proposed form of borrow bit handling is [already used in BigInteger class](https://github.com/djelinski/jdk/blob/ce26a19be5e907c11164b46f1bcb370b534d5bf6/src/java.base/share/classes/java/math/BigInteger.java#L1558). > > JMH results without the patch: > > Benchmark (maxNumbits) Mode Cnt Score Error Units > BigIntegers.testGcd 256 avgt 25 3181205,367 ? 155272,427 ns/op > > JMH results with the patch applied: > > Benchmark (maxNumbits) Mode Cnt Score Error Units > BigIntegers.testGcd 256 avgt 25 2696030,849 ? 14141,940 ns/op This pull request has now been integrated. Changeset: e73ee0ca Author: Daniel Jeli?ski Committer: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/e73ee0ca10b644600ee3747b901e5f69104d03df Stats: 16 lines in 2 files changed: 11 ins; 0 del; 5 mod 8281259: MutableBigInteger subtraction could be simplified Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/7342 From rriggs at openjdk.java.net Fri Feb 11 16:36:10 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 11 Feb 2022 16:36:10 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> Message-ID: On Fri, 11 Feb 2022 15:48:44 GMT, XenoAmess wrote: >> src/java.base/share/classes/java/util/WeakHashMap.java line 247: >> >>> 245: */ >>> 246: private static int calculateHashMapCapacity(int size){ >>> 247: return size + (size + 2) / 3; >> >> Consider integer overflow; if size were Integer.MAX_VALUE / 2; the computation would overflow. >> The negative result would eventually throw an exception. Using Long for the computation would avoid that and keep the expression simple. > > @RogerRiggs > > Hi. I added a overflow check. > > The check makes sure it cannot overflow now. > > I wrote a test to show this overflow check be correct. > > > public class A { > > /** > * use for calculate HashMap capacity, using default load factor 0.75 > * > * @param size size > * @return HashMap capacity under default load factor > */ > private static int calculateHashMapCapacity(int size) { > if (size > (int) (Integer.MAX_VALUE * 0.75)) { > return Integer.MAX_VALUE; > } > return size + (size + 2) / 3; > } > > public static void main(String[] args) { > for (int i = 1; i < Integer.MAX_VALUE ; ++i) { > if (calculateHashMapCapacity(i) <= 0) { > System.err.println(i); > return; > } > } > } > } > > > > I also see the compiled result to make sure the `(int) (Integer.MAX_VALUE * 0.75)` calculation is made at compiling but not runtime, which will not make this function too much slower. > > please review again, thanks! Performance is a lesser issue. Given all of the other computation that occurs to populate the map, this computation is in the noise. It is also likely that with more instructions to fetch and execute and a possible branch, the integer check is slower. With current hardware, the long divide dominates the cost. Addition is almost free. Code maintainability is more important; keep the source code simple and concise. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From plevart at openjdk.java.net Fri Feb 11 16:52:08 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 11 Feb 2022 16:52:08 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v7] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 13:51:38 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > liach has updated the pull request incrementally with two additional commits since the last revision: > > - The fast path should always come first. good lesson learned! > restore config field comments > - Try making the config a record and see if it works Marked as reviewed by plevart (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From plevart at openjdk.java.net Fri Feb 11 16:52:09 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 11 Feb 2022 16:52:09 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v6] In-Reply-To: References: Message-ID: <4V5fKwOiceIfn-UmjheMSTn4PM3-56aiix2BNZmL78I=.75d72eba-a8e4-4d77-bd10-eac70d4c13f3@github.com> On Fri, 11 Feb 2022 13:42:01 GMT, liach wrote: >> ...having suggested that rearrangement, perhaps the right way to do it is to enable some VM.isXXX queries themselves to be constant-foldable so that other callers too may benefit. Like this: >> https://github.com/plevart/jdk/commit/e918ccc52bbc288f6721af5fa66d8f7a8cc880cf >> WDYT? > > I believe your patch to fold these methods is a good choice: for example, `FileSystems.getDefault()` will be constant-foldable as a result. > For shutdown, the benefit may look negligible, but a consistency in style is beneficial. > To make this more efficient, I recommend looking at the callers to `VM.initLevel()` and replace with such boolean checks if possible: for example, `ClassLoader.getSystemClassLoader` may be constant-foldable if its default branch of switch on init level become a dedicated fast path. > > Since this change affects multiple components and beyond the reflection factory itself, I don't think I will include it here; I will just use the right arrangement. This belongs to another jbs ticket. Right, I wasn't suggesting to include that in the patch. Local rearrangement is OK anyway. Latest code looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From duke at openjdk.java.net Fri Feb 11 17:10:43 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 17:10:43 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v5] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap.putAll can cause redundant space waste XenoAmess has updated the pull request incrementally with one additional commit since the last revision: 9072610: HashMap.putAll can cause redundant space waste ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/2a1bf274..c6654478 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=03-04 Stats: 14 lines in 1 file changed: 0 ins; 13 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 17:10:44 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 17:10:44 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> Message-ID: On Fri, 11 Feb 2022 16:32:29 GMT, Roger Riggs wrote: >> @RogerRiggs >> >> Hi. I added a overflow check. >> >> The check makes sure it cannot overflow now. >> >> I wrote a test to show this overflow check be correct. >> >> >> public class A { >> >> /** >> * use for calculate HashMap capacity, using default load factor 0.75 >> * >> * @param size size >> * @return HashMap capacity under default load factor >> */ >> private static int calculateHashMapCapacity(int size) { >> if (size > (int) (Integer.MAX_VALUE * 0.75)) { >> return Integer.MAX_VALUE; >> } >> return size + (size + 2) / 3; >> } >> >> public static void main(String[] args) { >> for (int i = 1; i < Integer.MAX_VALUE ; ++i) { >> if (calculateHashMapCapacity(i) <= 0) { >> System.err.println(i); >> return; >> } >> } >> } >> } >> >> >> >> I also see the compiled result to make sure the `(int) (Integer.MAX_VALUE * 0.75)` calculation is made at compiling but not runtime, which will not make this function too much slower. >> >> please review again, thanks! > > Performance is a lesser issue. Given all of the other computation that occurs to populate the map, this computation is in the noise. It is also likely that with more instructions to fetch and execute and a possible branch, the integer check is slower. > With current hardware, the long divide dominates the cost. Addition is almost free. > > Code maintainability is more important; keep the source code simple and concise. @RogerRiggs so you recommend `(int) Math.min(((m.size() * 4L + 2L) / 3L), Integer.MAX_VALUE)`? OK then, changed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 17:36:19 2022 From: duke at openjdk.java.net (liach) Date: Fri, 11 Feb 2022 17:36:19 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v7] In-Reply-To: References: Message-ID: <12gJlvm05bYIVOpROD5Et1ZJkNrZ4cvcKd08ddZqhMo=.ad051e2f-6fe9-42c6-b741-293bae0a9094@github.com> On Fri, 11 Feb 2022 13:51:38 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > liach has updated the pull request incrementally with two additional commits since the last revision: > > - The fast path should always come first. good lesson learned! > restore config field comments > - Try making the config a record and see if it works mandy, does this patch look good? i added a comment to warn about indy for records so as to avoid future unintended problems, while the current setup looks safe. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From lancea at openjdk.java.net Fri Feb 11 17:50:09 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 11 Feb 2022 17:50:09 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v3] In-Reply-To: References: <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com> Message-ID: <0COr36OwTtowa8BVOnS_ZSR7mhByee9jwWl6f-4ps3E=.1969f9d1-bbae-45bb-818f-cfa7864a802d@github.com> On Fri, 11 Feb 2022 13:45:47 GMT, Alan Bateman wrote: >> Lance Andersen has updated the pull request incrementally with two additional commits since the last revision: >> >> - Return a null InputStream when the ZipEntry is not found in the Jar >> - Address formatting and message feedback > > src/java.base/share/classes/java/util/jar/JarFile.java line 881: > >> 879: ze = getJarEntry(entryName); >> 880: } else { >> 881: throw new ZipException("ZipEntry::getName returned null"); > > Throwing ZipException when ZipEntry::getName returns null is still surprising but not terrible. The spec for getInputStream specifies ZipException for when a zip file format occurs so we might have to extend that to add "or the zip entry name is null". If you would like me to update the ZipException to clarify this I can. The original issue was due to a format error in the CEN so the current wording covers that. It does not cover the case where ZipEntry is subclassed and ZipEntry::getName() returns null which is what your suggested wording would address. Please note the above change addresses the signed jar scenario. I can add an additional check in JarFile::getInputStream to check for null from ZipEntry::getName so that it covers unsigned jars and signed jars not being verified. The issue will not occur with ZipEntry::getInputStream given its use of ZipEntry.name which can never be null. Please let me know your preference ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From mchung at openjdk.java.net Fri Feb 11 18:10:11 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Feb 2022 18:10:11 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v2] In-Reply-To: References: <99-oYqMwklU1DZYP5zXTNyqNRLbDMBi366uFH_Ywopc=.996865ad-3bee-413d-a4e8-b76ab9e08979@github.com> Message-ID: On Fri, 11 Feb 2022 10:11:50 GMT, Maurizio Cimadamore wrote: > there is still residual common logic in how clients are expected to load libraries (e.g. either using a file name/absolute path, or using a library name, without file separator chars). These assumption seem very heavily influenced by how System::load/loadLibrary do things, I believe - and I wonder if they can, in the future, create other obstacles for a raw kind of library loading (which expects to be mostly a wrapper around dlopen/LoadLibrary). But that's a question/problem for another day. Good point. With the removal of the restriction, the raw library loading implementation can further be cleaned up (not be tied with the jni library loading logic). I'll look into what it takes and whether I should do it in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7435 From rriggs at openjdk.java.net Fri Feb 11 18:17:12 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 11 Feb 2022 18:17:12 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> Message-ID: On Fri, 11 Feb 2022 17:04:14 GMT, XenoAmess wrote: >> Performance is a lesser issue. Given all of the other computation that occurs to populate the map, this computation is in the noise. It is also likely that with more instructions to fetch and execute and a possible branch, the integer check is slower. >> With current hardware, the long divide dominates the cost. Addition is almost free. >> >> Code maintainability is more important; keep the source code simple and concise. > > @RogerRiggs > so you recommend `(int) Math.min(((m.size() * 4L + 2L) / 3L), Integer.MAX_VALUE)`? OK then, changed it. > please review again, thanks! Works for me. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From aph at openjdk.java.net Fri Feb 11 18:28:09 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 11 Feb 2022 18:28:09 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> Message-ID: On Fri, 11 Feb 2022 18:13:36 GMT, Roger Riggs wrote: >> @RogerRiggs >> so you recommend `(int) Math.min(((m.size() * 4L + 2L) / 3L), Integer.MAX_VALUE)`? OK then, changed it. >> please review again, thanks! > > Works for me. Thanks Just multiply by 0.75. On a modern design, floating-point multiply is 4 clocks latency, 4 ops/clock throughput. FP max is 2 clocks latency, conversions int-float and vice versa 3 clocks latency, 4 ops/clock throughput. Long division is 7-9 clocks, 2ops/clock throughput. Shift and add 2 clocks, 2/3 ops/clock througput. Compare is 1 clock, 3 ops/clock throughput, conditional move is 1 clock, 3 ops/clock throughput. Seems like it's a wash. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From darcy at openjdk.java.net Fri Feb 11 18:44:44 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 11 Feb 2022 18:44:44 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection Message-ID: This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. ------------- Commit messages: - JDK-8266670: Better modeling of modifiers in core reflection Changes: https://git.openjdk.java.net/jdk/pull/7445/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266670 Stats: 345 lines in 6 files changed: 345 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From smarks at openjdk.java.net Fri Feb 11 18:45:12 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 11 Feb 2022 18:45:12 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Feb 2022 12:25:08 GMT, XenoAmess wrote: > FWIW, (int) Math.ceil(expected / 0.75) and (int) ((expected * 4L + 2L) / 3L) would be equivalent. No, they are not equivalent. If `expected` exceeds a certain value around 1.6bn, then the intermediate result using the second expression will be greater than Integer.MAX_VALUE. Casting this to `int` can result in a negative number. In the first expression, a double value that exceeds the range of `int` will saturate at Integer.MAX_VALUE. jshell> (int) ((1700000000 * 4L + 2L) / 3L) $24 ==> -2028300629 jshell> (int) Math.ceil(1700000000 / 0.75) $25 ==> 2147483647 Let's stick with the `Math.ceil` expression please. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From smarks at openjdk.java.net Fri Feb 11 18:45:13 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 11 Feb 2022 18:45:13 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v5] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Feb 2022 17:10:43 GMT, XenoAmess wrote: >> 8281631: HashMap.putAll can cause redundant space waste > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > 9072610: HashMap.putAll can cause redundant space waste (It's too late now, but I'd suggest avoiding force-pushing changes into a branch that's opened in a PR. Doing so confuses the comment history, as the comments refer to code that is no longer present.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 18:54:15 2022 From: duke at openjdk.java.net (kabutz) Date: Fri, 11 Feb 2022 18:54:15 GMT Subject: Integrated: JDK-8277175 : Add a parallel multiply method to BigInteger In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 13:22:46 GMT, kabutz wrote: > BigInteger currently uses three different algorithms for multiply. The simple quadratic algorithm, then the slightly better Karatsuba if we exceed a bit count and then Toom Cook 3 once we go into the several thousands of bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to parallelize it. I have demonstrated this several times in conference talks. In order to be consistent with other classes such as Arrays and Collection, I have added a parallelMultiply() method. Internally we have added a parameter to the private multiply method to indicate whether the calculation should be done in parallel. > > The performance improvements are as should be expected. Fibonacci of 100 million (using a single-threaded Dijkstra's sum of squares version) completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with the sequential multiply() method. This is on my 1-8-2 laptop. The final multiplications are with very large numbers, which then benefit from the parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. > > We have also parallelized the private square() method. Internally, the square() method defaults to be sequential. > > Some benchmark results, run on my 1-6-2 server: > > > Benchmark (n) Mode Cnt Score Error Units > BigIntegerParallelMultiply.multiply 1000000 ss 4 51.707 ? 11.194 ms/op > BigIntegerParallelMultiply.multiply 10000000 ss 4 988.302 ? 235.977 ms/op > BigIntegerParallelMultiply.multiply 100000000 ss 4 24662.063 ? 1123.329 ms/op > BigIntegerParallelMultiply.parallelMultiply 1000000 ss 4 49.337 ? 26.611 ms/op > BigIntegerParallelMultiply.parallelMultiply 10000000 ss 4 527.560 ? 268.903 ms/op > BigIntegerParallelMultiply.parallelMultiply 100000000 ss 4 9076.551 ? 1899.444 ms/op > > > We can see that for larger calculations (fib 100m), the execution is 2.7x faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for small (fib 1m) it is roughly the same. Considering that the fibonacci algorithm that we used was in itself sequential, and that the last 3 calculations would dominate, 2.7x faster should probably be considered quite good on a 1-6-2 machine. This pull request has now been integrated. Changeset: 83ffbd2e Author: Dr Heinz M. Kabutz Committer: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/83ffbd2e7aed8a9c788395ccbe920ddff221ae16 Stats: 601 lines in 4 files changed: 582 ins; 0 del; 19 mod 8277175: Add a parallel multiply method to BigInteger Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/6409 From duke at openjdk.java.net Fri Feb 11 19:25:19 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 19:25:19 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v5] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Feb 2022 17:10:43 GMT, XenoAmess wrote: >> 8281631: HashMap.putAll can cause redundant space waste > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > 9072610: HashMap.putAll can cause redundant space waste > > FWIW, (int) Math.ceil(expected / 0.75) and (int) ((expected * 4L + 2L) / 3L) would be equivalent. > > No, they are not equivalent. If `expected` exceeds a certain value around 1.6bn, then the intermediate result using the second expression will be greater than Integer.MAX_VALUE. Casting this to `int` can result in a negative number. > > FWIW, (int) Math.ceil(expected / 0.75) and (int) ((expected * 4L + 2L) / 3L) would be equivalent. that is exactly why we added this check when it can reach such situation. if (size > (int) (Integer.MAX_VALUE * 0.75)) { return Integer.MAX_VALUE; } ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 19:25:20 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 19:25:20 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v5] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <9-OCMkv8332OF8qTfh4asEkG7luuS6XSb05dWEdBi5Y=.942d8893-d17c-4f1e-a3bb-0cecc81ac99b@github.com> On Fri, 11 Feb 2022 18:42:11 GMT, Stuart Marks wrote: > (It's too late now, but I'd suggest avoiding force-pushing changes into a branch that's opened in a PR. Doing so confuses the comment history, as the comments refer to code that is no longer present.) got it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From stuart.marks at oracle.com Fri Feb 11 19:25:19 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 11 Feb 2022 11:25:19 -0800 Subject: [External] : Sequenced Collections In-Reply-To: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> Message-ID: <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> Hi R?mi, I see that you're trying to reduce the number of interfaces introduced by unifying things around an existing interface, List. Yes, it's true that List is an ordered collection. However, your analysis conveniently omits other facts about List that make it unsuitable as a general "ordered collection" interface. Specifically: 1) List supports element access by int index; and 2) List is externally ordered. That is, its ordering is determined by a succession of API calls, irrespective of element values. This is in contrast to SortedSet et al which are internally ordered, in that the ordering is determined by the element values. The problem with indexed element access is that it creates a bunch of hidden performance pitfalls for any data structure where element access is other than O(1). So get(i) degrades to O(n), binarySearch degrades from O(log n) to O(n). (This is in the sequential implementation; the random access implementation degrades to O(n log n)). Apparently innocuous indexed for-loops degrade to quadratic. This is one of the reasons why LinkedList is a bad List implementation. If we refactor LinkedHashSet to implement List, we basically have created another situation just like LinkedList. That's a step in the wrong direction. Turning to internal ordering (SortedSet): it's fundamentally incompatible with List's external ordering. List has a lot of positional mutation operations such as add(i, obj); after this call, you expect obj to appear at position i. That can't work with a SortedSet. There is implicit positioning semantics in other methods that don't have index arguments. For example, replaceAll replaces each element of a List with the result of calling a function on that element. Crucially, the function result goes into the same location as the original element. That to cannot work with SortedSet. Well, we can try to deal with these issues somehow, like making certain methods throw UnsupportedOperationException, or by relaxing the semantics of the methods so that they no longer have the same element positioning semantics. Either of these approaches contorts the List interface to such an extent that it's no longer a List. So, no, it's not useful or effective to try to make List be the common "ordered collection" interface. s'marks On 2/10/22 3:14 AM, Remi Forax wrote: > I've read the draft of the JEP on sequenced collection, and i think the proposed design can be improved. > https://bugs.openjdk.java.net/browse/JDK-8280836 > > I agree with the motivation, there is a need for an API to consider the element of a list, a sorted set and a linked hash set as an ordered sequence of elements with a simple way to access/add/remove the first/last element and also reverse the elements as view. > > I disagree about the conclusion that we need to introduce 4 new interfaces for that matter. > > Here are the reasons > 1/ Usually an ordered collection is called a list. Introducing an interface SequencedCollection for something which is usually called a list will cause more harm than good. Or maybe we should rename LISP to SEQP :) > > 2/ There is already an interface List in Java, that represents an ordered sequence of elements, with LinkedList being the name of the the double linked list implementation. You can argue that there is a slight difference between the semantics of java.util.List and the proposed syntax of java.util.SequencedCollection, but given that people already have difficulties to understand basic data structure concepts, as a teacher i dread to have a discussion on those slight differences that are only true in Java. > > If the collection API was not already existing, we may discuss about having the same interface java.util.List to both indexed collection and ordered collection, but that boat has sailed a long time ago. > > So in first approach, we should refactor sorted set and linked hash set to directly implement java.util.List and all the proposed methods into java.util.List. But as you hint in the Risks and Assumptions section, this will cause regression due to inference and also we will have trouble with LinkedHashMap (see below). > > 3/ LinkedHashMap mixes 3 implementations in one class, some of these implementations does not conform to the semantics of SequencedMap. > - You can opt-out having the key sequentially ordered as defined by SequencedMap by using the constructor LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) and passing true as last parameter. > - You can opt-out having the key sequentially ordered as defined by SequencedMap by overriding removeEldestEntry(), removing the first entry at the same time you add a new one. > > Because all these reasons, i think we should move to another design, using delegation instead of inheritance, which for the collection framework means exposing new way to access/modify sorted set and linked hash set through java.util.List views. > > The concept of views is not a new concept, it's used in Arrays.asList(), List.subList() or Map.keySet()/values()/entrySet() (and more). The idea is not that a sorted set is a list but that it provides a method to see it as a list. It solves our problem of compatibility by not adding super types to existing type and also the problem of the semantics of LinkedHashMap because a view keeps the semantics of the data structure it originated. > > Here is the proposed new methods in List, SortedSet and SortedMap. > > interface List extends Collection { > // new methods > void addFirst(); > void addLast(); > E getFirst(); > E getLast(); > E removeFirst(); > E removeLast(); > List reversedList(); // or descendingList() ?? > } > > interface SortedSet implements Set { > // new methods > List asList(); > } > > interface SortedMap implements Map { > // new methods > List keyList(); // do not use covariant return type > List> entryList(); // same > } > > I believe this design is objectively better than the one proposed because as a user being able to use new interfaces is a slow process, the libraries/dependencies must be updated to take the new interfaces as parameter before the new types can be used. By contrast, the proposed design only enhance existing interfaces so people will enjoy the new methods directly when introduced. > > R?mi > From duke at openjdk.java.net Fri Feb 11 19:25:20 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 19:25:20 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> Message-ID: On Fri, 11 Feb 2022 18:24:49 GMT, Andrew Haley wrote: > Just multiply by 0.75. > > On a modern design, floating-point multiply is 4 clocks latency, 4 ops/clock throughput. FP max is 2 clocks latency, conversions int-float and vice versa 3 clocks latency, 4 ops/clock throughput. Long division is 7-9 clocks, 2ops/clock throughput. Shift and add 2 clocks, 2/3 ops/clock througput. Compare is 1 clock, 3 ops/clock throughput, conditional move is 1 clock, 3 ops/clock throughput. > > Seems like it's a wash. @theRealAph no multiply but divide. besides, did you count the cost for Math.ceil? it is the heaviest part. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 19:25:20 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 19:25:20 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Feb 2022 18:40:53 GMT, Stuart Marks wrote: > Let's stick with the `Math.ceil` expression please. I'm afraid Math.ceil is much too time costing, but fine if you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 11 19:32:48 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Feb 2022 19:32:48 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v6] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <3gAe1sJ-OD0p22Jz7IXCDtv3K883wsg5JoNEQd9nPWQ=.7a3f1f2d-0c06-4998-a912-16f511a6b82d@github.com> > 8281631: HashMap.putAll can cause redundant space waste XenoAmess has updated the pull request incrementally with one additional commit since the last revision: 9072610: HashMap.putAll can cause redundant space waste ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/c6654478..4e42cae1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=04-05 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From darcy at openjdk.java.net Fri Feb 11 20:34:43 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 11 Feb 2022 20:34:43 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v3] In-Reply-To: References: Message-ID: > Two changes to the toString output for annotations to give better source fidelity: > > 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. > > 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) > > Various existing regression tests are updated to accommodate the changes. > > Please also review the CSR: > https://bugs.openjdk.java.net/browse/JDK-8281568 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 four additional commits since the last revision: - Respond to more review feedback. - Merge branch 'master' into JDK-8281462 - Respond to review feedback. - JDK-8281462: Annotation toString output for enum not reusable for source input ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7418/files - new: https://git.openjdk.java.net/jdk/pull/7418/files/2989ff11..0af92ea9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7418&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7418&range=01-02 Stats: 3897 lines in 70 files changed: 2865 ins; 435 del; 597 mod Patch: https://git.openjdk.java.net/jdk/pull/7418.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7418/head:pull/7418 PR: https://git.openjdk.java.net/jdk/pull/7418 From duke at openjdk.java.net Fri Feb 11 20:41:39 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Fri, 11 Feb 2022 20:41:39 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null Message-ID: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null ------------- Commit messages: - Merge branch 'master' into JDK-8281003 - Merge branch 'master' into JDK-8281003 - removed commented out code - Moved null caller MethodHandles.lookup() test to a more reasonable location - JDK-8281003 - MethodHandles::lookup throws NPE if caller is null Changes: https://git.openjdk.java.net/jdk/pull/7447/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281003 Stats: 88 lines in 4 files changed: 82 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7447.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447 PR: https://git.openjdk.java.net/jdk/pull/7447 From darcy at openjdk.java.net Fri Feb 11 20:42:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 11 Feb 2022 20:42:10 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v2] In-Reply-To: References: Message-ID: <_IZWi-xoLsiJH4PKlcocJwlJT94a1Ca-m2C9zJ7etq4=.7271300b-68d8-4c9c-aa7f-9f0cce808079@github.com> On Fri, 11 Feb 2022 15:24:45 GMT, Sam Brannen wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java line 148: > >> 146: StringBuilder result = new StringBuilder(128); >> 147: result.append('@'); >> 148: // Guard against shouldn't-happen NPE for a missing canonical name > > NIT: A NPE would not be thrown. Rather, `"null"` would be appended to the buffer. Right? Update comment in latest push. ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From darcy at openjdk.java.net Fri Feb 11 20:42:09 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 11 Feb 2022 20:42:09 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v3] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 20:34:43 GMT, Joe Darcy wrote: >> Two changes to the toString output for annotations to give better source fidelity: >> >> 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. >> >> 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) >> >> Various existing regression tests are updated to accommodate the changes. >> >> Please also review the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8281568 > > 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 four additional commits since the last revision: > > - Respond to more review feedback. > - Merge branch 'master' into JDK-8281462 > - Respond to review feedback. > - JDK-8281462: Annotation toString output for enum not reusable for source input PS I checked and the implementation of printing annotation in javac for annotation processing uses enum constant names (rather than toString values) and uses canonical rather than binary names for nested types. ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From duke at openjdk.java.net Fri Feb 11 20:45:39 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Fri, 11 Feb 2022 20:45:39 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Message-ID: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null ------------- Commit messages: - Merge branch 'master' into JDK-8281000 - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Changes: https://git.openjdk.java.net/jdk/pull/7448/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281000 Stats: 140 lines in 4 files changed: 139 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448 PR: https://git.openjdk.java.net/jdk/pull/7448 From darcy at openjdk.java.net Fri Feb 11 20:53:04 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 11 Feb 2022 20:53:04 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v3] In-Reply-To: <8vjwyu44CD0O9u5iexvOaRgtZ5BPLWm9CiZHs7qBEfY=.456c485c-8e81-4de5-9716-3d99b0ceeff6@github.com> References: <8vjwyu44CD0O9u5iexvOaRgtZ5BPLWm9CiZHs7qBEfY=.456c485c-8e81-4de5-9716-3d99b0ceeff6@github.com> Message-ID: On Fri, 11 Feb 2022 15:30:58 GMT, Sam Brannen wrote: >> The getCanonicalName is not specified to behave that way, should be a RFE I suppose, but appears to in practice; changed as suggested in subsequent push. Thanks. > > Thanks, Joe. > > Regarding the RFE, do you plan to open an issue to address the documentation for `getCanonicalName`? Filed https://bugs.openjdk.java.net/browse/JDK-8281671 ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From almatvee at openjdk.java.net Fri Feb 11 21:22:44 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 11 Feb 2022 21:22:44 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v2] In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: <9APLT6NMYVgxHT6-nYAffj03PrQGKUot1mbdqadmYGY=.1e393b4f-fdd9-4ed8-aebc-6e004ed7c866@github.com> > Added ability to override description for additional launchers via "description" property. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8279995: jpackage --add-launcher option should allow overriding description [v2] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7399/files - new: https://git.openjdk.java.net/jdk/pull/7399/files/a764be5b..dbb36905 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=00-01 Stats: 50 lines in 1 file changed: 49 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7399/head:pull/7399 PR: https://git.openjdk.java.net/jdk/pull/7399 From almatvee at openjdk.java.net Fri Feb 11 21:22:46 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 11 Feb 2022 21:22:46 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote: > Added ability to override description for additional launchers via "description" property. Added automated tests for .exe files in Windows and .desktop files on Linux. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From duke at openjdk.java.net Fri Feb 11 21:26:12 2022 From: duke at openjdk.java.net (liach) Date: Fri, 11 Feb 2022 21:26:12 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v2] In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 20:48:39 GMT, liach wrote: >> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. > > 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 five additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.java.net/jdk into identityhashmap-default > - update dates > - Also test cme for identity hash map > - Fix putIfAbsent > - JDK-8277520: Implement JDK-8 default methods for IdentityHashMap Slightly busy now, will write benchmarks later and publish results for before and after. ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From mchung at openjdk.java.net Fri Feb 11 21:48:10 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Feb 2022 21:48:10 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v7] In-Reply-To: References: Message-ID: <3jzorf2Deyd_EvWZpdwnxQyTkvAaWJDFXEVYfQiIfsM=.6028d1a6-b224-4cfa-9b6c-09d1a5f173f9@github.com> On Fri, 11 Feb 2022 13:51:38 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > liach has updated the pull request incrementally with two additional commits since the last revision: > > - The fast path should always come first. good lesson learned! > restore config field comments > - Try making the config a record and see if it works src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 620: > 618: * The configurations exist as an object to avoid race conditions. > 619: * See bug 8261407. The object methods backed by indy may not be available. > 620: */ This comment is a bit unclear. With the suggestion of moving the static `ReflectionFactory::config()` method and the comment I suggest below, I think that should be adequate to understand. If not, we should improve the comment rather than relying on the readers to read the bug report. Maybe the comment can be: Configuration for core reflection which is configurable via system properties. The user-configured settings are not available during early VM startup. Note that the object methods of this Config record are called via indy which is available to use after initPhase1. We can workaround that limitation by implementing the object methods. src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 631: > 629: // To avoid this penalty we reuse the existing JVM entry points > 630: // for the first few invocations of Methods and Constructors and > 631: // then switch to the bytecode-based implementations. This block of comment describes why the default for `noInflation` is false. This can be moved to L645 as the comment for the `DEFAULT` config. src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 638: > 636: // true if deserialization constructor checking is disabled > 637: boolean disableSerialConstructorChecks > 638: ) { Formatting: preferable to follow the style of the local file, e.g. like the `newConstructor` method declaration private record Config(boolean noInflation, int inflationThreshold, int useDirectMethodHandle, boolean useNativeAccessorOnly, boolean disableSerialConstructorChecks) { ``` Same comment for L645-651 and L719-725 src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 660: > 658: * run, before the system properties are set up. > 659: */ > 660: private static @Stable Config instance; The comment makes me think that this static field and the static `instance` method belong to `ReflectionFactory` class. The static initializer of java.lang.reflect.Method/AccessibleObject causes this class (ReflectionFactory) to be initialzed early during VM initialization where the configuration is not available. The `Config` class is just a data type representing the setting. When the `Config` class is initialized, it's irrelevant. That should help the readers easier to understand. A minor update to the comment may help too: /** * The configuration is lazily initialized after the module system is initialized. * * The static initializer of this class is run before the system properties are set up. * The class initialization is caused by the class initialization of java.lang.reflect.Method * (more properly, caused by the class initialization for java.lang.reflect.AccessibleObject) * that happens very early VM startup, initPhase1. */ private static @Stable Config config; If this static field is moved back to ReflectionFactory class, your original variable name `config` and the accessor method `config()` is clear. `Config::load` can be renamed to `Config::instance` then. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From forax at univ-mlv.fr Fri Feb 11 21:51:27 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 11 Feb 2022 22:51:27 +0100 (CET) Subject: [External] : Sequenced Collections In-Reply-To: <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> Message-ID: <528556518.2543494.1644616287132.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Stuart Marks" > To: "Remi Forax" > Cc: "core-libs-dev" > Sent: Friday, February 11, 2022 8:25:19 PM > Subject: Re: [External] : Sequenced Collections > Hi R?mi, > > I see that you're trying to reduce the number of interfaces introduced by > unifying > things around an existing interface, List. Yes, it's true that List is an > ordered > collection. However, your analysis conveniently omits other facts about List > that > make it unsuitable as a general "ordered collection" interface. Specifically: > > 1) List supports element access by int index; and > > 2) List is externally ordered. That is, its ordering is determined by a > succession > of API calls, irrespective of element values. This is in contrast to SortedSet > et al > which are internally ordered, in that the ordering is determined by the element > values. > > The problem with indexed element access is that it creates a bunch of hidden > performance pitfalls for any data structure where element access is other than > O(1). > So get(i) degrades to O(n), binarySearch degrades from O(log n) to O(n). (This > is in > the sequential implementation; the random access implementation degrades to O(n > log > n)). Apparently innocuous indexed for-loops degrade to quadratic. This is one of > the > reasons why LinkedList is a bad List implementation. > > If we refactor LinkedHashSet to implement List, we basically have created > another > situation just like LinkedList. That's a step in the wrong direction. Everybody is focused on LinkedList but that's not the problem, the problem is that, unlike every other languages, in Java, doing an indexed loop on a List is a bad idea. There are plenty of other implementations of AbstractSequentialList, other than LinkedList, that exhibits the same bad performance when used in an indexed loop. A simple search on github find a lot of classes that implements AbstractSequentialList https://github.com/search?l=Java&p=6&q=%22extends+AbstractSequentialList%22+-luni+-LinkedList&type=Code In fact, the problem of performance is not something inherent to the List API, it's true for any interface of the collection API, By example, AbstractSet.contains() is linear, CopyOnWriteArrayList/CopyOnWriteArraySet.add() is linear etc. The whole idea of using interfaces in the collection API is at the same time - great because you have more interropt - awful because you have usually no idea of the complexity of the method you call. BTW, if we want to be serious and solve the issue of indexed Loop on List, we should not have stop half way with the enhanced for loop, and also provides a way to get an index for an element when looping And obviously, there is also a need for a compiler warning to explain that doing an indexed loop on a List is bad. > > Turning to internal ordering (SortedSet): it's fundamentally incompatible with > List's external ordering. List has a lot of positional mutation operations such > as > add(i, obj); after this call, you expect obj to appear at position i. That can't > work with a SortedSet. I don't propose that SortedSet implements List, i propose to add a new method asList() to SortedSet that return a view of the sorted set as a List. Obviously, like the Set returned by Map.keySet() does not implement all the methods of Set, calling add() throws an UnsupportedOperationException, the method List.add(int,E) will throw an UnsupportedOperationException when called on the result of SortedSet.asList() > > There is implicit positioning semantics in other methods that don't have index > arguments. For example, replaceAll replaces each element of a List with the > result > of calling a function on that element. Crucially, the function result goes into > the > same location as the original element. That to cannot work with SortedSet. Not with SortedSet, like above, replace() is an optional method, it will not be implemented by the List returned by SortedSet.asList(), but LinkedHashSet.asList() may return a List that implements replace(). > > Well, we can try to deal with these issues somehow, like making certain methods > throw UnsupportedOperationException, or by relaxing the semantics of the methods > so > that they no longer have the same element positioning semantics. Either of these > approaches contorts the List interface to such an extent that it's no longer a > List. As said above, it's a list view, like by example the List returned by Arrays.asList() does not implement add(E)/add(int,E) or remove(int)/remove(E), the view of the List does not have to implement the methods that do a mutation using an index. > > So, no, it's not useful or effective to try to make List be the common "ordered > collection" interface. It is because this is how people are using List actually. It's the default type which is used to say, the elements are ordered by insertion order. You may think that this is wrong, but i think it's better to be more pragmatic here. Trying to change how people think given that this way of thinking is already enshrined in existing codes is futile. Here are some examples Let suppose we have a parking containing cars, a straightforward implementation is class Parking { private final ArrayList cars = new ArrayList<>(); public void add(Car car) { cars.add(car); } public Optional findCarByLicencePlate(String plate) { return cars.stream().filter(...).findFirst(); } public List cars() { return Collections.unmodifiableList(cars); } } After some perf analysis, you find that findCarByLicencePlate() is used a lot and should be optimized, the easiest refactoring is to use a hash map, exactly a linked hash map to keep the order correct. Here being able to get the list of values as a view of the linked hash map becomes very handy. class Parking { private final LinkedHashMap carMap = new LinkedHashMap<>(); public void add(Car car) { carMap.put(car.getLicencePlate(), car); } public Optional findCarByLicencePlate(String plate) { return Optional.ofNullable(carMap.get(plate)); } public List cars() { return Collections.unmodifiableList(carMap.valueList()); } } Another example, I've an array of values and i want a list of the element without the duplicates, one can write List list = Arrays.stream(array).distinct().toList(); but it creates a Set (used internally by distinct) and a list. With this new API, you can use the view List list = new LinkedHashSet<>(Arrays.asList(array)).asList(); > > s'marks R?mi > > > > On 2/10/22 3:14 AM, Remi Forax wrote: >> I've read the draft of the JEP on sequenced collection, and i think the proposed >> design can be improved. >> https://bugs.openjdk.java.net/browse/JDK-8280836 >> >> I agree with the motivation, there is a need for an API to consider the element >> of a list, a sorted set and a linked hash set as an ordered sequence of >> elements with a simple way to access/add/remove the first/last element and also >> reverse the elements as view. >> >> I disagree about the conclusion that we need to introduce 4 new interfaces for >> that matter. >> >> Here are the reasons >> 1/ Usually an ordered collection is called a list. Introducing an interface >> SequencedCollection for something which is usually called a list will cause >> more harm than good. Or maybe we should rename LISP to SEQP :) >> >> 2/ There is already an interface List in Java, that represents an ordered >> sequence of elements, with LinkedList being the name of the the double linked >> list implementation. You can argue that there is a slight difference between >> the semantics of java.util.List and the proposed syntax of >> java.util.SequencedCollection, but given that people already have difficulties >> to understand basic data structure concepts, as a teacher i dread to have a >> discussion on those slight differences that are only true in Java. >> >> If the collection API was not already existing, we may discuss about having the >> same interface java.util.List to both indexed collection and ordered >> collection, but that boat has sailed a long time ago. >> >> So in first approach, we should refactor sorted set and linked hash set to >> directly implement java.util.List and all the proposed methods into >> java.util.List. But as you hint in the Risks and Assumptions section, this will >> cause regression due to inference and also we will have trouble with >> LinkedHashMap (see below). >> >> 3/ LinkedHashMap mixes 3 implementations in one class, some of these >> implementations does not conform to the semantics of SequencedMap. >> - You can opt-out having the key sequentially ordered as defined by SequencedMap >> by using the constructor LinkedHashMap(int initialCapacity, float loadFactor, >> boolean accessOrder) and passing true as last parameter. >> - You can opt-out having the key sequentially ordered as defined by SequencedMap >> by overriding removeEldestEntry(), removing the first entry at the same time >> you add a new one. >> >> Because all these reasons, i think we should move to another design, using >> delegation instead of inheritance, which for the collection framework means >> exposing new way to access/modify sorted set and linked hash set through >> java.util.List views. >> >> The concept of views is not a new concept, it's used in Arrays.asList(), >> List.subList() or Map.keySet()/values()/entrySet() (and more). The idea is not >> that a sorted set is a list but that it provides a method to see it as a list. >> It solves our problem of compatibility by not adding super types to existing >> type and also the problem of the semantics of LinkedHashMap because a view >> keeps the semantics of the data structure it originated. >> >> Here is the proposed new methods in List, SortedSet and SortedMap. >> >> interface List extends Collection { >> // new methods >> void addFirst(); >> void addLast(); >> E getFirst(); >> E getLast(); >> E removeFirst(); >> E removeLast(); >> List reversedList(); // or descendingList() ?? >> } >> >> interface SortedSet implements Set { >> // new methods >> List asList(); >> } >> >> interface SortedMap implements Map { >> // new methods >> List keyList(); // do not use covariant return type >> List> entryList(); // same >> } >> >> I believe this design is objectively better than the one proposed because as a >> user being able to use new interfaces is a slow process, the >> libraries/dependencies must be updated to take the new interfaces as parameter >> before the new types can be used. By contrast, the proposed design only enhance >> existing interfaces so people will enjoy the new methods directly when >> introduced. >> >> R?mi From asemenyuk at openjdk.java.net Fri Feb 11 22:17:09 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 11 Feb 2022 22:17:09 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v2] In-Reply-To: <9APLT6NMYVgxHT6-nYAffj03PrQGKUot1mbdqadmYGY=.1e393b4f-fdd9-4ed8-aebc-6e004ed7c866@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> <9APLT6NMYVgxHT6-nYAffj03PrQGKUot1mbdqadmYGY=.1e393b4f-fdd9-4ed8-aebc-6e004ed7c866@github.com> Message-ID: On Fri, 11 Feb 2022 21:22:44 GMT, Alexander Matveev wrote: >> Added ability to override description for additional launchers via "description" property. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8279995: jpackage --add-launcher option should allow overriding description [v2] test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 90: > 88: .findFirst().orElse(null); > 89: > 90: return entry == null ? null : entry.getValue(); This can be simply `rawProperties.stream().findAny(item -> item.getKey().equals(key)).map(e -> e.getValue()).orElse(null);` Or slightly better: public String getRawPropertyValue(String key, Supplier getDefault) { return rawProperties.stream().findAny(item -> item.getKey().equals(key)).map(e -> e.getValue()).orElseGet(getDefault); } Then we can create a function that will return the expected description of an additional launcher: private String getDesciption(JPackageCommand cmd) { return getRawPropertyValue("description", () -> cmd.getArgumentValue("--description", unused -> "Unknown")); } This will let you avoid `if (expectedDescription != null)` checks and **always** verify launcher description. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 275: > 273: expectedDescription.equals(lines.get(i).trim()); > 274: } > 275: } This piece of code can be placed in `WindowsHelper.getExecutableDesciption(Path pathToExeFile)` function to make it reusable in other tests if needed. This way it can be used to verify the description of the main launcher. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 277: > 275: } > 276: } > 277: TKit.assertTrue(descriptionIsValid, "Invalid file description"); I'd use `TKit.assertEquals()` to compare the expected description with the actual one. This will produce a meaningful error message in log output in case they don't match. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From mchung at openjdk.java.net Fri Feb 11 22:41:05 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Feb 2022 22:41:05 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null In-Reply-To: References: Message-ID: <7EXvojgCiyWx6vAjErWVakLoPpswTZzZo8K-FCylrLw=.b1a57a71-e6d1-49d8-a257-5610fd0bd00d@github.com> On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Thanks for taking on these null caller issue. To give more context to this issue, the spec of `ClassLoader::isRegisteredAsParallelCapable` returns true if this class loader is registered as parallel capable, otherwise false. The current spec does not specify what if the caller class is not a class loader. The current implementation throws NPE if caller is null. I initially proposed to return false for simplicity. However, if the caller is not a subclass of `ClassLoader`, the current implementation throws `ClassCastException`. Both cases are invalid caller and they should be handled in the same way, either return false or throw an exception. Having a second thought, since this API expects to be called by a class loader, I think throwing `IllegalCallerException` to indicate this method is called by an illegal caller. This will need a CSR due to the spec change. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/7448 From rriggs at openjdk.java.net Fri Feb 11 22:45:05 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 11 Feb 2022 22:45:05 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v4] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 00:03:50 GMT, Naoto Sato wrote: >> Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments Looks good. src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5103: > 5101: * @param timeStyle the time style to use, may be null > 5102: */ > 5103: LocalizedPrinterParser(FormatStyle dateStyle, FormatStyle timeStyle) { Can the constructors be `private`. The combination of package protected and the style of caller doing the validation makes me a bit nervous. There should not be any callers outside of DateTimeFormatterBuilder. src/java.base/share/classes/sun/text/spi/JavaTimeDateTimePatternProvider.java line 66: > 64: * Returns the formatting pattern for the requested template, calendarType, and locale. > 65: * Concrete implementation of this method will retrieve > 66: * a java.time specific pattern from selected Locale Provider. editorial: "from **the** selected Locale"... src/java.base/share/classes/sun/text/spi/JavaTimeDateTimePatternProvider.java line 79: > 77: public String getJavaTimeDateTimePattern(String requestedTemplate, String calType, Locale locale) { > 78: // default implementation throws exception > 79: throw new DateTimeException("Formatter is not available for the requested template: " + requestedTemplate); "Formatting **pattern** is not available"... ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7340 From mchung at openjdk.java.net Fri Feb 11 22:55:05 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Feb 2022 22:55:05 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v3] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 20:34:43 GMT, Joe Darcy wrote: >> Two changes to the toString output for annotations to give better source fidelity: >> >> 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. >> >> 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) >> >> Various existing regression tests are updated to accommodate the changes. >> >> Please also review the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8281568 > > 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 four additional commits since the last revision: > > - Respond to more review feedback. > - Merge branch 'master' into JDK-8281462 > - Respond to review feedback. > - JDK-8281462: Annotation toString output for enum not reusable for source input Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7418 From darcy at openjdk.java.net Fri Feb 11 23:28:12 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 11 Feb 2022 23:28:12 GMT Subject: Integrated: JDK-8281462: Annotation toString output for enum not reusable for source input In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 05:49:47 GMT, Joe Darcy wrote: > Two changes to the toString output for annotations to give better source fidelity: > > 1) For enum constants, call their name method rather than their toString method. An enum class can override the toString method to print something other than the name. > > 2) Switch from using binary names (names with "$" for nested types) to canonical names (names with "." with nested types) > > Various existing regression tests are updated to accommodate the changes. > > Please also review the CSR: > https://bugs.openjdk.java.net/browse/JDK-8281568 This pull request has now been integrated. Changeset: c3179a87 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/c3179a8760019b5954e344bf0d2775e1e1968f32 Stats: 80 lines in 8 files changed: 25 ins; 6 del; 49 mod 8281462: Annotation toString output for enum not reusable for source input Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From bchristi at openjdk.java.net Fri Feb 11 23:29:05 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 11 Feb 2022 23:29:05 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null In-Reply-To: <7EXvojgCiyWx6vAjErWVakLoPpswTZzZo8K-FCylrLw=.b1a57a71-e6d1-49d8-a257-5610fd0bd00d@github.com> References: <7EXvojgCiyWx6vAjErWVakLoPpswTZzZo8K-FCylrLw=.b1a57a71-e6d1-49d8-a257-5610fd0bd00d@github.com> Message-ID: On Fri, 11 Feb 2022 22:37:57 GMT, Mandy Chung wrote: > Thanks for taking on these null caller issue. > > To give more context to this issue, the spec of `ClassLoader::isRegisteredAsParallelCapable` returns true if this class loader is registered as parallel capable, otherwise false. The current spec does not specify what if the caller class is not a class loader. The current implementation throws NPE if caller is null. I initially proposed to return false for simplicity. However, if the caller is not a subclass of `ClassLoader`, the current implementation throws `ClassCastException`. Both cases are invalid caller and they should be handled in the same way, either return false or throw an exception. > > Having a second thought, since this API expects to be called by a class loader, I think throwing `IllegalCallerException` to indicate this method is called by an illegal caller. This will need a CSR due to the spec change. > > What do you think? Throwing IllegalCallerException sounds good to me. As a static method, from a language standpoint, the call could appear almost anywhere. But its intended usage is pretty narrow. I think it's worth notifying the developer of a pretty obvious error. Is this method mainly meant to be called from a classloader's static initializer? That might be worth mentioning in the JavaDoc (if we're doing a CSR anyway...). ------------- PR: https://git.openjdk.java.net/jdk/pull/7448 From erikj at openjdk.java.net Fri Feb 11 23:29:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 11 Feb 2022 23:29:05 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7448 From naoto at openjdk.java.net Fri Feb 11 23:55:46 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Feb 2022 23:55:46 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v5] In-Reply-To: References: Message-ID: > Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7340/files - new: https://git.openjdk.java.net/jdk/pull/7340/files/af3c0d62..399257d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7340&range=03-04 Stats: 31 lines in 2 files changed: 3 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/7340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7340/head:pull/7340 PR: https://git.openjdk.java.net/jdk/pull/7340 From naoto at openjdk.java.net Fri Feb 11 23:55:49 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Feb 2022 23:55:49 GMT Subject: RFR: 8176706: Additional Date-Time Formats [v4] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 22:26:03 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5103: > >> 5101: * @param timeStyle the time style to use, may be null >> 5102: */ >> 5103: LocalizedPrinterParser(FormatStyle dateStyle, FormatStyle timeStyle) { > > Can the constructors be `private`. > The combination of package protected and the style of caller doing the validation makes me a bit nervous. > There should not be any callers outside of DateTimeFormatterBuilder. Changed to `private` so that it can only be instantiated within `DateTimeFormatterBuilder`. Same modifications are applied to other `DateTimePrinterParser` implementations. > src/java.base/share/classes/sun/text/spi/JavaTimeDateTimePatternProvider.java line 79: > >> 77: public String getJavaTimeDateTimePattern(String requestedTemplate, String calType, Locale locale) { >> 78: // default implementation throws exception >> 79: throw new DateTimeException("Formatter is not available for the requested template: " + requestedTemplate); > > "Formatting **pattern** is not available"... Modified, as well as other minor corrections in the javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From duke at openjdk.java.net Sat Feb 12 00:30:05 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Sat, 12 Feb 2022 00:30:05 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Yes, I like the IllegalCallerException. ------------- PR: https://git.openjdk.java.net/jdk/pull/7448 From amaembo at gmail.com Sat Feb 12 03:24:24 2022 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 12 Feb 2022 10:24:24 +0700 Subject: [External] : Sequenced Collections In-Reply-To: <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> Message-ID: Wow, I missed that the Sequenced Collections JEP draft was posted! Of course, I strongly support this initiative and am happy that my proposal got some love and is moving forward. In general, I like the JEP in the way it is. I have only two slight concerns: 1. I'm not sure that having addition methods (addFirst, addLast, putFirst, putLast) is a good idea, as not every mutable implementation may support them. While this adds some API unification, it's quite a rare case when this could be necessary. I think most real world applications of Sequenced* types would be around querying, or maybe draining (so removal operations are ok). Probably it would be enough to add addFirst, addLast, putFirst, putLast directly to the compatible implementations/subinterfaces like List, LinkedHashSet, and LinkedHashMap removing them from the Sequenced* interfaces. In this case, SortedSet interface will not be polluted with operations that can never be implemented. Well my opinion is not very strong here. 2. SequencedCollection name is a little bit too long. I think every extra letter adds a hesitation for users to use the type, especially in APIs where it could be the most useful. I see the Naming section and must admit that I don't have better ideas. Well, maybe just Sequenced would work? Or too vague? Speaking of Remi's suggestion, I don't think it's a good idea. Maybe it could be if we designed the Collection API from scratch. But given the current state of Java collections, it's better to add new interfaces than to put the new semantics to the java.util.List and greatly increase the amount of non-random-accessed lists in the wild. There are tons of code that implicitly assume fast random access of every incoming list (using indexed iteration inside). The suggested approach could become a performance disaster. With best regards, Tagir Valeev. On Sat, Feb 12, 2022 at 2:26 AM Stuart Marks wrote: > Hi R?mi, > > I see that you're trying to reduce the number of interfaces introduced by > unifying > things around an existing interface, List. Yes, it's true that List is an > ordered > collection. However, your analysis conveniently omits other facts about > List that > make it unsuitable as a general "ordered collection" interface. > Specifically: > > 1) List supports element access by int index; and > > 2) List is externally ordered. That is, its ordering is determined by a > succession > of API calls, irrespective of element values. This is in contrast to > SortedSet et al > which are internally ordered, in that the ordering is determined by the > element values. > > The problem with indexed element access is that it creates a bunch of > hidden > performance pitfalls for any data structure where element access is other > than O(1). > So get(i) degrades to O(n), binarySearch degrades from O(log n) to O(n). > (This is in > the sequential implementation; the random access implementation degrades > to O(n log > n)). Apparently innocuous indexed for-loops degrade to quadratic. This is > one of the > reasons why LinkedList is a bad List implementation. > > If we refactor LinkedHashSet to implement List, we basically have created > another > situation just like LinkedList. That's a step in the wrong direction. > > Turning to internal ordering (SortedSet): it's fundamentally incompatible > with > List's external ordering. List has a lot of positional mutation operations > such as > add(i, obj); after this call, you expect obj to appear at position i. That > can't > work with a SortedSet. > > There is implicit positioning semantics in other methods that don't have > index > arguments. For example, replaceAll replaces each element of a List with > the result > of calling a function on that element. Crucially, the function result goes > into the > same location as the original element. That to cannot work with SortedSet. > > Well, we can try to deal with these issues somehow, like making certain > methods > throw UnsupportedOperationException, or by relaxing the semantics of the > methods so > that they no longer have the same element positioning semantics. Either of > these > approaches contorts the List interface to such an extent that it's no > longer a List. > > So, no, it's not useful or effective to try to make List be the common > "ordered > collection" interface. > > s'marks > > > > On 2/10/22 3:14 AM, Remi Forax wrote: > > I've read the draft of the JEP on sequenced collection, and i think the > proposed design can be improved. > > https://bugs.openjdk.java.net/browse/JDK-8280836 > > > > I agree with the motivation, there is a need for an API to consider the > element of a list, a sorted set and a linked hash set as an ordered > sequence of elements with a simple way to access/add/remove the first/last > element and also reverse the elements as view. > > > > I disagree about the conclusion that we need to introduce 4 new > interfaces for that matter. > > > > Here are the reasons > > 1/ Usually an ordered collection is called a list. Introducing an > interface SequencedCollection for something which is usually called a list > will cause more harm than good. Or maybe we should rename LISP to SEQP :) > > > > 2/ There is already an interface List in Java, that represents an > ordered sequence of elements, with LinkedList being the name of the the > double linked list implementation. You can argue that there is a slight > difference between the semantics of java.util.List and the proposed syntax > of java.util.SequencedCollection, but given that people already have > difficulties to understand basic data structure concepts, as a teacher i > dread to have a discussion on those slight differences that are only true > in Java. > > > > If the collection API was not already existing, we may discuss about > having the same interface java.util.List to both indexed collection and > ordered collection, but that boat has sailed a long time ago. > > > > So in first approach, we should refactor sorted set and linked hash set > to directly implement java.util.List and all the proposed methods into > java.util.List. But as you hint in the Risks and Assumptions section, this > will cause regression due to inference and also we will have trouble with > LinkedHashMap (see below). > > > > 3/ LinkedHashMap mixes 3 implementations in one class, some of these > implementations does not conform to the semantics of SequencedMap. > > - You can opt-out having the key sequentially ordered as defined by > SequencedMap by using the constructor LinkedHashMap(int initialCapacity, > float loadFactor, boolean accessOrder) and passing true as last parameter. > > - You can opt-out having the key sequentially ordered as defined by > SequencedMap by overriding removeEldestEntry(), removing the first entry at > the same time you add a new one. > > > > Because all these reasons, i think we should move to another design, > using delegation instead of inheritance, which for the collection framework > means exposing new way to access/modify sorted set and linked hash set > through java.util.List views. > > > > The concept of views is not a new concept, it's used in Arrays.asList(), > List.subList() or Map.keySet()/values()/entrySet() (and more). The idea is > not that a sorted set is a list but that it provides a method to see it as > a list. It solves our problem of compatibility by not adding super types to > existing type and also the problem of the semantics of LinkedHashMap > because a view keeps the semantics of the data structure it originated. > > > > Here is the proposed new methods in List, SortedSet and SortedMap. > > > > interface List extends Collection { > > // new methods > > void addFirst(); > > void addLast(); > > E getFirst(); > > E getLast(); > > E removeFirst(); > > E removeLast(); > > List reversedList(); // or descendingList() ?? > > } > > > > interface SortedSet implements Set { > > // new methods > > List asList(); > > } > > > > interface SortedMap implements Map { > > // new methods > > List keyList(); // do not use covariant return type > > List> entryList(); // same > > } > > > > I believe this design is objectively better than the one proposed > because as a user being able to use new interfaces is a slow process, the > libraries/dependencies must be updated to take the new interfaces as > parameter before the new types can be used. By contrast, the proposed > design only enhance existing interfaces so people will enjoy the new > methods directly when introduced. > > > > R?mi > > > From duke at openjdk.java.net Sat Feb 12 14:19:07 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sat, 12 Feb 2022 14:19:07 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 Please keep open, still working on it. ------------- PR: https://git.openjdk.java.net/jdk/pull/6935 From alanb at openjdk.java.net Sat Feb 12 15:20:01 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 12 Feb 2022 15:20:01 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null In-Reply-To: References: <7EXvojgCiyWx6vAjErWVakLoPpswTZzZo8K-FCylrLw=.b1a57a71-e6d1-49d8-a257-5610fd0bd00d@github.com> Message-ID: On Fri, 11 Feb 2022 23:25:44 GMT, Brent Christian wrote: > Having a second thought, since this API expects to be called by a class loader, I think throwing `IllegalCallerException` to indicate this method is called by an illegal caller. This will need a CSR due to the spec change. I think this would work for both the "no caller" case and also the case where there is reflection hackery calling this method from somewhere other than a ClassLoader. So it would be a small change in behavior from CCE to ICE. ------------- PR: https://git.openjdk.java.net/jdk/pull/7448 From jbhateja at openjdk.java.net Sun Feb 13 02:55:14 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Feb 2022 02:55:14 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v2] In-Reply-To: <2TVKx_BFFyAK2ooOWKpdsEIMFzJngYxlWjbgeZ2y4Mc=.5deb2173-8107-476d-92ca-1835d69ce336@github.com> References: <2TVKx_BFFyAK2ooOWKpdsEIMFzJngYxlWjbgeZ2y4Mc=.5deb2173-8107-476d-92ca-1835d69ce336@github.com> Message-ID: On Fri, 21 Jan 2022 00:49:04 GMT, Sandhya Viswanathan wrote: > The JVM currently initializes the x86 mxcsr to round to nearest even, see below in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, exceptions masked StubRoutines::x86::_mxcsr_std = 0x1F80; The above works for Math.rint which is specified to be round to nearest even. Please see: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html : section 4.8.4 > > The rounding mode needed for Math.round is round to positive infinity which needs a different x86 mxcsr initialization(0x5F80). Hi @sviswa7 , As per JLS 17 section 15.4 Java follows round to nearest rounding policy for all floating point operations except conversion to integer and remainder where it uses round toward zero. So it may not be feasible to modify global MXCSR.RC setting, also modifying MXCSR setting just before rounding and re-setting back to its original value after operation will also not work as OOO processor is free to re-order LMXCSR instruction if used without any barriers and thus it may also influence other floating point operation. I am pushing an incremental patch which is vectorizes existing rounding APIs and is showing significant gain over existing implementation. Best Regards, Jatin ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sun Feb 13 03:09:43 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Feb 2022 03:09:43 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23 > FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 8279508: Adding vectorized algorithms to match the semantics of rounding operations. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 - 8279508: Adding a test for scalar intrinsification. - 8279508: Auto-vectorize Math.round API ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/575d2935..2dc364fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=01-02 Stats: 33695 lines in 1192 files changed: 23243 ins; 5703 del; 4749 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Sun Feb 13 03:23:06 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 13 Feb 2022 03:23:06 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 03:09:43 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23 >> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - 8279508: Adding vectorized algorithms to match the semantics of rounding operations. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Adding a test for scalar intrinsification. > - 8279508: Auto-vectorize Math.round API Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Sun Feb 13 05:18:34 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 13 Feb 2022 05:18:34 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v3] In-Reply-To: References: Message-ID: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com> > Hi, > > This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. > > Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: missing ForceInline ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7358/files - new: https://git.openjdk.java.net/jdk/pull/7358/files/8028be52..cf78527b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7358&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7358&range=01-02 Stats: 10 lines in 2 files changed: 6 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7358/head:pull/7358 PR: https://git.openjdk.java.net/jdk/pull/7358 From duke at openjdk.java.net Sun Feb 13 05:18:36 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 13 Feb 2022 05:18:36 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v2] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 18:55:29 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision: >> >> - minor rename >> - address reviews > > Observing the following failures on CPUs with "Intel_R__Xeon_R__Gold_6354_CPU___3.00GHz" with HotSpot flags: > > -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation > > > TestVectorCastAVX512.java: > > Failed IR Rules (1) > ------------------ > - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUI256toL512(int[],long[])": > * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastI2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" > - counts: Graph contains wrong number of nodes: > Regex 1: (\\d+(\\s){2}(VectorUCastI2X.*)+(\\s){2}===.*) > Expected 1 but found 0 nodes. > > > TestVectorCastAVX1.java: > > - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toS64(byte[],short[])": > * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" > - counts: Graph contains wrong number of nodes: > Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*) > Expected 1 but found 0 nodes. > > - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toI128(byte[],int[])": > * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" > - counts: Graph contains wrong number of nodes: > Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*) > Expected 1 but found 0 nodes. @PaulSandoz Thanks a lot for your testing, the reason seems to be due to `LaneType::asIntegral` missing `ForceInline` annotation. I have run the reshape test 10 times without getting any failure while with previous patch there is often 1 or 2. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From duke at openjdk.java.net Sun Feb 13 07:58:16 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 13 Feb 2022 07:58:16 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 am still working on it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From duke at openjdk.java.net Sun Feb 13 08:39:11 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 13 Feb 2022 08:39:11 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 03:09:43 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23 >> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - 8279508: Adding vectorized algorithms to match the semantics of rounding operations. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Adding a test for scalar intrinsification. > - 8279508: Auto-vectorize Math.round API Also, it seems you have tried using `roundss/sd/ps/pd` followed by a cast to correct the rounding behaviour but decided to take another approach. Some comments around the functions explaining why that is so would be preferable. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From aph at openjdk.java.net Sun Feb 13 11:01:06 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Sun, 13 Feb 2022 11:01:06 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 03:09:43 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23 >> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - 8279508: Adding vectorized algorithms to match the semantics of rounding operations. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Adding a test for scalar intrinsification. > - 8279508: Auto-vectorize Math.round API src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4066: > 4064: } > 4065: > 4066: void C2_MacroAssembler::vector_cast_double_special_cases_evex(XMMRegister dst, XMMRegister src, XMMRegister xtmp1, What does this do? Comment, even pseudo code, would be nice. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sun Feb 13 13:12:07 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Feb 2022 13:12:07 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 10:58:19 GMT, Andrew Haley wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - 8279508: Adding vectorized algorithms to match the semantics of rounding operations. >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 >> - 8279508: Adding a test for scalar intrinsification. >> - 8279508: Auto-vectorize Math.round API > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4066: > >> 4064: } >> 4065: >> 4066: void C2_MacroAssembler::vector_cast_double_special_cases_evex(XMMRegister dst, XMMRegister src, XMMRegister xtmp1, > > What does this do? Comment, even pseudo code, would be nice. > Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks. Hi @merykitty , You are correct, we can embed RC mode in instruction encoding round instructions (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values also are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sun Feb 13 13:16:16 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Feb 2022 13:16:16 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 13:08:41 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4066: >> >>> 4064: } >>> 4065: >>> 4066: void C2_MacroAssembler::vector_cast_double_special_cases_evex(XMMRegister dst, XMMRegister src, XMMRegister xtmp1, >> >> What does this do? Comment, even pseudo code, would be nice. > >> Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks. > > Hi @merykitty , You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values also are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects. > What does this do? Comment, even pseudo code, would be nice. Thanks @theRealAph , I shall append the comments over the routine. BTW, entire rounding algorithm can also be implemented using Vector API which can perform if-conversion using masked operations. class roundf { public static VectorSpecies ISPECIES = IntVector.SPECIES_512; public static VectorSpecies SPECIES = FloatVector.SPECIES_512; public static int round_vector(float[] a, int[] r, int ctr) { IntVector shiftVBC = (IntVector) ISPECIES.broadcast(24 - 2 + 127); for (int i = 0; i < a.length; i += SPECIES.length()) { FloatVector fv = FloatVector.fromArray(SPECIES, a, i); IntVector iv = fv.reinterpretAsInts(); IntVector biasedExpV = iv.lanewise(VectorOperators.AND, 0x7F800000); biasedExpV = biasedExpV.lanewise(VectorOperators.ASHR, 23); IntVector shiftV = shiftVBC.lanewise(VectorOperators.SUB, biasedExpV); VectorMask cond = shiftV.lanewise(VectorOperators.AND, -32) .compare(VectorOperators.EQ, 0); IntVector res = iv.lanewise(VectorOperators.AND, 0x007FFFFF) .lanewise(VectorOperators.OR, 0x007FFFFF + 1); VectorMask cond1 = iv.compare(VectorOperators.LT, 0); VectorMask cond2 = cond1.and(cond); res = res.lanewise(VectorOperators.NEG, cond2); res = res.lanewise(VectorOperators.ASHR, shiftV) .lanewise(VectorOperators.ADD, 1) .lanewise(VectorOperators.ASHR, 1); res = fv.convert(VectorOperators.F2I, 0) .reinterpretAsInts() .blend(res, cond); res.intoArray(r, i); } return r[ctr]; } ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From forax at univ-mlv.fr Sun Feb 13 17:40:57 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 13 Feb 2022 18:40:57 +0100 (CET) Subject: [External] : Sequenced Collections In-Reply-To: References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> Message-ID: <114971094.2972940.1644774057868.JavaMail.zimbra@u-pem.fr> > From: "Tagir Valeev" > To: "Stuart Marks" > Cc: "Remi Forax" , "core-libs-dev" > > Sent: Saturday, February 12, 2022 4:24:24 AM > Subject: Re: [External] : Sequenced Collections > Wow, I missed that the Sequenced Collections JEP draft was posted! > Of course, I strongly support this initiative and am happy that my proposal got > some love and is moving forward. In general, I like the JEP in the way it is. I > have only two slight concerns: > 1. I'm not sure that having addition methods (addFirst, addLast, putFirst, > putLast) is a good idea, as not every mutable implementation may support them. > While this adds some API unification, it's quite a rare case when this could be > necessary. I think most real world applications of Sequenced* types would be > around querying, or maybe draining (so removal operations are ok). Probably it > would be enough to add addFirst, addLast, putFirst, putLast directly to the > compatible implementations/subinterfaces like List, LinkedHashSet, and > LinkedHashMap removing them from the Sequenced* interfaces. In this case, > SortedSet interface will not be polluted with operations that can never be > implemented. Well my opinion is not very strong here. > 2. SequencedCollection name is a little bit too long. I think every extra letter > adds a hesitation for users to use the type, especially in APIs where it could > be the most useful. I see the Naming section and must admit that I don't have > better ideas. Well, maybe just Sequenced would work? Or too vague? > Speaking of Remi's suggestion, I don't think it's a good idea. Maybe it could be > if we designed the Collection API from scratch. ?? Here is the first sentence of the javadoc for java.util.List "An ordered collection (also known as a sequence )." And the first paragraph of java.util.RandomAccess "Marker interface used by List implementations to indicate that they support fast (generally constant time) random access. The primary purpose of this interface is to allow generic algorithms to alter their behavior to provide good performance when applied to either random or sequential access lists" You can find that the actual design, mixing ordered collection and indexed collection into one interface named List not great, but you can not say that this is not the actual design. > But given the current state of Java collections, it's better to add new > interfaces than to put the new semantics to the java.util.List and greatly > increase the amount of non-random-accessed lists in the wild. > There are tons of code that implicitly assume fast random access of every > incoming list (using indexed iteration inside). The suggested approach could > become a performance disaster. If you take several Java developers, some will stick to the javadoc definition, a List is either sequential or random access and some will think that a List is only random access. Because of that, adding more sequential implementations under the List interface is an issue. Introducing SequencesCollection (more on the name later), a super interface of List solves that issue, the new implementations will only implement the sequential part of interface List. But it does not solve the other problems, mainly adding 4 interfaces when one is enough, not being backward compatible because of inference and the weird semantics of LinkedHashMap. We still need SortedSet or LinkedHashSet to not directly implement SequencesCollection but to use delegation and a have a method returning a view. The same reasoning applied to SortedMap, LinkedHashMap. By using views, there is no need to the two other proposed interfaces SequenceSet and SequenceMap. Another question is ListIterator, a list can be iterated forward and backward, a SequenceCollection can do almost the same thing, with iterator() and reversed().iterator(). It's not exactly the same semantics but i don't think it exist an implementation of SequenceCollection that can be implemented without the property that given one element, it's predecessor and successor can be found in O(1). Do we need a new SequenceCollectionIterator that provides the method next/hasNext/previous/hasPrevious but not add/set/nextIndex/previousIndex ? For the name, Java uses single simple name of one syllable for the important interface List, Set, Map or Deque (the javadoc of Deque insist that Deque should be pronounced using one syllable). So the name should be Seq. The main issue with the name "Seq" is that it is perhaps too close to the name "Set". Also, it can not be "Sequence" because of CharSequence. interface Seq extends Collection { void addFirst(); void addLast(); E getFirst(); E getLast(); E removeFirst(); E removeLast(); Seq reversed(); } interface List extends Seq { } interface SortedSet implements Set { // or NavigableSet // new methods Seq asSeq(); } interface SortedMap implements Map { // or NavigableMap // new methods Seq keySeq(); // do not use covariant return type Seq valueSeq(); Seq> entrySeq(); } I'm still not sure that introducing an interface like Seq instead of using List is the way to go. If we do that, there will be a lot of blog post/bikeshedding about when to use List vs Seq and a lot of github issues about taking a Seq instead of a List as parameter of a method of a library. > With best regards, > Tagir Valeev. R?mi > On Sat, Feb 12, 2022 at 2:26 AM Stuart Marks < [ mailto:stuart.marks at oracle.com > | stuart.marks at oracle.com ] > wrote: >> Hi R?mi, >> I see that you're trying to reduce the number of interfaces introduced by >> unifying >> things around an existing interface, List. Yes, it's true that List is an >> ordered >> collection. However, your analysis conveniently omits other facts about List >> that >> make it unsuitable as a general "ordered collection" interface. Specifically: >> 1) List supports element access by int index; and >> 2) List is externally ordered. That is, its ordering is determined by a >> succession >> of API calls, irrespective of element values. This is in contrast to SortedSet >> et al >> which are internally ordered, in that the ordering is determined by the element >> values. >> The problem with indexed element access is that it creates a bunch of hidden >> performance pitfalls for any data structure where element access is other than >> O(1). >> So get(i) degrades to O(n), binarySearch degrades from O(log n) to O(n). (This >> is in >> the sequential implementation; the random access implementation degrades to O(n >> log >> n)). Apparently innocuous indexed for-loops degrade to quadratic. This is one of >> the >> reasons why LinkedList is a bad List implementation. >> If we refactor LinkedHashSet to implement List, we basically have created >> another >> situation just like LinkedList. That's a step in the wrong direction. >> Turning to internal ordering (SortedSet): it's fundamentally incompatible with >> List's external ordering. List has a lot of positional mutation operations such >> as >> add(i, obj); after this call, you expect obj to appear at position i. That can't >> work with a SortedSet. >> There is implicit positioning semantics in other methods that don't have index >> arguments. For example, replaceAll replaces each element of a List with the >> result >> of calling a function on that element. Crucially, the function result goes into >> the >> same location as the original element. That to cannot work with SortedSet. >> Well, we can try to deal with these issues somehow, like making certain methods >> throw UnsupportedOperationException, or by relaxing the semantics of the methods >> so >> that they no longer have the same element positioning semantics. Either of these >> approaches contorts the List interface to such an extent that it's no longer a >> List. >> So, no, it's not useful or effective to try to make List be the common "ordered >> collection" interface. >> s'marks >> On 2/10/22 3:14 AM, Remi Forax wrote: >>> I've read the draft of the JEP on sequenced collection, and i think the proposed >> > design can be improved. >>> [ https://bugs.openjdk.java.net/browse/JDK-8280836 | >> > https://bugs.openjdk.java.net/browse/JDK-8280836 ] >>> I agree with the motivation, there is a need for an API to consider the element >>> of a list, a sorted set and a linked hash set as an ordered sequence of >>> elements with a simple way to access/add/remove the first/last element and also >> > reverse the elements as view. >>> I disagree about the conclusion that we need to introduce 4 new interfaces for >> > that matter. >> > Here are the reasons >>> 1/ Usually an ordered collection is called a list. Introducing an interface >>> SequencedCollection for something which is usually called a list will cause >> > more harm than good. Or maybe we should rename LISP to SEQP :) >>> 2/ There is already an interface List in Java, that represents an ordered >>> sequence of elements, with LinkedList being the name of the the double linked >>> list implementation. You can argue that there is a slight difference between >>> the semantics of java.util.List and the proposed syntax of >>> java.util.SequencedCollection, but given that people already have difficulties >>> to understand basic data structure concepts, as a teacher i dread to have a >> > discussion on those slight differences that are only true in Java. >>> If the collection API was not already existing, we may discuss about having the >>> same interface java.util.List to both indexed collection and ordered >> > collection, but that boat has sailed a long time ago. >>> So in first approach, we should refactor sorted set and linked hash set to >>> directly implement java.util.List and all the proposed methods into >>> java.util.List. But as you hint in the Risks and Assumptions section, this will >>> cause regression due to inference and also we will have trouble with >> > LinkedHashMap (see below). >>> 3/ LinkedHashMap mixes 3 implementations in one class, some of these >> > implementations does not conform to the semantics of SequencedMap. >>> - You can opt-out having the key sequentially ordered as defined by SequencedMap >>> by using the constructor LinkedHashMap(int initialCapacity, float loadFactor, >> > boolean accessOrder) and passing true as last parameter. >>> - You can opt-out having the key sequentially ordered as defined by SequencedMap >>> by overriding removeEldestEntry(), removing the first entry at the same time >> > you add a new one. >>> Because all these reasons, i think we should move to another design, using >>> delegation instead of inheritance, which for the collection framework means >>> exposing new way to access/modify sorted set and linked hash set through >> > java.util.List views. >>> The concept of views is not a new concept, it's used in Arrays.asList(), >>> List.subList() or Map.keySet()/values()/entrySet() (and more). The idea is not >>> that a sorted set is a list but that it provides a method to see it as a list. >>> It solves our problem of compatibility by not adding super types to existing >>> type and also the problem of the semantics of LinkedHashMap because a view >> > keeps the semantics of the data structure it originated. >> > Here is the proposed new methods in List, SortedSet and SortedMap. >> > interface List extends Collection { >> > // new methods >> > void addFirst(); >> > void addLast(); >> > E getFirst(); >> > E getLast(); >> > E removeFirst(); >> > E removeLast(); >> > List reversedList(); // or descendingList() ?? >> > } >> > interface SortedSet implements Set { >> > // new methods >> > List asList(); >> > } >> > interface SortedMap implements Map { >> > // new methods >> > List keyList(); // do not use covariant return type >> > List> entryList(); // same >> > } >>> I believe this design is objectively better than the one proposed because as a >>> user being able to use new interfaces is a slow process, the >>> libraries/dependencies must be updated to take the new interfaces as parameter >>> before the new types can be used. By contrast, the proposed design only enhance >>> existing interfaces so people will enjoy the new methods directly when >> > introduced. >> > R?mi From jpai at openjdk.java.net Mon Feb 14 05:34:29 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 14 Feb 2022 05:34:29 GMT Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters Message-ID: Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634? The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory): err.exception.message err.invalid.options err.multirelease.version.associated err.missing.arg err.multirelease.jar.malformed err.option.already.specified err.missing.dependences err.module.not.found err.invalid.path err.genmoduleinfo.not.jarfile err.invalid.arg.for.option err.multirelease.option.notfound err.filter.not.specified err.unknown.option err.command.set err.invalid.filters err.genmoduleinfo.unnamed.package err.option.after.class Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?) The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix. An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool. This PR adds that assertion. Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code: - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test. - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message. - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR. With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR. ------------- Commit messages: - 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters Changes: https://git.openjdk.java.net/jdk/pull/7455/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7455&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281634 Stats: 14 lines in 2 files changed: 5 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7455.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7455/head:pull/7455 PR: https://git.openjdk.java.net/jdk/pull/7455 From plevart at openjdk.java.net Mon Feb 14 08:05:12 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 14 Feb 2022 08:05:12 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v7] In-Reply-To: <3jzorf2Deyd_EvWZpdwnxQyTkvAaWJDFXEVYfQiIfsM=.6028d1a6-b224-4cfa-9b6c-09d1a5f173f9@github.com> References: <3jzorf2Deyd_EvWZpdwnxQyTkvAaWJDFXEVYfQiIfsM=.6028d1a6-b224-4cfa-9b6c-09d1a5f173f9@github.com> Message-ID: <1eAVhopRkRh07y6jB1mZ_2AhFi1js6SaE59eGVaGQt0=.b6c33733-a1bd-4c81-8d5b-856cbea4ebdb@github.com> On Fri, 11 Feb 2022 21:44:04 GMT, Mandy Chung wrote: > Note that the object methods of this Config record are called via indy which is > available to use after initPhase1. We can workaround that limitation by > implementing the object methods. "Note that the object methods of this Config record are called via indy" is not very precise. They are called as any other method AFAIU. It's their implementation that uses indy, right? So perhaps, a better wording: "Note that synthetic object methods of this Config record (toString, equals, hashCode) use indy in their implementation which is available to use after initPhase1. These methods are currently not used, but should they be needed, a workaround is to explicitly (re)implement them." ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From aph at openjdk.java.net Mon Feb 14 09:16:10 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 14 Feb 2022 09:16:10 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 13:12:35 GMT, Jatin Bhateja wrote: >>> Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks. >> >> Hi @merykitty , You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects. > >> What does this do? Comment, even pseudo code, would be nice. > > Thanks @theRealAph , I shall append the comments over the routine. > BTW, entire rounding algorithm can also be implemented using Vector API which can perform if-conversion using masked operations. > > class roundf { > public static VectorSpecies ISPECIES = IntVector.SPECIES_512; > public static VectorSpecies SPECIES = FloatVector.SPECIES_512; > > public static int round_vector(float[] a, int[] r, int ctr) { > IntVector shiftVBC = (IntVector) ISPECIES.broadcast(24 - 2 + 127); > for (int i = 0; i < a.length; i += SPECIES.length()) { > FloatVector fv = FloatVector.fromArray(SPECIES, a, i); > IntVector iv = fv.reinterpretAsInts(); > IntVector biasedExpV = iv.lanewise(VectorOperators.AND, 0x7F800000); > biasedExpV = biasedExpV.lanewise(VectorOperators.ASHR, 23); > IntVector shiftV = shiftVBC.lanewise(VectorOperators.SUB, biasedExpV); > VectorMask cond = shiftV.lanewise(VectorOperators.AND, -32) > .compare(VectorOperators.EQ, 0); > IntVector res = iv.lanewise(VectorOperators.AND, 0x007FFFFF) > .lanewise(VectorOperators.OR, 0x007FFFFF + 1); > VectorMask cond1 = iv.compare(VectorOperators.LT, 0); > VectorMask cond2 = cond1.and(cond); > res = res.lanewise(VectorOperators.NEG, cond2); > res = res.lanewise(VectorOperators.ASHR, shiftV) > .lanewise(VectorOperators.ADD, 1) > .lanewise(VectorOperators.ASHR, 1); > res = fv.convert(VectorOperators.F2I, 0) > .reinterpretAsInts() > .blend(res, cond); > res.intoArray(r, i); > } > return r[ctr]; > } That pseudocode would make a very useful comment too. This whole patch is very thinly commented. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From aturbanov at openjdk.java.net Mon Feb 14 10:19:35 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 14 Feb 2022 10:19:35 GMT Subject: RFR: 8281728: Redundant null check in LineNumberInputStream.read Message-ID: At start of method `b` is already checked for null. https://github.com/openjdk/jdk/blob/178b962e01cc6c150442bf41dc6bd199caff0042/src/java.base/share/classes/java/io/LineNumberInputStream.java#L129-L131 ------------- Commit messages: - [PATCH] Remove redundant null check in LineNumberInputStream.read Changes: https://git.openjdk.java.net/jdk/pull/7409/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7409&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281728 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7409.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7409/head:pull/7409 PR: https://git.openjdk.java.net/jdk/pull/7409 From dfuchs at openjdk.java.net Mon Feb 14 10:23:10 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 14 Feb 2022 10:23:10 GMT Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634? > > The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory): > > err.exception.message > err.invalid.options > err.multirelease.version.associated > err.missing.arg > err.multirelease.jar.malformed > err.option.already.specified > err.missing.dependences > err.module.not.found > err.invalid.path > err.genmoduleinfo.not.jarfile > err.invalid.arg.for.option > err.multirelease.option.notfound > err.filter.not.specified > err.unknown.option > err.command.set > err.invalid.filters > err.genmoduleinfo.unnamed.package > err.option.after.class > > Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?) > > The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix. > > An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool. This PR adds that assertion. > Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code: > - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test. > - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message. > - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR. > > With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR. The changes look reasonable. Thanks for taking that on Jaikiran! Maybe wait one day or two before integrating to give Mandy a chance to chime in. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7455 From thartmann at openjdk.java.net Mon Feb 14 10:37:54 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 14 Feb 2022 10:37:54 GMT Subject: [jdk18] RFR: 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE Message-ID: We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures. Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending. Thanks, Tobias ------------- Commit messages: - Revert "8275448: [REDO] AArch64: Implement string_compare intrinsic in SVE" Changes: https://git.openjdk.java.net/jdk18/pull/116/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=116&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281713 Stats: 423 lines in 9 files changed: 0 ins; 412 del; 11 mod Patch: https://git.openjdk.java.net/jdk18/pull/116.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/116/head:pull/116 PR: https://git.openjdk.java.net/jdk18/pull/116 From redestad at openjdk.java.net Mon Feb 14 10:44:11 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 14 Feb 2022 10:44:11 GMT Subject: RFR: 8281728: Redundant null check in LineNumberInputStream.read In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 18:51:22 GMT, Andrey Turbanov wrote: > At start of method `b` is already checked for null. > > https://github.com/openjdk/jdk/blob/178b962e01cc6c150442bf41dc6bd199caff0042/src/java.base/share/classes/java/io/LineNumberInputStream.java#L129-L131 Looks good. The surrounding code looks due for a larger clean-up, but this improvement looks reasonable in isolation. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7409 From jpai at openjdk.java.net Mon Feb 14 11:42:14 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 14 Feb 2022 11:42:14 GMT Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634? > > The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory): > > err.exception.message > err.invalid.options > err.multirelease.version.associated > err.missing.arg > err.multirelease.jar.malformed > err.option.already.specified > err.missing.dependences > err.module.not.found > err.invalid.path > err.genmoduleinfo.not.jarfile > err.invalid.arg.for.option > err.multirelease.option.notfound > err.filter.not.specified > err.unknown.option > err.command.set > err.invalid.filters > err.genmoduleinfo.unnamed.package > err.option.after.class > > Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?) > > The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix. > > An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool. This PR adds that assertion. > Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code: > - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test. > - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message. > - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR. > > With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR. Thank you for your review, Daniel. > Maybe wait one day or two before integrating to give Mandy a chance to chime in. Certainly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7455 From alanb at openjdk.java.net Mon Feb 14 11:59:11 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 14 Feb 2022 11:59:11 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121: > 119: Class c = Reflection.getCallerClass(); > 120: if (c == null) { > 121: throw new IllegalCallerException(); Throwing ICE is probably okay here, I just wonder if there is any practical advantage to having it return publicLookup instead, e.g. is there any scenario where a JNI attached thread might want to invoke a method with a Lookup parameter? ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From lkorinth at openjdk.java.net Mon Feb 14 12:08:13 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 14 Feb 2022 12:08:13 GMT Subject: Integrated: 8281585: Remove unused imports under test/lib and jtreg/gc In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 15:39:53 GMT, Leo Korinth wrote: > Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. This pull request has now been integrated. Changeset: 2604a88f Author: Leo Korinth URL: https://git.openjdk.java.net/jdk/commit/2604a88fbb6d0f9aec51c7d607ea275bc34a672c Stats: 151 lines in 60 files changed: 0 ins; 92 del; 59 mod 8281585: Remove unused imports under test/lib and jtreg/gc Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/7426 From lkorinth at openjdk.java.net Mon Feb 14 12:08:12 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 14 Feb 2022 12:08:12 GMT Subject: RFR: 8281585: Remove unused imports under test/lib and jtreg/gc [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote: >> Remove unused imports under test/lib and jtreg/gc. They create lots of warnings if editing using an IDE. Tests in hotspot_gc passed. > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > updating copyright Thanks David and Serguei! ------------- PR: https://git.openjdk.java.net/jdk/pull/7426 From ihse at openjdk.java.net Mon Feb 14 12:11:09 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 14 Feb 2022 12:11:09 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Build changes LGTM. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7448 From ihse at openjdk.java.net Mon Feb 14 12:11:10 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 14 Feb 2022 12:11:10 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null Build changes are OK ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7447 From rriggs at openjdk.java.net Mon Feb 14 15:51:08 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 14 Feb 2022 15:51:08 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 18:31:57 GMT, Joe Darcy wrote: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Looks promising, some comments: The terminology in the JVMS is about modifiers; can the class name include the word Modifier, perhaps ModifierFlag(s)? Several of the modifiers are not related to "access". The `getXXXFlags()` methods in Class, etc. should mention the Set is immutable/unmodifiable. The post-Beans API signature would be just "flags()" without the Get prefix. Consistency with the current methods may tend to keep the prefix. The Set manipulation functions are not very smooth (but true for all Sets). Checking for `anyOf` or `allOf` a set of modifiers has to be written out as a boolean expression. Though `allOf` could create an intermediate set. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From asotona at openjdk.java.net Mon Feb 14 16:33:08 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Mon, 14 Feb 2022 16:33:08 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 18:31:57 GMT, Joe Darcy wrote: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 206: > 204: * modifier in the Java programming language} > 205: */ > 206: public boolean sourceModifer() { probably a typo - should be sourceModifier ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From jbhateja at openjdk.java.net Mon Feb 14 17:18:07 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 14 Feb 2022 17:18:07 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 09:12:54 GMT, Andrew Haley wrote: >>> What does this do? Comment, even pseudo code, would be nice. >> >> Thanks @theRealAph , I shall append the comments over the routine. >> BTW, entire rounding algorithm can also be implemented using Vector API which can perform if-conversion using masked operations. >> >> class roundf { >> public static VectorSpecies ISPECIES = IntVector.SPECIES_512; >> public static VectorSpecies SPECIES = FloatVector.SPECIES_512; >> >> public static int round_vector(float[] a, int[] r, int ctr) { >> IntVector shiftVBC = (IntVector) ISPECIES.broadcast(24 - 2 + 127); >> for (int i = 0; i < a.length; i += SPECIES.length()) { >> FloatVector fv = FloatVector.fromArray(SPECIES, a, i); >> IntVector iv = fv.reinterpretAsInts(); >> IntVector biasedExpV = iv.lanewise(VectorOperators.AND, 0x7F800000); >> biasedExpV = biasedExpV.lanewise(VectorOperators.ASHR, 23); >> IntVector shiftV = shiftVBC.lanewise(VectorOperators.SUB, biasedExpV); >> VectorMask cond = shiftV.lanewise(VectorOperators.AND, -32) >> .compare(VectorOperators.EQ, 0); >> IntVector res = iv.lanewise(VectorOperators.AND, 0x007FFFFF) >> .lanewise(VectorOperators.OR, 0x007FFFFF + 1); >> VectorMask cond1 = iv.compare(VectorOperators.LT, 0); >> VectorMask cond2 = cond1.and(cond); >> res = res.lanewise(VectorOperators.NEG, cond2); >> res = res.lanewise(VectorOperators.ASHR, shiftV) >> .lanewise(VectorOperators.ADD, 1) >> .lanewise(VectorOperators.ASHR, 1); >> res = fv.convert(VectorOperators.F2I, 0) >> .reinterpretAsInts() >> .blend(res, cond); >> res.intoArray(r, i); >> } >> return r[ctr]; >> } > > That pseudocode would make a very useful comment too. This whole patch is very thinly commented. > > Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks. > > Hi @merykitty , You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects. **Just want to correct above statement, LDMXCSR will not be re-ordered/re-scheduled early OOO backend.** ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From mchung at openjdk.java.net Mon Feb 14 17:27:12 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 17:27:12 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v7] In-Reply-To: <1eAVhopRkRh07y6jB1mZ_2AhFi1js6SaE59eGVaGQt0=.b6c33733-a1bd-4c81-8d5b-856cbea4ebdb@github.com> References: <3jzorf2Deyd_EvWZpdwnxQyTkvAaWJDFXEVYfQiIfsM=.6028d1a6-b224-4cfa-9b6c-09d1a5f173f9@github.com> <1eAVhopRkRh07y6jB1mZ_2AhFi1js6SaE59eGVaGQt0=.b6c33733-a1bd-4c81-8d5b-856cbea4ebdb@github.com> Message-ID: On Mon, 14 Feb 2022 08:01:38 GMT, Peter Levart wrote: >> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 620: >> >>> 618: * The configurations exist as an object to avoid race conditions. >>> 619: * See bug 8261407. The object methods backed by indy may not be available. >>> 620: */ >> >> This comment is a bit unclear. With the suggestion of moving the static `ReflectionFactory::config()` method and the comment I suggest below, I think that should be adequate to understand. If not, we should improve the comment rather than relying on the readers to read the bug report. >> >> Maybe the comment can be: >> >> Configuration for core reflection which is configurable via system properties. >> The user-configured settings are not available during early VM startup. >> >> Note that the object methods of this Config record are called via indy which is >> available to use after initPhase1. We can workaround that limitation by >> implementing the object methods. > >> Note that the object methods of this Config record are called via indy which is >> available to use after initPhase1. We can workaround that limitation by >> implementing the object methods. > > "Note that the object methods of this Config record are called via indy" is not very precise. They are called as any other method AFAIU. It's their implementation that uses indy, right? So perhaps, a better wording: > > "Note that synthetic object methods of this Config record (toString, equals, hashCode) use indy in their implementation which is available to use after initPhase1. These methods are currently not used, but should they be needed, a workaround is to explicitly (re)implement them." "uses indy" is the right description. Minor tweak: s/synthetic/the default implementation of/ ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From naoto at openjdk.java.net Mon Feb 14 17:46:10 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Feb 2022 17:46:10 GMT Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634? > > The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory): > > err.exception.message > err.invalid.options > err.multirelease.version.associated > err.missing.arg > err.multirelease.jar.malformed > err.option.already.specified > err.missing.dependences > err.module.not.found > err.invalid.path > err.genmoduleinfo.not.jarfile > err.invalid.arg.for.option > err.multirelease.option.notfound > err.filter.not.specified > err.unknown.option > err.command.set > err.invalid.filters > err.genmoduleinfo.unnamed.package > err.option.after.class > > Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?) > > The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix. > > An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool. This PR adds that assertion. > Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code: > - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test. > - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message. > - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR. > > With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR. Looks good. As to the l10n of those English resources should be handled with https://bugs.openjdk.java.net/browse/JDK-8280400 ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7455 From mchung at openjdk.java.net Mon Feb 14 17:52:08 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 17:52:08 GMT Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634? > > The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory): > > err.exception.message > err.invalid.options > err.multirelease.version.associated > err.missing.arg > err.multirelease.jar.malformed > err.option.already.specified > err.missing.dependences > err.module.not.found > err.invalid.path > err.genmoduleinfo.not.jarfile > err.invalid.arg.for.option > err.multirelease.option.notfound > err.filter.not.specified > err.unknown.option > err.command.set > err.invalid.filters > err.genmoduleinfo.unnamed.package > err.option.after.class > > Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?) > > The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix. > > An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool. This PR adds that assertion. > Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code: > - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test. > - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message. > - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR. > > With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR. Thanks for fixing this. This looks good. Fixing the test together is fine. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7455 From mchung at openjdk.java.net Mon Feb 14 18:07:09 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 18:07:09 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Mon, 14 Feb 2022 11:56:16 GMT, Alan Bateman wrote: >> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121: > >> 119: Class c = Reflection.getCallerClass(); >> 120: if (c == null) { >> 121: throw new IllegalCallerException(); > > Throwing ICE is probably okay here, I just wonder if there is any practical advantage to having it return publicLookup instead, e.g. is there any scenario where a JNI attached thread might want to invoke a method with a Lookup parameter? `MethodHandles::publicLookup` can be called instead to get a public Lookup to invoke a method with a Lookup parameter. The dilemma here is whether the API should be made null-caller friendly or using a proper API `MethodHandles::publicLookup` for such case. ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From darcy at openjdk.java.net Mon Feb 14 18:15:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Feb 2022 18:15:10 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection In-Reply-To: References: Message-ID: <5g18aJMhrgCTIBOI7py_wAsKBfFfb0qufKvaK5f5M5w=.3e339b77-8405-46e4-be54-976b10336ce4@github.com> On Mon, 14 Feb 2022 16:29:36 GMT, Adam Sotona wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 206: > >> 204: * modifier in the Java programming language} >> 205: */ >> 206: public boolean sourceModifer() { > > probably a typo - should be sourceModifier Thanks for catching the typo Adam; I'll fix it in the next push. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From alanb at openjdk.java.net Mon Feb 14 18:15:08 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 14 Feb 2022 18:15:08 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null test/jdk/java/lang/invoke/MethodHandles/exeNullCallerMethodHandlesLookup/NullCallerMethodHandlesLookupTest.java line 2: > 1: /* > 2: * Copyright (c) 2019, 2022, Oracle and/or its affiliates. All rights reserved. As this is a new file then I assume it should be 2022 only. test/jdk/java/lang/invoke/MethodHandles/exeNullCallerMethodHandlesLookup/NullCallerMethodHandlesLookupTest.java line 48: > 46: public class NullCallerMethodHandlesLookupTest { > 47: public static void main(String[] args) throws IOException { > 48: Path launcher = Paths.get(System.getProperty("test.nativepath"), "NullCallerMethodHandlesLookupTest"); Path.of might be nicer here but doesn't matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From alanb at openjdk.java.net Mon Feb 14 18:15:08 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 14 Feb 2022 18:15:08 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Mon, 14 Feb 2022 18:03:45 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121: >> >>> 119: Class c = Reflection.getCallerClass(); >>> 120: if (c == null) { >>> 121: throw new IllegalCallerException(); >> >> Throwing ICE is probably okay here, I just wonder if there is any practical advantage to having it return publicLookup instead, e.g. is there any scenario where a JNI attached thread might want to invoke a method with a Lookup parameter? > > `MethodHandles::publicLookup` can be called instead to get a public Lookup to invoke a method with a Lookup parameter. The dilemma here is whether the API should be made null-caller friendly or using a proper API `MethodHandles::publicLookup` for such case. You are right. If a JNI attached thread with no Java frames wants a Lookup then it can invoke publicLookup. I think the proposal here is good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From cstein at openjdk.java.net Mon Feb 14 18:23:11 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Mon, 14 Feb 2022 18:23:11 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: <6DQ5_BAMP-bV8XkY9txYZBRnXzc3ypCXV9b0YdgvAkk=.7bc88afb-4f9d-4659-9b33-153977afbb34@github.com> References: <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com> <6DQ5_BAMP-bV8XkY9txYZBRnXzc3ypCXV9b0YdgvAkk=.7bc88afb-4f9d-4659-9b33-153977afbb34@github.com> Message-ID: On Thu, 10 Feb 2022 17:24:17 GMT, Jonathan Gibbons wrote: >>> Perhaps like this? >>> >>> ```java >>> /** >>> * ... >>> * @provides java.util.spi.ToolProvider >>> * Module {@code jdk.jartool} provides a tool named {@code "jar"}. >>> * Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")} >>> * to create an instance of this tool. >>> * ... >>> */ >>> ``` >> >> What about >> >> `Module {@code jdk.jartool) provides the equivalent of command-line access to the {@code "jar"} tool` > > The focus should be to document the service specified in the `@provides` directive, and how to access to access an instance of the service. > > How about: > > Use `TP.findFirst("NAME")` to obtain an instance of a `ToolProvider` that provides the equivalent of command-line access to the {@code "NAME"} tool. I think Jon's latest proposal combines all requirements with using better wording than my initial text. Do you agree, @AlanBateman and @LanceAndersen? ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From mchung at openjdk.java.net Mon Feb 14 18:37:09 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 18:37:09 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: <7n-jij4H0hg3F1eeArL1SuR1mJ9Qnm8NbP1Fhkz5Yro=.1c1c5df3-b1f2-444d-9dfd-c106a41bed99@github.com> On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null This needs a CSR and the spec needs update. The test name could be shortened to `s/exeNullCallerMethodHandlesLookup/exeNullCallerLookup/`. src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121: > 119: Class c = Reflection.getCallerClass(); > 120: if (c == null) { > 121: throw new IllegalCallerException(); Suggestion: throw new IllegalCallerException("no caller frame"); ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From mchung at openjdk.java.net Mon Feb 14 18:37:10 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 18:37:10 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: <7n-jij4H0hg3F1eeArL1SuR1mJ9Qnm8NbP1Fhkz5Yro=.1c1c5df3-b1f2-444d-9dfd-c106a41bed99@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> <7n-jij4H0hg3F1eeArL1SuR1mJ9Qnm8NbP1Fhkz5Yro=.1c1c5df3-b1f2-444d-9dfd-c106a41bed99@github.com> Message-ID: <3R3yOvHFQsMjYXK2ccrQDMUK_u-kqWpGodTE7_w17M0=.14f0fb54-a6c8-4e02-a174-91e18885f2cd@github.com> On Mon, 14 Feb 2022 18:28:09 GMT, Mandy Chung wrote: >> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 121: > >> 119: Class c = Reflection.getCallerClass(); >> 120: if (c == null) { >> 121: throw new IllegalCallerException(); > > Suggestion: > > throw new IllegalCallerException("no caller frame"); The javadoc needs to be updated to specify this `IllegalCallerException` be thrown. * @throws IllegalCallerException if there is no caller frame on the stack when called * directly from a JNI attached thread ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From jrose at openjdk.java.net Mon Feb 14 18:55:07 2022 From: jrose at openjdk.java.net (John R Rose) Date: Mon, 14 Feb 2022 18:55:07 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: <159C_yfAzGOHHJ2ThjrpjZgefdbdAoUBFYR6ZgEFV8Q=.c6f0770c-c1de-419d-bcb1-39a6743ba3e9@github.com> On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null Marked as reviewed by jrose (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From jrose at openjdk.java.net Mon Feb 14 18:55:07 2022 From: jrose at openjdk.java.net (John R Rose) Date: Mon, 14 Feb 2022 18:55:07 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Mon, 14 Feb 2022 18:10:37 GMT, Alan Bateman wrote: >> `MethodHandles::publicLookup` can be called instead to get a public Lookup to invoke a method with a Lookup parameter. The dilemma here is whether the API should be made null-caller friendly or using a proper API `MethodHandles::publicLookup` for such case. > > You are right. If a JNI attached thread with no Java frames wants a Lookup then it can invoke publicLookup. I think the proposal here is good. Agreed. In this case there is no caller and any kind of fail-over to a designated caller would risk privilege escalation. So we should throw. I have no objection to throwing something more "diagnostic" than a NPE. Arguably, JNI code is full-privileged, so someone might suggest, "just return a fully privileged lookup on some designated class". But, even if such a class could be designated somehow (e.g., by rummaging down the stack), handing out privileges on that class might be unexpected to the JNI author. In fact, if the JNI code is working on behalf of a *low-privileged class* (whatever that means in context), then handing back a `Lookup` with higher privileges potentially leaks those privileges to the low-privileged class (depending on data flow, of course). Trying to guess at a `Lookup` in this case would only create potential privilege escalations. So we throw, and require the JNI programmer to say something clearer about their intentions. ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From lancea at openjdk.java.net Mon Feb 14 19:12:07 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 14 Feb 2022 19:12:07 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com> <6DQ5_BAMP-bV8XkY9txYZBRnXzc3ypCXV9b0YdgvAkk=.7bc88afb-4f9d-4659-9b33-153977afbb34@github.com> Message-ID: On Mon, 14 Feb 2022 18:20:19 GMT, Christian Stein wrote: > I think Jon's latest proposal combines all requirements with using better wording than my initial text. > > Do you agree, @AlanBateman and @LanceAndersen? Yes, I think that sounds good ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From psandoz at openjdk.java.net Mon Feb 14 19:35:10 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 14 Feb 2022 19:35:10 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v3] In-Reply-To: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com> References: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com> Message-ID: On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > missing ForceInline Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From psandoz at openjdk.java.net Mon Feb 14 19:35:10 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 14 Feb 2022 19:35:10 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v2] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 05:14:47 GMT, Quan Anh Mai wrote: >> Observing the following failures on CPUs with "Intel_R__Xeon_R__Gold_6354_CPU___3.00GHz" with HotSpot flags: >> >> -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation >> >> >> TestVectorCastAVX512.java: >> >> Failed IR Rules (1) >> ------------------ >> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUI256toL512(int[],long[])": >> * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastI2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" >> - counts: Graph contains wrong number of nodes: >> Regex 1: (\\d+(\\s){2}(VectorUCastI2X.*)+(\\s){2}===.*) >> Expected 1 but found 0 nodes. >> >> >> TestVectorCastAVX1.java: >> >> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toS64(byte[],short[])": >> * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" >> - counts: Graph contains wrong number of nodes: >> Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*) >> Expected 1 but found 0 nodes. >> >> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toI128(byte[],int[])": >> * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})" >> - counts: Graph contains wrong number of nodes: >> Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*) >> Expected 1 but found 0 nodes. > > @PaulSandoz Thanks a lot for your testing, the reason seems to be due to `LaneType::asIntegral` missing `ForceInline` annotation. I have run the reshape test 10 times without getting any failure while with previous patch there is often 1 or 2. > Thanks. @merykitty testing now passes. Java bits look good. Needs HotSpot reviewer. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From naoto at openjdk.java.net Mon Feb 14 19:45:34 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Feb 2022 19:45:34 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range Message-ID: Fixing an issue in `CompactNumberFormat` which was caused by BigDecimal.divide() that incremented the number in the resulting format string. Also fixing some typos by taking this opportunity. ------------- Commit messages: - 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range Changes: https://git.openjdk.java.net/jdk/pull/7412/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7412&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281317 Stats: 42 lines in 2 files changed: 31 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7412.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7412/head:pull/7412 PR: https://git.openjdk.java.net/jdk/pull/7412 From igraves at openjdk.java.net Mon Feb 14 20:00:23 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 14 Feb 2022 20:00:23 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. Message-ID: Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. ------------- Commit messages: - Catching erronious setting of matcher.hitEnd Changes: https://git.openjdk.java.net/jdk/pull/7466/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7466&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281560 Stats: 28 lines in 2 files changed: 27 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7466/head:pull/7466 PR: https://git.openjdk.java.net/jdk/pull/7466 From darcy at openjdk.java.net Mon Feb 14 20:02:50 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Feb 2022 20:02:50 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v2] In-Reply-To: References: Message-ID: <7W2TRBwVgI8j6-lgu5IdoO0OeAmb_lo7yYIRxwTZBPI=.768c663e-c39a-4b4e-994f-eefdfd0af36b@github.com> > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. 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 three additional commits since the last revision: - Fix typo from review feedback. - Merge branch 'master' into JDK-8266670 - JDK-8266670: Better modeling of modifiers in core reflection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/6a6b958a..74ec715d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=00-01 Stats: 2554 lines in 67 files changed: 1895 ins; 379 del; 280 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Mon Feb 14 20:56:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Feb 2022 20:56:10 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v2] In-Reply-To: <5g18aJMhrgCTIBOI7py_wAsKBfFfb0qufKvaK5f5M5w=.3e339b77-8405-46e4-be54-976b10336ce4@github.com> References: <5g18aJMhrgCTIBOI7py_wAsKBfFfb0qufKvaK5f5M5w=.3e339b77-8405-46e4-be54-976b10336ce4@github.com> Message-ID: <9DTfvC6xWVq_4nyp1w8JF6wBW-SP2qhsspGKpb9d3NY=.94290ed4-0a52-44de-bec2-1f5a44a2466f@github.com> On Mon, 14 Feb 2022 18:12:13 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 206: >> >>> 204: * modifier in the Java programming language} >>> 205: */ >>> 206: public boolean sourceModifer() { >> >> probably a typo - should be sourceModifier > > Thanks for catching the typo Adam; I'll fix it in the next push. > Looks promising, some comments: > > The terminology in the JVMS is about modifiers; can the class name include the word Modifier, perhaps ModifierFlag(s)? Several of the modifiers are not related to "access". > > The `getXXXFlags()` methods in Class, etc. should mention the Set is immutable/unmodifiable. The post-Beans API signature would be just "flags()" without the Get prefix. Consistency with the current methods may tend to keep the prefix. > > The Set manipulation functions are not very smooth (but true for all Sets). Checking for `anyOf` or `allOf` a set of modifiers has to be written out as a boolean expression. Though `allOf` could create an intermediate set. The JVMS uses "access flags" terminology: JVMS 4.7 Attributes "The value of the access_flags item is a mask of flags used to denote access permissions to and properties of this class or interface. " JVMS 4.5 Fields "The value of the access_flags item is a mask of flags used to denote access permission to and properties of this field." JVMS 4.6 Methods "The value of the access_flags item is a mask of flags used to denote access permission to and properties of this method." JVMS 4.7.6 The InnerClasses Attribute "The value of the inner_class_access_flags item is a mask of flags used to denote access permissions to and properties of class or interface C as declared in the source code from which this class file was compiled." JVMS 4.7.24 The MethodParameters Attribute "The value of the access_flags item is as follows: ..." This consistent usage was the motivation to rename the enum class to "AccessFlags" compared to "ModifierFlag" as initially sketched in the bug. Agreed that the returned sets should be specified to be immutable. Some newer methods added to Class omit the "get" prefix while many older methods include it. I linked the RFE of this issue to the RFE for an ImmutableEnumSet. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From kvn at openjdk.java.net Mon Feb 14 20:56:25 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 14 Feb 2022 20:56:25 GMT Subject: [jdk18] RFR: 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote: > We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures. > > Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending. > > Thanks, > Tobias Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk18/pull/116 From darcy at openjdk.java.net Mon Feb 14 21:00:45 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Feb 2022 21:00:45 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v3] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback explicitly stating returned sets are immutable. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/74ec715d..88be1e3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=01-02 Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From mchung at openjdk.java.net Mon Feb 14 21:28:06 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 21:28:06 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v3] In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 21:00:45 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback explicitly stating returned sets are immutable. I'm glad to see this proposal moving along to better model the JVM access flags. I think it's right to define a better enhanced API than updating `java.lang.reflect.Modifier` (which is indeed inadequate to provide the sufficient context for modeling). I also think `AccessFlag` is a good class name that well represents the `access_flags` in a class file per the JVM spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From mchung at openjdk.java.net Mon Feb 14 21:34:11 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 21:34:11 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v3] In-Reply-To: References: Message-ID: <3VRk2bX4uN8E5nkn2ZGE8xkb6igh_h_eL1EodXyiVEw=.b6def963-2731-45df-b2e2-1dcf55d104f1@github.com> On Mon, 14 Feb 2022 21:00:45 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback explicitly stating returned sets are immutable. It may be useful to update the javadoc of `Modifier` constants to link to `AccessFlag` enums. src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 196: > 194: > 195: /** > 196: * {@return corresponding integer mask for the flag; 0 if none} 0 would not be possible, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From mchung at openjdk.java.net Mon Feb 14 21:34:12 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 21:34:12 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v2] In-Reply-To: <7W2TRBwVgI8j6-lgu5IdoO0OeAmb_lo7yYIRxwTZBPI=.768c663e-c39a-4b4e-994f-eefdfd0af36b@github.com> References: <7W2TRBwVgI8j6-lgu5IdoO0OeAmb_lo7yYIRxwTZBPI=.768c663e-c39a-4b4e-994f-eefdfd0af36b@github.com> Message-ID: <5DmTQnOLTQiKRcs9eJIpT0yPvxvfD738P1gKQXfmBLY=.b80f763c-90b3-4ce1-a7bc-62b62fd229f1@github.com> On Mon, 14 Feb 2022 20:02:50 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > 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 three additional commits since the last revision: > > - Fix typo from review feedback. > - Merge branch 'master' into JDK-8266670 > - JDK-8266670: Better modeling of modifiers in core reflection src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 146: > 144: */ > 145: SYNTHETIC(0x00001000, false, > 146: Set.of(TYPE, FIELD, METHOD, CONSTRUCTOR, ElementType.MODULE, PARAMETER)), Suggestion: Set.of(TYPE, FIELD, METHOD, CONSTRUCTOR, MODULE, PARAMETER)), `ElementType.MODULE` is already imported. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From rriggs at openjdk.java.net Mon Feb 14 21:48:10 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 14 Feb 2022 21:48:10 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v3] In-Reply-To: <9DTfvC6xWVq_4nyp1w8JF6wBW-SP2qhsspGKpb9d3NY=.94290ed4-0a52-44de-bec2-1f5a44a2466f@github.com> References: <5g18aJMhrgCTIBOI7py_wAsKBfFfb0qufKvaK5f5M5w=.3e339b77-8405-46e4-be54-976b10336ce4@github.com> <9DTfvC6xWVq_4nyp1w8JF6wBW-SP2qhsspGKpb9d3NY=.94290ed4-0a52-44de-bec2-1f5a44a2466f@github.com> Message-ID: <20ho3UBw5LFgp_ncW2szgaB4xINWaehxgimfjiJ35Ks=.64afd3d8-9e10-453e-a5bf-d96048a74cf5@github.com> On Mon, 14 Feb 2022 20:52:28 GMT, Joe Darcy wrote: >> Thanks for catching the typo Adam; I'll fix it in the next push. > >> Looks promising, some comments: >> >> The terminology in the JVMS is about modifiers; can the class name include the word Modifier, perhaps ModifierFlag(s)? Several of the modifiers are not related to "access". >> >> The `getXXXFlags()` methods in Class, etc. should mention the Set is immutable/unmodifiable. The post-Beans API signature would be just "flags()" without the Get prefix. Consistency with the current methods may tend to keep the prefix. >> >> The Set manipulation functions are not very smooth (but true for all Sets). Checking for `anyOf` or `allOf` a set of modifiers has to be written out as a boolean expression. Though `allOf` could create an intermediate set. > > The JVMS uses "access flags" terminology: > > JVMS 4.7 Attributes "The value of the access_flags item is a mask of flags used to denote access permissions to and properties of this class or interface. " > > JVMS 4.5 Fields "The value of the access_flags item is a mask of flags used to denote access permission to and properties of this field." > > JVMS 4.6 Methods "The value of the access_flags item is a mask of flags used to denote access permission to and properties of this method." > > JVMS 4.7.6 The InnerClasses Attribute "The value of the inner_class_access_flags item is a mask of flags used to denote access permissions to and properties of class or interface C as declared in the source code from which this class file was compiled." > > JVMS 4.7.24 The MethodParameters Attribute "The value of the access_flags item is as follows: ..." > > This consistent usage was the motivation to rename the enum class to "AccessFlags" compared to "ModifierFlag" as initially sketched in the bug. > > Agreed that the returned sets should be specified to be immutable. > > Some newer methods added to Class omit the "get" prefix while many older methods include it. > > I linked the RFE of this issue to the RFE for an ImmutableEnumSet. Thanks for the updates and correction on terminology origin. Adding "@ Override" in the implementations of `Member.accessFlags()` might be in order. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Mon Feb 14 22:10:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Feb 2022 22:10:06 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v2] In-Reply-To: <5DmTQnOLTQiKRcs9eJIpT0yPvxvfD738P1gKQXfmBLY=.b80f763c-90b3-4ce1-a7bc-62b62fd229f1@github.com> References: <7W2TRBwVgI8j6-lgu5IdoO0OeAmb_lo7yYIRxwTZBPI=.768c663e-c39a-4b4e-994f-eefdfd0af36b@github.com> <5DmTQnOLTQiKRcs9eJIpT0yPvxvfD738P1gKQXfmBLY=.b80f763c-90b3-4ce1-a7bc-62b62fd229f1@github.com> Message-ID: On Mon, 14 Feb 2022 21:10:22 GMT, Mandy Chung wrote: >> 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 three additional commits since the last revision: >> >> - Fix typo from review feedback. >> - Merge branch 'master' into JDK-8266670 >> - JDK-8266670: Better modeling of modifiers in core reflection > > src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 146: > >> 144: */ >> 145: SYNTHETIC(0x00001000, false, >> 146: Set.of(TYPE, FIELD, METHOD, CONSTRUCTOR, ElementType.MODULE, PARAMETER)), > > Suggestion: > > Set.of(TYPE, FIELD, METHOD, CONSTRUCTOR, MODULE, PARAMETER)), > > > `ElementType.MODULE` is already imported. Hi Mandy. Since "MODULE" is also an enum constant in the AccessFlag class, the references to ElementType's MODULE need to be qualified. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From mchung at openjdk.java.net Mon Feb 14 22:39:13 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Feb 2022 22:39:13 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v2] In-Reply-To: References: <7W2TRBwVgI8j6-lgu5IdoO0OeAmb_lo7yYIRxwTZBPI=.768c663e-c39a-4b4e-994f-eefdfd0af36b@github.com> <5DmTQnOLTQiKRcs9eJIpT0yPvxvfD738P1gKQXfmBLY=.b80f763c-90b3-4ce1-a7bc-62b62fd229f1@github.com> Message-ID: <4RbUTlULXkM4Snk-toN0EmMtM-0LxgfMIyHVeewcwZY=.86940be4-cd19-4133-9566-1f3250860315@github.com> On Mon, 14 Feb 2022 22:07:24 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 146: >> >>> 144: */ >>> 145: SYNTHETIC(0x00001000, false, >>> 146: Set.of(TYPE, FIELD, METHOD, CONSTRUCTOR, ElementType.MODULE, PARAMETER)), >> >> Suggestion: >> >> Set.of(TYPE, FIELD, METHOD, CONSTRUCTOR, MODULE, PARAMETER)), >> >> >> `ElementType.MODULE` is already imported. > > Hi Mandy. Since "MODULE" is also an enum constant in the AccessFlag class, the references to ElementType's MODULE need to be qualified. Ah, right. I missed this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Mon Feb 14 22:40:01 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Mon, 14 Feb 2022 22:40:01 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v2] In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: Changes from feedback. - Improved javadoc. - Single copyright date in new files. - Informative string in exception that is thrown. - Shortened the test name. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7447/files - new: https://git.openjdk.java.net/jdk/pull/7447/files/1bb6316f..02d00ecb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=00-01 Stats: 152 lines in 5 files changed: 77 ins; 70 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7447.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447 PR: https://git.openjdk.java.net/jdk/pull/7447 From dlong at openjdk.java.net Mon Feb 14 22:42:15 2022 From: dlong at openjdk.java.net (Dean Long) Date: Mon, 14 Feb 2022 22:42:15 GMT Subject: [jdk18] RFR: 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote: > We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures. > > Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending. > > Thanks, > Tobias Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/116 From darcy at openjdk.java.net Mon Feb 14 22:44:17 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Feb 2022 22:44:17 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v3] In-Reply-To: <3VRk2bX4uN8E5nkn2ZGE8xkb6igh_h_eL1EodXyiVEw=.b6def963-2731-45df-b2e2-1dcf55d104f1@github.com> References: <3VRk2bX4uN8E5nkn2ZGE8xkb6igh_h_eL1EodXyiVEw=.b6def963-2731-45df-b2e2-1dcf55d104f1@github.com> Message-ID: On Mon, 14 Feb 2022 21:12:51 GMT, Mandy Chung wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback explicitly stating returned sets are immutable. > > src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 196: > >> 194: >> 195: /** >> 196: * {@return corresponding integer mask for the flag; 0 if none} > > 0 would not be possible, right? Right; I'll fix the spec in the next revision. (This was a hold over of code originally copied from the Modifier class.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Mon Feb 14 22:47:53 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Feb 2022 22:47:53 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4] In-Reply-To: References: Message-ID: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to more review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/88be1e3e..ab623f8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=02-03 Stats: 68 lines in 5 files changed: 67 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Mon Feb 14 23:38:53 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Mon, 14 Feb 2022 23:38:53 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v3] In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: missing dot ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7447/files - new: https://git.openjdk.java.net/jdk/pull/7447/files/02d00ecb..c803a93b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7447.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447 PR: https://git.openjdk.java.net/jdk/pull/7447 From almatvee at openjdk.java.net Mon Feb 14 23:56:43 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Mon, 14 Feb 2022 23:56:43 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v3] In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: > Added ability to override description for additional launchers via "description" property. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8279995: jpackage --add-launcher option should allow overriding description [v3] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7399/files - new: https://git.openjdk.java.net/jdk/pull/7399/files/dbb36905..c5fea599 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=01-02 Stats: 64 lines in 2 files changed: 26 ins; 19 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7399/head:pull/7399 PR: https://git.openjdk.java.net/jdk/pull/7399 From duke at openjdk.java.net Tue Feb 15 00:10:44 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Tue, 15 Feb 2022 00:10:44 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v4] In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: remove excess description ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7447/files - new: https://git.openjdk.java.net/jdk/pull/7447/files/c803a93b..7d1b97fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7447.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447 PR: https://git.openjdk.java.net/jdk/pull/7447 From almatvee at openjdk.java.net Tue Feb 15 00:59:04 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 15 Feb 2022 00:59:04 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v2] In-Reply-To: References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> <9APLT6NMYVgxHT6-nYAffj03PrQGKUot1mbdqadmYGY=.1e393b4f-fdd9-4ed8-aebc-6e004ed7c866@github.com> Message-ID: On Fri, 11 Feb 2022 22:11:44 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279995: jpackage --add-launcher option should allow overriding description [v2] > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 90: > >> 88: .findFirst().orElse(null); >> 89: >> 90: return entry == null ? null : entry.getValue(); > > This can be simply > `rawProperties.stream().findAny(item -> item.getKey().equals(key)).map(e -> e.getValue()).orElse(null);` > > Or slightly better: > > public String getRawPropertyValue(String key, Supplier getDefault) { > return rawProperties.stream().findAny(item -> item.getKey().equals(key)).map(e -> e.getValue()).orElseGet(getDefault); > } > > > > Then we can create a function that will return the expected description of an additional launcher: > > private String getDesciption(JPackageCommand cmd) { > return getRawPropertyValue("description", () -> cmd.getArgumentValue("--description", unused -> "Unknown")); > } > > > This will let you avoid `if (expectedDescription != null)` checks and **always** verify launcher description. Fixed as suggested, except app name is used instead of "Unknown", since our default description is app name. > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 275: > >> 273: expectedDescription.equals(lines.get(i).trim()); >> 274: } >> 275: } > > This piece of code can be placed in `WindowsHelper.getExecutableDesciption(Path pathToExeFile)` function to make it reusable in other tests if needed. This way it can be used to verify the description of the main launcher. > > `if (lines != null)` check is rudimentary. > > Instead of running the loop, I'd simply check the output second from the last line for "---" and if so, would return the last line of the output. Otherwise would throw an exception indicating the command returned an unexpected result. I kept original implementation. Actually, powershell returns 6 lines: empty, FileDescription, ----, Actual Description, empty, empty. I think it is better to make sure FileDescription is present and go from top to bottom in case if output can be something like: empty, ErrorMessage, ---, Actual error message, empty, empty. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From darcy at openjdk.java.net Tue Feb 15 01:22:35 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Feb 2022 01:22:35 GMT Subject: RFR: JDK-8281766: Update java.lang.reflect.Parameter to implement Member Message-ID: Retrofitting of Parameter to implement Member, an interface already implemented by similar reflective modeling classes. Since Parameter is final, there is little compatibility impact from adding a new method. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8281767 I'll update the copyright year before pushing; I judged this as trivial enough to not require a regression test. ------------- Commit messages: - JDK-8281767: Update java.lang.reflect.Parameter to implement Member Changes: https://git.openjdk.java.net/jdk/pull/7468/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7468&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281766 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7468.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7468/head:pull/7468 PR: https://git.openjdk.java.net/jdk/pull/7468 From smarks at openjdk.java.net Tue Feb 15 02:04:08 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Feb 2022 02:04:08 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v6] In-Reply-To: <3gAe1sJ-OD0p22Jz7IXCDtv3K883wsg5JoNEQd9nPWQ=.7a3f1f2d-0c06-4998-a912-16f511a6b82d@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <3gAe1sJ-OD0p22Jz7IXCDtv3K883wsg5JoNEQd9nPWQ=.7a3f1f2d-0c06-4998-a912-16f511a6b82d@github.com> Message-ID: On Fri, 11 Feb 2022 19:32:48 GMT, XenoAmess wrote: >> 8281631: HashMap.putAll can cause redundant space waste > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > 9072610: HashMap.putAll can cause redundant space waste OK. The changes to HashMap and WeakHashMap look like they're on the right track. The changes to j.l.Class and the EnumConstantDirectory test don't belong here -- these are _uses_ of HashMap. This bug and fix should focus on HashMap itself, to ensure that the cases in question allocate a table of the right size. Are there any other maps that have this computation besides HashMap and WeakHashMap? There should be a regression test for this. It's probably sufficient to base this on your original test program, which puts 12 entries into a HashMap using a variety of techniques. It should assert that the table size is 16 in all cases. Also, should there be a test case for WeakHashMap? Also, I changed the summary of the bug report to be more precise. The PR title will need to be changed to correspond to it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From sviswanathan at openjdk.java.net Tue Feb 15 02:14:14 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 15 Feb 2022 02:14:14 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v3] In-Reply-To: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com> References: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com> Message-ID: On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > missing ForceInline Marked as reviewed by sviswanathan (Reviewer). Hotspot changes look good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From duke at openjdk.java.net Tue Feb 15 02:16:11 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 15 Feb 2022 02:16:11 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v6] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <3gAe1sJ-OD0p22Jz7IXCDtv3K883wsg5JoNEQd9nPWQ=.7a3f1f2d-0c06-4998-a912-16f511a6b82d@github.com> Message-ID: On Tue, 15 Feb 2022 02:00:35 GMT, Stuart Marks wrote: > The changes to j.l.Class and the EnumConstantDirectory test don't belong here -- these are _uses_ of HashMap. This bug and fix should focus on HashMap itself, to ensure that the cases in question allocate a table of the right size. A test will fail if not change codes there. > Are there any other maps that have this computation besides HashMap and WeakHashMap? good question. Can I get a list of classes where I should check??I guesd I shall start at linkerhashmap and sets? but have no further ideas? > There should be a regression test for this. It's probably sufficient to base this on your original test program, which puts 12 entries into a HashMap using a variety of techniques. It should assert that the table size is 16 in all cases. Also, should there be a test case for WeakHashMap? OK I will havr a try... > Also, I changed the summary of the bug report to be more precise. The PR title will need to be changed to correspond to it. Thanks. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From mchung at openjdk.java.net Tue Feb 15 02:17:00 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 15 Feb 2022 02:17:00 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v3] In-Reply-To: References: Message-ID: > This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. > > The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Remove the coupling of RawNativeLibraries with JNI library loading ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7435/files - new: https://git.openjdk.java.net/jdk/pull/7435/files/6e492d2b..755c67d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7435&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7435&range=01-02 Stats: 505 lines in 7 files changed: 259 ins; 213 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/7435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7435/head:pull/7435 PR: https://git.openjdk.java.net/jdk/pull/7435 From smarks at openjdk.java.net Tue Feb 15 03:48:09 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Feb 2022 03:48:09 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v6] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <3gAe1sJ-OD0p22Jz7IXCDtv3K883wsg5JoNEQd9nPWQ=.7a3f1f2d-0c06-4998-a912-16f511a6b82d@github.com> Message-ID: On Tue, 15 Feb 2022 02:12:48 GMT, XenoAmess wrote: > A test will fail if not change codes there. Every pr should pass ci, so I have no choice. Hm, yes I recall in the preliminary email that there was some mention of a test. However, the test seemed to use the same (incorrect) calculation, so maybe the test needs to be fixed instead. > Good question. Can I get a list of classes where I should check??I guesd I shall start at LinkedHashMap and hash sets? but have no further ideas? Offhand, the HashMap/LinkedHashMap and the corresponding Set classes, and WeakHashMap, are the main places to look. IdentityHashMap and the Map.of() implementations use a different organization so are probably unrelated. ConcurrentHashMap is another obvious place; you might want to investigate there, but depending on the fix (if any) we might want to handle it separately. I'd search for "loadFactor" or "LOAD_FACTOR" and see if anything else turns up. > OK I will have a try... a hard part is how to read private field in class but I think I can find some clue in the existed tests. There is an incantation in the test header to ensure that the java.base module is opened for reflection. Let me know if you have trouble with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From jpai at openjdk.java.net Tue Feb 15 03:58:18 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Feb 2022 03:58:18 GMT Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634? > > The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory): > > err.exception.message > err.invalid.options > err.multirelease.version.associated > err.missing.arg > err.multirelease.jar.malformed > err.option.already.specified > err.missing.dependences > err.module.not.found > err.invalid.path > err.genmoduleinfo.not.jarfile > err.invalid.arg.for.option > err.multirelease.option.notfound > err.filter.not.specified > err.unknown.option > err.command.set > err.invalid.filters > err.genmoduleinfo.unnamed.package > err.option.after.class > > Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?) > > The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix. > > An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool. This PR adds that assertion. > Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code: > - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test. > - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message. > - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR. > > With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR. Thank you for the reviews, Mandy and Naoto. ------------- PR: https://git.openjdk.java.net/jdk/pull/7455 From jpai at openjdk.java.net Tue Feb 15 03:58:18 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Feb 2022 03:58:18 GMT Subject: Integrated: 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634? > > The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory): > > err.exception.message > err.invalid.options > err.multirelease.version.associated > err.missing.arg > err.multirelease.jar.malformed > err.option.already.specified > err.missing.dependences > err.module.not.found > err.invalid.path > err.genmoduleinfo.not.jarfile > err.invalid.arg.for.option > err.multirelease.option.notfound > err.filter.not.specified > err.unknown.option > err.command.set > err.invalid.filters > err.genmoduleinfo.unnamed.package > err.option.after.class > > Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?) > > The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix. > > An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool. This PR adds that assertion. > Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code: > - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test. > - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message. > - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR. > > With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR. This pull request has now been integrated. Changeset: d4cd8dfe Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/d4cd8dfedbe220fb3b9a68650aba90536e9b12ee Stats: 14 lines in 2 files changed: 5 ins; 0 del; 9 mod 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters Reviewed-by: dfuchs, naoto, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7455 From duke at openjdk.java.net Tue Feb 15 04:17:12 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 15 Feb 2022 04:17:12 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v6] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <3gAe1sJ-OD0p22Jz7IXCDtv3K883wsg5JoNEQd9nPWQ=.7a3f1f2d-0c06-4998-a912-16f511a6b82d@github.com> Message-ID: On Tue, 15 Feb 2022 03:45:19 GMT, Stuart Marks wrote: > > A test will fail if not change codes there. Every pr should pass ci, so I have no choice. > > Hm, yes I recall in the preliminary email that there was some mention of a test. However, the test seemed to use the same (incorrect) calculation, so maybe the test needs to be fixed instead. These changes in those 2 class already the minimal changes for passing ci, as that test itself seems meaningful so I don't wanna shut it down. > Offhand, the HashMap/LinkedHashMap and the corresponding Set classes, and WeakHashMap, are the main places to look. IdentityHashMap and the Map.of() implementations use a different organization so are probably unrelated. ConcurrentHashMap is another obvious place; you might want to investigate there, but depending on the fix (if any) we might want to handle it separately. I'd search for "loadFactor" or "LOAD_FACTOR" and see if anything else turns up. Thanks, I will start from there and see if can found something interesting. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From cstein at openjdk.java.net Tue Feb 15 04:45:50 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 15 Feb 2022 04:45:50 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used [v2] In-Reply-To: References: Message-ID: > A number of modules declare that the "provide" ToolProvider. > > These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update wording ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7406/files - new: https://git.openjdk.java.net/jdk/pull/7406/files/56e0c249..eaa9a322 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7406&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7406&range=00-01 Stats: 19 lines in 6 files changed: 1 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7406.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7406/head:pull/7406 PR: https://git.openjdk.java.net/jdk/pull/7406 From stuart.marks at oracle.com Tue Feb 15 05:06:54 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 14 Feb 2022 21:06:54 -0800 Subject: [External] : Sequenced Collections In-Reply-To: <114971094.2972940.1644774057868.JavaMail.zimbra@u-pem.fr> References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> <114971094.2972940.1644774057868.JavaMail.zimbra@u-pem.fr> Message-ID: <0fd61be1-0e52-2854-a3ca-d73a2d27a90b@oracle.com> > Here is the first sentence of the javadoc for java.util.List "An ordered collection (also known as a sequence)." > And the first paragraph of java.util.RandomAccess "Marker interface used by List implementations to indicate that they support fast (generally constant time) random access. The primary purpose of this interface is to allow generic algorithms to alter their behavior to provide good performance when applied to either random or sequential access lists" > > You can find that the actual design, mixing ordered collection and indexed collection into one interface named List not great, but you can not say that this is not the actual design. Hi R?mi, You have a talent for omitting pieces of the specification that are inconvenient to your argument. The complete first paragraph of the List specification is An ordered collection (also known as a sequence). The user of this interface has precise control over where in the list each element is inserted. The user can access elements by their integer index (position in the list), and search for elements in the list. Clearly, a List is not *merely* an ordered collection or sequence. Positioning (which I refer to as external ordering) and access by index are also inherent to List. The original design does support "random access" and "sequential" (linked) lists. However, 20 years of experience with LinkedList, and with alternative algorithms that check the RandomAccess marker interface, have shown that this doesn't work very well. It would be a bad idea to extend that design by making LinkedHashSet implement List or for it to provide a List view. SortedSet is internally ordered and is therefore semantically incompatible with the external ordering of List. This incompatibility exists regardless of whether SortedSet implements List directly or merely provides a List view. In object design you can always take a sledgehammer to something and pound on it until it kind of looks like what you want. Indeed, you could do that with List in the way that you suggest, but the result will be confusing to work with and burdensome to implement. So, no, I'm not going to do that. s'marks On 2/13/22 9:40 AM, forax at univ-mlv.fr wrote: > > > ------------------------------------------------------------------------------------ > > *From: *"Tagir Valeev" > *To: *"Stuart Marks" > *Cc: *"Remi Forax" , "core-libs-dev" > > *Sent: *Saturday, February 12, 2022 4:24:24 AM > *Subject: *Re: [External] : Sequenced Collections > > Wow, I missed that the Sequenced Collections JEP draft was posted! > Of course, I strongly support this initiative and am happy that my proposal got > some love and is moving forward. In general, I like the JEP in the way it is. I > have only two slight concerns: > 1. I'm not sure that having addition methods (addFirst, addLast, putFirst, > putLast) is a good idea, as not every mutable implementation may support them. > While this adds some API unification, it's quite a rare case when this could be > necessary. I think most real world applications of Sequenced* types would be > around querying, or maybe draining (so removal operations are ok). Probably it > would be enough to add addFirst, addLast, putFirst, putLast?directly to the > compatible implementations/subinterfaces like List, LinkedHashSet, and > LinkedHashMap removing them from the Sequenced* interfaces. In this case, > SortedSet interface will not be polluted with operations that?can never be > implemented. Well my opinion is not very strong here. > > 2. SequencedCollection name is a little bit too long. I think every extra letter > adds a hesitation for users to use the type, especially in APIs where it could > be the most useful. I see the Naming section and must admit that I don't have > better ideas. Well, maybe just Sequenced would work? Or too vague? > > Speaking of Remi's suggestion, I don't think it's a good idea. Maybe it could be > if we designed the Collection API from scratch. > > > ?? > Here is the first sentence of the javadoc for java.util.List "An ordered collection > (also known as a /sequence/)." > And the first paragraph of java.util.RandomAccess "Marker interface used by |List| > implementations to indicate that they support fast (generally constant time) random > access. The primary purpose of this interface is to allow generic algorithms to > alter their behavior to provide good performance when applied to either random or > sequential access lists" > > You can find that the actual design, mixing ordered collection and indexed > collection into one interface named List not great, but you can not say that this is > not the actual design. > > But given the current state of Java collections, it's better to add new > interfaces than to put the new semantics to the java.util.List and greatly > increase the amount of non-random-accessed lists in the wild. > There are tons of code that implicitly assume fast random access of every > incoming list (using indexed iteration inside). The suggested approach could > become a performance disaster. > > > If you take several Java developers, some will stick to the javadoc definition, a > List is either sequential or random access and some will think that a List is only > random access. Because of that, adding more sequential implementations under the > List interface is an issue. > > Introducing SequencesCollection (more on the name later), a super interface of List > solves that issue, the new implementations will only implement the sequential part > of interface List. > But it does not solve the other problems, mainly adding 4 interfaces when one is > enough, not being backward compatible because of inference and the weird semantics > of LinkedHashMap. > > We still need SortedSet or LinkedHashSet to not directly implement > SequencesCollection but to use delegation and a have a method returning a view. The > same reasoning applied to SortedMap, LinkedHashMap. > By using views, there is no need to the two other proposed interfaces SequenceSet > and SequenceMap. > > Another question is ListIterator, a list can be iterated forward and backward, a > SequenceCollection can do almost the same thing, with iterator() and > reversed().iterator(). It's not exactly the same semantics but i don't think it > exist an implementation of SequenceCollection that can be implemented without the > property that given one element, it's predecessor and successor can be found in O(1). > Do we need a new SequenceCollectionIterator that provides the method > next/hasNext/previous/hasPrevious but not add/set/nextIndex/previousIndex ? > > For the name, Java uses single simple name of one syllable for the important > interface List, Set, Map or Deque (the javadoc of Deque insist that Deque should be > pronounced using one syllable). > So the name should be Seq. > The main issue with the name "Seq" is that it is perhaps too close to the name "Set". > Also, it can not be "Sequence" because of CharSequence. > > interface Seq extends Collection { > ?? void addFirst(); > ?? void addLast(); > ?? E getFirst(); > ?? E getLast(); > ?? E removeFirst(); > ?? E removeLast(); > ?? Seq reversed(); > } > > interface List extends Seq { } > > interface SortedSet implements Set {? // or NavigableSet > ?? // new methods > ?? Seq asSeq(); > } > > interface SortedMap implements Map {? // or NavigableMap > ?? // new methods > ?? Seq keySeq();? // do not use covariant return type > ?? Seq valueSeq(); > ?? Seq> entrySeq(); > } > > I'm still not sure that introducing an interface like Seq instead of using List is > the way to go. > If we do that, there will be a lot of blog post/bikeshedding about when to use List > vs Seq and a lot of github issues about taking a Seq instead of a List as parameter > of a method of a library. > > > With best regards, > Tagir Valeev. > > > R?mi > > > On Sat, Feb 12, 2022 at 2:26 AM Stuart Marks > wrote: > > Hi R?mi, > > I see that you're trying to reduce the number of interfaces introduced by > unifying > things around an existing interface, List. Yes, it's true that List is an > ordered > collection. However, your analysis conveniently omits other facts about List > that > make it unsuitable as a general "ordered collection" interface. Specifically: > > 1) List supports element access by int index; and > > 2) List is externally ordered. That is, its ordering is determined by a > succession > of API calls, irrespective of element values. This is in contrast to > SortedSet et al > which are internally ordered, in that the ordering is determined by the > element values. > > The problem with indexed element access is that it creates a bunch of hidden > performance pitfalls for any data structure where element access is other > than O(1). > So get(i) degrades to O(n), binarySearch degrades from O(log n) to O(n). > (This is in > the sequential implementation; the random access implementation degrades to > O(n log > n)). Apparently innocuous indexed for-loops degrade to quadratic. This is > one of the > reasons why LinkedList is a bad List implementation. > > If we refactor LinkedHashSet to implement List, we basically have created > another > situation just like LinkedList. That's a step in the wrong direction. > > Turning to internal ordering (SortedSet): it's fundamentally incompatible with > List's external ordering. List has a lot of positional mutation operations > such as > add(i, obj); after this call, you expect obj to appear at position i. That > can't > work with a SortedSet. > > There is implicit positioning semantics in other methods that don't have index > arguments. For example, replaceAll replaces each element of a List with the > result > of calling a function on that element. Crucially, the function result goes > into the > same location as the original element. That to cannot work with SortedSet. > > Well, we can try to deal with these issues somehow, like making certain methods > throw UnsupportedOperationException, or by relaxing the semantics of the > methods so > that they no longer have the same element positioning semantics. Either of > these > approaches contorts the List interface to such an extent that it's no longer > a List. > > So, no, it's not useful or effective to try to make List be the common "ordered > collection" interface. > > s'marks > > > > On 2/10/22 3:14 AM, Remi Forax wrote: > > I've read the draft of the JEP on sequenced collection, and i think the > proposed design can be improved. > > https://bugs.openjdk.java.net/browse/JDK-8280836 > > > > > I agree with the motivation, there is a need for an API to consider the > element of a list, a sorted set and a linked hash set as an ordered sequence > of elements with a simple way to access/add/remove the first/last element > and also reverse the elements as view. > > > > I disagree about the conclusion that we need to introduce 4 new > interfaces for that matter. > > > > Here are the reasons > > 1/ Usually an ordered collection is called a list. Introducing an > interface SequencedCollection for something which is usually called a list > will cause more harm than good. Or maybe we should rename LISP to SEQP :) > > > > 2/ There is already an interface List in Java, that represents an ordered > sequence of elements, with LinkedList being the name of the the double > linked list implementation. You can argue that there is a slight difference > between the semantics of java.util.List and the proposed syntax of > java.util.SequencedCollection, but given that people already have > difficulties to understand basic data structure concepts, as a teacher i > dread to have a discussion on those slight differences that are only true in > Java. > > > > If the collection API was not already existing, we may discuss about > having the same interface java.util.List to both indexed collection and > ordered collection, but that boat has sailed a long time ago. > > > > So in first approach, we should refactor sorted set and linked hash set > to directly implement java.util.List and all the proposed methods into > java.util.List. But as you hint in the Risks and Assumptions section, this > will cause regression due to inference and also we will have trouble with > LinkedHashMap (see below). > > > > 3/ LinkedHashMap mixes 3 implementations in one class, some of these > implementations does not conform to the semantics of SequencedMap. > > - You can opt-out having the key sequentially ordered as defined by > SequencedMap by using the constructor LinkedHashMap(int initialCapacity, > float loadFactor, boolean accessOrder) and passing true as last parameter. > > - You can opt-out having the key sequentially ordered as defined by > SequencedMap by overriding removeEldestEntry(), removing the first entry at > the same time you add a new one. > > > > Because all these reasons, i think we should move to another design, > using delegation instead of inheritance, which for the collection framework > means exposing new way to access/modify sorted set and linked hash set > through java.util.List views. > > > > The concept of views is not a new concept, it's used in Arrays.asList(), > List.subList() or Map.keySet()/values()/entrySet() (and more). The idea is > not that a sorted set is a list but that it provides a method to see it as a > list. It solves our problem of compatibility by not adding super types to > existing type and also the problem of the semantics of LinkedHashMap because > a view keeps the semantics of the data structure it originated. > > > > Here is the proposed new methods in List, SortedSet and SortedMap. > > > > interface List extends Collection { > >? ? // new methods > >? ? void addFirst(); > >? ? void addLast(); > >? ? E getFirst(); > >? ? E getLast(); > >? ? E removeFirst(); > >? ? E removeLast(); > >? ? List reversedList(); // or descendingList() ?? > > } > > > > interface SortedSet implements Set { > >? ? // new methods > >? ? List asList(); > > } > > > > interface SortedMap implements Map { > >? ? // new methods > >? ? List keyList();? // do not use covariant return type > >? ? List> entryList();? // same > > } > > > > I believe this design is objectively better than the one proposed because > as a user being able to use new interfaces is a slow process, the > libraries/dependencies must be updated to take the new interfaces as > parameter before the new types can be used. By contrast, the proposed design > only enhance existing interfaces so people will enjoy the new methods > directly when introduced. > > > > R?mi > > > > From david.holmes at oracle.com Tue Feb 15 05:36:54 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Feb 2022 15:36:54 +1000 Subject: RFR: JDK-8281766: Update java.lang.reflect.Parameter to implement Member In-Reply-To: References: Message-ID: <5213c742-3d1d-f425-c200-a8b738ffc3dd@oracle.com> Hi Joe, On 15/02/2022 11:22 am, Joe Darcy wrote: > Retrofitting of Parameter to implement Member, an interface already implemented by similar reflective modeling classes. But a parameter is not a Member! David > Since Parameter is final, there is little compatibility impact from adding a new method. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8281767 > > I'll update the copyright year before pushing; I judged this as trivial enough to not require a regression test. > > ------------- > > Commit messages: > - JDK-8281767: Update java.lang.reflect.Parameter to implement Member > > Changes: https://git.openjdk.java.net/jdk/pull/7468/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7468&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8281766 > Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/7468.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/7468/head:pull/7468 > > PR: https://git.openjdk.java.net/jdk/pull/7468 From duke at openjdk.java.net Tue Feb 15 05:41:13 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Tue, 15 Feb 2022 05:41:13 GMT Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts [v3] In-Reply-To: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com> References: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com> Message-ID: On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai wrote: >> Hi, >> >> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > missing ForceInline Thanks a lot for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From cstein at openjdk.java.net Tue Feb 15 06:40:57 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 15 Feb 2022 06:40:57 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used [v3] In-Reply-To: References: Message-ID: > A number of modules declare that the "provide" ToolProvider. > > These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Fix typo [skip actions] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7406/files - new: https://git.openjdk.java.net/jdk/pull/7406/files/eaa9a322..ca92a6cc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7406&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7406&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7406.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7406/head:pull/7406 PR: https://git.openjdk.java.net/jdk/pull/7406 From stuart.marks at oracle.com Tue Feb 15 06:45:01 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 14 Feb 2022 22:45:01 -0800 Subject: [External] : Sequenced Collections In-Reply-To: References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> Message-ID: On 2/11/22 7:24 PM, Tagir Valeev wrote: > Of course, I strongly support this initiative and am happy that my proposal got some > love and is moving forward. In general, I like the JEP in the way it is. I have only > two slight concerns: > 1. I'm not sure that having addition methods (addFirst, addLast, putFirst, putLast) > is a good idea, as not every mutable implementation may support them. While this > adds some API unification, it's quite a rare case when this could be necessary. I > think most real world applications of Sequenced* types would be around querying, or > maybe draining (so removal operations are ok). Probably it would be enough to add > addFirst, addLast, putFirst, putLast?directly to the compatible > implementations/subinterfaces like List, LinkedHashSet, and LinkedHashMap removing > them from the Sequenced* interfaces. In this case, SortedSet interface will not be > polluted with operations that?can never be implemented. Well my opinion is not very > strong here. Hi Tagir, thanks for looking at this. Yes, this particular issue involves some tradeoffs. As you noted, addFirst/addLast can't be implemented by SortedSet and so they throw UOE. This is an unfortunate asymmetry. If these were omitted, the design would be cleaner in the sense that there would be fewer things that throw UOE. But there are costs to not having those methods, which I think outweigh the asymmetry around SortedSet. The other collections have interfaces corresponding to common implementations: ArrayList has List, ArrayDeque has Deque, TreeSet has SortedSet, etc., and Java style tends to encourage "programming to the interface." But there's no interface that corresponds to LinkedHashSet. Over the years we've mostly just put up with this gap. But it's really noticeable when you add the reversed view. The reversed view of a List is a List, the reversed view of a Deque is a Deque, the reversed view of a SortedSet is a SortedSet, and the reversed view of a LinkedHashSet is a ... what? SequencedSet is the answer here. We also want the reversed view to be equivalent in power to the forward view. If the addFirst/addLast methods were only on LinkedHashSet, it would be possible to add at either end of a LinkedHashSet but not its reversed view. This is a big hole. So the addFirst/addLast methods need to be on the interface. Since the method specifications originally came from Deque, they're actually on SequencedCollection. In addition, the majority of cases can implement addFirst/addLast: Deque, List, LinkedHashSet. SortedSet is the outlier; it would seem a shame to omit the methods only because of SortedSet. The alternative is to omit SortedSet from the SequencedCollection family, but that seems worse, as SortedSet can implement the other operations just fine. > 2. SequencedCollection name is a little bit too long. I think every extra letter > adds a hesitation for users to use the type, especially in APIs where it could be > the most useful. I see the Naming section and must admit that I don't have better > ideas. Well, maybe just Sequenced would work? Or too vague? Yeah, the names are rather longer than I would have liked. At least "Sequenced" is shorter than "Reversible". :-) One reason it's ok to have a longer name is that it reduces the possibility of name collections. We want the types to be nouns, so the obvious noun here is Sequence. But we need Set and Map variations as well, so that would result in Sequence SequencedSet SequencedMap or similar variations. Kind of asymmetrical. Or maybe Seq, SeqSet, SeqMap? Not clearly better. One nice thing about the names in the current draft is that they line up with the existing collection types nicely: Collection SequencedCollection Set SequencedSet Map SequencedMap I'm not claiming these are absolutely the best names, but I've thought about this for a while and I haven't been able to come up with anything clearly better. I'm open to better names if there's something I might have missed though. s'marks From asotona at openjdk.java.net Tue Feb 15 07:00:07 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Tue, 15 Feb 2022 07:00:07 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4] In-Reply-To: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> References: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> Message-ID: On Mon, 14 Feb 2022 22:47:53 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 55: > 53: */ > 54: @SuppressWarnings("doclint:reference") // cross-module link > 55: public enum AccessFlag { I think there is missing SUPER ACC_SUPER 0x0020 ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From thartmann at openjdk.java.net Tue Feb 15 07:10:21 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 15 Feb 2022 07:10:21 GMT Subject: [jdk18] RFR: 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote: > We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures. > > Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending. > > Thanks, > Tobias Vladimir, Dean, thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk18/pull/116 From thartmann at openjdk.java.net Tue Feb 15 07:10:22 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 15 Feb 2022 07:10:22 GMT Subject: [jdk18] Integrated: 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE In-Reply-To: References: Message-ID: <1D6SYN3fdj71U0GtxJE-_cLjtGOksVPyILjctK05mjw=.c4c8ec5f-728a-4f72-9095-40ed3f89dda2@github.com> On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote: > We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures. > > Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 2be2a298 Author: Tobias Hartmann URL: https://git.openjdk.java.net/jdk18/commit/2be2a298f13c3a38d9518ccfea11dfd8a736d56c Stats: 423 lines in 9 files changed: 0 ins; 412 del; 11 mod 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: kvn, dlong ------------- PR: https://git.openjdk.java.net/jdk18/pull/116 From aturbanov at openjdk.java.net Tue Feb 15 07:13:06 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 15 Feb 2022 07:13:06 GMT Subject: Integrated: 8281728: Redundant null check in LineNumberInputStream.read In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 18:51:22 GMT, Andrey Turbanov wrote: > At start of method `b` is already checked for null. > > https://github.com/openjdk/jdk/blob/178b962e01cc6c150442bf41dc6bd199caff0042/src/java.base/share/classes/java/io/LineNumberInputStream.java#L129-L131 > > Found by IntelliJ IDEA > ![IDEA warning](https://user-images.githubusercontent.com/741251/153844753-a36c7d4f-6fc1-4618-9d22-04541af155b2.png) This pull request has now been integrated. Changeset: 622970e4 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/622970e47cedd6e0b94b74235aa984ad79281389 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8281728: Redundant null check in LineNumberInputStream.read Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/7409 From zjx001202 at gmail.com Tue Feb 15 07:13:59 2022 From: zjx001202 at gmail.com (Glavo) Date: Tue, 15 Feb 2022 15:13:59 +0800 Subject: [External] : Sequenced Collections In-Reply-To: References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> Message-ID: How about `OrderedCollection`? The meaning of "order" has been defined in the Stream API, so I think the 'ordered' may be a better choice. Stuart Marks ?2022?2?15??? 14:45??? > > > On 2/11/22 7:24 PM, Tagir Valeev wrote: > > Of course, I strongly support this initiative and am happy that my > proposal got some > > love and is moving forward. In general, I like the JEP in the way it is. > I have only > > two slight concerns: > > > 1. I'm not sure that having addition methods (addFirst, addLast, > putFirst, putLast) > > is a good idea, as not every mutable implementation may support them. > While this > > adds some API unification, it's quite a rare case when this could be > necessary. I > > think most real world applications of Sequenced* types would be around > querying, or > > maybe draining (so removal operations are ok). Probably it would be > enough to add > > addFirst, addLast, putFirst, putLast directly to the compatible > > implementations/subinterfaces like List, LinkedHashSet, and > LinkedHashMap removing > > them from the Sequenced* interfaces. In this case, SortedSet interface > will not be > > polluted with operations that can never be implemented. Well my opinion > is not very > > strong here. > > Hi Tagir, thanks for looking at this. > > Yes, this particular issue involves some tradeoffs. As you noted, > addFirst/addLast > can't be implemented by SortedSet and so they throw UOE. This is an > unfortunate > asymmetry. If these were omitted, the design would be cleaner in the sense > that > there would be fewer things that throw UOE. > > But there are costs to not having those methods, which I think outweigh > the > asymmetry around SortedSet. > > The other collections have interfaces corresponding to common > implementations: > ArrayList has List, ArrayDeque has Deque, TreeSet has SortedSet, etc., and > Java > style tends to encourage "programming to the interface." But there's no > interface > that corresponds to LinkedHashSet. > > Over the years we've mostly just put up with this gap. But it's really > noticeable > when you add the reversed view. The reversed view of a List is a List, the > reversed > view of a Deque is a Deque, the reversed view of a SortedSet is a > SortedSet, and the > reversed view of a LinkedHashSet is a ... what? SequencedSet is the answer > here. > > We also want the reversed view to be equivalent in power to the forward > view. If the > addFirst/addLast methods were only on LinkedHashSet, it would be possible > to add at > either end of a LinkedHashSet but not its reversed view. This is a big > hole. So the > addFirst/addLast methods need to be on the interface. Since the method > specifications originally came from Deque, they're actually on > SequencedCollection. > > In addition, the majority of cases can implement addFirst/addLast: Deque, > List, > LinkedHashSet. SortedSet is the outlier; it would seem a shame to omit the > methods > only because of SortedSet. The alternative is to omit SortedSet from the > SequencedCollection family, but that seems worse, as SortedSet can > implement the > other operations just fine. > > > 2. SequencedCollection name is a little bit too long. I think every > extra letter > > adds a hesitation for users to use the type, especially in APIs where it > could be > > the most useful. I see the Naming section and must admit that I don't > have better > > ideas. Well, maybe just Sequenced would work? Or too vague? > > Yeah, the names are rather longer than I would have liked. At least > "Sequenced" is > shorter than "Reversible". :-) > > One reason it's ok to have a longer name is that it reduces the > possibility of name > collections. > > We want the types to be nouns, so the obvious noun here is Sequence. But > we need Set > and Map variations as well, so that would result in > > Sequence > SequencedSet > SequencedMap > > or similar variations. Kind of asymmetrical. Or maybe Seq, SeqSet, SeqMap? > Not > clearly better. > > One nice thing about the names in the current draft is that they line up > with the > existing collection types nicely: > > Collection SequencedCollection > Set SequencedSet > Map SequencedMap > > I'm not claiming these are absolutely the best names, but I've thought > about this > for a while and I haven't been able to come up with anything clearly > better. I'm > open to better names if there's something I might have missed though. > > s'marks > From asotona at openjdk.java.net Tue Feb 15 07:20:13 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Tue, 15 Feb 2022 07:20:13 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4] In-Reply-To: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> References: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> Message-ID: <0WF8hyxQSTsxCmq9zaBKD4aqOSA_fg06D5s2WPf9F8c=.61509b3c-a7b8-4251-8cfe-d2e1b0222146@github.com> On Mon, 14 Feb 2022 22:47:53 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. I would also recommend to sort access flags by the mask value. Sorted flags will match the specification and it will also make more deterministic all operations crawling through all the flags. This AccessFlag enum is very useful even outside of java.lang.reflect and having it ordered by the spec would make it perfect. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From zjx001202 at gmail.com Tue Feb 15 07:38:44 2022 From: zjx001202 at gmail.com (Glavo) Date: Tue, 15 Feb 2022 15:38:44 +0800 Subject: [External] : Sequenced Collections In-Reply-To: References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> Message-ID: On the one hand, I am very opposed to using the name ` SequencedCollection `. In the JVM ecosystem, several widely used libraries are using the term Seq, Typical examples are Scala and kotlin's standard libraries, Scala uses `Seq` as a similar correspondence to a `List`, while Kotlin's `Sequence` represents something with semantics between `Iterable` and `Stream`. Introducing things with similar names may lead to more confusion. On the other hand, we have defined the meaning of "ordered". Refer to `Stream::forEachOrdered` and `Spliterator.ORDERED`. Their semantics for known collections are similar to the one you discussed. Direct reuse is not only shorter, but also more harmonious and unified in semantics. So I think `OrderedCollection` is a good choice. On Tue, Feb 15, 2022 at 2:45 PM Stuart Marks wrote: > > > On 2/11/22 7:24 PM, Tagir Valeev wrote: > > Of course, I strongly support this initiative and am happy that my > proposal got some > > love and is moving forward. In general, I like the JEP in the way it is. > I have only > > two slight concerns: > > > 1. I'm not sure that having addition methods (addFirst, addLast, > putFirst, putLast) > > is a good idea, as not every mutable implementation may support them. > While this > > adds some API unification, it's quite a rare case when this could be > necessary. I > > think most real world applications of Sequenced* types would be around > querying, or > > maybe draining (so removal operations are ok). Probably it would be > enough to add > > addFirst, addLast, putFirst, putLast directly to the compatible > > implementations/subinterfaces like List, LinkedHashSet, and > LinkedHashMap removing > > them from the Sequenced* interfaces. In this case, SortedSet interface > will not be > > polluted with operations that can never be implemented. Well my opinion > is not very > > strong here. > > Hi Tagir, thanks for looking at this. > > Yes, this particular issue involves some tradeoffs. As you noted, > addFirst/addLast > can't be implemented by SortedSet and so they throw UOE. This is an > unfortunate > asymmetry. If these were omitted, the design would be cleaner in the sense > that > there would be fewer things that throw UOE. > > But there are costs to not having those methods, which I think outweigh > the > asymmetry around SortedSet. > > The other collections have interfaces corresponding to common > implementations: > ArrayList has List, ArrayDeque has Deque, TreeSet has SortedSet, etc., and > Java > style tends to encourage "programming to the interface." But there's no > interface > that corresponds to LinkedHashSet. > > Over the years we've mostly just put up with this gap. But it's really > noticeable > when you add the reversed view. The reversed view of a List is a List, the > reversed > view of a Deque is a Deque, the reversed view of a SortedSet is a > SortedSet, and the > reversed view of a LinkedHashSet is a ... what? SequencedSet is the answer > here. > > We also want the reversed view to be equivalent in power to the forward > view. If the > addFirst/addLast methods were only on LinkedHashSet, it would be possible > to add at > either end of a LinkedHashSet but not its reversed view. This is a big > hole. So the > addFirst/addLast methods need to be on the interface. Since the method > specifications originally came from Deque, they're actually on > SequencedCollection. > > In addition, the majority of cases can implement addFirst/addLast: Deque, > List, > LinkedHashSet. SortedSet is the outlier; it would seem a shame to omit the > methods > only because of SortedSet. The alternative is to omit SortedSet from the > SequencedCollection family, but that seems worse, as SortedSet can > implement the > other operations just fine. > > > 2. SequencedCollection name is a little bit too long. I think every > extra letter > > adds a hesitation for users to use the type, especially in APIs where it > could be > > the most useful. I see the Naming section and must admit that I don't > have better > > ideas. Well, maybe just Sequenced would work? Or too vague? > > Yeah, the names are rather longer than I would have liked. At least > "Sequenced" is > shorter than "Reversible". :-) > > One reason it's ok to have a longer name is that it reduces the > possibility of name > collections. > > We want the types to be nouns, so the obvious noun here is Sequence. But > we need Set > and Map variations as well, so that would result in > > Sequence > SequencedSet > SequencedMap > > or similar variations. Kind of asymmetrical. Or maybe Seq, SeqSet, SeqMap? > Not > clearly better. > > One nice thing about the names in the current draft is that they line up > with the > existing collection types nicely: > > Collection SequencedCollection > Set SequencedSet > Map SequencedMap > > I'm not claiming these are absolutely the best names, but I've thought > about this > for a while and I haven't been able to come up with anything clearly > better. I'm > open to better names if there's something I might have missed though. > > s'marks > From lucy at openjdk.java.net Tue Feb 15 08:29:16 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 15 Feb 2022 08:29:16 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 12:11:54 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad 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: > > - Merge branch 'master' into count_positives > - Restore partial vector checks in AVX2 and SSE intrinsic variants > - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral > - Simplify changes to encodeUTF8 > - Fix little-endian error caught by testing > - Reduce jumps in the ascii path > - Remove unused tail_mask > - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives) > - Add more comments, simplify tail branching in AVX512 variant > - Resolve issues in the precise implementation > - ... and 13 more: https://git.openjdk.java.net/jdk/compare/d4fb8919...c4bb3612 Hi Claes, I'm working on the s390 implementation. I hoped to have it ready, but tests are failing. I'll post a PR (similar to Martin's) once I believe my work is worth to be looked at. Just for clarification: the return value must be the index of the first negative byte? ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From duke at openjdk.java.net Tue Feb 15 09:26:12 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 15 Feb 2022 09:26:12 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4] In-Reply-To: References: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> Message-ID: On Tue, 15 Feb 2022 06:56:51 GMT, Adam Sotona wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to more review feedback. > > src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 55: > >> 53: */ >> 54: @SuppressWarnings("doclint:reference") // cross-module link >> 55: public enum AccessFlag { > > I think there is missing SUPER ACC_SUPER 0x0020 Note?that the?presence or?absence of?`ACC_SUPER` has?no?effect since?**Java?8**, which?always treats?it as?set regardless?of the?actual?contents of?the?binary class?file. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Tue Feb 15 09:26:12 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 15 Feb 2022 09:26:12 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4] In-Reply-To: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> References: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> Message-ID: On Mon, 14 Feb 2022 22:47:53 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to more review feedback. src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 163: > 161: * @see Class#isEnum() > 162: */ > 163: ENUM(0x00004000, false, Set.of(TYPE, FIELD)), These?can?use the?**package?private** constant?fields from?`java.lang.reflect.Modifier`: ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Tue Feb 15 09:29:13 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 15 Feb 2022 09:29:13 GMT Subject: RFR: JDK-8281766: Update java.lang.reflect.Parameter to implement Member In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 01:13:43 GMT, Joe Darcy wrote: > Retrofitting of Parameter to implement Member, an interface already implemented by similar reflective modeling classes. > > Since Parameter is final, there is little compatibility impact from adding a new method. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8281767 > > I'll update the copyright year before pushing; I judged this as trivial enough to not require a regression test. src/java.base/share/classes/java/lang/reflect/Parameter.java line 30: > 28: import java.util.HashMap; > 29: import java.util.Map; > 30: import java.util.Set; `java.util.Set` doesn?t?seem to?be?referenced from anywhere else in?this?class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7468 From mcimadamore at openjdk.java.net Tue Feb 15 09:52:18 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Feb 2022 09:52:18 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v3] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 02:17:00 GMT, Mandy Chung wrote: >> This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. >> >> The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Remove the coupling of RawNativeLibraries with JNI library loading Looks - good, I like the way this patch makes a cleaner distinction between JNI-like and more dlopen-like library loading. src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 427: > 425: new ConcurrentHashMap<>(); > 426: > 427: static void acquireNativeLibraryLock(String libraryName) { Note sure about these two routines. Should they be shared? Should we have two locks, one for JNI, one for raw? Of course, as is the code looks fine - but I wonder if a single lock isn't overly strict. src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java line 107: > 105: * {@link System#mapLibraryName} can be used to convert a name to > 106: * a platform-specific pathname: > 107: * {@snipplet Suggestion: * {@snippet ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7435 From redestad at openjdk.java.net Tue Feb 15 10:41:10 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 15 Feb 2022 10:41:10 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 08:25:29 GMT, Lutz Schmidt wrote: > Hi Claes, I'm working on the s390 implementation. Awesome, thanks! > > Just for clarification: the return value must be the index of the first negative byte? Yes, or the length if there are no such bytes. I've considered (and am still considering) writing the spec of `countPositives` to allow intrinsics to do an early return of a value that is less than the index if it's prohibitively expensive or complicated to implement the intrinsic to be precise in the case where it finds a negative byte. While it must be precise w.r.t. returning the full length if it's all positive bytes, no call site would break if the intrinsic returned 0 or some convenient number less than the first negative index (my first experiments with the x86 intrinsic did it like this, but since the semantics of the intrinsic would then differ from the java code I was asked to try and make it precise). The aarch64 algorithm is proving to be a challenge to work with and I might ask again for some leeway in a first implementation there. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From lancea at openjdk.java.net Tue Feb 15 11:23:09 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Feb 2022 11:23:09 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used [v3] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 06:40:57 GMT, Christian Stein wrote: >> A number of modules declare that the "provide" ToolProvider. >> >> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo > > [skip actions] I think we are looking good. Thank you for your persistence on the wordsmithing ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7406 From lucy at openjdk.java.net Tue Feb 15 11:24:18 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 15 Feb 2022 11:24:18 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v2] In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 12:11:54 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad 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: > > - Merge branch 'master' into count_positives > - Restore partial vector checks in AVX2 and SSE intrinsic variants > - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral > - Simplify changes to encodeUTF8 > - Fix little-endian error caught by testing > - Reduce jumps in the ascii path > - Remove unused tail_mask > - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives) > - Add more comments, simplify tail branching in AVX512 variant > - Resolve issues in the precise implementation > - ... and 13 more: https://git.openjdk.java.net/jdk/compare/cee17570...c4bb3612 Well, with the existing implementations for ppc and s390, I do not see a complexity advantage with a relaxed spec. The code would have to be there anyway. When it comes to cost, the worst case would be an array of length n, a loop unroll factor of (u==n) and the first (and only) negative byte at index (n-1). All bytes would then be checked twice. With growing n, the overhead diminishes. After all, you want profile-based stub generation - with actual load matching the profile, of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Tue Feb 15 13:45:07 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 15 Feb 2022 13:45:07 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 11:20:55 GMT, Lutz Schmidt wrote: > Well, with the existing implementations for ppc and s390, I do not see a complexity advantage with a relaxed spec. The code would have to be there anyway. Same for x86, but we could avoid going into and checking the tail on a negative byte in a vector and instead an early return that returns `N * vector_size` where `N` is the number of vectors we've checked that were all positive. This could save a few ns in some cases. > > When it comes to cost, the worst case would be an array of length n, a loop unroll factor of (u==n) and the first (and only) negative byte at index (n-1). All bytes would then be checked twice. With growing n, the overhead diminishes. After all, you want profile-based stub generation - with actual load matching the profile, of course. Sounds about right. I've explored the cost of this in a few microbenchmarks. In `StringDecode/-Encode` such double-checking would happen anyhow later on in the java code. So for most of the prominent use such double-checking is performance neutral even in the worst case. There are a few places where we don't productively use the count and continue to lean on a `hasNegatives` predicate which calls into `countPositives`. This will mean a small amount of useless computation on certain inputs. For the 16- and 32-byte vectors I've benchmarked extensively on x86 (AVX2) the worst case overhead landed in the vicinity of 20 cycles (7.5-15ns @ 2.4Ghz). Allowing for imprecision _could_ improve a few such corner cases, but I've not found a performance sensitive place where it would really matter. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From alanb at openjdk.java.net Tue Feb 15 14:40:16 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Feb 2022 14:40:16 GMT Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the name that can be used [v3] In-Reply-To: References: Message-ID: <_Ua0IDQTMbEnwATcYEu33eJBDjh3R8TINQ_OeIKgoUY=.71140c81-5672-47e3-9615-564a2428210f@github.com> On Tue, 15 Feb 2022 06:40:57 GMT, Christian Stein wrote: >> A number of modules declare that the "provide" ToolProvider. >> >> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo > > [skip actions] Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From asemenyuk at openjdk.java.net Tue Feb 15 15:45:08 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 15 Feb 2022 15:45:08 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v3] In-Reply-To: References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: <_Bxmxz6zi-YqyktkzncVpA7QNHpIjTN6ihCrlrlA-JM=.4907c7fb-4a8c-4e67-b562-62f9eb0b8bb9@github.com> On Mon, 14 Feb 2022 23:56:43 GMT, Alexander Matveev wrote: >> Added ability to override description for additional launchers via "description" property. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8279995: jpackage --add-launcher option should allow overriding description [v3] test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 265: > 263: WindowsHelper.getExecutableDesciption(launcherPath); > 264: TKit.assertEquals(expectedDescription, actualDescription, > 265: "Invalid file description"); The message should be the name of an action taken, not the error description. The testing framework will build the error message itself. So it can be `Check file description of `. You can use `TKit.assertDirectoryExists()` as a reference -https://github.com/openjdk/jdk/blob/bc6148407e629bd99fa5a8577ebd90320610f349/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java#L683 ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From asemenyuk at openjdk.java.net Tue Feb 15 15:51:15 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 15 Feb 2022 15:51:15 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v3] In-Reply-To: References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Mon, 14 Feb 2022 23:56:43 GMT, Alexander Matveev wrote: >> Added ability to override description for additional launchers via "description" property. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8279995: jpackage --add-launcher option should allow overriding description [v3] test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 159: > 157: } > 158: > 159: TKit.assertNotNull(description, "Failed to get file description"); Failure to get the executable's description through powersehll script is not an issue of a test case being executed. This is the testing framework issue. Throwing RuntimeException with the message containing file path will be the appropriate error handling. Having a file name in the exception message will help to localize the issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From duke at openjdk.java.net Tue Feb 15 16:50:47 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 15 Feb 2022 16:50:47 GMT Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v7] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap.putAll can cause redundant space waste XenoAmess has updated the pull request incrementally with one additional commit since the last revision: 9072610: HashMap.putAll can cause redundant space waste ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/4e42cae1..95dc4c1b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=05-06 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Tue Feb 15 16:58:49 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 15 Feb 2022 16:58:49 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v8] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <2f7tHP7_rkjgT3WHuzmzSwNJ7rwqlWItfTuswfd11bg=.775c5f56-e8f1-4f77-8b25-c95788fbd286@github.com> > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: 9072610: HashMap.putAll can cause redundant space waste ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/95dc4c1b..e77fe7db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=06-07 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Tue Feb 15 17:14:06 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 15 Feb 2022 17:14:06 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v8] In-Reply-To: <2f7tHP7_rkjgT3WHuzmzSwNJ7rwqlWItfTuswfd11bg=.775c5f56-e8f1-4f77-8b25-c95788fbd286@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <2f7tHP7_rkjgT3WHuzmzSwNJ7rwqlWItfTuswfd11bg=.775c5f56-e8f1-4f77-8b25-c95788fbd286@github.com> Message-ID: On Tue, 15 Feb 2022 16:58:49 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > 9072610: HashMap.putAll can cause redundant space waste IdentityHashMap...checked. uninvolved. ConcurrentHashMap...checked. fixed. HashMap and WeakHashMap...checked. fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From asemenyuk at openjdk.java.net Tue Feb 15 17:50:26 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 15 Feb 2022 17:50:26 GMT Subject: RFR: 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 Message-ID: Code clean up. Remove obsolete comments, unused imports, and unneeded jtreg test parameter. Fix the code to handle the case when installers are not created and there is nothing to verify in the test. ------------- Commit messages: - 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 Changes: https://git.openjdk.java.net/jdk/pull/7481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7481&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281170 Stats: 46 lines in 1 file changed: 12 ins; 19 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/7481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7481/head:pull/7481 PR: https://git.openjdk.java.net/jdk/pull/7481 From cstein at openjdk.java.net Tue Feb 15 17:59:09 2022 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 15 Feb 2022 17:59:09 GMT Subject: Integrated: 8280825: Modules that "provide" ToolProvider should document the name that can be used In-Reply-To: References: Message-ID: <8zb_ci6u-SZ3pwg_J4JQbsGaB1GecpIJPrEP1j1BgVs=.4ac2ef58-66c6-4bd6-bfff-2f856ac89041@github.com> On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein wrote: > A number of modules declare that the "provide" ToolProvider. > > These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag. This pull request has now been integrated. Changeset: 394ce5f9 Author: Christian Stein Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/394ce5f948c21b3861d76dd8db57957efa1df979 Stats: 27 lines in 6 files changed: 22 ins; 0 del; 5 mod 8280825: Modules that "provide" ToolProvider should document the name that can be used Reviewed-by: jjg, lancea, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7406 From brian.goetz at oracle.com Tue Feb 15 18:12:30 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 15 Feb 2022 13:12:30 -0500 Subject: [External] : Sequenced Collections In-Reply-To: References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> Message-ID: <0fd5b3de-1e28-f393-a406-0755c1bb1ea3@oracle.com> It's a time-honored tradition in naming bikesheds to pick and choose the precedents you want to be "consistent" with, and I think that's what's going on here with your preference for "Ordered" over "Sequenced".? But in an ecosystem as large as Java, you can always find conflicting precedents to be "consistent" with, which makes "for consistency" arguments generally weak. There's a reason that we didn't propose "ordered", and it's not because it didn't occur to us; it is already heavily used to indicate ordering of the elements.? Any mention of Comparator or Comparable will quickly use the word "order" to mean ordering of the elements (after the mathematical terms "partial order" and "total order".)? From Comparator (first lines): ?* A comparison function, which imposes a total ordering on ?* some collection of objects.? This ordering is referred to as the class's natural ?* ordering From Comparable (first lines): ?* Compares this object with the specified object for order. From TreeSet: ?* Constructs a new, empty tree set, sorted according to the ?* natural ordering of its elements. From Collections::sort: ?* Sorts the specified list into ascending order, according to the ?* {@linkplain Comparable natural ordering} of its elements. And there are also helper methods like Collections::reverseOrder and Comparator::naturalOrder. So, we can find precedent for "ordered" meaning element order, and also for it meaning has-an-encounter-order.? So how do we choose?? Well, we're talking about enhancing *collections*, and throughout Collections, "ordered" primarily means "element order".? So while you could be mad at Streams for having used "ordered" to mean "has an encounter order", it's still not the case that both terms have an equal claim; context matters. On 2/15/2022 2:38 AM, Glavo wrote: > On the one hand, I am very opposed to using the name ` SequencedCollection > `. In the JVM ecosystem, several widely used libraries are using the term > Seq, > Typical examples are Scala and kotlin's standard libraries, Scala uses > `Seq` as a similar correspondence to a `List`, while Kotlin's `Sequence` > represents something with semantics between `Iterable` and `Stream`. > Introducing things with similar names may lead to more confusion. > > On the other hand, we have defined the meaning of "ordered". > Refer to `Stream::forEachOrdered` and `Spliterator.ORDERED`. Their > semantics for known collections are similar to the one you discussed. > Direct reuse is not only shorter, but also more harmonious and unified in > semantics. > So I think `OrderedCollection` is a good choice. > > > On Tue, Feb 15, 2022 at 2:45 PM Stuart Marks > wrote: > >> >> On 2/11/22 7:24 PM, Tagir Valeev wrote: >>> Of course, I strongly support this initiative and am happy that my >> proposal got some >>> love and is moving forward. In general, I like the JEP in the way it is. >> I have only >>> two slight concerns: >>> 1. I'm not sure that having addition methods (addFirst, addLast, >> putFirst, putLast) >>> is a good idea, as not every mutable implementation may support them. >> While this >>> adds some API unification, it's quite a rare case when this could be >> necessary. I >>> think most real world applications of Sequenced* types would be around >> querying, or >>> maybe draining (so removal operations are ok). Probably it would be >> enough to add >>> addFirst, addLast, putFirst, putLast directly to the compatible >>> implementations/subinterfaces like List, LinkedHashSet, and >> LinkedHashMap removing >>> them from the Sequenced* interfaces. In this case, SortedSet interface >> will not be >>> polluted with operations that can never be implemented. Well my opinion >> is not very >>> strong here. >> Hi Tagir, thanks for looking at this. >> >> Yes, this particular issue involves some tradeoffs. As you noted, >> addFirst/addLast >> can't be implemented by SortedSet and so they throw UOE. This is an >> unfortunate >> asymmetry. If these were omitted, the design would be cleaner in the sense >> that >> there would be fewer things that throw UOE. >> >> But there are costs to not having those methods, which I think outweigh >> the >> asymmetry around SortedSet. >> >> The other collections have interfaces corresponding to common >> implementations: >> ArrayList has List, ArrayDeque has Deque, TreeSet has SortedSet, etc., and >> Java >> style tends to encourage "programming to the interface." But there's no >> interface >> that corresponds to LinkedHashSet. >> >> Over the years we've mostly just put up with this gap. But it's really >> noticeable >> when you add the reversed view. The reversed view of a List is a List, the >> reversed >> view of a Deque is a Deque, the reversed view of a SortedSet is a >> SortedSet, and the >> reversed view of a LinkedHashSet is a ... what? SequencedSet is the answer >> here. >> >> We also want the reversed view to be equivalent in power to the forward >> view. If the >> addFirst/addLast methods were only on LinkedHashSet, it would be possible >> to add at >> either end of a LinkedHashSet but not its reversed view. This is a big >> hole. So the >> addFirst/addLast methods need to be on the interface. Since the method >> specifications originally came from Deque, they're actually on >> SequencedCollection. >> >> In addition, the majority of cases can implement addFirst/addLast: Deque, >> List, >> LinkedHashSet. SortedSet is the outlier; it would seem a shame to omit the >> methods >> only because of SortedSet. The alternative is to omit SortedSet from the >> SequencedCollection family, but that seems worse, as SortedSet can >> implement the >> other operations just fine. >> >>> 2. SequencedCollection name is a little bit too long. I think every >> extra letter >>> adds a hesitation for users to use the type, especially in APIs where it >> could be >>> the most useful. I see the Naming section and must admit that I don't >> have better >>> ideas. Well, maybe just Sequenced would work? Or too vague? >> Yeah, the names are rather longer than I would have liked. At least >> "Sequenced" is >> shorter than "Reversible". :-) >> >> One reason it's ok to have a longer name is that it reduces the >> possibility of name >> collections. >> >> We want the types to be nouns, so the obvious noun here is Sequence. But >> we need Set >> and Map variations as well, so that would result in >> >> Sequence >> SequencedSet >> SequencedMap >> >> or similar variations. Kind of asymmetrical. Or maybe Seq, SeqSet, SeqMap? >> Not >> clearly better. >> >> One nice thing about the names in the current draft is that they line up >> with the >> existing collection types nicely: >> >> Collection SequencedCollection >> Set SequencedSet >> Map SequencedMap >> >> I'm not claiming these are absolutely the best names, but I've thought >> about this >> for a while and I haven't been able to come up with anything clearly >> better. I'm >> open to better names if there's something I might have missed though. >> >> s'marks >> From duke at openjdk.java.net Tue Feb 15 18:23:51 2022 From: duke at openjdk.java.net (XenoAmess) Date: Tue, 15 Feb 2022 18:23:51 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v9] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: 9072610: HashMap copy constructor and putAll can over-allocate table ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/e77fe7db..6d9069da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=07-08 Stats: 90 lines in 1 file changed: 90 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From mchung at openjdk.java.net Tue Feb 15 18:45:05 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 15 Feb 2022 18:45:05 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v4] In-Reply-To: References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Tue, 15 Feb 2022 00:10:44 GMT, Tim Prinzing wrote: >> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > remove excess description Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7447 From mchung at openjdk.java.net Tue Feb 15 18:52:13 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 15 Feb 2022 18:52:13 GMT Subject: RFR: JDK-8281766: Update java.lang.reflect.Parameter to implement Member In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 01:13:43 GMT, Joe Darcy wrote: > Retrofitting of Parameter to implement Member, an interface already implemented by similar reflective modeling classes. > > Since Parameter is final, there is little compatibility impact from adding a new method. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8281767 > > I'll update the copyright year before pushing; I judged this as trivial enough to not require a regression test. I also consider that Parameter is not a Member. A member is a field, method, constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/7468 From duke at openjdk.java.net Tue Feb 15 19:01:08 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Tue, 15 Feb 2022 19:01:08 GMT Subject: Integrated: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts In-Reply-To: References: Message-ID: On Sat, 5 Feb 2022 15:34:08 GMT, Quan Anh Mai wrote: > Hi, > > This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations. > > Thank you very much. This pull request has now been integrated. Changeset: 0af356bb Author: Quan Anh Mai Committer: Sandhya Viswanathan URL: https://git.openjdk.java.net/jdk/commit/0af356bb4bfee99223d4bd4f8b0001c5f362c150 Stats: 490 lines in 19 files changed: 428 ins; 24 del; 38 mod 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts Reviewed-by: psandoz, sviswanathan ------------- PR: https://git.openjdk.java.net/jdk/pull/7358 From mchung at openjdk.java.net Tue Feb 15 19:59:43 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 15 Feb 2022 19:59:43 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v4] In-Reply-To: References: Message-ID: > This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. > > The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: No need for explicit locking for raw loading ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7435/files - new: https://git.openjdk.java.net/jdk/pull/7435/files/755c67d9..1be1afad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7435&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7435&range=02-03 Stats: 45 lines in 2 files changed: 14 ins; 18 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7435/head:pull/7435 PR: https://git.openjdk.java.net/jdk/pull/7435 From mchung at openjdk.java.net Tue Feb 15 20:02:10 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 15 Feb 2022 20:02:10 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v3] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 09:48:21 GMT, Maurizio Cimadamore wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the coupling of RawNativeLibraries with JNI library loading > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 427: > >> 425: new ConcurrentHashMap<>(); >> 426: >> 427: static void acquireNativeLibraryLock(String libraryName) { > > Note sure about these two routines. Should they be shared? Should we have two locks, one for JNI, one for raw? Of course, as is the code looks fine - but I wonder if a single lock isn't overly strict. I initially planned to come back to this but I obviously forgot. This does not need the per-library locking for JNI library which avoids the deadlock due to the class and library loading scenarios involving JNI_OnLoad, class initialization, and `Sytem::loadLibrary`. I now removed the locking entirely as it uses the concurrent hash map to register/unregister the loaded libraries. Much simplified. > src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java line 107: > >> 105: * {@link System#mapLibraryName} can be used to convert a name to >> 106: * a platform-specific pathname: >> 107: * {@snipplet > > Suggestion: > > * {@snippet Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7435 From mchung at openjdk.java.net Tue Feb 15 20:06:16 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 15 Feb 2022 20:06:16 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v3] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 19:59:11 GMT, Mandy Chung wrote: >> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 427: >> >>> 425: new ConcurrentHashMap<>(); >>> 426: >>> 427: static void acquireNativeLibraryLock(String libraryName) { >> >> Note sure about these two routines. Should they be shared? Should we have two locks, one for JNI, one for raw? Of course, as is the code looks fine - but I wonder if a single lock isn't overly strict. > > I initially planned to come back to this but I obviously forgot. > > This does not need the per-library locking for JNI library which avoids the deadlock due to the class and library loading scenarios involving JNI_OnLoad, class initialization, and `Sytem::loadLibrary`. I now removed the locking entirely as it uses the concurrent hash map to register/unregister the loaded libraries. Much simplified. Thanks again for the feedback. This version is much cleaner. ------------- PR: https://git.openjdk.java.net/jdk/pull/7435 From darcy at openjdk.java.net Tue Feb 15 21:09:57 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Feb 2022 21:09:57 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v5] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. 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 seven additional commits since the last revision: - Reorder constants by mask value per review feedback. - Merge branch 'master' into JDK-8266670 - Respond to more review feedback. - Respond to review feedback explicitly stating returned sets are immutable. - Fix typo from review feedback. - Merge branch 'master' into JDK-8266670 - JDK-8266670: Better modeling of modifiers in core reflection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/ab623f8a..2f9b168d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=03-04 Stats: 2427 lines in 133 files changed: 1478 ins; 546 del; 403 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Tue Feb 15 21:09:57 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Feb 2022 21:09:57 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4] In-Reply-To: <0WF8hyxQSTsxCmq9zaBKD4aqOSA_fg06D5s2WPf9F8c=.61509b3c-a7b8-4251-8cfe-d2e1b0222146@github.com> References: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> <0WF8hyxQSTsxCmq9zaBKD4aqOSA_fg06D5s2WPf9F8c=.61509b3c-a7b8-4251-8cfe-d2e1b0222146@github.com> Message-ID: On Tue, 15 Feb 2022 07:17:12 GMT, Adam Sotona wrote: > I would also recommend to sort access flags by the mask value. Sorted flags will match the specification and it will also make more deterministic all operations crawling through all the flags. This AccessFlag enum is very useful even outside of java.lang.reflect and having it ordered by the spec would make it perfect. > > Thanks! Good point; updated as suggested with a note future additions will follow the same policy. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Tue Feb 15 21:09:57 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Feb 2022 21:09:57 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4] In-Reply-To: References: <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com> Message-ID: On Tue, 15 Feb 2022 09:04:02 GMT, ExE Boss wrote: >> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 55: >> >>> 53: */ >>> 54: @SuppressWarnings("doclint:reference") // cross-module link >>> 55: public enum AccessFlag { >> >> I think there is missing SUPER ACC_SUPER 0x0020 > > Note?that the?presence or?absence of?`ACC_SUPER` has?no?effect since?**Java?8**, which?always treats?it as?set regardless?of the?actual?contents of?the?binary class?file. For completeness, I think including SUPER is reasonable, even though has been a no-op for some time. (Some time in the future, there could be a class file version aware additions to this enum class.) Well spotted omission. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From joehw at openjdk.java.net Tue Feb 15 22:03:05 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 15 Feb 2022 22:03:05 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 22:37:45 GMT, Naoto Sato wrote: > Fixing an issue in `CompactNumberFormat` which was caused by BigDecimal.divide() that incremented the number in the resulting format string. Also fixing some typos by taking this opportunity. src/java.base/share/classes/java/text/CompactNumberFormat.java line 595: > 593: divisor = (Long) divisors.get(++compactDataIndex); > 594: iPart = getIntegerPart(number, divisor); > 595: } This and the few lines surrounding it were duplicated. Might be worth considering consolidation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7412 From joehw at openjdk.java.net Tue Feb 15 22:08:09 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 15 Feb 2022 22:08:09 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 22:37:45 GMT, Naoto Sato wrote: > Fixing an issue in `CompactNumberFormat` which was caused by BigDecimal.divide() that incremented the number in the resulting format string. Also fixing some typos by taking this opportunity. Marked as reviewed by joehw (Reviewer). test/jdk/java/text/Format/CompactNumberFormat/TestCompactPatternsValidity.java line 106: > 104: {COMPACT_PATTERN8, List.of(new BigInteger("223565686837667632"), new BigDecimal("12322456774334.89766"), 30000, 3456.78, > 105: new BigInteger("999999999999"), new BigDecimal("999999999999.0"), 999_999), > 106: List.of("223566T", "12T", "30K", "3K", "1T", "1T", "1M")}, The case where 999_999_999 was formatted to 1000 million and now 1 billion may be added too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7412 From duke at openjdk.java.net Tue Feb 15 22:17:53 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Tue, 15 Feb 2022 22:17:53 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v2] In-Reply-To: References: Message-ID: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: Changes from feedback. - Copyright dates fixed - IllegalCallerException thrown for no caller frame, and associated javadoc changes - test changed to look for IllegalCallerException thrown. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7448/files - new: https://git.openjdk.java.net/jdk/pull/7448/files/c6d37069..fa66af15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=00-01 Stats: 33 lines in 3 files changed: 22 ins; 2 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448 PR: https://git.openjdk.java.net/jdk/pull/7448 From forax at openjdk.java.net Tue Feb 15 22:22:03 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 15 Feb 2022 22:22:03 GMT Subject: RFR: JDK-8281766: Update java.lang.reflect.Parameter to implement Member In-Reply-To: References: Message-ID: <0XXfBO3vSRoi6apugNIS6k-6Cij3y7D1GGX3bZ9xv6M=.bdd7964b-fec6-45f0-8cc6-f1e4d0a3052d@github.com> On Tue, 15 Feb 2022 01:13:43 GMT, Joe Darcy wrote: > Retrofitting of Parameter to implement Member, an interface already implemented by similar reflective modeling classes. > > Since Parameter is final, there is little compatibility impact from adding a new method. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8281767 > > I'll update the copyright year before pushing; I judged this as trivial enough to not require a regression test. I agree with Mandy and David, a Member is the thingy inside a class, so a parameter is no a member, it has no declaring class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7468 From darcy at openjdk.java.net Tue Feb 15 22:31:42 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Feb 2022 22:31:42 GMT Subject: RFR: JDK-8281671: Class.getCanonicalName should explicitly over array classes Message-ID: <10PnaFB6_FOhf5r80F3iS9fIvfei_dxapYA9v5WZjok=.f8bc4061-4d9d-4dad-90e5-19dba977e1c3@github.com> Add explicit discussion of array types to Class.getCanonicalName, no change in behavior. I didn't see any existing regression tests for the various "getFooName" methods of Class so I created a new test file for a handful of test cases. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8281922 ------------- Commit messages: - JDK-8281671: Class.getCanonicalName should explicitly over array classes Changes: https://git.openjdk.java.net/jdk/pull/7483/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7483&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281671 Stats: 80 lines in 2 files changed: 80 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7483/head:pull/7483 PR: https://git.openjdk.java.net/jdk/pull/7483 From naoto at openjdk.java.net Tue Feb 15 22:31:47 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 15 Feb 2022 22:31:47 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range [v2] In-Reply-To: References: Message-ID: > Fixing an issue in `CompactNumberFormat` which was caused by BigDecimal.divide() that incremented the number in the resulting format string. Also fixing some typos by taking this opportunity. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7412/files - new: https://git.openjdk.java.net/jdk/pull/7412/files/8ea8ccfa..f6c86254 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7412&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7412&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7412.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7412/head:pull/7412 PR: https://git.openjdk.java.net/jdk/pull/7412 From dholmes at openjdk.java.net Tue Feb 15 22:36:11 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 15 Feb 2022 22:36:11 GMT Subject: RFR: JDK-8281766: Update java.lang.reflect.Parameter to implement Member In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 01:13:43 GMT, Joe Darcy wrote: > Retrofitting of Parameter to implement Member, an interface already implemented by similar reflective modeling classes. > > Since Parameter is final, there is little compatibility impact from adding a new method. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8281767 > > I'll update the copyright year before pushing; I judged this as trivial enough to not require a regression test. Technically a constructor is not a Member either, but the reflection API can get away with lumping constructors in with methods. The JLS definition of Member comes from 8.1.6 and 8.2 - the key definition being in 8.1.6: "A class body may contain declarations of members of the class, that is, fields (?8.3), methods (?8.4), classes (?8.5), and interfaces (?8.5)." ------------- PR: https://git.openjdk.java.net/jdk/pull/7468 From naoto at openjdk.java.net Tue Feb 15 22:35:10 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 15 Feb 2022 22:35:10 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range [v2] In-Reply-To: References: Message-ID: <5xTUS8fRHxoHUfefD05WjIZflnDSuE1KrHEJO_W3FFE=.130182ac-1836-4993-b19f-4e7e7f10131c@github.com> On Tue, 15 Feb 2022 21:59:42 GMT, Joe Wang wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressing review comments > > src/java.base/share/classes/java/text/CompactNumberFormat.java line 595: > >> 593: divisor = (Long) divisors.get(++compactDataIndex); >> 594: iPart = getIntegerPart(number, divisor); >> 595: } > > This and the few lines surrounding it were duplicated. Might be worth considering consolidation. Right. In fact, I tried to converge them but ended up not to, as there are slight differences for each number type. > test/jdk/java/text/Format/CompactNumberFormat/TestCompactPatternsValidity.java line 106: > >> 104: {COMPACT_PATTERN8, List.of(new BigInteger("223565686837667632"), new BigDecimal("12322456774334.89766"), 30000, 3456.78, >> 105: new BigInteger("999999999999"), new BigDecimal("999999999999.0"), 999_999), >> 106: List.of("223566T", "12T", "30K", "3K", "1T", "1T", "1M")}, > > The case where 999_999_999 was formatted to 1000 million and now 1 billion may be added too. Sure, added the 1 bil test case. ------------- PR: https://git.openjdk.java.net/jdk/pull/7412 From asemenyuk at openjdk.java.net Tue Feb 15 23:03:17 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 15 Feb 2022 23:03:17 GMT Subject: RFR: 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Message-ID: <-CZikWDMQNwKyHaDRCcNkVMOy50PXnzyMSxttHVaJ2E=.9ac50cca-c1b9-4424-b347-6214b9e1839c@github.com> 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test ------------- Commit messages: - 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Changes: https://git.openjdk.java.net/jdk/pull/7484/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7484&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281874 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7484/head:pull/7484 PR: https://git.openjdk.java.net/jdk/pull/7484 From mchung at openjdk.java.net Tue Feb 15 23:23:11 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 15 Feb 2022 23:23:11 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 22:17:53 GMT, Tim Prinzing wrote: >> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > Changes from feedback. > > - Copyright dates fixed > - IllegalCallerException thrown for no caller frame, and associated > javadoc changes > - test changed to look for IllegalCallerException thrown. src/java.base/share/classes/java/lang/ClassLoader.java line 1612: > 1610: * In cases where {@code ClassLoader.registerAsParallelCapable} is called from a context where > 1611: * there is no caller frame on the stack (e.g. when called directly > 1612: * from a JNI attached thread), {@code IllegalCallerException} is thrown. Suggestion: * In cases where this method is called from a context where the caller is not a subclass * {@code ClassLoader} or there is no caller frame on the stack (e.g. when called directly * from a JNI attached thread), {@code IllegalCallerException} is thrown. Should mention the non-class loader caller as well. src/java.base/share/classes/java/lang/ClassLoader.java line 1617: > 1615: * @return {@code true} if the caller is successfully registered as > 1616: * parallel capable and {@code false} if otherwise. > 1617: * @throws IllegalCallerException if there is no caller frame on the stack. Suggestion: * @throws IllegalCallerException if the caller is not a subclass of {@code ClassLoader} src/java.base/share/classes/java/lang/ClassLoader.java line 1626: > 1624: protected static boolean registerAsParallelCapable() { > 1625: final Class caller = Reflection.getCallerClass(); > 1626: if (caller == null) { Suggestion: if (caller == null || !ClassLoader.class.isAssignableFrom(caller)) { throw new IllegalCallerException(caller + " not a subclass of ClassLoader"); } What we suggested is to throw IllegalCallerException if the caller is not a class loader and that will include null caller case. test/jdk/java/lang/ClassLoader/exeNullCallerClassLoaderTest/NullCallerClassLoaderTest.java line 30: > 28: * @summary Test uses custom launcher that starts VM using JNI that verifies > 29: * ClassLoader.registerAsParallelCapable with null caller class does not throw a NullPointerException, > 30: * and instead returns false. `@summary` needs update to reflect the new change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7448 From mchung at openjdk.java.net Tue Feb 15 23:23:11 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 15 Feb 2022 23:23:11 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 23:05:30 GMT, Mandy Chung wrote: >> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes from feedback. >> >> - Copyright dates fixed >> - IllegalCallerException thrown for no caller frame, and associated >> javadoc changes >> - test changed to look for IllegalCallerException thrown. > > src/java.base/share/classes/java/lang/ClassLoader.java line 1626: > >> 1624: protected static boolean registerAsParallelCapable() { >> 1625: final Class caller = Reflection.getCallerClass(); >> 1626: if (caller == null) { > > Suggestion: > > if (caller == null || !ClassLoader.class.isAssignableFrom(caller)) { > throw new IllegalCallerException(caller + " not a subclass of ClassLoader"); > } > > > What we suggested is to throw IllegalCallerException if the caller is not a class loader and that will include null caller case. This also needs a test case for non-class loader caller. I looked at the existing tests testing `registerAsParallelCapable` but I can't find a good one to add the new test case. The closest one could be `test/jdk/java/lang/ClassLoader/IsParallelCapable.java`. I'm okay to include a new test case in `IsParallelCapable.java` to verify `IllegalCallerException` if called by a non-class loader. ------------- PR: https://git.openjdk.java.net/jdk/pull/7448 From joehw at openjdk.java.net Tue Feb 15 23:53:08 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 15 Feb 2022 23:53:08 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range [v2] In-Reply-To: References: Message-ID: <8V-YdqscV09fOGsDzLoflH9atRjJ8qsH6MKS9s8jVT0=.a1d97983-0a7a-43f0-9c1e-8999f176ae1b@github.com> On Tue, 15 Feb 2022 22:31:47 GMT, Naoto Sato wrote: >> Fixing an issue in `CompactNumberFormat` which was caused by BigDecimal.divide() that incremented the number in the resulting format string. Also fixing some typos by taking this opportunity. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7412 From joehw at openjdk.java.net Tue Feb 15 23:53:08 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 15 Feb 2022 23:53:08 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range [v2] In-Reply-To: <5xTUS8fRHxoHUfefD05WjIZflnDSuE1KrHEJO_W3FFE=.130182ac-1836-4993-b19f-4e7e7f10131c@github.com> References: <5xTUS8fRHxoHUfefD05WjIZflnDSuE1KrHEJO_W3FFE=.130182ac-1836-4993-b19f-4e7e7f10131c@github.com> Message-ID: On Tue, 15 Feb 2022 22:31:28 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/CompactNumberFormat.java line 595: >> >>> 593: divisor = (Long) divisors.get(++compactDataIndex); >>> 594: iPart = getIntegerPart(number, divisor); >>> 595: } >> >> This and the few lines surrounding it were duplicated. Might be worth considering consolidation. > > Right. In fact, I tried to converge them but ended up not to, as there are slight differences for each number type. Yeah, that's fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7412 From darcy at openjdk.java.net Tue Feb 15 23:53:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Feb 2022 23:53:10 GMT Subject: RFR: JDK-8281766: Update java.lang.reflect.Parameter to implement Member In-Reply-To: References: Message-ID: <9j_TO5N5tHXFCZ9C0zqVozkOeqA1M8CrQLrc6kGNwGE=.ac08c062-f3fe-47fa-adba-c456e6e60a76@github.com> On Tue, 15 Feb 2022 22:32:29 GMT, David Holmes wrote: > Technically a constructor is not a Member either, but the reflection API can get away with lumping constructors in with methods. > > The JLS definition of Member comes from 8.1.6 and 8.2 - the key definition being in 8.1.6: > > "A class body may contain declarations of members of the class, that is, fields (?8.3), methods (?8.4), classes (?8.5), and interfaces (?8.5)." Hmmm. Okay; I'll concede to the consensus here and withdraw the PR, CSR, etc. Parameter does mostly pass the "duck test" for me to be a Member, but I don't think it is essential for it to implement the interface (and also not essential to create one or more new interfaces separate from JLS terminology to characterize parameters and members/constructors as a more precise unified type than AnnotatedElement). Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7468 From darcy at openjdk.java.net Wed Feb 16 00:01:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Feb 2022 00:01:07 GMT Subject: Withdrawn: JDK-8281766: Update java.lang.reflect.Parameter to implement Member In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 01:13:43 GMT, Joe Darcy wrote: > Retrofitting of Parameter to implement Member, an interface already implemented by similar reflective modeling classes. > > Since Parameter is final, there is little compatibility impact from adding a new method. > > Please also review the corresponding CSR: > > https://bugs.openjdk.java.net/browse/JDK-8281767 > > I'll update the copyright year before pushing; I judged this as trivial enough to not require a regression test. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7468 From almatvee at openjdk.java.net Wed Feb 16 02:20:04 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 16 Feb 2022 02:20:04 GMT Subject: RFR: 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 17:44:24 GMT, Alexey Semenyuk wrote: > Code clean up. Remove obsolete comments, unused imports, and unneeded jtreg test parameter. > Fix the code to handle the case when installers are not created and there is nothing to verify in the test. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7481 From almatvee at openjdk.java.net Wed Feb 16 03:22:04 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 16 Feb 2022 03:22:04 GMT Subject: RFR: 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test In-Reply-To: <-CZikWDMQNwKyHaDRCcNkVMOy50PXnzyMSxttHVaJ2E=.9ac50cca-c1b9-4424-b347-6214b9e1839c@github.com> References: <-CZikWDMQNwKyHaDRCcNkVMOy50PXnzyMSxttHVaJ2E=.9ac50cca-c1b9-4424-b347-6214b9e1839c@github.com> Message-ID: On Tue, 15 Feb 2022 22:56:35 GMT, Alexey Semenyuk wrote: > 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7484 From simonis at openjdk.java.net Wed Feb 16 09:36:37 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Wed, 16 Feb 2022 09:36:37 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream Message-ID: Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). before JDK-8281962 ------------------ Benchmark (size) Mode Cnt Score Error Units InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op after JDK-8281962 ----------------- Benchmark (size) Mode Cnt Score Error Units InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: int readcount = 0; while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { outputStream.write(data, 0, bytesRead); readCount++; } if (readCount == 1) { return data; // <---- first bytes might be overwritten } return outputStream.toByteArray(); Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). [1] https://github.com/spring-projects/spring-framework/issues/27429 [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 ------------- Commit messages: - 8281962: Avoid unnecessary native calls in InflaterInputStream Changes: https://git.openjdk.java.net/jdk/pull/7492/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7492&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281962 Stats: 114 lines in 2 files changed: 112 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7492/head:pull/7492 PR: https://git.openjdk.java.net/jdk/pull/7492 From jbhateja at openjdk.java.net Wed Feb 16 11:05:07 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 16 Feb 2022 11:05:07 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v4] In-Reply-To: References: Message-ID: <1dqqh2KXNKFtAUuCMwvI9mLA0jFw--Bqz-AEfrxq_NM=.1b9f677e-3798-4877-9b58-8afdc8ed64ac@github.com> > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23 > FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Replacing by efficient instruction sequence based on MXCSR.RC mode. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/2dc364fa..1c9ff777 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=02-03 Stats: 143 lines in 4 files changed: 4 ins; 82 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Wed Feb 16 11:32:06 2022 From: duke at openjdk.java.net (Sam Brannen) Date: Wed, 16 Feb 2022 11:32:06 GMT Subject: RFR: JDK-8281462: Annotation toString output for enum not reusable for source input [v3] In-Reply-To: References: <8vjwyu44CD0O9u5iexvOaRgtZ5BPLWm9CiZHs7qBEfY=.456c485c-8e81-4de5-9716-3d99b0ceeff6@github.com> Message-ID: On Fri, 11 Feb 2022 20:49:33 GMT, Joe Darcy wrote: >> Thanks, Joe. >> >> Regarding the RFE, do you plan to open an issue to address the documentation for `getCanonicalName`? > > Filed https://bugs.openjdk.java.net/browse/JDK-8281671 Thanks for filing that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7418 From jbhateja at openjdk.java.net Wed Feb 16 12:30:28 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 16 Feb 2022 12:30:28 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 17:14:10 GMT, Jatin Bhateja wrote: >> That pseudocode would make a very useful comment too. This whole patch is very thinly commented. > >> > Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks. >> >> Hi @merykitty , You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects. > > **Just want to correct above statement, LDMXCSR will not be re-ordered/re-scheduled early OOO backend.** > That pseudocode would make a very useful comment too. This whole patch is very thinly commented. I have replaced earlier bulky sequence, new sequence is having similar performance but reduction in code may improve inlining behavior. Added descriptive comments around the special cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Wed Feb 16 12:30:27 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 16 Feb 2022 12:30:27 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v5] In-Reply-To: References: Message-ID: <-NfiIwcnrf7TRNxA9x1d9itPvKYgeCYogpjSZgGYtvc=.15346702-2db7-4295-8e5a-a4864f3bbdbd@github.com> > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23 > FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - 8279508: Adding few descriptive comments. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 - 8279508: Replacing by efficient instruction sequence based on MXCSR.RC mode. - 8279508: Adding vectorized algorithms to match the semantics of rounding operations. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 - 8279508: Adding a test for scalar intrinsification. - 8279508: Auto-vectorize Math.round API ------------- Changes: https://git.openjdk.java.net/jdk/pull/7094/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=04 Stats: 739 lines in 23 files changed: 648 ins; 29 del; 62 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Wed Feb 16 12:40:10 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 16 Feb 2022 12:40:10 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v3] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 12:26:45 GMT, Jatin Bhateja wrote: >>> > Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks. >>> >>> Hi @merykitty , You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects. >> >> **Just want to correct above statement, LDMXCSR will not be re-ordered/re-scheduled early OOO backend.** > >> That pseudocode would make a very useful comment too. This whole patch is very thinly commented. > > I have replaced earlier bulky sequence, new sequence is having similar performance but reduction in code may improve inlining behavior. Added descriptive comments around the special cases. > There are already `RoundFloat`, `RoundDouble`, and `RoundDoubleMode` nodes defined. > > Though `RoundFloat` and `RoundDouble` are legacy nodes used only on x86-32, `RoundDoubleMode` supports multiple rounding modes and is amenable to auto-vectorization. > > What do you think about the following alternative? > > Reuse `RoundDoubleMode` (with a new rounding mode) and introduce `RoundFloatMode`. > > Special rounding rules is not the only peculiarity of `Math.round()`. It also converts the result to an integral type. It can be represented as `ConvF2I (RoundFloatMode f #rmode)` / `ConvD2L (RoundDoubleMode d #rmode)`. In scalar case, it can be matched as a single AD instruction. > > Auto-vectorizer can then convert it to `VectorCastF2X (RoundFloatModeV vf #rmode)` / `VectorCastD2X (RoundDoubleModeV vd #rmode)` and match it in a similar manner. Adding new rounding mode to RoundDoubleMode may disturb other targets. match_rule_supported routine operates over Opcodes and currently any target supporting RoundDoubleMode generates code for all the rounding modes. Your solution is anyways based on creating new scalar and vector IR node for floating point rounding operation, which is what patch is doing currently. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From redux1234567 at mail.ru Wed Feb 16 13:13:40 2022 From: redux1234567 at mail.ru (=?UTF-8?B?SWx5YSBTdGFyY2hlbmtv?=) Date: Wed, 16 Feb 2022 16:13:40 +0300 Subject: =?UTF-8?B?VXNlIGNvcHlfZmlsZV9yYW5nZSBzeXN0ZW0gY2FsbCBmb3IgY29weWluZyBv?= =?UTF-8?B?biBMaW51eCBzeXN0ZW1z?= Message-ID: <1645017220.499957536@f542.i.mail.ru> ? I have suggestion. Copy_file_range() has been introduced in the Linux kernel since version 4.5. system call performs an in-kernel copy between two file descriptors without the additional cost of transferring data from the kernel to user space and then back into the kernel, including NFS(It will have huge performance impact). It copies up to len bytes of data from the source file descriptor fd_in to the target file descriptor fd_out, overwriting any data that exists within the requested range of the target file. Currently we use sendfile, but I think we need to use copy_file_range when possible. What do you think? -- Ilya Starchenko From mcimadamore at openjdk.java.net Wed Feb 16 13:18:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 16 Feb 2022 13:18:10 GMT Subject: RFR: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library [v4] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 19:59:43 GMT, Mandy Chung wrote: >> This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. >> >> The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > No need for explicit locking for raw loading Looks good! Thanks for the changes! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7435 From duke at openjdk.java.net Wed Feb 16 13:22:16 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 16 Feb 2022 13:22:16 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v5] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 21:09:57 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > 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 seven additional commits since the last revision: > > - Reorder constants by mask value per review feedback. > - Merge branch 'master' into JDK-8266670 > - Respond to more review feedback. > - Respond to review feedback explicitly stating returned sets are immutable. > - Fix typo from review feedback. > - Merge branch 'master' into JDK-8266670 > - JDK-8266670: Better modeling of modifiers in core reflection test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java line 65: > 63: if (left.mask() > right.mask()) { > 64: throw new RuntimeException(left > 65: + "has a greater mas than " Typo: Suggestion: + "has a greater mask than " ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From Alan.Bateman at oracle.com Wed Feb 16 13:40:30 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Feb 2022 13:40:30 +0000 Subject: Use copy_file_range system call for copying on Linux systems In-Reply-To: <1645017220.499957536@f542.i.mail.ru> References: <1645017220.499957536@f542.i.mail.ru> Message-ID: <17f865c8-857e-4d6a-058d-6fac3c0cd310@oracle.com> On 16/02/2022 13:13, Ilya Starchenko wrote: > > I have suggestion. Copy_file_range() has been introduced in the Linux kernel since version 4.5. system call performs an in-kernel copy between two file descriptors without the additional cost of transferring data from the kernel to user space and then back into the kernel, including NFS(It will have huge performance impact). It copies up to len bytes of data from the source file descriptor fd_in to the target file descriptor fd_out, overwriting any data that exists within the requested range of the target file. Currently we use sendfile, but I think we need to use copy_file_range when possible. What do you think? > There was brief discussion about this on nio-dev in April 2021. As I recall, there was an issue with the function prototype not being available (I can't recall if it was system include files or glibc). It might be best to start a new discussion there as it may be time to look at it again. -Alan From duke at openjdk.java.net Wed Feb 16 13:45:09 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Feb 2022 13:45:09 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v9] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Tue, 15 Feb 2022 18:23:51 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > 9072610: HashMap copy constructor and putAll can over-allocate table ConcurrentHashMap is a little complicated... Would like to put it into another pr. Let's focus on non-thread-safe Maps in this pr. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Wed Feb 16 13:49:05 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Feb 2022 13:49:05 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v10] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - revert changes in ConcurrentHashMap - 9072610: HashMap copy constructor and putAll can over-allocate table ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/6d9069da..e8bfa526 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=08-09 Stats: 9 lines in 2 files changed: 0 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Wed Feb 16 15:40:40 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Feb 2022 15:40:40 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v11] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: fix test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/e8bfa526..f37f8d2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From brian.burkhalter at oracle.com Wed Feb 16 16:42:35 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 16 Feb 2022 16:42:35 +0000 Subject: Use copy_file_range system call for copying on Linux systems In-Reply-To: <17f865c8-857e-4d6a-058d-6fac3c0cd310@oracle.com> References: <1645017220.499957536@f542.i.mail.ru> <17f865c8-857e-4d6a-058d-6fac3c0cd310@oracle.com> Message-ID: On Feb 16, 2022, at 5:40 AM, Alan Bateman > wrote: On 16/02/2022 13:13, Ilya Starchenko wrote: I have suggestion. Copy_file_range() has been introduced in the Linux kernel since version 4.5. system call performs an in-kernel copy between two file descriptors without the additional cost of transferring data from the kernel to user space and then back into the kernel, including NFS(It will have huge performance impact). It copies up to len bytes of data from the source file descriptor fd_in to the target file descriptor fd_out, overwriting any data that exists within the requested range of the target file. Currently we use sendfile, but I think we need to use copy_file_range when possible. What do you think? There was brief discussion about this on nio-dev in April 2021. As I recall, there was an issue with the function prototype not being available (I can't recall if it was system include files or glibc). It might be best to start a new discussion there as it may be time to look at it again. Please refer to [1]. The system call copy_file_range() is newer than the version of the Linux headers used to build the JDK. It might be that we could use dlsym() to be able to leverage it where it is available but that would require further investigation. Brian [1] https://bugs.openjdk.java.net/browse/JDK-8264744 From naoto at openjdk.java.net Wed Feb 16 16:59:12 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Feb 2022 16:59:12 GMT Subject: Integrated: 8176706: Additional Date-Time Formats In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 23:29:54 GMT, Naoto Sato wrote: > Following the prior discussion [1], here is the PR for the subject enhancement. CSR has also been updated according to the suggestion. > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-January/085175.html This pull request has now been integrated. Changeset: 9b74c3f2 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/9b74c3f2e74a4efdec1c1488e96ab5939a408df0 Stats: 821 lines in 12 files changed: 725 ins; 12 del; 84 mod 8176706: Additional Date-Time Formats Reviewed-by: joehw, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7340 From duke at openjdk.java.net Wed Feb 16 17:17:05 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Feb 2022 17:17:05 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v12] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: fix test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/f37f8d2a..b191bd6a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=10-11 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Wed Feb 16 17:22:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Feb 2022 17:22:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v13] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: fix test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/b191bd6a..3e8f2d7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=11-12 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From asemenyuk at openjdk.java.net Wed Feb 16 17:34:13 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 16 Feb 2022 17:34:13 GMT Subject: Integrated: 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 17:44:24 GMT, Alexey Semenyuk wrote: > Code clean up. Remove obsolete comments, unused imports, and unneeded jtreg test parameter. > Fix the code to handle the case when installers are not created and there is nothing to verify in the test. This pull request has now been integrated. Changeset: bb4dece2 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/bb4dece246a56f2b225089c331e9f3d092dfbfa1 Stats: 46 lines in 1 file changed: 12 ins; 19 del; 15 mod 8281170: Test jdk/tools/jpackage/windows/WinInstallerIconTest always fails on Windows 11 Reviewed-by: almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/7481 From asemenyuk at openjdk.java.net Wed Feb 16 17:35:13 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 16 Feb 2022 17:35:13 GMT Subject: Integrated: 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test In-Reply-To: <-CZikWDMQNwKyHaDRCcNkVMOy50PXnzyMSxttHVaJ2E=.9ac50cca-c1b9-4424-b347-6214b9e1839c@github.com> References: <-CZikWDMQNwKyHaDRCcNkVMOy50PXnzyMSxttHVaJ2E=.9ac50cca-c1b9-4424-b347-6214b9e1839c@github.com> Message-ID: <7raCrXZDk36Pezn9m3CfHXWeNejfe3AD22GkxELC7Rk=.94021cf9-43e5-4479-8d73-71b9c68933b4@github.com> On Tue, 15 Feb 2022 22:56:35 GMT, Alexey Semenyuk wrote: > 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test This pull request has now been integrated. Changeset: 81645521 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/81645521c81c7363d199e5051d51043146058a91 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8281874: Can't unpack msi installers from test/jdk/tools/jpackage/windows/test/jdk/tools/jpackage/windows/WinShortcutPromptTest.java test Reviewed-by: almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/7484 From duke at openjdk.java.net Wed Feb 16 17:38:01 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 16 Feb 2022 17:38:01 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v3] In-Reply-To: References: Message-ID: <7UJHcb3yr4qdq33PtAfOc8TmmFAqvbfGgMcgmQXXFWM=.f2b198f2-66c7-4d73-95a5-3a155942611d@github.com> > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: More changes from feedback. The javadoc is improved to reflect InvalidCallerException is thrown with a caller that can't be assigned to a ClassLoader as well as a null caller frame. Added a test IsParallelCapableBadCaller that uses reflection hackery to create a case where called with an invalid caller on the call stack. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7448/files - new: https://git.openjdk.java.net/jdk/pull/7448/files/fa66af15..d67bbb16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=01-02 Stats: 85 lines in 3 files changed: 74 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448 PR: https://git.openjdk.java.net/jdk/pull/7448 From iklam at openjdk.java.net Wed Feb 16 17:49:11 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Feb 2022 17:49:11 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3] In-Reply-To: References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> <7c6mh2-s3SkpfGG1WptyZsJjTfcDy1wX0Ll0713MLkU=.7df74a01-7ea5-49c1-9bda-f73798df3852@github.com> Message-ID: On Wed, 19 Jan 2022 05:50:50 GMT, Ioi Lam wrote: >> I don't really know this code well enough to do a good code review. I had some comments though. > >> I don't really know this code well enough to do a good code review. I had some comments though. > > Hi Coleen, thanks for taking a look. > > This PR has two major parts: > > 1. Check for inappropriate reference to static fields. This is mainly done in cdsHeapVerifier.cpp. These checks don't affect the contents of the CDS archive. They just print out warnings if problems are found. > 2. Special initialization of enum classes. Essentially if any instance of an enum class `X` is archived, then `X::` will not be executed, and we'll take this path instead (in instanceKlass.cpp): > > > // This is needed to ensure the consistency of the archived heap objects. > if (has_archived_enum_objs()) { > assert(is_shared(), "must be"); > bool initialized = HeapShared::initialize_enum_klass(this, CHECK); > if (initialized) { > return; > } > } > > Could you check if (2) is correct? > @iklam This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! keepalive ------------- PR: https://git.openjdk.java.net/jdk/pull/6653 From redux1234567 at mail.ru Wed Feb 16 17:51:00 2022 From: redux1234567 at mail.ru (=?UTF-8?B?SWx5YSBTdGFyY2hlbmtv?=) Date: Wed, 16 Feb 2022 20:51:00 +0300 Subject: =?UTF-8?B?UmVbMl06IFVzZSBjb3B5X2ZpbGVfcmFuZ2Ugc3lzdGVtIGNhbGwgZm9yIGNv?= =?UTF-8?B?cHlpbmcgb24gTGludXggc3lzdGVtcw==?= In-Reply-To: References: <1645017220.499957536@f542.i.mail.ru> <17f865c8-857e-4d6a-058d-6fac3c0cd310@oracle.com> Message-ID: <1645033860.788324307@f312.i.mail.ru> I think we can just check if syscall return ENOSYS and if it?s true fail back to more generic code. ? -- Ilya Starchenko ? ? >Wednesday, February 16, 2022 10:42 PM +06:00 from Brian Burkhalter : >? >? >>On Feb 16, 2022, at 5:40 AM, Alan Bateman < Alan.Bateman at oracle.com > wrote: ? >>On 16/02/2022 13:13, Ilya Starchenko wrote: >>>?I have suggestion. Copy_file_range() has been introduced in the Linux kernel since version 4.5. system call performs an in-kernel copy between two file descriptors without the additional cost of transferring data from the kernel to user space and then back into the kernel, including NFS(It will have huge performance impact). It copies up to len bytes of data from the source file descriptor fd_in to the target file descriptor fd_out, overwriting any data that exists within the requested range of the target file. Currently we use sendfile, but I think we need to use copy_file_range when possible. What do you think? >>>? >>There was brief discussion about this on nio-dev in April 2021. As I recall, there was an issue with the function prototype not being available (I can't recall if it was system include files or glibc). It might be best to start a new discussion there as it may be time to look at it again. >? >Please refer to [1]. The system call copy_file_range() is newer than the version of the Linux headers used to build the JDK. It might be that we could use dlsym() to be able to leverage it where it is available but that would require further investigation. >? >Brian >? >[1]? https://bugs.openjdk.java.net/browse/JDK-8264744 ? From duke at openjdk.java.net Wed Feb 16 17:54:42 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 16 Feb 2022 17:54:42 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v4] In-Reply-To: References: Message-ID: <4Ro7V9aiXs_6yecVuneFzWKFbAygPHl8UM9irXuiaeU=.78523a6c-76e5-4bab-8217-0cabd5d6c333@github.com> > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: fix copyright date ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7448/files - new: https://git.openjdk.java.net/jdk/pull/7448/files/d67bbb16..533a0660 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448 PR: https://git.openjdk.java.net/jdk/pull/7448 From duke at openjdk.java.net Wed Feb 16 17:55:55 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 16 Feb 2022 17:55:55 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v5] In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: fix copyright date ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7447/files - new: https://git.openjdk.java.net/jdk/pull/7447/files/7d1b97fe..ecfd125f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7447&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7447.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7447/head:pull/7447 PR: https://git.openjdk.java.net/jdk/pull/7447 From asemenyuk at openjdk.java.net Wed Feb 16 18:01:31 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 16 Feb 2022 18:01:31 GMT Subject: RFR: 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% Message-ID: 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% ------------- Commit messages: - 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails locally Changes: https://git.openjdk.java.net/jdk/pull/7500/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7500&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282011 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7500.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7500/head:pull/7500 PR: https://git.openjdk.java.net/jdk/pull/7500 From mchung at openjdk.java.net Wed Feb 16 18:35:12 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 16 Feb 2022 18:35:12 GMT Subject: Integrated: 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 23:27:49 GMT, Mandy Chung wrote: > This patch removes the restriction in the raw library loading mechanism that does not allow mix-n-match of loading a library as a JNI library and as a raw library. > > The raw library loading mechanism is designed for panama to load native library essentially equivalent to dlopen/dlclose calls independent of JNI library loading. If a native library is loaded as a JNI library and a raw library, it will get different NativeLibrary instances. When a class loader is being unloaded, JNI_Unload will be invoked but the native library may not be unloaded until NativeLibrary::unload is explicitly called for the raw library. This pull request has now been integrated. Changeset: 980d1878 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/980d18789139295c95ec6045539b68d1ae57bc31 Stats: 281 lines in 7 files changed: 183 ins; 66 del; 32 mod 8281335: Allow a library already loaded via System::loadLibrary to be loaded as a raw library Reviewed-by: sundar, mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/7435 From alanb at openjdk.java.net Wed Feb 16 18:42:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Feb 2022 18:42:10 GMT Subject: RFR: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null [v5] In-Reply-To: References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Wed, 16 Feb 2022 17:55:55 GMT, Tim Prinzing wrote: >> JDK-8281003 - MethodHandles::lookup throws NPE if caller is null > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright date Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From igraves at openjdk.java.net Wed Feb 16 18:52:25 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 16 Feb 2022 18:52:25 GMT Subject: RFR: 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception Message-ID: This is a fix in the buggy way CIBackRef traverses unicode characters that could be variable-length. Originally it followed the approach that BackRef does, but failed to account for unicode characters that could be 2 chars-long. The upper bound (groupSize) for the traversing loop is set by the difference between group start and stop indexes. This works for single char characters and it also works for case-sensitive comparisons because byte-by-byte comparisons are acceptable, but it doesn't work for a comparison where some kind of normalization (i.e. case) is required. This fix adjusts the upper bound for the loop that traverses the character when a two-char character is encountered. An alternative was to check the length of the group size by scanning the group in advance and converting to code points, but this could potentially result in multiple scans and codepoint conversions of the same matcher group which could be long. The solution that adjusts the loop bounds on the fly avoids this case. ------------- Commit messages: - Adding test - Initial fix for IOOBE in CIBackRef Changes: https://git.openjdk.java.net/jdk/pull/7501/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7501&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281315 Stats: 26 lines in 2 files changed: 22 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7501/head:pull/7501 PR: https://git.openjdk.java.net/jdk/pull/7501 From duke at openjdk.java.net Wed Feb 16 19:08:56 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 16 Feb 2022 19:08:56 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v5] In-Reply-To: References: Message-ID: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with three additional commits since the last revision: - reformat test summary - reformat test summary - improve test name and remove experimental test code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7448/files - new: https://git.openjdk.java.net/jdk/pull/7448/files/533a0660..a449acdc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=03-04 Stats: 129 lines in 3 files changed: 58 ins; 70 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448 PR: https://git.openjdk.java.net/jdk/pull/7448 From duke at openjdk.java.net Wed Feb 16 19:11:53 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Feb 2022 19:11:53 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v14] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: fix test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/3e8f2d7e..d0a4e6fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From brian.burkhalter at oracle.com Wed Feb 16 20:03:41 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 16 Feb 2022 20:03:41 +0000 Subject: Use copy_file_range system call for copying on Linux systems In-Reply-To: <1645033860.788324307@f312.i.mail.ru> References: <1645017220.499957536@f542.i.mail.ru> <17f865c8-857e-4d6a-058d-6fac3c0cd310@oracle.com> <1645033860.788324307@f312.i.mail.ru> Message-ID: On Feb 16, 2022, at 9:51 AM, Ilya Starchenko > wrote: I think we can just check if syscall return ENOSYS and if it?s true fail back to more generic code. The code would not even build without the syscall in the headers so I don?t think so. Brian From Alan.Bateman at oracle.com Wed Feb 16 20:10:46 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Feb 2022 20:10:46 +0000 Subject: Use copy_file_range system call for copying on Linux systems In-Reply-To: References: <1645017220.499957536@f542.i.mail.ru> <17f865c8-857e-4d6a-058d-6fac3c0cd310@oracle.com> <1645033860.788324307@f312.i.mail.ru> Message-ID: <37b75a84-b9ed-0659-b6a9-9b65fe1e8cda@oracle.com> On 16/02/2022 20:03, Brian Burkhalter wrote: > >> On Feb 16, 2022, at 9:51 AM, Ilya Starchenko >> wrote: >> >> I think we can just check if syscall return ENOSYS and if it?s true >> fail back to more generic code. > > The code would not even build without the syscall in the headers so I > don?t think so. > I suspect Ilya meant using syscall(2) with the NR. We had code in libnio that used approach for the *at functions before they were added to the glibc header files. It's a bit fragile as they are architecture specific. -Alan From duke at openjdk.java.net Wed Feb 16 20:13:13 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 16 Feb 2022 20:13:13 GMT Subject: Integrated: JDK-8281003 - MethodHandles::lookup throws NPE if caller is null In-Reply-To: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> References: <7vy3Qm2wLg1v48_ImAbcidYxyoNpZ0Y7PaDUjRzb_kg=.4b2363fb-28ae-4032-be8d-9e588ba104fd@github.com> Message-ID: On Fri, 11 Feb 2022 20:32:46 GMT, Tim Prinzing wrote: > JDK-8281003 - MethodHandles::lookup throws NPE if caller is null This pull request has now been integrated. Changeset: 67763df4 Author: Tim Prinzing Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/67763df4dce387da33da6d93d0f5d80e54cf8e5b Stats: 160 lines in 4 files changed: 158 ins; 0 del; 2 mod 8281003: MethodHandles::lookup throws NPE if caller is null Reviewed-by: ihse, mchung, jrose, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7447 From mchung at openjdk.java.net Wed Feb 16 20:25:12 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 16 Feb 2022 20:25:12 GMT Subject: RFR: JDK-8281671: Class.getCanonicalName spec should explicitly cover array classes In-Reply-To: <10PnaFB6_FOhf5r80F3iS9fIvfei_dxapYA9v5WZjok=.f8bc4061-4d9d-4dad-90e5-19dba977e1c3@github.com> References: <10PnaFB6_FOhf5r80F3iS9fIvfei_dxapYA9v5WZjok=.f8bc4061-4d9d-4dad-90e5-19dba977e1c3@github.com> Message-ID: On Tue, 15 Feb 2022 22:23:36 GMT, Joe Darcy wrote: > Add explicit discussion of array types to Class.getCanonicalName, no change in behavior. > > I didn't see any existing regression tests for the various "getFooName" methods of Class so I created a new test file for a handful of test cases. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8281922 Marked as reviewed by mchung (Reviewer). test/jdk/java/lang/Class/NameTest.java line 27: > 25: * @test > 26: * @bug 8281671 > 27: * @summary Checks on various "getFooName" methods of java.lang.Class This tests only `getCanonicalName` method. test/jdk/java/lang/Class/NameTest.java line 56: > 54: expectedCanonicalName.put(int.class, "int"); > 55: expectedCanonicalName.put(Object.class, "java.lang.Object"); > 56: expectedCanonicalName.put(objectArray.getClass(), "java.lang.Object[]"); Just an observation: TestNG is a good option to clearly show the data provider and the test body. Up to you. ------------- PR: https://git.openjdk.java.net/jdk/pull/7483 From asemenyuk at openjdk.java.net Wed Feb 16 20:25:28 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 16 Feb 2022 20:25:28 GMT Subject: RFR: 8282007: Assorted enhancements to jpackage testing framework Message-ID: 8282007: Assorted enhancements to jpackage testing framework ------------- Commit messages: - Trailing whitespace removed - 8282007: Assorted enhancements to jpackage testing framework - macOS bugix - Don't use TKit.assertZZZ to validate test setup correctness. Throw exception instead. - Assorted fixes and enhancements to jpackage testing framework Changes: https://git.openjdk.java.net/jdk/pull/7502/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7502&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282007 Stats: 738 lines in 17 files changed: 413 ins; 180 del; 145 mod Patch: https://git.openjdk.java.net/jdk/pull/7502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7502/head:pull/7502 PR: https://git.openjdk.java.net/jdk/pull/7502 From aturbanov at openjdk.java.net Wed Feb 16 20:59:26 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Feb 2022 20:59:26 GMT Subject: RFR: 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath Message-ID: Couple of fields in StrictMath are unused since [JDK-8244146](https://bugs.openjdk.java.net/browse/JDK-8244146). Also I fixed incorrect javadoc for private method. Looks like typo in [JDK-6282196](https://bugs.openjdk.java.net/browse/JDK-6282196) ------------- Commit messages: - [PATCH] Remove unused static fields 'DEGREES_TO_RADIANS', RADIANS_TO_DEGREES in StrictMath Changes: https://git.openjdk.java.net/jdk/pull/7495/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7495&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282019 Stats: 17 lines in 1 file changed: 0 ins; 13 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7495.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7495/head:pull/7495 PR: https://git.openjdk.java.net/jdk/pull/7495 From naoto at openjdk.java.net Wed Feb 16 21:05:09 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Feb 2022 21:05:09 GMT Subject: RFR: 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 18:45:29 GMT, Ian Graves wrote: > This is a fix in the buggy way CIBackRef traverses unicode characters that could be variable-length. Originally it followed the approach that BackRef does, but failed to account for unicode characters that could be 2 chars-long. The upper bound (groupSize) for the traversing loop is set by the difference between group start and stop indexes. This works for single char characters and it also works for case-sensitive comparisons because byte-by-byte comparisons are acceptable, but it doesn't work for a comparison where some kind of normalization (i.e. case) is required. This fix adjusts the upper bound for the loop that traverses the character when a two-char character is encountered. > > An alternative was to check the length of the group size by scanning the group in advance and converting to code points, but this could potentially result in multiple scans and codepoint conversions of the same matcher group which could be long. The solution that adjusts the loop bounds on the fly avoids this case. Looks good with a minor suggestion. src/java.base/share/classes/java/util/regex/Pattern.java line 5104: > 5102: j += Character.charCount(c2); > 5103: > 5104: if(xIncr > 1) { You can eliminate `xIncr` by comparing `c1 >= Character.MIN_SUPPLEMENTARY_CODE_POINT` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7501 From darcy at openjdk.java.net Wed Feb 16 21:10:48 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Feb 2022 21:10:48 GMT Subject: RFR: JDK-8281671: Class.getCanonicalName spec should explicitly cover array classes [v2] In-Reply-To: <10PnaFB6_FOhf5r80F3iS9fIvfei_dxapYA9v5WZjok=.f8bc4061-4d9d-4dad-90e5-19dba977e1c3@github.com> References: <10PnaFB6_FOhf5r80F3iS9fIvfei_dxapYA9v5WZjok=.f8bc4061-4d9d-4dad-90e5-19dba977e1c3@github.com> Message-ID: <-HUXvhZ0uEXti__BnFGeNIHQcoaeD6ZHtQxarCZnXuY=.51f4252e-6c72-46a9-b6ed-6196a1823cd2@github.com> > Add explicit discussion of array types to Class.getCanonicalName, no change in behavior. > > I didn't see any existing regression tests for the various "getFooName" methods of Class so I created a new test file for a handful of test cases. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8281922 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Augment test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7483/files - new: https://git.openjdk.java.net/jdk/pull/7483/files/2b0729ad..b414e3ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7483&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7483&range=00-01 Stats: 31 lines in 1 file changed: 31 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7483.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7483/head:pull/7483 PR: https://git.openjdk.java.net/jdk/pull/7483 From duke at openjdk.java.net Wed Feb 16 21:13:34 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 16 Feb 2022 21:13:34 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v6] In-Reply-To: References: Message-ID: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: fix test breakage from rename ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7448/files - new: https://git.openjdk.java.net/jdk/pull/7448/files/a449acdc..977162db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448 PR: https://git.openjdk.java.net/jdk/pull/7448 From omikhaltcova at openjdk.java.net Wed Feb 16 21:25:20 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Wed, 16 Feb 2022 21:25:20 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder Message-ID: This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. For example, it's needed to execute the following command on Windows: `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` it's equal to: `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. private static String unQuote(String str) { .. if (str.endsWith("\\"")) { return str; // not properly quoted, treat as unquoted } .. } that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test (jdk.lang.Process.allowAmbiguousCommands = true) pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test (jdk.lang.Process.allowAmbiguousCommands = false) Obviously, a string ending with "\\"" must not be started with """ to treat as unquoted overwise it?s should be treated as properly quoted. ------------- Commit messages: - 8282008: Incorrect handling of quoted arguments in ProcessBuilder Changes: https://git.openjdk.java.net/jdk/pull/7504/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7504&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282008 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7504.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7504/head:pull/7504 PR: https://git.openjdk.java.net/jdk/pull/7504 From brian.burkhalter at oracle.com Wed Feb 16 21:33:37 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 16 Feb 2022 21:33:37 +0000 Subject: Use copy_file_range system call for copying on Linux systems In-Reply-To: <37b75a84-b9ed-0659-b6a9-9b65fe1e8cda@oracle.com> References: <1645017220.499957536@f542.i.mail.ru> <17f865c8-857e-4d6a-058d-6fac3c0cd310@oracle.com> <1645033860.788324307@f312.i.mail.ru> <37b75a84-b9ed-0659-b6a9-9b65fe1e8cda@oracle.com> Message-ID: <3B7C20D4-BB09-4F26-A608-266D4DDB1086@oracle.com> On Feb 16, 2022, at 12:10 PM, Alan Bateman > wrote: I suspect Ilya meant using syscall(2) with the NR. We had code in libnio that used approach for the *at functions before they were added to the glibc header files. It's a bit fragile as they are architecture specific. Oh, I see. It looks like the only place that is still used is in UnixNativeDispatcher.c for fstatat() on Linux. Brian From duke at openjdk.java.net Wed Feb 16 21:39:20 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 16 Feb 2022 21:39:20 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v7] In-Reply-To: References: Message-ID: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge master - fix test breakage from rename - reformat test summary - reformat test summary - improve test name and remove experimental test code - fix copyright date - More changes from feedback. The javadoc is improved to reflect InvalidCallerException is thrown with a caller that can't be assigned to a ClassLoader as well as a null caller frame. Added a test IsParallelCapableBadCaller that uses reflection hackery to create a case where called with an invalid caller on the call stack. - Changes from feedback. - Copyright dates fixed - IllegalCallerException thrown for no caller frame, and associated javadoc changes - test changed to look for IllegalCallerException thrown. - Merge branch 'master' into JDK-8281000 - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null ------------- Changes: https://git.openjdk.java.net/jdk/pull/7448/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7448&range=06 Stats: 216 lines in 5 files changed: 216 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7448.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7448/head:pull/7448 PR: https://git.openjdk.java.net/jdk/pull/7448 From bpb at openjdk.java.net Wed Feb 16 21:40:05 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 16 Feb 2022 21:40:05 GMT Subject: RFR: 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 14:48:04 GMT, Andrey Turbanov wrote: > Couple of fields in StrictMath are unused since [JDK-8244146](https://bugs.openjdk.java.net/browse/JDK-8244146). > Also I fixed incorrect javadoc for private method. Looks like typo in [JDK-6282196](https://bugs.openjdk.java.net/browse/JDK-6282196) Approved assuming that there are no build errors. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7495 From mchung at openjdk.java.net Wed Feb 16 21:45:05 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 16 Feb 2022 21:45:05 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v7] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:39:20 GMT, Tim Prinzing wrote: >> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null > > Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge master > - fix test breakage from rename > - reformat test summary > - reformat test summary > - improve test name and remove experimental test code > - fix copyright date > - More changes from feedback. > > The javadoc is improved to reflect InvalidCallerException is thrown with > a caller that can't be assigned to a ClassLoader as well as a null > caller frame. Added a test IsParallelCapableBadCaller that uses > reflection hackery to create a case where called with an invalid caller > on the call stack. > - Changes from feedback. > > - Copyright dates fixed > - IllegalCallerException thrown for no caller frame, and associated > javadoc changes > - test changed to look for IllegalCallerException thrown. > - Merge branch 'master' into JDK-8281000 > - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7448 From igraves at openjdk.java.net Wed Feb 16 22:02:06 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 16 Feb 2022 22:02:06 GMT Subject: RFR: 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:00:00 GMT, Naoto Sato wrote: >> This is a fix in the buggy way CIBackRef traverses unicode characters that could be variable-length. Originally it followed the approach that BackRef does, but failed to account for unicode characters that could be 2 chars-long. The upper bound (groupSize) for the traversing loop is set by the difference between group start and stop indexes. This works for single char characters and it also works for case-sensitive comparisons because byte-by-byte comparisons are acceptable, but it doesn't work for a comparison where some kind of normalization (i.e. case) is required. This fix adjusts the upper bound for the loop that traverses the character when a two-char character is encountered. >> >> An alternative was to check the length of the group size by scanning the group in advance and converting to code points, but this could potentially result in multiple scans and codepoint conversions of the same matcher group which could be long. The solution that adjusts the loop bounds on the fly avoids this case. > > src/java.base/share/classes/java/util/regex/Pattern.java line 5104: > >> 5102: j += Character.charCount(c2); >> 5103: >> 5104: if(xIncr > 1) { > > You can eliminate `xIncr` by comparing `c1 >= Character.MIN_SUPPLEMENTARY_CODE_POINT` here. Nice! Thanks will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/7501 From darcy at openjdk.java.net Wed Feb 16 22:06:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Feb 2022 22:06:10 GMT Subject: RFR: JDK-8281671: Class.getCanonicalName spec should explicitly cover array classes [v2] In-Reply-To: References: <10PnaFB6_FOhf5r80F3iS9fIvfei_dxapYA9v5WZjok=.f8bc4061-4d9d-4dad-90e5-19dba977e1c3@github.com> Message-ID: On Wed, 16 Feb 2022 20:17:31 GMT, Mandy Chung wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Augment test. > > test/jdk/java/lang/Class/NameTest.java line 27: > >> 25: * @test >> 26: * @bug 8281671 >> 27: * @summary Checks on various "getFooName" methods of java.lang.Class > > This tests only `getCanonicalName` method. Added analogous test cases for getSimpleName name. > test/jdk/java/lang/Class/NameTest.java line 56: > >> 54: expectedCanonicalName.put(int.class, "int"); >> 55: expectedCanonicalName.put(Object.class, "java.lang.Object"); >> 56: expectedCanonicalName.put(objectArray.getClass(), "java.lang.Object[]"); > > Just an observation: TestNG is a good option to clearly show the data provider and the test body. Up to you. Noted; I'll stick with the hand-written code for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7483 From darcy at openjdk.java.net Wed Feb 16 22:06:11 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Feb 2022 22:06:11 GMT Subject: Integrated: JDK-8281671: Class.getCanonicalName spec should explicitly cover array classes In-Reply-To: <10PnaFB6_FOhf5r80F3iS9fIvfei_dxapYA9v5WZjok=.f8bc4061-4d9d-4dad-90e5-19dba977e1c3@github.com> References: <10PnaFB6_FOhf5r80F3iS9fIvfei_dxapYA9v5WZjok=.f8bc4061-4d9d-4dad-90e5-19dba977e1c3@github.com> Message-ID: <56UVKj8EHDWOGgB2zuE5U96q8K7AWPibRWIhzKh-HM4=.1b2cadb9-6ea1-4e65-b71d-1580ea5453bd@github.com> On Tue, 15 Feb 2022 22:23:36 GMT, Joe Darcy wrote: > Add explicit discussion of array types to Class.getCanonicalName, no change in behavior. > > I didn't see any existing regression tests for the various "getFooName" methods of Class so I created a new test file for a handful of test cases. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8281922 This pull request has now been integrated. Changeset: 5ec7898d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/5ec7898dbf1ebe261e5e25939cad42134611ff12 Stats: 111 lines in 2 files changed: 111 ins; 0 del; 0 mod 8281671: Class.getCanonicalName spec should explicitly cover array classes Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7483 From darcy at openjdk.java.net Wed Feb 16 22:12:04 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Feb 2022 22:12:04 GMT Subject: RFR: 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 14:48:04 GMT, Andrey Turbanov wrote: > Couple of fields in StrictMath are unused since [JDK-8244146](https://bugs.openjdk.java.net/browse/JDK-8244146). > Also I fixed incorrect javadoc for private method. Looks like typo in [JDK-6282196](https://bugs.openjdk.java.net/browse/JDK-6282196) Marked as reviewed by darcy (Reviewer). Looks fine; thanks for the cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/7495 From joe.darcy at oracle.com Wed Feb 16 22:20:20 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 16 Feb 2022 14:20:20 -0800 Subject: RFR: 8279508: Auto-vectorize Math.round API [v2] In-Reply-To: References: <2TVKx_BFFyAK2ooOWKpdsEIMFzJngYxlWjbgeZ2y4Mc=.5deb2173-8107-476d-92ca-1835d69ce336@github.com> Message-ID: <6e3a21d8-fc16-24b3-ead1-fefb52db9684@oracle.com> On 2/12/2022 6:55 PM, Jatin Bhateja wrote: > On Fri, 21 Jan 2022 00:49:04 GMT, Sandhya Viswanathan wrote: > >> The JVM currently initializes the x86 mxcsr to round to nearest even, see below in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, exceptions masked StubRoutines::x86::_mxcsr_std = 0x1F80; The above works for Math.rint which is specified to be round to nearest even. Please see: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html : section 4.8.4 >> >> The rounding mode needed for Math.round is round to positive infinity which needs a different x86 mxcsr initialization(0x5F80). > Hi @sviswa7 , > As per JLS 17 section 15.4 Java follows round to nearest rounding policy for all floating point operations except conversion to integer and remainder where it uses round toward zero. That is a true background condition, but I will note that the Math.round method does independently define the semantics of its operation and rounding behavior, which has changed (slightly) over the lifetime of the platform. -Joe From rriggs at openjdk.java.net Wed Feb 16 22:29:14 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Feb 2022 22:29:14 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:19:04 GMT, Olga Mikhaltsova wrote: > This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. > > For example, it's needed to execute the following command on Windows: > `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` > it's equal to: > `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` > > While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. > > private static String unQuote(String str) { > .. > if (str.endsWith("\\"")) { > return str; // not properly quoted, treat as unquoted > } > .. > } > > > that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. > As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: > > pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test > (jdk.lang.Process.allowAmbiguousCommands = true) > pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test > (jdk.lang.Process.allowAmbiguousCommands = false) > > > Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. The fix looks right. The PR should include a test. Can you write a standalone test in jdk/test/java/lang/ProcessBuilder/... to confirm the fix. Possibly it could be added to Basic.java but that file is pretty large and doesn't seem like the correct place to add. It may be sufficient to invoke echo with that 3rd argument and verify the output. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From bchristi at openjdk.java.net Wed Feb 16 22:37:04 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 16 Feb 2022 22:37:04 GMT Subject: RFR: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null [v7] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:39:20 GMT, Tim Prinzing wrote: >> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null > > Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge master > - fix test breakage from rename > - reformat test summary > - reformat test summary > - improve test name and remove experimental test code > - fix copyright date > - More changes from feedback. > > The javadoc is improved to reflect InvalidCallerException is thrown with > a caller that can't be assigned to a ClassLoader as well as a null > caller frame. Added a test IsParallelCapableBadCaller that uses > reflection hackery to create a case where called with an invalid caller > on the call stack. > - Changes from feedback. > > - Copyright dates fixed > - IllegalCallerException thrown for no caller frame, and associated > javadoc changes > - test changed to look for IllegalCallerException thrown. > - Merge branch 'master' into JDK-8281000 > - JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null Looks fine. ------------- Marked as reviewed by bchristi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7448 From bpb at openjdk.java.net Wed Feb 16 22:38:21 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 16 Feb 2022 22:38:21 GMT Subject: RFR: 8254574: PrintWriter handling of InterruptedIOException is not documented Message-ID: Remove reference to `java.io.InterruptedIOException` from `java.io.PrintStream`, and make the specifications of `checkError()`, `setError()`, and `clearError()` consistent between `java.io.PrintStream` and `java.io.PrintWriter`. ------------- Commit messages: - 8254574: PrintWriter handling of InterruptedIOException is not documented Changes: https://git.openjdk.java.net/jdk/pull/7507/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7507&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254574 Stats: 21 lines in 2 files changed: 0 ins; 11 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7507/head:pull/7507 PR: https://git.openjdk.java.net/jdk/pull/7507 From igraves at openjdk.java.net Wed Feb 16 22:41:40 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 16 Feb 2022 22:41:40 GMT Subject: RFR: 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception [v2] In-Reply-To: References: Message-ID: > This is a fix in the buggy way CIBackRef traverses unicode characters that could be variable-length. Originally it followed the approach that BackRef does, but failed to account for unicode characters that could be 2 chars-long. The upper bound (groupSize) for the traversing loop is set by the difference between group start and stop indexes. This works for single char characters and it also works for case-sensitive comparisons because byte-by-byte comparisons are acceptable, but it doesn't work for a comparison where some kind of normalization (i.e. case) is required. This fix adjusts the upper bound for the loop that traverses the character when a two-char character is encountered. > > An alternative was to check the length of the group size by scanning the group in advance and converting to code points, but this could potentially result in multiple scans and codepoint conversions of the same matcher group which could be long. The solution that adjusts the loop bounds on the fly avoids this case. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Removing increment variable and some other tweaks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7501/files - new: https://git.openjdk.java.net/jdk/pull/7501/files/28d80c80..c4e5343e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7501&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7501&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7501/head:pull/7501 PR: https://git.openjdk.java.net/jdk/pull/7501 From bpb at openjdk.java.net Wed Feb 16 22:43:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 16 Feb 2022 22:43:04 GMT Subject: RFR: 8254574: PrintWriter handling of InterruptedIOException is not documented In-Reply-To: References: Message-ID: <924k9IuzqZ_CwPPhDSsm4IuRXlyKk_lbxmtK0ANif0M=.4e7d7951-e862-42eb-a1be-f49e0bb515ff@github.com> On Wed, 16 Feb 2022 22:32:21 GMT, Brian Burkhalter wrote: > Remove reference to `java.io.InterruptedIOException` from `java.io.PrintStream`, and make the specifications of `checkError()`, `setError()`, and `clearError()` consistent between `java.io.PrintStream` and `java.io.PrintWriter`. In the various methods which print there is still this sort of construct try { // print operation which can throw IOException } catch (InterruptedIOException x) { Thread.currentThread().interrupt(); } catch (IOException x) { trouble = true; } where an `InterruptedIOException` causes the current thread to be interrupted. Should this PR also excise these interrupts (as vestigial)? There is no longer any description of this in the specifications of the two print stream classes although in theory an, e.g., `OutputStream` which throws `InterruptedIOException` could be passed in. ------------- PR: https://git.openjdk.java.net/jdk/pull/7507 From naoto at openjdk.java.net Wed Feb 16 23:26:02 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Feb 2022 23:26:02 GMT Subject: RFR: 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 22:41:40 GMT, Ian Graves wrote: >> This is a fix in the buggy way CIBackRef traverses unicode characters that could be variable-length. Originally it followed the approach that BackRef does, but failed to account for unicode characters that could be 2 chars-long. The upper bound (groupSize) for the traversing loop is set by the difference between group start and stop indexes. This works for single char characters and it also works for case-sensitive comparisons because byte-by-byte comparisons are acceptable, but it doesn't work for a comparison where some kind of normalization (i.e. case) is required. This fix adjusts the upper bound for the loop that traverses the character when a two-char character is encountered. >> >> An alternative was to check the length of the group size by scanning the group in advance and converting to code points, but this could potentially result in multiple scans and codepoint conversions of the same matcher group which could be long. The solution that adjusts the loop bounds on the fly avoids this case. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Removing increment variable and some other tweaks Looks fine. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7501 From almatvee at openjdk.java.net Wed Feb 16 23:27:08 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 16 Feb 2022 23:27:08 GMT Subject: RFR: 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 17:52:43 GMT, Alexey Semenyuk wrote: > 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7500 From asemenyuk at openjdk.java.net Wed Feb 16 23:27:09 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 16 Feb 2022 23:27:09 GMT Subject: Integrated: 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 17:52:43 GMT, Alexey Semenyuk wrote: > 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% This pull request has now been integrated. Changeset: 0b00ce17 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/0b00ce17cd6b530d9394e79ac8b07208cd4b92f5 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8282011: test/jdk/tools/jpackage/windows/WinL10nTest.java test fails if light.exe is not in %PATH% Reviewed-by: almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/7500 From asemenyuk at openjdk.java.net Wed Feb 16 23:51:30 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 16 Feb 2022 23:51:30 GMT Subject: RFR: 8282007: Assorted enhancements to jpackage testing framework [v2] In-Reply-To: References: Message-ID: > 8282007: Assorted enhancements to jpackage testing framework Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Don't fail if requested to uninstall not installed Debian package ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7502/files - new: https://git.openjdk.java.net/jdk/pull/7502/files/895997ac..8ce156d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7502&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7502&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7502/head:pull/7502 PR: https://git.openjdk.java.net/jdk/pull/7502 From jwilhelm at openjdk.java.net Thu Feb 17 00:23:36 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Feb 2022 00:23:36 GMT Subject: RFR: Merge jdk18 Message-ID: Forwardport JDK 18 -> JDK 19 ------------- Commit messages: - Merge - 8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022 - 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7509&range=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7509&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/7509/files Stats: 423 lines in 9 files changed: 0 ins; 412 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7509.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7509/head:pull/7509 PR: https://git.openjdk.java.net/jdk/pull/7509 From duke at openjdk.java.net Thu Feb 17 00:27:06 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 17 Feb 2022 00:27:06 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v6] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <3gAe1sJ-OD0p22Jz7IXCDtv3K883wsg5JoNEQd9nPWQ=.7a3f1f2d-0c06-4998-a912-16f511a6b82d@github.com> Message-ID: On Tue, 15 Feb 2022 03:45:19 GMT, Stuart Marks wrote: >>> The changes to j.l.Class and the EnumConstantDirectory test don't belong here -- these are _uses_ of HashMap. This bug and fix should focus on HashMap itself, to ensure that the cases in question allocate a table of the right size. >> >> A test will fail if not change codes there. Every pr should pass ci, so I have no choice. >> >>> Are there any other maps that have this computation besides HashMap and WeakHashMap? >> >> Good question. Can I get a list of classes where I should check??I guesd I shall start at LinkedHashMap and hash sets? but have no further ideas? >> >>> There should be a regression test for this. It's probably sufficient to base this on your original test program, which puts 12 entries into a HashMap using a variety of techniques. It should assert that the table size is 16 in all cases. Also, should there be a test case for WeakHashMap? >> >> OK I will have a try... a hard part is how to read private field in class but I think I can find some clue in the existed tests. >> >>> Also, I changed the summary of the bug report to be more precise. The PR title will need to be changed to correspond to it. Thanks. >> >> OK. > >> A test will fail if not change codes there. Every pr should pass ci, so I have no choice. > > Hm, yes I recall in the preliminary email that there was some mention of a test. However, the test seemed to use the same (incorrect) calculation, so maybe the test needs to be fixed instead. > >> Good question. Can I get a list of classes where I should check??I guesd I shall start at LinkedHashMap and hash sets? but have no further ideas? > > Offhand, the HashMap/LinkedHashMap and the corresponding Set classes, and WeakHashMap, are the main places to look. IdentityHashMap and the Map.of() implementations use a different organization so are probably unrelated. ConcurrentHashMap is another obvious place; you might want to investigate there, but depending on the fix (if any) we might want to handle it separately. I'd search for "loadFactor" or "LOAD_FACTOR" and see if anything else turns up. > >> OK I will have a try... a hard part is how to read private field in class but I think I can find some clue in the existed tests. > > There is an incantation in the test header to ensure that the java.base module is opened for reflection. Let me know if you have trouble with it. @stuart-marks done. please review again. thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From almatvee at openjdk.java.net Thu Feb 17 00:55:11 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 17 Feb 2022 00:55:11 GMT Subject: RFR: 8282007: Assorted enhancements to jpackage testing framework [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 23:51:30 GMT, Alexey Semenyuk wrote: >> 8282007: Assorted enhancements to jpackage testing framework > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Don't fail if requested to uninstall not installed Debian package test/jdk/tools/jpackage/helpers/jdk/jpackage/test/CfgFile.java line 2: > 1: /* > 2: * Copyright (c) 2019, 2022 Oracle and/or its affiliates. All rights reserved. Missing ",". test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 2: > 1: /* > 2: * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. Do you know why 2021 is removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/7502 From jwilhelm at openjdk.java.net Thu Feb 17 01:17:06 2022 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Feb 2022 01:17:06 GMT Subject: Integrated: Merge jdk18 In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 00:16:02 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: b6e48e67 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/b6e48e678244481dd45d38bc3ddc325fccda2acc Stats: 423 lines in 9 files changed: 0 ins; 412 del; 11 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/7509 From darcy at openjdk.java.net Thu Feb 17 01:38:42 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 01:38:42 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v6] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. 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 ten additional commits since the last revision: - Update JVMS references. - Merge branch 'master' into JDK-8266670 - Reorder constants by mask value per review feedback. - Merge branch 'master' into JDK-8266670 - Respond to more review feedback. - Respond to review feedback explicitly stating returned sets are immutable. - Fix typo from review feedback. - Merge branch 'master' into JDK-8266670 - JDK-8266670: Better modeling of modifiers in core reflection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/2f9b168d..02228108 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=04-05 Stats: 4119 lines in 128 files changed: 3549 ins; 218 del; 352 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Thu Feb 17 02:56:53 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 02:56:53 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v3] In-Reply-To: References: Message-ID: > Make explicit illegal argument cases of Class.arrayType. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 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 six additional commits since the last revision: - Revisit and update fix to address review feedback. - Merge branch 'master' into 8268250 - Add missing ending newline. - Add test file. - Merge branch 'master' into 8268250 - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4382/files - new: https://git.openjdk.java.net/jdk/pull/4382/files/088e025f..226b2260 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=01-02 Stats: 1299276 lines in 8092 files changed: 742875 ins; 505966 del; 50435 mod Patch: https://git.openjdk.java.net/jdk/pull/4382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4382/head:pull/4382 PR: https://git.openjdk.java.net/jdk/pull/4382 From sundar at openjdk.java.net Thu Feb 17 03:09:14 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 17 Feb 2022 03:09:14 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v3] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 02:56:53 GMT, Joe Darcy wrote: >> Make explicit illegal argument cases of Class.arrayType. >> >> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 > > 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 six additional commits since the last revision: > > - Revisit and update fix to address review feedback. > - Merge branch 'master' into 8268250 > - Add missing ending newline. > - Add test file. > - Merge branch 'master' into 8268250 > - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException test/jdk/java/lang/Class/ArrayType.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. 2022? ------------- PR: https://git.openjdk.java.net/jdk/pull/4382 From sundar at openjdk.java.net Thu Feb 17 03:12:17 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 17 Feb 2022 03:12:17 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v3] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 02:56:53 GMT, Joe Darcy wrote: >> Make explicit illegal argument cases of Class.arrayType. >> >> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 > > 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 six additional commits since the last revision: > > - Revisit and update fix to address review feedback. > - Merge branch 'master' into 8268250 > - Add missing ending newline. > - Add test file. > - Merge branch 'master' into 8268250 > - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4382 From jbhateja at openjdk.java.net Thu Feb 17 03:44:02 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 17 Feb 2022 03:44:02 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v5] In-Reply-To: <-NfiIwcnrf7TRNxA9x1d9itPvKYgeCYogpjSZgGYtvc=.15346702-2db7-4295-8e5a-a4864f3bbdbd@github.com> References: <-NfiIwcnrf7TRNxA9x1d9itPvKYgeCYogpjSZgGYtvc=.15346702-2db7-4295-8e5a-a4864f3bbdbd@github.com> Message-ID: On Wed, 16 Feb 2022 12:30:27 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23 >> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - 8279508: Adding few descriptive comments. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Replacing by efficient instruction sequence based on MXCSR.RC mode. > - 8279508: Adding vectorized algorithms to match the semantics of rounding operations. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Adding a test for scalar intrinsification. > - 8279508: Auto-vectorize Math.round API > _Mailing list message from [Joseph D. Darcy](mailto:joe.darcy at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_ > > On 2/12/2022 6:55 PM, Jatin Bhateja wrote: > > > On Fri, 21 Jan 2022 00:49:04 GMT, Sandhya Viswanathan wrote: > > > The JVM currently initializes the x86 mxcsr to round to nearest even, see below in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, exceptions masked StubRoutines::x86::_mxcsr_std = 0x1F80; The above works for Math.rint which is specified to be round to nearest even. Please see: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html : section 4.8.4 > > > The rounding mode needed for Math.round is round to positive infinity which needs a different x86 mxcsr initialization(0x5F80). > > > Hi @sviswa7 , > > > As per JLS 17 section 15.4 Java follows round to nearest rounding policy for all floating point operations except conversion to integer and remainder where it uses round toward zero. > > That is a true background condition, but I will note that the Math.round method does independently define the semantics of its operation and rounding behavior, which has changed (slightly) over the lifetime of the platform. > > -Joe Hi @jddarcy , Thanks for your comments, patch has been updated to follow the prescribed semantics of Math.round API. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From asemenyuk at openjdk.java.net Thu Feb 17 03:50:39 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 17 Feb 2022 03:50:39 GMT Subject: RFR: 8282007: Assorted enhancements to jpackage testing framework [v3] In-Reply-To: References: Message-ID: > 8282007: Assorted enhancements to jpackage testing framework Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Copyright years fixed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7502/files - new: https://git.openjdk.java.net/jdk/pull/7502/files/8ce156d9..c890c8a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7502&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7502&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7502.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7502/head:pull/7502 PR: https://git.openjdk.java.net/jdk/pull/7502 From asemenyuk at openjdk.java.net Thu Feb 17 03:50:44 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 17 Feb 2022 03:50:44 GMT Subject: RFR: 8282007: Assorted enhancements to jpackage testing framework [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 23:53:44 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't fail if requested to uninstall not installed Debian package > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/CfgFile.java line 2: > >> 1: /* >> 2: * Copyright (c) 2019, 2022 Oracle and/or its affiliates. All rights reserved. > > Missing ",". Fixed! > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 2: > >> 1: /* >> 2: * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. > > Do you know why 2021 is removed? By accident. Restored and changed to 2022 ------------- PR: https://git.openjdk.java.net/jdk/pull/7502 From darcy at openjdk.java.net Thu Feb 17 05:06:16 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 05:06:16 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v3] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 02:56:53 GMT, Joe Darcy wrote: >> Make explicit illegal argument cases of Class.arrayType. >> >> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 > > 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 six additional commits since the last revision: > > - Revisit and update fix to address review feedback. > - Merge branch 'master' into 8268250 > - Add missing ending newline. > - Add test file. > - Merge branch 'master' into 8268250 > - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Reviving this request, I looked over the exception types defined in java.lang and if IllegalArgumentException is not used, UnsupportedOperationException seems to me to be the most appropriate alternative. This is a small behavioral change from the current (undocumented) behavior of throwing IllegalArgumentException, but I don't estimate the cases in question are common in practice. ------------- PR: https://git.openjdk.java.net/jdk/pull/4382 From darcy at openjdk.java.net Thu Feb 17 05:11:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 05:11:40 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v4] In-Reply-To: References: Message-ID: <_hlxFQJPJd_qnC-8EDBCZniNBTQ2dajXVwDzlt8YxqA=.61b7f64f-36c1-4d45-baac-8179dc3e3b1d@github.com> > Make explicit illegal argument cases of Class.arrayType. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4382/files - new: https://git.openjdk.java.net/jdk/pull/4382/files/226b2260..b2a7d900 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4382/head:pull/4382 PR: https://git.openjdk.java.net/jdk/pull/4382 From darcy at openjdk.java.net Thu Feb 17 05:11:51 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 05:11:51 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v3] In-Reply-To: References: Message-ID: <4MaczIs7rima2iqZyHBqcTG3196PbumFuMqM_2AUdYU=.bcc2bb9c-017a-4d9c-8508-dce883f7916e@github.com> On Thu, 17 Feb 2022 03:05:36 GMT, Athijegannathan Sundararajan wrote: >> 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 six additional commits since the last revision: >> >> - Revisit and update fix to address review feedback. >> - Merge branch 'master' into 8268250 >> - Add missing ending newline. >> - Add test file. >> - Merge branch 'master' into 8268250 >> - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException > > test/jdk/java/lang/Class/ArrayType.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > > 2022? Copyright updated to cover 2022 (filed created in 2021); thanks,. ------------- PR: https://git.openjdk.java.net/jdk/pull/4382 From almatvee at openjdk.java.net Thu Feb 17 05:25:03 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 17 Feb 2022 05:25:03 GMT Subject: RFR: 8282007: Assorted enhancements to jpackage testing framework [v3] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 03:50:39 GMT, Alexey Semenyuk wrote: >> 8282007: Assorted enhancements to jpackage testing framework > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Copyright years fixed Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7502 From sundar at openjdk.java.net Thu Feb 17 05:26:06 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 17 Feb 2022 05:26:06 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v4] In-Reply-To: <_hlxFQJPJd_qnC-8EDBCZniNBTQ2dajXVwDzlt8YxqA=.61b7f64f-36c1-4d45-baac-8179dc3e3b1d@github.com> References: <_hlxFQJPJd_qnC-8EDBCZniNBTQ2dajXVwDzlt8YxqA=.61b7f64f-36c1-4d45-baac-8179dc3e3b1d@github.com> Message-ID: On Thu, 17 Feb 2022 05:11:40 GMT, Joe Darcy wrote: >> Make explicit illegal argument cases of Class.arrayType. >> >> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by sundar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4382 From asemenyuk at openjdk.java.net Thu Feb 17 05:31:06 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 17 Feb 2022 05:31:06 GMT Subject: Integrated: 8282007: Assorted enhancements to jpackage testing framework In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 20:06:09 GMT, Alexey Semenyuk wrote: > 8282007: Assorted enhancements to jpackage testing framework This pull request has now been integrated. Changeset: cd234f5d Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/cd234f5dbebd18ebf0c78dfdf533318cdc627971 Stats: 742 lines in 17 files changed: 416 ins; 180 del; 146 mod 8282007: Assorted enhancements to jpackage testing framework Reviewed-by: almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/7502 From smarks at openjdk.java.net Thu Feb 17 05:50:05 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 17 Feb 2022 05:50:05 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v14] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <9c0GGkfvXLZGQoxBrvtVQ0sI_RvVsGsBBcI6AluPZCQ=.02f0af77-c4da-4838-891b-3b6d66c40995@github.com> On Wed, 16 Feb 2022 19:11:53 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > fix test OK, good progress. Yes, leaving ConcurrentHashMap to another PR is fine. Do the changes to Class.java and the enum optimal capacity test need to be part of this PR? They seem unrelated. It's not clear to me that test is actually testing anything useful; it's just testing the same computation a couple different ways. The test seems reasonable enough and is a good start. There are a number of things that could be improved about it though. 1) It should probably be a TestNG test. This will allow you to use a DataProvider and also use TestNG assertions. 2) There are 12 test cases here, which seems amenable to using a DataProvider. You could try to make a little "combo" test that combines the three classes with the four ways of creating them, but it might be difficult to do that without using reflection. It might be easier to write a table with 12 cases, even if there is a bit of repetition. 3) Instead of writing reflective code to create the maps, it's probably easier to use suppliers that create the maps into the desired state. Each of the 12 test cases should have a lambda that does the creation. The test method then invokes the supplier and makes its assertions over the resulting map instance. 4) The `fill12` method can be used in an expression if it returns its argument. 5) Create a map with 12 entries as part of the test setup, and then just use it as the copy constructor argument. Note, I'll be on vacation next week, so there will be a gap in my responses during that time. test/jdk/java/util/Map/HashMapsPutAllOverAllocateTableTest.java line 2: > 1: /* > 2: * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. Fix copyright year. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From almatvee at openjdk.java.net Thu Feb 17 06:54:33 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 17 Feb 2022 06:54:33 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v4] In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: > Added ability to override description for additional launchers via "description" property. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8279995: jpackage --add-launcher option should allow overriding description [v4] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7399/files - new: https://git.openjdk.java.net/jdk/pull/7399/files/c5fea599..6d4b4d3f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=02-03 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7399/head:pull/7399 PR: https://git.openjdk.java.net/jdk/pull/7399 From alanb at openjdk.java.net Thu Feb 17 07:46:03 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Feb 2022 07:46:03 GMT Subject: RFR: 8254574: PrintWriter handling of InterruptedIOException is not documented In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 22:32:21 GMT, Brian Burkhalter wrote: > Remove reference to `java.io.InterruptedIOException` from `java.io.PrintStream`, and make the specifications of `checkError()`, `setError()`, and `clearError()` consistent between `java.io.PrintStream` and `java.io.PrintWriter`. I think looks okay, we should have removed that text from checkError's javadoc a long time ago. I've added the "csr" label to the PR as this is a spec change that should be tracked. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7507 From clanger at openjdk.java.net Thu Feb 17 09:39:04 2022 From: clanger at openjdk.java.net (Christoph Langer) Date: Thu, 17 Feb 2022 09:39:04 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 09:30:46 GMT, Volker Simonis wrote: > Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). > > > before JDK-8281962 > ------------------ > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op > > after JDK-8281962 > ----------------- > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op > > > Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. > > As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: > > > int readcount = 0; > while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { > outputStream.write(data, 0, bytesRead); > readCount++; > } > if (readCount == 1) { > return data; // <---- first bytes might be overwritten > } > return outputStream.toByteArray(); > > > Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). > > [1] https://github.com/spring-projects/spring-framework/issues/27429 > [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 Makes sense to me. Benchmark numbers look good. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7492 From alanb at openjdk.java.net Thu Feb 17 10:02:07 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Feb 2022 10:02:07 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 09:30:46 GMT, Volker Simonis wrote: > Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). > > > before JDK-8281962 > ------------------ > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op > > after JDK-8281962 > ----------------- > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op > > > Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. > > As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: > > > int readcount = 0; > while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { > outputStream.write(data, 0, bytesRead); > readCount++; > } > if (readCount == 1) { > return data; // <---- first bytes might be overwritten > } > return outputStream.toByteArray(); > > > Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). > > [1] https://github.com/spring-projects/spring-framework/issues/27429 > [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 This change is probably okay but will require study to see if there are any side effects (sadly, this area has a history of side effects being reported months and years after a change). Would you mind holding off integrating this change until it has been reviewed by someone that works in the area? ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From redestad at openjdk.java.net Thu Feb 17 10:10:07 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Feb 2022 10:10:07 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 09:30:46 GMT, Volker Simonis wrote: > Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). > > > before JDK-8281962 > ------------------ > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op > > after JDK-8281962 > ----------------- > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op > > > Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. > > As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: > > > int readcount = 0; > while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { > outputStream.write(data, 0, bytesRead); > readCount++; > } > if (readCount == 1) { > return data; // <---- first bytes might be overwritten > } > return outputStream.toByteArray(); > > > Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). > > [1] https://github.com/spring-projects/spring-framework/issues/27429 > [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 Code changes look good to me. (Shouldn't the copyright header have a year?) test/micro/org/openjdk/bench/java/util/zip/InflaterInputStreams.java line 78: > 76: private byte[] words; > 77: private static final int MAX_SIZE = 5000; // Should be bigger than the biggest size @Param > 78: private static byte[] inflated = new byte[MAX_SIZE]; If it isn't important for the benchmark, I'd remove the hard-coded `MAX_SIZE` and make `inflated` non-static and allocate it in `beforeRun` using `size` (or some multiple thereof). Future enhancements could very well be interested in assessing the performance of larger sized entries, and we shouldn't put up trip-wires if they want to increase `size`. ------------- Changes requested by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7492 From alanb at openjdk.java.net Thu Feb 17 10:10:06 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Feb 2022 10:10:06 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v4] In-Reply-To: <_hlxFQJPJd_qnC-8EDBCZniNBTQ2dajXVwDzlt8YxqA=.61b7f64f-36c1-4d45-baac-8179dc3e3b1d@github.com> References: <_hlxFQJPJd_qnC-8EDBCZniNBTQ2dajXVwDzlt8YxqA=.61b7f64f-36c1-4d45-baac-8179dc3e3b1d@github.com> Message-ID: On Thu, 17 Feb 2022 05:11:40 GMT, Joe Darcy wrote: >> Make explicit illegal argument cases of Class.arrayType. >> >> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. The updated proposal to throw UOE (rather than IAE) looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4382 From aturbanov at openjdk.java.net Thu Feb 17 12:34:08 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 17 Feb 2022 12:34:08 GMT Subject: Integrated: 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 14:48:04 GMT, Andrey Turbanov wrote: > Couple of fields in StrictMath are unused since [JDK-8244146](https://bugs.openjdk.java.net/browse/JDK-8244146). > Also I fixed incorrect javadoc for private method. Looks like typo in [JDK-6282196](https://bugs.openjdk.java.net/browse/JDK-6282196) This pull request has now been integrated. Changeset: d0e11808 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/d0e11808fd688d96e5cfeb586d1de277f26da5ad Stats: 17 lines in 1 file changed: 0 ins; 13 del; 4 mod 8282019: Unused static fields DEGREES_TO_RADIANS, RADIANS_TO_DEGREES in StrictMath Reviewed-by: bpb, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/7495 From rriggs at openjdk.java.net Thu Feb 17 13:17:08 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Feb 2022 13:17:08 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:19:04 GMT, Olga Mikhaltsova wrote: > This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. > > For example, it's needed to execute the following command on Windows: > `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` > it's equal to: > `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` > > While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. > > private static String unQuote(String str) { > .. > if (str.endsWith("\\"")) { > return str; // not properly quoted, treat as unquoted > } > .. > } > > > that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. > As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: > > pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test > (jdk.lang.Process.allowAmbiguousCommands = true) > pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test > (jdk.lang.Process.allowAmbiguousCommands = false) > > > Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. Actually, there's a bit more to this than first meets the eye. "A double quote mark preceded by a backslash (") is interpreted as a literal double quote mark (")." According to: https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args That was the reason for the change in JDK-8250568. So the application supplied quotes combined with the trailing file separator results in unbalanced quotes. Without the application supplied quotes, the implementation quotes the string (because of the embedded space) and doubles up the backslash so it does not escape the final quote. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From redestad at openjdk.java.net Thu Feb 17 15:18:27 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Feb 2022 15:18:27 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks Message-ID: Splitting out these micro changes from #7231 - Clean up and simplify setup and code - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. ------------- Commit messages: - Rearrange and align names - Add inputs with only latin1 and UTF16 codepoints - Drop encodeAsciiCharsetName, align names - Enhance StringDecode/Encode micros Changes: https://git.openjdk.java.net/jdk/pull/7516/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7516&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282047 Stats: 297 lines in 2 files changed: 162 ins; 82 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/7516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7516/head:pull/7516 PR: https://git.openjdk.java.net/jdk/pull/7516 From duke at openjdk.java.net Thu Feb 17 15:28:09 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 17 Feb 2022 15:28:09 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v14] In-Reply-To: <9c0GGkfvXLZGQoxBrvtVQ0sI_RvVsGsBBcI6AluPZCQ=.02f0af77-c4da-4838-891b-3b6d66c40995@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <9c0GGkfvXLZGQoxBrvtVQ0sI_RvVsGsBBcI6AluPZCQ=.02f0af77-c4da-4838-891b-3b6d66c40995@github.com> Message-ID: On Thu, 17 Feb 2022 05:45:54 GMT, Stuart Marks wrote: > It's not clear to me that test is actually testing anything useful; it's just testing the same computation a couple different ways. Well if I don't change it, then the test will fail. > Do the changes to Class.java and the enum optimal capacity test need to be part of this PR? They seem unrelated. But on the other hands, as they are not relative to this issue, if you think that test (`test/jdk/java/lang/Enum/ConstantDirectoryOptimalCapacity.java`)is useless and want to delete it, it shall happen elsewhere, but not in this pr. According to minimal change, I just make it can pass, but have no interest in shutting it down / heavily modify it. > 1. It should probably be a TestNG test. This will allow you to use a DataProvider and also use TestNG assertions. good. I learned something about jtreg today and find it can invoke Junit 5. I would like to migrate this test to Junit 5, it is more familiar to me than TestNG. > 2. There are 12 test cases here, which seems amenable to using a DataProvider. You could try to make a little "combo" test that combines the three classes with the four ways of creating them, but it might be difficult to do that without using reflection. It might be easier to write a table with 12 cases, even if there is a bit of repetition. > 3. Instead of writing reflective code to create the maps, it's probably easier to use suppliers that create the maps into the desired state. Each of the 12 test cases should have a lambda that does the creation. The test method then invokes the supplier and makes its assertions over the resulting map instance. > 4. The `fill12` method can be used in an expression if it returns its argument. > 5. Create a map with 12 entries as part of the test setup, and then just use it as the copy constructor argument. OK, would have a try. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From redestad at openjdk.java.net Thu Feb 17 15:28:57 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Feb 2022 15:28:57 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v3] In-Reply-To: References: Message-ID: <7kC4xxWon70YnYlqH_KJFTa2eEJf-P3VQ1L9ahugJgk=.0943bcaa-b53d-4216-afa1-69496dac248a@github.com> > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision: - Revert micro changes, split out to #7516 - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives - Merge branch 'master' into count_positives - Restore partial vector checks in AVX2 and SSE intrinsic variants - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral - Simplify changes to encodeUTF8 - Fix little-endian error caught by testing - Reduce jumps in the ascii path - Remove unused tail_mask - Remove has_negatives intrinsic on x86 (and hook up 32-bit x86 to use count_positives) - ... and 15 more: https://git.openjdk.java.net/jdk/compare/1ca44ef9...531139a1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/c4bb3612..531139a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=01-02 Stats: 10910 lines in 329 files changed: 7340 ins; 2150 del; 1420 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From duke at openjdk.java.net Thu Feb 17 15:42:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 17 Feb 2022 15:42:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v15] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: fix license year in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/d0a4e6fa..2998571a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=13-14 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Thu Feb 17 15:42:53 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 17 Feb 2022 15:42:53 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v14] In-Reply-To: <9c0GGkfvXLZGQoxBrvtVQ0sI_RvVsGsBBcI6AluPZCQ=.02f0af77-c4da-4838-891b-3b6d66c40995@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <9c0GGkfvXLZGQoxBrvtVQ0sI_RvVsGsBBcI6AluPZCQ=.02f0af77-c4da-4838-891b-3b6d66c40995@github.com> Message-ID: <9RgxqVEseJIDvKfst0409lK9vgmXIi1IZAtNLU-5F-Y=.723e809a-695f-460b-99ad-eb29e8a17e78@github.com> On Thu, 17 Feb 2022 05:46:38 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test > > test/jdk/java/util/Map/HashMapsPutAllOverAllocateTableTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > > Fix copyright year. changed to 2022. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From simonis at openjdk.java.net Thu Feb 17 16:02:44 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 17 Feb 2022 16:02:44 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 09:35:47 GMT, Christoph Langer wrote: > Makes sense to me. Benchmark numbers look good. Thanks Christoph! ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From simonis at openjdk.java.net Thu Feb 17 16:02:48 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 17 Feb 2022 16:02:48 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 10:01:11 GMT, Claes Redestad wrote: >> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed hardcoded constant to JMH parmater and removed non-ASCII chars from comments > > test/micro/org/openjdk/bench/java/util/zip/InflaterInputStreams.java line 78: > >> 76: private byte[] words; >> 77: private static final int MAX_SIZE = 5000; // Should be bigger than the biggest size @Param >> 78: private static byte[] inflated = new byte[MAX_SIZE]; > > If it isn't important for the benchmark, I'd remove the hard-coded `MAX_SIZE` and make `inflated` non-static and allocate it in `beforeRun` using `size` (or some multiple thereof). Future enhancements could very well be interested in assessing the performance of larger sized entries, and we shouldn't put up trip-wires if they want to increase `size`. Sure , you're absolutely right. Updated as suggested. I've also removed some non-ASCII characters from the comment to avoid problems with javac. Finally, a year isn't required in the Amazon copyright header. We specially removed all years a while back. PS: and thanks a lot for your review :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From simonis at openjdk.java.net Thu Feb 17 16:02:42 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 17 Feb 2022 16:02:42 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: > Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). > > > before JDK-8281962 > ------------------ > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op > > after JDK-8281962 > ----------------- > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op > > > Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. > > As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: > > > int readcount = 0; > while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { > outputStream.write(data, 0, bytesRead); > readCount++; > } > if (readCount == 1) { > return data; // <---- first bytes might be overwritten > } > return outputStream.toByteArray(); > > > Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). > > [1] https://github.com/spring-projects/spring-framework/issues/27429 > [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: Changed hardcoded constant to JMH parmater and removed non-ASCII chars from comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7492/files - new: https://git.openjdk.java.net/jdk/pull/7492/files/8314380e..c393b584 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7492&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7492&range=00-01 Stats: 13 lines in 1 file changed: 3 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7492/head:pull/7492 PR: https://git.openjdk.java.net/jdk/pull/7492 From simonis at openjdk.java.net Thu Feb 17 16:02:46 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Thu, 17 Feb 2022 16:02:46 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 09:59:08 GMT, Alan Bateman wrote: > This change is probably okay Hi Alan, thanks for looking at this change. > but will require study to see if there are any side effects (sadly, this area has a history of side effects being reported months and years after a change). Would you mind holding off integrating this change until it has been reviewed by someone that works in the area? Sure, no problem. But can you please be a little more specific on who you consider to qualify as "*works in the area*" :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From rriggs at openjdk.java.net Thu Feb 17 16:34:06 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Feb 2022 16:34:06 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v6] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 01:38:42 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > 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 ten additional commits since the last revision: > > - Update JVMS references. > - Merge branch 'master' into JDK-8266670 > - Reorder constants by mask value per review feedback. > - Merge branch 'master' into JDK-8266670 > - Respond to more review feedback. > - Respond to review feedback explicitly stating returned sets are immutable. > - Fix typo from review feedback. > - Merge branch 'master' into JDK-8266670 > - JDK-8266670: Better modeling of modifiers in core reflection The jvms also has `access_flags` for parameters. [4.7.24. The MethodParameters Attribute](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.24) Even if java.lang.reflect.Parameter is not a "Member", it would be useful for Parameter to have an `accessFlags()` method and loosen up the spec for AccessFlag to allow its use in Parameter. Its access flags have the same underlying bit patterns and definitions. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From bpb at openjdk.java.net Thu Feb 17 16:38:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 17 Feb 2022 16:38:04 GMT Subject: RFR: 8254574: PrintWriter handling of InterruptedIOException is not documented In-Reply-To: References: Message-ID: <2jTRi_2489q8Uushnp-3gyrE7eDCjRvr-sa8UQt5Hok=.6eec1ec6-9989-40d1-a2b9-e5f70098dbfa@github.com> On Wed, 16 Feb 2022 22:32:21 GMT, Brian Burkhalter wrote: > Remove reference to `java.io.InterruptedIOException` from `java.io.PrintStream`, and make the specifications of `checkError()`, `setError()`, and `clearError()` consistent between `java.io.PrintStream` and `java.io.PrintWriter`. Thanks. I was holding off on that label until the PR approached consensus. ------------- PR: https://git.openjdk.java.net/jdk/pull/7507 From darcy at openjdk.java.net Thu Feb 17 17:16:11 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 17:16:11 GMT Subject: Integrated: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 00:09:33 GMT, Joe Darcy wrote: > Make explicit illegal argument cases of Class.arrayType. > > Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 This pull request has now been integrated. Changeset: 4c7f8b49 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/4c7f8b49a4845acf58272c42327328d6d2837cea Stats: 59 lines in 2 files changed: 58 ins; 0 del; 1 mod 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Reviewed-by: sundar, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/4382 From duke at openjdk.java.net Thu Feb 17 17:32:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 17 Feb 2022 17:32:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v16] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: migrate to junit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/2998571a..87b73334 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=14-15 Stats: 100 lines in 1 file changed: 74 ins; 7 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Thu Feb 17 17:38:09 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 17 Feb 2022 17:38:09 GMT Subject: Integrated: JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 20:36:26 GMT, Tim Prinzing wrote: > JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is null This pull request has now been integrated. Changeset: a6f8a386 Author: Tim Prinzing Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/a6f8a386efa7af162f4b815951287f0a9bc1f396 Stats: 216 lines in 5 files changed: 216 ins; 0 del; 0 mod 8281000: ClassLoader::registerAsParallelCapable throws NPE if caller is null Reviewed-by: erikj, ihse, mchung, bchristi ------------- PR: https://git.openjdk.java.net/jdk/pull/7448 From jbhateja at openjdk.java.net Thu Feb 17 17:43:43 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 17 Feb 2022 17:43:43 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v6] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- > 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98 > 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58 > 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56 > 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Fixing for windows failure. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/73674fe4..f35ed9cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From igraves at openjdk.java.net Thu Feb 17 18:09:35 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 17 Feb 2022 18:09:35 GMT Subject: RFR: 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java Message-ID: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> Adding a missing period per this doc bug. ------------- Commit messages: - Adding missing period Changes: https://git.openjdk.java.net/jdk/pull/7521/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7521&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276686 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7521.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7521/head:pull/7521 PR: https://git.openjdk.java.net/jdk/pull/7521 From iris at openjdk.java.net Thu Feb 17 18:15:10 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 17 Feb 2022 18:15:10 GMT Subject: RFR: 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java In-Reply-To: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> References: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> Message-ID: On Thu, 17 Feb 2022 18:02:20 GMT, Ian Graves wrote: > Adding a missing period per this doc bug. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7521 From bpb at openjdk.java.net Thu Feb 17 18:15:10 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 17 Feb 2022 18:15:10 GMT Subject: RFR: 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java In-Reply-To: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> References: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> Message-ID: On Thu, 17 Feb 2022 18:02:20 GMT, Ian Graves wrote: > Adding a missing period per this doc bug. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7521 From lancea at openjdk.java.net Thu Feb 17 18:15:10 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 17 Feb 2022 18:15:10 GMT Subject: RFR: 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java In-Reply-To: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> References: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> Message-ID: On Thu, 17 Feb 2022 18:02:20 GMT, Ian Graves wrote: > Adding a missing period per this doc bug. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7521 From brian.goetz at oracle.com Thu Feb 17 18:16:34 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 17 Feb 2022 13:16:34 -0500 Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v6] In-Reply-To: References: Message-ID: Yes, and ... There are words of flags elsewhere scattered through the JDK, such the InnerClasses attribute, module flags in the Module attribute, and flags on the "requires" entries in the Module attribute.? Having one abstraction to cover all these locations, even though reflection doesn't currently serve up them all, would be a sensible thing. On 2/17/2022 11:34 AM, Roger Riggs wrote: > On Thu, 17 Feb 2022 01:38:42 GMT, Joe Darcy wrote: > >>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >>> >>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >>> >>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >>> >>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >>> >>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >>> >>> The CSRhttps://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. >> 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 ten additional commits since the last revision: >> >> - Update JVMS references. >> - Merge branch 'master' into JDK-8266670 >> - Reorder constants by mask value per review feedback. >> - Merge branch 'master' into JDK-8266670 >> - Respond to more review feedback. >> - Respond to review feedback explicitly stating returned sets are immutable. >> - Fix typo from review feedback. >> - Merge branch 'master' into JDK-8266670 >> - JDK-8266670: Better modeling of modifiers in core reflection > The jvms also has `access_flags` for parameters. > [4.7.24. The MethodParameters Attribute](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.24) > > Even if java.lang.reflect.Parameter is not a "Member", it would be useful for Parameter to have an `accessFlags()` method and loosen up the spec for AccessFlag to allow its use in Parameter. > Its access flags have the same underlying bit patterns and definitions. > > ------------- > > PR:https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Thu Feb 17 18:45:11 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 18:45:11 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v5] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 13:18:47 GMT, ExE Boss wrote: >> 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 seven additional commits since the last revision: >> >> - Reorder constants by mask value per review feedback. >> - Merge branch 'master' into JDK-8266670 >> - Respond to more review feedback. >> - Respond to review feedback explicitly stating returned sets are immutable. >> - Fix typo from review feedback. >> - Merge branch 'master' into JDK-8266670 >> - JDK-8266670: Better modeling of modifiers in core reflection > > test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java line 65: > >> 63: if (left.mask() > right.mask()) { >> 64: throw new RuntimeException(left >> 65: + "has a greater mas than " > > Typo: > Suggestion: > > + "has a greater mask than " Will correct in next push; thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From joe.darcy at oracle.com Thu Feb 17 18:47:26 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 17 Feb 2022 10:47:26 -0800 Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v6] In-Reply-To: References: Message-ID: <95ee8aef-233f-833b-e784-d4bab1a51cea@oracle.com> On 2/17/2022 8:34 AM, Roger Riggs wrote: > On Thu, 17 Feb 2022 01:38:42 GMT, Joe Darcy wrote: > >>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >>> >>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >>> >>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >>> >>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >>> >>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >>> >>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. >> 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 ten additional commits since the last revision: >> >> - Update JVMS references. >> - Merge branch 'master' into JDK-8266670 >> - Reorder constants by mask value per review feedback. >> - Merge branch 'master' into JDK-8266670 >> - Respond to more review feedback. >> - Respond to review feedback explicitly stating returned sets are immutable. >> - Fix typo from review feedback. >> - Merge branch 'master' into JDK-8266670 >> - JDK-8266670: Better modeling of modifiers in core reflection > The jvms also has `access_flags` for parameters. > [4.7.24. The MethodParameters Attribute](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.24) I'll augment/edit the spec describing where the flags come from to mention method parameters. > > Even if java.lang.reflect.Parameter is not a "Member", it would be useful for Parameter to have an `accessFlags()` method and loosen up the spec for AccessFlag to allow its use in Parameter. > Its access flags have the same underlying bit patterns and definitions. An accessFlags method on Parameter has been part of this proposal since the first push: https://openjdk.github.io/cr/?repo=jdk&pr=7445&range=00#udiff-5-src/java.base/share/classes/java/lang/reflect/Parameter.java -Joe From lancea at openjdk.java.net Thu Feb 17 19:00:47 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 17 Feb 2022 19:00:47 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Return null when ZipEntry::getName is null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/32f6c284..d5cf8db8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=02-03 Stats: 201 lines in 2 files changed: 34 ins; 96 del; 71 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Thu Feb 17 19:05:13 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 17 Feb 2022 19:05:13 GMT Subject: RFR: 8280409: JarFile::verifiableEntry can fail with NPE accessing ze.getName() [v3] In-Reply-To: <0COr36OwTtowa8BVOnS_ZSR7mhByee9jwWl6f-4ps3E=.1969f9d1-bbae-45bb-818f-cfa7864a802d@github.com> References: <-7AnFYAj6YtdDUcUtgXYiDyNeojJW4vs7NgCLQPrbQY=.c0552e1f-4285-4cc9-b1dd-6d88d8da6d78@github.com> <0COr36OwTtowa8BVOnS_ZSR7mhByee9jwWl6f-4ps3E=.1969f9d1-bbae-45bb-818f-cfa7864a802d@github.com> Message-ID: On Fri, 11 Feb 2022 17:43:47 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/jar/JarFile.java line 881: >> >>> 879: ze = getJarEntry(entryName); >>> 880: } else { >>> 881: throw new ZipException("ZipEntry::getName returned null"); >> >> Throwing ZipException when ZipEntry::getName returns null is still surprising but not terrible. The spec for getInputStream specifies ZipException for when a zip file format occurs so we might have to extend that to add "or the zip entry name is null". > > If you would like me to update the ZipException to clarify this I can. The original issue was due to a format error in the CEN so the current wording covers that. It does not cover the case where ZipEntry is subclassed and ZipEntry::getName() returns null which is what your suggested wording would address. > > Please note the above change addresses the signed jar scenario. I can add an additional check in JarFile::getInputStream to check for null from ZipEntry::getName so that it covers unsigned jars and signed jars not being verified. > > The issue will not occur with ZipEFile::getInputStream given its use of ZipEntry.name which can never be null. > > Another thought would be to return null for the InputStream similar to when the ZipEntry does not represent a file within the Jar > > Please let me know your preference Per a discussion with Sean and Alan, we are now returning null for the InputStream to be consistent with ZipFile::getInputStream and how unsigned jars are handled ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From naoto at openjdk.java.net Thu Feb 17 19:07:13 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 17 Feb 2022 19:07:13 GMT Subject: Integrated: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 22:37:45 GMT, Naoto Sato wrote: > Fixing an issue in `CompactNumberFormat` which was caused by BigDecimal.divide() that incremented the number in the resulting format string. Also fixing some typos by taking this opportunity. This pull request has now been integrated. Changeset: 12927765 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/129277653e51e9b1387ecee279a6ccee9199c8ff Stats: 42 lines in 2 files changed: 31 ins; 0 del; 11 mod 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/7412 From darcy at openjdk.java.net Thu Feb 17 19:26:13 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 19:26:13 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v7] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. 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 11 additional commits since the last revision: - Add support for module flags; fix typo. - Merge branch 'master' into JDK-8266670 - Update JVMS references. - Merge branch 'master' into JDK-8266670 - Reorder constants by mask value per review feedback. - Merge branch 'master' into JDK-8266670 - Respond to more review feedback. - Respond to review feedback explicitly stating returned sets are immutable. - Fix typo from review feedback. - Merge branch 'master' into JDK-8266670 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/d7b3d5dd...5cc6ba50 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/02228108..5cc6ba50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=05-06 Stats: 494 lines in 13 files changed: 48 ins; 412 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Thu Feb 17 19:35:59 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 17 Feb 2022 19:35:59 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v17] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: migrate to junit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/87b73334..29af7c24 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Thu Feb 17 19:39:47 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 17 Feb 2022 19:39:47 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v18] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: migrate to junit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/29af7c24..cdfb03bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=16-17 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From rriggs at openjdk.java.net Thu Feb 17 20:06:10 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Feb 2022 20:06:10 GMT Subject: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 15:57:58 GMT, Roger Riggs wrote: > The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. > The result is retention of the class loader. > > The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. > The test verifies that the process reaper threads have a null context classloader. Please review this use of InnocuousThread. Tnx ------------- PR: https://git.openjdk.java.net/jdk/pull/7131 From duke at openjdk.java.net Thu Feb 17 20:18:11 2022 From: duke at openjdk.java.net (Selikoff) Date: Thu, 17 Feb 2022 20:18:11 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range [v2] In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 22:31:47 GMT, Naoto Sato wrote: >> Fixing an issue in `CompactNumberFormat` which was caused by BigDecimal.divide() that incremented the number in the resulting format string. Also fixing some typos by taking this opportunity. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addressing review comments Can I please be added as a Reviewer? I was the one who originally reported this bug on 2/7/2022 via Oracle's web form. ------------- PR: https://git.openjdk.java.net/jdk/pull/7412 From duke at openjdk.java.net Thu Feb 17 20:36:10 2022 From: duke at openjdk.java.net (ExE Boss) Date: Thu, 17 Feb 2022 20:36:10 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v7] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 19:26:13 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > 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 11 additional commits since the last revision: > > - Add support for module flags; fix typo. > - Merge branch 'master' into JDK-8266670 > - Update JVMS references. > - Merge branch 'master' into JDK-8266670 > - Reorder constants by mask value per review feedback. > - Merge branch 'master' into JDK-8266670 > - Respond to more review feedback. > - Respond to review feedback explicitly stating returned sets are immutable. > - Fix typo from review feedback. > - Merge branch 'master' into JDK-8266670 > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b1511105...5cc6ba50 Note?that the?`accessFlags()`?method is?still?missing in?the?`ModuleDescriptor.Opens` and?the?top?level `ModuleDescriptor`?classes: ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From joe.darcy at oracle.com Thu Feb 17 20:41:05 2022 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Feb 2022 12:41:05 -0800 Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v6] In-Reply-To: References: Message-ID: Okay; I'll work on a location/context enum to model where flags can appear for the next iteration as the place-holder ElementType enum fro annotations doesn't quite work for this VM-centric context. Thanks, -Joe On 2/17/2022 10:16 AM, Brian Goetz wrote: > Yes, and ... > > There are words of flags elsewhere scattered through the JDK, such the > InnerClasses attribute, module flags in the Module attribute, and > flags on the "requires" entries in the Module attribute. Having one > abstraction to cover all these locations, even though reflection > doesn't currently serve up them all, would be a sensible thing. > > > > On 2/17/2022 11:34 AM, Roger Riggs wrote: >> On Thu, 17 Feb 2022 01:38:42 GMT, Joe Darcy? wrote: >> >>>> This is an early review of changes to better model JVM access >>>> flags, that is "modifiers" like public, protected, etc. but >>>> explicitly at a VM level. >>>> >>>> Language level modifiers and JVM level access flags are closely >>>> related, but distinct. There are concepts that overlap in the two >>>> domains (public, private, etc.), others that only have a >>>> language-level modifier (sealed), and still others that only have >>>> an access flag (synthetic). >>>> >>>> The existing java.lang.reflect.Modifier class is inadequate to >>>> model these subtleties. For example, the bit positions used by >>>> access flags on different kinds of elements overlap (such as >>>> "volatile" for fields and "bridge" for methods. Just having a raw >>>> integer does not provide sufficient context to decode the >>>> corresponding language-level string. Methods like >>>> Modifier.methodModifiers() were introduced to cope with this >>>> situation. >>>> >>>> With additional modifiers and flags on the horizon with projects >>>> like Valhalla, addressing the existent modeling deficiency now >>>> ahead of time is reasonable before further strain is introduced. >>>> >>>> This PR in its current form is meant to give the overall shape of >>>> the API. It is missing implementations to map from, say, method >>>> modifiers to access flags, taking into account overlaps in bit >>>> positions. >>>> >>>> The CSRhttps://bugs.openjdk.java.net/browse/JDK-8281660 will be >>>> filled in once the API is further along. >>> 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 >>> ten additional commits since the last revision: >>> >>> ? - Update JVMS references. >>> ? - Merge branch 'master' into JDK-8266670 >>> ? - Reorder constants by mask value per review feedback. >>> ? - Merge branch 'master' into JDK-8266670 >>> ? - Respond to more review feedback. >>> ? - Respond to review feedback explicitly stating returned sets are >>> immutable. >>> ? - Fix typo from review feedback. >>> ? - Merge branch 'master' into JDK-8266670 >>> ? - JDK-8266670: Better modeling of modifiers in core reflection >> The jvms also has `access_flags` for parameters. >> [4.7.24. The MethodParameters >> Attribute](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.24) >> >> Even if java.lang.reflect.Parameter is not a "Member", it would be >> useful for Parameter to have an `accessFlags()` method and loosen up >> the spec for AccessFlag to allow its use in Parameter. >> Its access flags have the same underlying bit patterns and definitions. >> >> ------------- >> >> PR:https://git.openjdk.java.net/jdk/pull/7445 From naoto at openjdk.java.net Thu Feb 17 20:55:12 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 17 Feb 2022 20:55:12 GMT Subject: RFR: 8281317: CompactNumberFormat displays 4-digit values when rounding to a new range [v2] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 07:32:36 GMT, Selikoff wrote: > Can I please be added as a Reviewer? I was the one who originally reported this bug on 2/7/2022 via Oracle's web form. To be listed as a Reviewer, you will need to be a Reviewer of the JDK Project (https://openjdk.java.net/bylaws#reviewer). Instead, I tried to add you as a contributor in this PR, but failed as I wasn't aware `/contributor` command does not work after the PR is closed. Sorry. ------------- PR: https://git.openjdk.java.net/jdk/pull/7412 From lancea at openjdk.java.net Thu Feb 17 21:02:12 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 17 Feb 2022 21:02:12 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 16:02:42 GMT, Volker Simonis wrote: >> Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). >> >> >> before JDK-8281962 >> ------------------ >> Benchmark (size) Mode Cnt Score Error Units >> InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op >> InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op >> InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op >> >> after JDK-8281962 >> ----------------- >> Benchmark (size) Mode Cnt Score Error Units >> InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op >> InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op >> InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op >> >> >> Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. >> >> As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: >> >> >> int readcount = 0; >> while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { >> outputStream.write(data, 0, bytesRead); >> readCount++; >> } >> if (readCount == 1) { >> return data; // <---- first bytes might be overwritten >> } >> return outputStream.toByteArray(); >> >> >> Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). >> >> [1] https://github.com/spring-projects/spring-framework/issues/27429 >> [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Changed hardcoded constant to JMH parmater and removed non-ASCII chars from comments The change looks innocuous so it is probably OK. I would like to kick of our Mach5 runs to see if it shakes out any potential issues. >From reading the 3rd party problem reports, it appears that the problem is with the 3rd party zlib implementations. Hopefully this change will not mask other issues ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From almatvee at openjdk.java.net Thu Feb 17 21:17:34 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 17 Feb 2022 21:17:34 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v5] In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: > Added ability to override description for additional launchers via "description" property. Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge master - 8279995: jpackage --add-launcher option should allow overriding description [v4] - 8279995: jpackage --add-launcher option should allow overriding description [v3] - 8279995: jpackage --add-launcher option should allow overriding description [v2] - 8279995: jpackage --add-launcher option should allow overriding description ------------- Changes: https://git.openjdk.java.net/jdk/pull/7399/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=04 Stats: 77 lines in 7 files changed: 67 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7399/head:pull/7399 PR: https://git.openjdk.java.net/jdk/pull/7399 From almatvee at openjdk.java.net Thu Feb 17 21:33:11 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 17 Feb 2022 21:33:11 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v3] In-Reply-To: References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Tue, 15 Feb 2022 15:48:02 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279995: jpackage --add-launcher option should allow overriding description [v3] > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 159: > >> 157: } >> 158: >> 159: TKit.assertNotNull(description, "Failed to get file description"); > > Failure to get the executable's description through powersehll script is not an issue of a test case being executed. This is the testing framework issue. Throwing RuntimeException with the message containing file path will be the appropriate error handling. Having a file name in the exception message will help to localize the issue. Fixed. Error message also fixed for description check. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From darcy at openjdk.java.net Thu Feb 17 22:54:05 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 22:54:05 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v8] In-Reply-To: References: Message-ID: <1KAHhWZtTcIyQaVBnbWKo8At77aRlkQJfEjl0VD1VXQ=.19dc4144-e23c-4bf3-8ea6-41dd3fa8d73d@github.com> > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/5cc6ba50..131010f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=06-07 Stats: 24 lines in 1 file changed: 22 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Thu Feb 17 22:59:02 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Feb 2022 22:59:02 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v7] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 20:32:45 GMT, ExE Boss wrote: > Note that the `accessFlags()` method is still missing in the `ModuleDescriptor.Opens` and the top?level `ModuleDescriptor` classes: > > https://github.com/openjdk/jdk/blob/5cc6ba50b1155340d13bc29d581c91ac543d2d95/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L637-L651 > > https://github.com/openjdk/jdk/blob/5cc6ba50b1155340d13bc29d581c91ac543d2d95/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L1307-L1324 You're correct; addressed in subsequent push. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Thu Feb 17 23:09:30 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 17 Feb 2022 23:09:30 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding Message-ID: FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. With these changes however, my test systems continue to fail. - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 Note that the expected value is populated from native.encoding. This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). --- A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. ------------- Commit messages: - Changes FileEncodingTest test to delegate behaviour of -Dfile.encoding=COMPAT to Changes: https://git.openjdk.java.net/jdk/pull/7525/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282042 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7525/head:pull/7525 PR: https://git.openjdk.java.net/jdk/pull/7525 From ccheung at openjdk.java.net Thu Feb 17 23:24:05 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 17 Feb 2022 23:24:05 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v4] In-Reply-To: References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: On Wed, 19 Jan 2022 05:47:57 GMT, Ioi Lam wrote: >> **Background:** >> >> In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: >> >> >> public enum Day { SUNDAY, MONDAY ... } >> >> >> to >> >> >> public class Day extends java.lang.Enum { >> public static final SUNDAY = new Day("SUNDAY"); >> public static final MONDAY = new Day("MONDAY"); ... >> } >> >> >> With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) >> >> **Fix:** >> >> During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. >> >> This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. >> >> **Verification:** >> >> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt >> >> **Testing:** >> >> Passed Oracle CI tiers 1-4. WIll run tier 5 as well. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Use InstanceKlass::do_local_static_fields for some field iterations Looks good. Minor comment below. Also, several files with copyright year 2021 need updating. src/hotspot/share/cds/cdsHeapVerifier.cpp line 63: > 61: // class Bar { > 62: // // this field is initialized in both CDS dump time and runtime. > 63: // static final Bar bar = new Bar; `new Bar` should be `new Bar()`? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6653 From darcy at openjdk.java.net Fri Feb 18 03:38:36 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 18 Feb 2022 03:38:36 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v9] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Switch to location enum. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/131010f3..c3f6b0a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=07-08 Stats: 112 lines in 1 file changed: 78 ins; 0 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From forax at univ-mlv.fr Fri Feb 18 08:09:54 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 18 Feb 2022 09:09:54 +0100 (CET) Subject: [External] : Sequenced Collections In-Reply-To: <0fd61be1-0e52-2854-a3ca-d73a2d27a90b@oracle.com> References: <1180838175.1539088.1644491691456.JavaMail.zimbra@u-pem.fr> <1cadbca8-93e0-aa93-5f19-71248a903f8c@oracle.com> <114971094.2972940.1644774057868.JavaMail.zimbra@u-pem.fr> <0fd61be1-0e52-2854-a3ca-d73a2d27a90b@oracle.com> Message-ID: <1667892838.5184733.1645171794784.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Stuart Marks" > To: "Remi Forax" > Cc: "core-libs-dev" , "Tagir Valeev" > Sent: Tuesday, February 15, 2022 6:06:54 AM > Subject: Re: [External] : Sequenced Collections >> Here is the first sentence of the javadoc for java.util.List "An ordered >> collection (also known as a sequence)." >> And the first paragraph of java.util.RandomAccess "Marker interface used by List >> implementations to indicate that they support fast (generally constant time) >> random access. The primary purpose of this interface is to allow generic >> algorithms to alter their behavior to provide good performance when applied to >> either random or sequential access lists" >> >> You can find that the actual design, mixing ordered collection and indexed >> collection into one interface named List not great, but you can not say that >> this is not the actual design. > > Hi R?mi, > > You have a talent for omitting pieces of the specification that are inconvenient > to > your argument. The complete first paragraph of the List specification is > > An ordered collection (also known as a sequence). The user of this interface > has precise control over where in the list each element is inserted. The user > can access elements by their integer index (position in the list), and search > for elements in the list. > > Clearly, a List is not *merely* an ordered collection or sequence. Positioning > (which I refer to as external ordering) and access by index are also inherent to > List. I don't disagree, my point is that java.util.List is both an ordered collection or sequence and an indexed collection. So from the POV of an implementer it's both, but from the POV of a user, if you want only an ordered collection or sequence, you will use List. Introducing SequencedCollection may be ok in term of implementation, but it will cause trouble in term of usage, an alarmist view is to think that introducing SequencedCollection will cause chaos, but i think it will simple than that, people will quickly learn that as OrderedSet, NavigableSet or Queue, SequencedCollection is a second class citizen interface and should rarely used in the signature of public methods. > > The original design does support "random access" and "sequential" (linked) > lists. > However, 20 years of experience with LinkedList, and with alternative algorithms > that check the RandomAccess marker interface, have shown that this doesn't work > very > well. It would be a bad idea to extend that design by making LinkedHashSet > implement > List or for it to provide a List view. Yes, you right about that, but it does not mean that SequencedCollection will solve anything. > > SortedSet is internally ordered and is therefore semantically incompatible with > the > external ordering of List. This incompatibility exists regardless of whether > SortedSet implements List directly or merely provides a List view. If it's a view, you now that a view keeps the semantics of the original collection, this is how a view works, so i agree that a SortedSet can not implement List directly, but it do not think it's an issue if SortedSet provides a view. > > In object design you can always take a sledgehammer to something and pound on it > until it kind of looks like what you want. Indeed, you could do that with List > in > the way that you suggest, but the result will be confusing to work with and > burdensome to implement. So, no, I'm not going to do that. I don't think there is a good solution here, I'm wary about the fact that you want to fix a 20 year old design bug by trying to shoehorn SequencedCollection with the hope that it will fix that design error, my experience is that this kind of refactoring does more harm than good. And we can not use List because we dpo not want to introduce new sequential implementations of List. And you did not answer about providing a bidirectional iterator of the fact that LinkedHashMap does not implement SequencedMap correctly, as an example the following code may throw an AssertionError with a SequencedSet created from a LinkedHashMap constructed with true as last argument. void brokenInvariant(SequencedSet set) { var first = set.getFirst(); set.contains("foo"); assertEquals(first, set.getFirst()); } > > s'marks R?mi > > > > > On 2/13/22 9:40 AM, forax at univ-mlv.fr wrote: >> >> >> ------------------------------------------------------------------------------------ >> >> *From: *"Tagir Valeev" >> *To: *"Stuart Marks" >> *Cc: *"Remi Forax" , "core-libs-dev" >> >> *Sent: *Saturday, February 12, 2022 4:24:24 AM >> *Subject: *Re: [External] : Sequenced Collections >> >> Wow, I missed that the Sequenced Collections JEP draft was posted! >> Of course, I strongly support this initiative and am happy that my proposal got >> some love and is moving forward. In general, I like the JEP in the way it is. I >> have only two slight concerns: >> 1. I'm not sure that having addition methods (addFirst, addLast, putFirst, >> putLast) is a good idea, as not every mutable implementation may support them. >> While this adds some API unification, it's quite a rare case when this could be >> necessary. I think most real world applications of Sequenced* types would be >> around querying, or maybe draining (so removal operations are ok). Probably it >> would be enough to add addFirst, addLast, putFirst, putLast?directly to the >> compatible implementations/subinterfaces like List, LinkedHashSet, and >> LinkedHashMap removing them from the Sequenced* interfaces. In this case, >> SortedSet interface will not be polluted with operations that?can never be >> implemented. Well my opinion is not very strong here. >> >> 2. SequencedCollection name is a little bit too long. I think every extra letter >> adds a hesitation for users to use the type, especially in APIs where it could >> be the most useful. I see the Naming section and must admit that I don't have >> better ideas. Well, maybe just Sequenced would work? Or too vague? >> >> Speaking of Remi's suggestion, I don't think it's a good idea. Maybe it could be >> if we designed the Collection API from scratch. >> >> >> ?? >> Here is the first sentence of the javadoc for java.util.List "An ordered >> collection >> (also known as a /sequence/)." >> And the first paragraph of java.util.RandomAccess "Marker interface used by >> |List| >> implementations to indicate that they support fast (generally constant time) >> random >> access. The primary purpose of this interface is to allow generic algorithms to >> alter their behavior to provide good performance when applied to either random >> or >> sequential access lists" >> >> You can find that the actual design, mixing ordered collection and indexed >> collection into one interface named List not great, but you can not say that >> this is >> not the actual design. >> >> But given the current state of Java collections, it's better to add new >> interfaces than to put the new semantics to the java.util.List and greatly >> increase the amount of non-random-accessed lists in the wild. >> There are tons of code that implicitly assume fast random access of every >> incoming list (using indexed iteration inside). The suggested approach could >> become a performance disaster. >> >> >> If you take several Java developers, some will stick to the javadoc definition, >> a >> List is either sequential or random access and some will think that a List is >> only >> random access. Because of that, adding more sequential implementations under the >> List interface is an issue. >> >> Introducing SequencesCollection (more on the name later), a super interface of >> List >> solves that issue, the new implementations will only implement the sequential >> part >> of interface List. >> But it does not solve the other problems, mainly adding 4 interfaces when one is >> enough, not being backward compatible because of inference and the weird >> semantics >> of LinkedHashMap. >> >> We still need SortedSet or LinkedHashSet to not directly implement >> SequencesCollection but to use delegation and a have a method returning a view. >> The >> same reasoning applied to SortedMap, LinkedHashMap. >> By using views, there is no need to the two other proposed interfaces >> SequenceSet >> and SequenceMap. >> >> Another question is ListIterator, a list can be iterated forward and backward, a >> SequenceCollection can do almost the same thing, with iterator() and >> reversed().iterator(). It's not exactly the same semantics but i don't think it >> exist an implementation of SequenceCollection that can be implemented without >> the >> property that given one element, it's predecessor and successor can be found in >> O(1). >> Do we need a new SequenceCollectionIterator that provides the method >> next/hasNext/previous/hasPrevious but not add/set/nextIndex/previousIndex ? >> >> For the name, Java uses single simple name of one syllable for the important >> interface List, Set, Map or Deque (the javadoc of Deque insist that Deque should >> be >> pronounced using one syllable). >> So the name should be Seq. >> The main issue with the name "Seq" is that it is perhaps too close to the name >> "Set". >> Also, it can not be "Sequence" because of CharSequence. >> >> interface Seq extends Collection { >> ?? void addFirst(); >> ?? void addLast(); >> ?? E getFirst(); >> ?? E getLast(); >> ?? E removeFirst(); >> ?? E removeLast(); >> ?? Seq reversed(); >> } >> >> interface List extends Seq { } >> >> interface SortedSet implements Set {? // or NavigableSet >> ?? // new methods >> ?? Seq asSeq(); >> } >> >> interface SortedMap implements Map {? // or NavigableMap >> ?? // new methods >> ?? Seq keySeq();? // do not use covariant return type >> ?? Seq valueSeq(); >> ?? Seq> entrySeq(); >> } >> >> I'm still not sure that introducing an interface like Seq instead of using List >> is >> the way to go. >> If we do that, there will be a lot of blog post/bikeshedding about when to use >> List >> vs Seq and a lot of github issues about taking a Seq instead of a List as >> parameter >> of a method of a library. >> >> >> With best regards, >> Tagir Valeev. >> >> >> R?mi >> >> >> On Sat, Feb 12, 2022 at 2:26 AM Stuart Marks > > wrote: >> >> Hi R?mi, >> >> I see that you're trying to reduce the number of interfaces introduced by >> unifying >> things around an existing interface, List. Yes, it's true that List is an >> ordered >> collection. However, your analysis conveniently omits other facts about List >> that >> make it unsuitable as a general "ordered collection" interface. Specifically: >> >> 1) List supports element access by int index; and >> >> 2) List is externally ordered. That is, its ordering is determined by a >> succession >> of API calls, irrespective of element values. This is in contrast to >> SortedSet et al >> which are internally ordered, in that the ordering is determined by the >> element values. >> >> The problem with indexed element access is that it creates a bunch of hidden >> performance pitfalls for any data structure where element access is other >> than O(1). >> So get(i) degrades to O(n), binarySearch degrades from O(log n) to O(n). >> (This is in >> the sequential implementation; the random access implementation degrades to >> O(n log >> n)). Apparently innocuous indexed for-loops degrade to quadratic. This is >> one of the >> reasons why LinkedList is a bad List implementation. >> >> If we refactor LinkedHashSet to implement List, we basically have created >> another >> situation just like LinkedList. That's a step in the wrong direction. >> >> Turning to internal ordering (SortedSet): it's fundamentally incompatible with >> List's external ordering. List has a lot of positional mutation operations >> such as >> add(i, obj); after this call, you expect obj to appear at position i. That >> can't >> work with a SortedSet. >> >> There is implicit positioning semantics in other methods that don't have index >> arguments. For example, replaceAll replaces each element of a List with the >> result >> of calling a function on that element. Crucially, the function result goes >> into the >> same location as the original element. That to cannot work with SortedSet. >> >> Well, we can try to deal with these issues somehow, like making certain methods >> throw UnsupportedOperationException, or by relaxing the semantics of the >> methods so >> that they no longer have the same element positioning semantics. Either of >> these >> approaches contorts the List interface to such an extent that it's no longer >> a List. >> >> So, no, it's not useful or effective to try to make List be the common "ordered >> collection" interface. >> >> s'marks >> >> >> >> On 2/10/22 3:14 AM, Remi Forax wrote: >> > I've read the draft of the JEP on sequenced collection, and i think the >> proposed design can be improved. >> > https://bugs.openjdk.java.net/browse/JDK-8280836 >> >> > >> > I agree with the motivation, there is a need for an API to consider the >> element of a list, a sorted set and a linked hash set as an ordered sequence >> of elements with a simple way to access/add/remove the first/last element >> and also reverse the elements as view. >> > >> > I disagree about the conclusion that we need to introduce 4 new >> interfaces for that matter. >> > >> > Here are the reasons >> > 1/ Usually an ordered collection is called a list. Introducing an >> interface SequencedCollection for something which is usually called a list >> will cause more harm than good. Or maybe we should rename LISP to SEQP :) >> > >> > 2/ There is already an interface List in Java, that represents an ordered >> sequence of elements, with LinkedList being the name of the the double >> linked list implementation. You can argue that there is a slight difference >> between the semantics of java.util.List and the proposed syntax of >> java.util.SequencedCollection, but given that people already have >> difficulties to understand basic data structure concepts, as a teacher i >> dread to have a discussion on those slight differences that are only true in >> Java. >> > >> > If the collection API was not already existing, we may discuss about >> having the same interface java.util.List to both indexed collection and >> ordered collection, but that boat has sailed a long time ago. >> > >> > So in first approach, we should refactor sorted set and linked hash set >> to directly implement java.util.List and all the proposed methods into >> java.util.List. But as you hint in the Risks and Assumptions section, this >> will cause regression due to inference and also we will have trouble with >> LinkedHashMap (see below). >> > >> > 3/ LinkedHashMap mixes 3 implementations in one class, some of these >> implementations does not conform to the semantics of SequencedMap. >> > - You can opt-out having the key sequentially ordered as defined by >> SequencedMap by using the constructor LinkedHashMap(int initialCapacity, >> float loadFactor, boolean accessOrder) and passing true as last parameter. >> > - You can opt-out having the key sequentially ordered as defined by >> SequencedMap by overriding removeEldestEntry(), removing the first entry at >> the same time you add a new one. >> > >> > Because all these reasons, i think we should move to another design, >> using delegation instead of inheritance, which for the collection framework >> means exposing new way to access/modify sorted set and linked hash set >> through java.util.List views. >> > >> > The concept of views is not a new concept, it's used in Arrays.asList(), >> List.subList() or Map.keySet()/values()/entrySet() (and more). The idea is >> not that a sorted set is a list but that it provides a method to see it as a >> list. It solves our problem of compatibility by not adding super types to >> existing type and also the problem of the semantics of LinkedHashMap because >> a view keeps the semantics of the data structure it originated. >> > >> > Here is the proposed new methods in List, SortedSet and SortedMap. >> > >> > interface List extends Collection { >> >? ? // new methods >> >? ? void addFirst(); >> >? ? void addLast(); >> >? ? E getFirst(); >> >? ? E getLast(); >> >? ? E removeFirst(); >> >? ? E removeLast(); >> >? ? List reversedList(); // or descendingList() ?? >> > } >> > >> > interface SortedSet implements Set { >> >? ? // new methods >> >? ? List asList(); >> > } >> > >> > interface SortedMap implements Map { >> >? ? // new methods >> >? ? List keyList();? // do not use covariant return type >> >? ? List> entryList();? // same >> > } >> > >> > I believe this design is objectively better than the one proposed because >> as a user being able to use new interfaces is a slow process, the >> libraries/dependencies must be updated to take the new interfaces as >> parameter before the new types can be used. By contrast, the proposed design >> only enhance existing interfaces so people will enjoy the new methods >> directly when introduced. >> > >> > R?mi >> > >> From simonis at openjdk.java.net Fri Feb 18 08:49:55 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Fri, 18 Feb 2022 08:49:55 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 20:58:54 GMT, Lance Andersen wrote: > The change looks innocuous so it is probably OK. I would like to kick of our Mach5 runs to see if it shakes out any potential issues. > Thanks Lance! Much appreciated. > From reading the 3rd party problem reports, it appears that the problem is with the 3rd party zlib implementations. Hopefully this change will not mask other issues The problem arises from a difference in the specification of zlib's inflate function and Java's Input stream. Basically, both take a buffer and the *length* of that buffer as input and return the number of bytes (i.e. payload) written into that buffer (which can be smaller than *length*). However, zlib doesn't specify that bytes between the *returned length* and the the *buffer length* can't be modified while Java does. Mark Adler's original zlib version never wrote more bytes into the buffer than it returned as *length* value and users of his implementation started to more or less rely on this implementation detail. But newer and improved versions of zlib might write more bytes into the output buffer than they return as *length* value (e.g. because they use vector instructions for writes). According to zlib's inflate specification this is fine as long as they don't overwrite the end of the buffer and as long as they return the correct *length* of inflated bytes. In order to make this behavior more evident, Chromium's zlib version puts some extra padding bytes after the last inflated byte if there's enough space left in the buffer (and this happens even if zero bytes were inflated). This behavior becomes particularly harmful if Java's InflaterInputStream unnecessarily calls the native inflate() function just to find out that there's no data left to inflate. With Chromium's zlib this will still write the padding bytes to the beginning of the output buffer and potentially overwrite the inflated output from the last call to InflaterInputStream::read. So to cut a long story short, there's no problem with Chromium's zlib implementation. It behaves correctly according to the zlib specification. This change (besides the performance improvements) helps using other zlib implementations which behave correctly but slightly different from the original zlib implementation into Java. ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From turbanoff at gmail.com Fri Feb 18 09:55:45 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Fri, 18 Feb 2022 12:55:45 +0300 Subject: Unused static constant MathContext.DEFAULT_DIGITS Message-ID: Hello. I noticed unused field java.math.MathContext#DEFAULT_DIGITS https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/math/MathContext.java#L61 As I can see, it was already unused in the initial OpenJDK source. Does VM use this field somehow? Or used to use? Andrey Turbanov From duke at openjdk.java.net Fri Feb 18 11:24:00 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 18 Feb 2022 11:24:00 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v18] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Thu, 17 Feb 2022 19:39:47 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > migrate to junit well seems jtreg cannot invoke Junit4 's parameterized test. I tried to join their mailing list but nobody approve. well then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From eirbjo at gmail.com Fri Feb 18 11:42:28 2022 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 18 Feb 2022 12:42:28 +0100 Subject: Accessing the BCI of Throwable's StackTraceElement Message-ID: Hi, Currently, StackWalker.StackFrame::getByteCodeIndex provides a way to get the BCI of stack frames during a stack walk. Similarly, it might be useful to get the BCI when inspecting a Throwable's StackTraceElements. This does however not seem possible, given that StackTraceElement currently does not expose the BCI. (It exposes the lineNumber, but that's not useful for my current use case). On another note, it seems like calling Throwable.getStackTrace() would be a wasteful way to just find the BCI of the top stack frame. Would be really nice if one could do a StackWalk with a Throwable as input, which I imagine should work a lot more efficiently. (My use case here is to attribute any exception to a BCI in the same method such that I don't need to instrument code to track the BCI myself). So I guess I have two questions: 1: Would it be reasonable to add a getByteCodeIndex method to StackTraceElement? Or perhaps even make StackTraceElement implement StackWalker.StackFrame? 2: Could the StackWalker API be suitable for walking not just the stack of current threads, but also the stacks of Throwables? Was this discussed during the development of StackWalker for Java 9? Cheers, Eirik. From alanb at openjdk.java.net Fri Feb 18 12:12:54 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 12:12:54 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 19:00:47 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the attached patch to address >> >> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter >> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs >> >> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Return null when ZipEntry::getName is null The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From sverre.moe at gmail.com Fri Feb 18 13:31:21 2022 From: sverre.moe at gmail.com (Sverre Moe) Date: Fri, 18 Feb 2022 14:31:21 +0100 Subject: JDK-17: Wndows jpackage destination directory not writable In-Reply-To: References: <6e1e209f-1919-c98a-0b86-0a6453ce5bba@oracle.com> Message-ID: I executed our JDK11 docker image, which works fine with JDK11 and JDK14 (for jpackage support). Then I installed the JDK17 MSI package, changed JAVA_HOME and PATH. Building our application now with JDK17 it still cannot write to the "build/native" jpackage output directory. Leads me to conclude something has changed in jpackage between JDK14 and JDK17. I modified my gradle configuration, to use jpackage from JDK14 when packaging my JDK17 built application. It works using JDK14 jpackage to package our JDK17 application. Using the JDK17 jpackage directly in Windows works fine. It is only in the Docker container that it does not work. /Sverre tir. 5. okt. 2021 kl. 11:55 skrev Sverre Moe : > I ran cacls after the failed jpackage. > > C:\temp\my-javafx-application>cacls build > C:\temp\my-javafx-application\build F > CREATOR OWNER:(OI)(CI)(IO)F > R > CREATOR GROUP:(OI)(CI)(IO)R > Everyone:(OI)(CI)R > > C:\temp\my-javafx-application>cacls build\native > C:\temp\my-javafx-application\build\native F > CREATOR OWNER:(OI)(CI)(IO)F > R > CREATOR GROUP:(OI)(CI)(IO)R > Everyone:(OI)(CI)R > > > As cacls was deprecated it suggested to use icacls instead: > > C:\temp\my-javafx-application>icacls build > build S-1-5-21-406077803-2019195645-689573112-1003:(I)(F) > CREATOR OWNER:(I)(OI)(CI)(IO)(F) > S-1-5-21-406077803-2019195645-689573112-513:(I)(RX) > CREATOR GROUP:(I)(OI)(CI)(IO)(RX) > Everyone:(I)(OI)(CI)(RX) > > Successfully processed 1 files; Failed processing 0 files > > C:\temp\my-javafx-application>icacls build\native > build\native S-1-5-83-1-1537791174-1084404783-2478187907-2577323605:(I)(F) > CREATOR OWNER:(I)(OI)(CI)(IO)(F) > S-1-5-83-0:(I)(RX) > CREATOR GROUP:(I)(OI)(CI)(IO)(RX) > Everyone:(I)(OI)(CI)(RX) > > Successfully processed 1 files; Failed processing 0 files > > Running attrib on the workspace, and build dirs: > > C:\Temp\my-javafx-application>attrib > A C:\Temp\my-javafx-application\.description > A C:\Temp\my-javafx-application\.gitignore > A C:\Temp\my-javafx-application\build.gradle > A C:\Temp\my-javafx-application\gradle.properties > A C:\Temp\my-javafx-application\gradlew > A C:\Temp\my-javafx-application\gradlew.bat > A C:\Temp\my-javafx-application\Jenkinsfile > A C:\Temp\my-javafx-application\packager.gradle > A C:\Temp\my-javafx-application\README.adoc > A C:\Temp\my-javafx-application\settings.gradle > A C:\Temp\my-javafx-application\spotless.gradle > > C:\Temp\my-javafx-application>attrib build > C:\Temp\my-javafx-application\build > > C:\Temp\meos-dashboard>attrib build\native > C:\Temp\my-javafx-application\build\native > > /Sverre > > tir. 5. okt. 2021 kl. 10:41 skrev Alan Bateman : > >> On 05/10/2021 08:54, Sverre Moe wrote: >> > With JDK 17, jpackage fails to write to the destination directory on >> > Windows. >> > >> > It worked fine with JDK 11 (with jpackage from JDK14) and Docker. >> > >> > Only happens on Windows docker. Running directly on WIndows it works >> with >> > JDK 17. >> > >> > What has changed with jpackage that it no longer can write to the >> > destination directory when running in Docker? >> > Is it a regression/bug with jpackage? >> > >> I don't know what has changed in jpackage, maybe it didn't check for >> write access previously. However, the error you are seeing suggests >> there may be a lower-level issue, maybe a driver issue. It would be >> useful if you could print out the DACL (using cacls is okay) and the DOS >> attributes. >> >> -Alan >> > From david.holmes at oracle.com Fri Feb 18 13:51:50 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Feb 2022 23:51:50 +1000 Subject: Unused static constant MathContext.DEFAULT_DIGITS In-Reply-To: References: Message-ID: <1fa2f19c-562d-365c-0ece-b00dd082b873@oracle.com> On 18/02/2022 7:55 pm, Andrey Turbanov wrote: > Hello. > I noticed unused field java.math.MathContext#DEFAULT_DIGITS > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/math/MathContext.java#L61 > > As I can see, it was already unused in the initial OpenJDK source. > Does VM use this field somehow? Or used to use? The VM doesn't use it. Looks like dead code. Cheers, David > Andrey Turbanov From rriggs at openjdk.java.net Fri Feb 18 14:56:50 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 18 Feb 2022 14:56:50 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v9] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 03:38:36 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Switch to location enum. The Location enum does give more control over the places modifiers can occur and be extended as needed. But its unfortunate there's no (simple/obvious) mapping to the other concepts of the corresponding types, such as ElementType or Class/Method/Constructor. I don't have a clear use case for the mapping, so maybe its just a rough edge that can be smoothed out when AccessFlags gets used. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Fri Feb 18 15:29:26 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 18 Feb 2022 15:29:26 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v18] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 18 Feb 2022 11:20:12 GMT, XenoAmess wrote: > well seems jtreg cannot invoke Junit4 's parameterized test. Nope, it can! :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 18 15:29:25 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 18 Feb 2022 15:29:25 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v19] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <1AW2iddnLOTU-np_YhZgGuFx9MLgl0yX4qKtPFiFELM=.4f4c8a42-1ffa-4dfe-acb0-df1487d6a49c@github.com> > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - migrate to junit - change threshold ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/cdfb03bb..aa599698 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=17-18 Stats: 64 lines in 2 files changed: 17 ins; 17 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From rriggs at openjdk.java.net Fri Feb 18 15:36:24 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 18 Feb 2022 15:36:24 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true Message-ID: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> In some Linux configurations, the Linux home directory provided by getpwent is not usable. The value of the system property `user.home` should fallback to the value of $HOME if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. If $HOME is undefined or empty, the value of the getpwent.user_home is retained. There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. ------------- Commit messages: - Fallback to $HOME, if defined, if the os supplied user_home is - Fallback to $HOME if the home directory is "/" or not available - 8280357: user.home = "?" when running with systemd DynamicUser=true Changes: https://git.openjdk.java.net/jdk/pull/7534/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7534&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280357 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7534.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7534/head:pull/7534 PR: https://git.openjdk.java.net/jdk/pull/7534 From alanb at openjdk.java.net Fri Feb 18 15:54:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 15:54:47 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true In-Reply-To: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> Message-ID: On Fri, 18 Feb 2022 15:29:34 GMT, Roger Riggs wrote: > In some Linux configurations, the Linux home directory provided by getpwent is not usable. > The value of the system property `user.home` should fallback to the value of $HOME > if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. > > If $HOME is undefined or empty, the value of the getpwent.user_home is retained. > > There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 > > The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. There is an argument that the JDK should read $HOME first but changing it after 20+ years could be risky, probably difficult to get a list of configurations/environments where the two might yield different locations. So I think the approach is reasonable. Even if "/" were a configured as the home directory in the user entry then $HOME would need to agree so that I think the <2 check is okay too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From redestad at openjdk.java.net Fri Feb 18 15:57:40 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 18 Feb 2022 15:57:40 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v4] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/531139a1..a5e28b32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=02-03 Stats: 59 lines in 8 files changed: 7 ins; 14 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From omikhaltcova at openjdk.java.net Fri Feb 18 16:07:29 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 18 Feb 2022 16:07:29 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v2] In-Reply-To: References: Message-ID: <-wRMY6KNRPss8NEnURu_vYwq50MTFqyedLUrT_jg9xM=.b4af8e96-a721-482e-9588-2cd23aaff3f8@github.com> > This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. > > For example, it's needed to execute the following command on Windows: > `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` > it's equal to: > `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` > > While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. > > private static String unQuote(String str) { > .. > if (str.endsWith("\\"")) { > return str; // not properly quoted, treat as unquoted > } > .. > } > > > that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. > As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: > > pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test > (jdk.lang.Process.allowAmbiguousCommands = true) > pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test > (jdk.lang.Process.allowAmbiguousCommands = false) > > > Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: Add test for JDK-8282008 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7504/files - new: https://git.openjdk.java.net/jdk/pull/7504/files/721d4023..6a2c82f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7504&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7504&range=00-01 Stats: 88 lines in 1 file changed: 88 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7504.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7504/head:pull/7504 PR: https://git.openjdk.java.net/jdk/pull/7504 From rriggs at openjdk.java.net Fri Feb 18 16:18:49 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 18 Feb 2022 16:18:49 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true In-Reply-To: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> Message-ID: On Fri, 18 Feb 2022 15:29:34 GMT, Roger Riggs wrote: > In some Linux configurations, the Linux home directory provided by getpwent is not usable. > The value of the system property `user.home` should fallback to the value of $HOME > if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. > > If $HOME is undefined or empty, the value of the getpwent.user_home is retained. > > There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 > > The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. I'm uncertain whether the fallback should only be done on Linux to cover the `systemd` case and Docker. The need for a fallback seems less applicable on macOs, but since $HOME is usually set to the same value, may be harmless. ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From lancea at openjdk.java.net Fri Feb 18 16:28:55 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 18 Feb 2022 16:28:55 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 12:09:53 GMT, Alan Bateman wrote: > The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array. Those instructions are already in the comments for the constant `SIGNED_VALID_ENTRY_NAME` ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From rriggs at openjdk.java.net Fri Feb 18 16:35:50 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 18 Feb 2022 16:35:50 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v2] In-Reply-To: <-wRMY6KNRPss8NEnURu_vYwq50MTFqyedLUrT_jg9xM=.b4af8e96-a721-482e-9588-2cd23aaff3f8@github.com> References: <-wRMY6KNRPss8NEnURu_vYwq50MTFqyedLUrT_jg9xM=.b4af8e96-a721-482e-9588-2cd23aaff3f8@github.com> Message-ID: On Fri, 18 Feb 2022 16:07:29 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add test for JDK-8282008 @omikhaltsova Please take another look at the comment above. The fix incorrectly allows a final double-quote to be escaped, resulting in unbalanced quotes and possibly allowing an argument to be joined with the next. The recommendation is for the application to NOT add quotes to arguments and allow ProcessBuilder to do the necessary quoting. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From alanb at openjdk.java.net Fri Feb 18 17:08:55 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 17:08:55 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 16:25:30 GMT, Lance Andersen wrote: > > The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array. > > Those instructions are already in the comments for the constant `SIGNED_VALID_ENTRY_NAME` That's the keytool command to sign the JAR. What I meant is the complete steps to create the JAR file, sign it, and then create the byte array. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Fri Feb 18 17:18:56 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 18 Feb 2022 17:18:56 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:05:53 GMT, Alan Bateman wrote: > > > The updates changes to ZipFile/JarFile look okay. I don't have time to study the test too closely right now but it will need to include instructions on how to re-create the signed JAR that is stored in the byte array. > > > > > > Those instructions are already in the comments for the constant `SIGNED_VALID_ENTRY_NAME` > > That's the keytool command to sign the JAR. What I meant is the complete steps to create the JAR file, sign it, and then create the byte array. The `createByteArray` method which is at the bottom of the test class documents how the byte array can be made from a jar. The signed jar is created using the steps defined in `SIGNED_VALID_ENTRY_NAME` from the jar derived from `VALID_ENTRY_NAME` If you feel there is still something lacking for documentation, I can certainly make another pass clarify/add it, but I tried to cover the steps (but I also understand what might be obvious to me might not be as obvious as I thought). ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From omikhaltcova at openjdk.java.net Fri Feb 18 17:21:48 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 18 Feb 2022 17:21:48 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: > This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. > > For example, it's needed to execute the following command on Windows: > `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` > it's equal to: > `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` > > While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. > > private static String unQuote(String str) { > .. > if (str.endsWith("\\"")) { > return str; // not properly quoted, treat as unquoted > } > .. > } > > > that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. > As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: > > pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test > (jdk.lang.Process.allowAmbiguousCommands = true) > pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test > (jdk.lang.Process.allowAmbiguousCommands = false) > > > Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: Add a new line to the end of test file for JDK-8282008 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7504/files - new: https://git.openjdk.java.net/jdk/pull/7504/files/6a2c82f9..0eceecac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7504&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7504&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7504.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7504/head:pull/7504 PR: https://git.openjdk.java.net/jdk/pull/7504 From alanb at openjdk.java.net Fri Feb 18 17:23:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 17:23:49 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:15:17 GMT, Lance Andersen wrote: > If you feel there is still something lacking for documentation, I can certainly make another pass clarify/add it, but I tried to cover the steps (but I also understand what might be obvious to me might not be as obvious as I thought). Yes, I think clear instructions are important to have for tests like this. It doesn't need much but what you know is scattered across a method and a comment on a byte array, just not clear/easy. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From omikhaltcova at openjdk.java.net Fri Feb 18 17:28:54 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Fri, 18 Feb 2022 17:28:54 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add a new line to the end of test file for JDK-8282008 Roger, thanks for your comments! But in this case how it is possible to present a path ending with '\' and including a space inside? ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From rriggs at openjdk.java.net Fri Feb 18 17:41:52 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 18 Feb 2022 17:41:52 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: <5fypkJQxWfsfHO2WeXWlp-aACX-9btgOrLkb5BkcAJ4=.179dcbc4-f2e0-45b3-830e-6be0af11df03@github.com> On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add a new line to the end of test file for JDK-8282008 ProcessBuilder handles the quoting of arguments with spaces. In your QuotedArguments.java, just remove the quotes from the first argument to CheckCase: ```CheckCase[] cases = { new CheckCase("C:\\Program Files\\Git\", "C:\\Program Files\\Git\", "true"), new CheckCase("C:\\Program Files\\Git\", "C:\\Program Files\\Git\", "false") }; That worked for me using openjdk version "17.0.2". Problems with knowing what and if to quote go back a long time. I'm working on a new [JEP](https://bugs.openjdk.java.net/browse/JDK-8263697) to handle more of the cases without application intervention. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From naoto at openjdk.java.net Fri Feb 18 17:48:53 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 18 Feb 2022 17:48:53 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. The purpose of this test is to check the default encoding for the environments known to be correct. Thus those test values are hardcoded. Replacing it with `System.getProperty("native.encoding")` would introduce some uncertainty because the test may not be run under the C locale. As to the suggestion to canonicalize `native.encoding`, it was introduced for users to obtain the encoding name that used to be the value of `file.encoding` prior to JEP 400. So normalizing it to the canonicalized name, such as `ANSI_X3.4-1968` to `US-ASCII` would somewhat defy the purpose. Now, back to the test case, the test blindly assumes that C locale's default code set is `US-ASCII` which is not correct (as in this issue), it only requires Portable Character Set, which US-ASCII/ISO-8859-1/UTF-8 all suffice. I would change the test to check if the platform is AIX, then check the charset for COMPAT to ISO-8859-1. ------------- PR: https://git.openjdk.java.net/jdk/pull/7525 From darcy at openjdk.java.net Fri Feb 18 17:59:56 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 18 Feb 2022 17:59:56 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v9] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 14:53:42 GMT, Roger Riggs wrote: > The Location enum does give more control over the places modifiers can occur and be extended as needed. But its unfortunate there's no (simple/obvious) mapping to the other concepts of the corresponding types, such as ElementType or Class/Method/Constructor. I don't have a clear use case for the mapping, so maybe its just a rough edge that can be smoothed out when AccessFlags gets used. A near-future iteration of this work will include functionality to map from an integer to a set of access flags. Since there are flags with the same mask position, such as volatile and bridge, some location context is needed to know which mapping 0x0000_0040 -> BRIDGE 0x0000_0040 -> VOLATILE is correct and desired in context. The Location enum could include a condensed primer on how Java programs get compiled into class files (constructors are just weird static methods to the VM!), but I didn't think that was necessary for the initial version and the included comment "Just stub-out constant descriptions for now." was meant to imply more detailed discussion would be forthcoming. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Fri Feb 18 18:02:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 18 Feb 2022 18:02:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v14] In-Reply-To: <9c0GGkfvXLZGQoxBrvtVQ0sI_RvVsGsBBcI6AluPZCQ=.02f0af77-c4da-4838-891b-3b6d66c40995@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <9c0GGkfvXLZGQoxBrvtVQ0sI_RvVsGsBBcI6AluPZCQ=.02f0af77-c4da-4838-891b-3b6d66c40995@github.com> Message-ID: On Thu, 17 Feb 2022 05:45:54 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> fix test > > OK, good progress. Yes, leaving ConcurrentHashMap to another PR is fine. > > Do the changes to Class.java and the enum optimal capacity test need to be part of this PR? They seem unrelated. It's not clear to me that test is actually testing anything useful; it's just testing the same computation a couple different ways. > > The test seems reasonable enough and is a good start. There are a number of things that could be improved about it though. > > 1) It should probably be a TestNG test. This will allow you to use a DataProvider and also use TestNG assertions. > > 2) There are 12 test cases here, which seems amenable to using a DataProvider. You could try to make a little "combo" test that combines the three classes with the four ways of creating them, but it might be difficult to do that without using reflection. It might be easier to write a table with 12 cases, even if there is a bit of repetition. > > 3) Instead of writing reflective code to create the maps, it's probably easier to use suppliers that create the maps into the desired state. Each of the 12 test cases should have a lambda that does the creation. The test method then invokes the supplier and makes its assertions over the resulting map instance. > > 4) The `fill12` method can be used in an expression if it returns its argument. > > 5) Create a map with 12 entries as part of the test setup, and then just use it as the copy constructor argument. > > Note, I'll be on vacation next week, so there will be a gap in my responses during that time. @stuart-marks please have a look again, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From alanb at openjdk.java.net Fri Feb 18 18:03:52 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Feb 2022 18:03:52 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true In-Reply-To: References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> Message-ID: <9kW8deP8Z-lWogxlgSJ_a0X6rlDx4Cie9fKqosv1gos=.f141ee6c-1c3e-4130-a134-c1c553f681d5@github.com> On Fri, 18 Feb 2022 16:15:18 GMT, Roger Riggs wrote: > I'm uncertain whether the fallback should only be done on Linux to cover the `systemd` case and Docker. > The need for a fallback seems less applicable on macOs, but since $HOME is usually set to the same value, may be harmless. I think what you have is okay because it is only used when getpwent doesn't return something useful. It would add complexity if you tried to limit it systemd or containers. I can't think of scenarios on macOS that might trigger the fallback, but it's not a bad fallback to have there too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From alexey.semenyuk at oracle.com Fri Feb 18 18:33:11 2022 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 18 Feb 2022 13:33:11 -0500 Subject: JDK-17: Wndows jpackage destination directory not writable In-Reply-To: References: <6e1e209f-1919-c98a-0b86-0a6453ce5bba@oracle.com> Message-ID: <06cd2184-5567-76e5-dba3-eb7fd628582c@oracle.com> Hi Sverre, Interesting, I don't see changes in jpackage code related to the issue. In particular jdk.jpackage.internal.IOUtils.writableOutputDir() function is the same in JDK14, JDK17, and mainline. - Alexey On 2/18/2022 8:31 AM, Sverre Moe wrote: > I executed our JDK11 docker image, which works fine with JDK11 and JDK14 > (for jpackage support). > Then I installed the JDK17 MSI package, changed JAVA_HOME and PATH. > Building our application now with JDK17 it still cannot write to the > "build/native" jpackage output directory. > > Leads me to conclude something has changed in jpackage between JDK14 and > JDK17. > I modified my gradle configuration, to use jpackage from JDK14 when > packaging my JDK17 built application. > It works using JDK14 jpackage to package our JDK17 application. > > Using the JDK17 jpackage directly in Windows works fine. It is only in the > Docker container that it does not work. > > /Sverre > > > > tir. 5. okt. 2021 kl. 11:55 skrev Sverre Moe: > >> I ran cacls after the failed jpackage. >> >> C:\temp\my-javafx-application>cacls build >> C:\temp\my-javafx-application\build F >> CREATOR OWNER:(OI)(CI)(IO)F >> R >> CREATOR GROUP:(OI)(CI)(IO)R >> Everyone:(OI)(CI)R >> >> C:\temp\my-javafx-application>cacls build\native >> C:\temp\my-javafx-application\build\native F >> CREATOR OWNER:(OI)(CI)(IO)F >> R >> CREATOR GROUP:(OI)(CI)(IO)R >> Everyone:(OI)(CI)R >> >> >> As cacls was deprecated it suggested to use icacls instead: >> >> C:\temp\my-javafx-application>icacls build >> build S-1-5-21-406077803-2019195645-689573112-1003:(I)(F) >> CREATOR OWNER:(I)(OI)(CI)(IO)(F) >> S-1-5-21-406077803-2019195645-689573112-513:(I)(RX) >> CREATOR GROUP:(I)(OI)(CI)(IO)(RX) >> Everyone:(I)(OI)(CI)(RX) >> >> Successfully processed 1 files; Failed processing 0 files >> >> C:\temp\my-javafx-application>icacls build\native >> build\native S-1-5-83-1-1537791174-1084404783-2478187907-2577323605:(I)(F) >> CREATOR OWNER:(I)(OI)(CI)(IO)(F) >> S-1-5-83-0:(I)(RX) >> CREATOR GROUP:(I)(OI)(CI)(IO)(RX) >> Everyone:(I)(OI)(CI)(RX) >> >> Successfully processed 1 files; Failed processing 0 files >> >> Running attrib on the workspace, and build dirs: >> >> C:\Temp\my-javafx-application>attrib >> A C:\Temp\my-javafx-application\.description >> A C:\Temp\my-javafx-application\.gitignore >> A C:\Temp\my-javafx-application\build.gradle >> A C:\Temp\my-javafx-application\gradle.properties >> A C:\Temp\my-javafx-application\gradlew >> A C:\Temp\my-javafx-application\gradlew.bat >> A C:\Temp\my-javafx-application\Jenkinsfile >> A C:\Temp\my-javafx-application\packager.gradle >> A C:\Temp\my-javafx-application\README.adoc >> A C:\Temp\my-javafx-application\settings.gradle >> A C:\Temp\my-javafx-application\spotless.gradle >> >> C:\Temp\my-javafx-application>attrib build >> C:\Temp\my-javafx-application\build >> >> C:\Temp\meos-dashboard>attrib build\native >> C:\Temp\my-javafx-application\build\native >> >> /Sverre >> >> tir. 5. okt. 2021 kl. 10:41 skrev Alan Bateman: >> >>> On 05/10/2021 08:54, Sverre Moe wrote: >>>> With JDK 17, jpackage fails to write to the destination directory on >>>> Windows. >>>> >>>> It worked fine with JDK 11 (with jpackage from JDK14) and Docker. >>>> >>>> Only happens on Windows docker. Running directly on WIndows it works >>> with >>>> JDK 17. >>>> >>>> What has changed with jpackage that it no longer can write to the >>>> destination directory when running in Docker? >>>> Is it a regression/bug with jpackage? >>>> >>> I don't know what has changed in jpackage, maybe it didn't check for >>> write access previously. However, the error you are seeing suggests >>> there may be a lower-level issue, maybe a driver issue. It would be >>> useful if you could print out the DACL (using cacls is okay) and the DOS >>> attributes. >>> >>> -Alan >>> From smarks at openjdk.java.net Fri Feb 18 18:35:53 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Feb 2022 18:35:53 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v19] In-Reply-To: <1AW2iddnLOTU-np_YhZgGuFx9MLgl0yX4qKtPFiFELM=.4f4c8a42-1ffa-4dfe-acb0-df1487d6a49c@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <1AW2iddnLOTU-np_YhZgGuFx9MLgl0yX4qKtPFiFELM=.4f4c8a42-1ffa-4dfe-acb0-df1487d6a49c@github.com> Message-ID: <7n0zRL2aNC--r9BVCQ0whdD7h_Auy091iVRe4t4tFEM=.f3b8b1c8-7fe0-4d8b-87ff-b5dc839fb7c0@github.com> On Fri, 18 Feb 2022 15:29:25 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - migrate to junit > - change threshold Sigh. (I'm sighing at the author of the Enum/ConstantDirectoryOptimalCapacity.java test, not you.) What a mess. See https://bugs.openjdk.java.net/browse/JDK-8282120 which I just filed. The broken test and the OptimalCapacity utilities are mostly useless, so the change to that test and Class.java should be removed this PR, and the test added to the Problem List so it doesn't get run anymore. See test/jdk/ProblemList.txt and add an entry for the now-failing test, with a reference to 8282120. I don't think I'll have time to look at the junit rewrite and to run this through our internal build/test system today, so sorry, this may need to wait a week. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 18 18:40:57 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 18:40:57 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding In-Reply-To: References: Message-ID: <3tbGa5ZKmSY0-ptDRQL6mtbtcY-v3j6sC7SJBz5hsJk=.1420f8ef-d667-415e-8441-e6032662387b@github.com> On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. Thanks for your feedback Naoto. I agree it's a little odd to test the way I proposed above, as it introduces uncertainty as you mentioned, as well as other issues like both native.encoding and Charsets.defaultCharset() being wrong, but being wrong in the same way. The main part of testing this way was the quoted line from JEP-400 (of which I recognize you are an author). Maybe I'm being too literal; in my testing the encodings match, even if the names are aliases of the ones I expect. In addition, you have a good point about the purpose of the COMPAT flag being compatibility. I agree that it's not really appropriate to change the values of native.encoding to the canonical ones. I was feeling torn between the proposed option and alternative, and your feedback definitely sways me towards the alternative. I'll change this PR to simply add an exception to the test for AIX. ------------- PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Fri Feb 18 18:44:32 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 18:44:32 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v2] In-Reply-To: References: Message-ID: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. Tyler Steele has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7525/files - new: https://git.openjdk.java.net/jdk/pull/7525/files/fd06a608..83b6e4bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7525/head:pull/7525 PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Fri Feb 18 18:44:33 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 18:44:33 GMT Subject: Withdrawn: 8282042: [testbug] FileEncodingTest.java depends on default encoding In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Fri Feb 18 18:49:28 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 18:49:28 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v3] In-Reply-To: References: Message-ID: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Changes FileEncodingTest to include hardcoded value for AIX ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7525/files - new: https://git.openjdk.java.net/jdk/pull/7525/files/83b6e4bc..ff2918d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7525/head:pull/7525 PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Fri Feb 18 18:53:43 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 18 Feb 2022 18:53:43 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v20] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: revert unrelated changes and add it to ProblemList.txt https://bugs.openjdk.java.net/browse/JDK-8282120 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/aa599698..182c22d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=18-19 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 18 18:59:26 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 18:59:26 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v4] In-Reply-To: References: Message-ID: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Minor fixes: Removes unused Booleans, adds varname ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7525/files - new: https://git.openjdk.java.net/jdk/pull/7525/files/ff2918d6..9341ecb7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7525/head:pull/7525 PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Fri Feb 18 19:00:52 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 18 Feb 2022 19:00:52 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v19] In-Reply-To: <7n0zRL2aNC--r9BVCQ0whdD7h_Auy091iVRe4t4tFEM=.f3b8b1c8-7fe0-4d8b-87ff-b5dc839fb7c0@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <1AW2iddnLOTU-np_YhZgGuFx9MLgl0yX4qKtPFiFELM=.4f4c8a42-1ffa-4dfe-acb0-df1487d6a49c@github.com> <7n0zRL2aNC--r9BVCQ0whdD7h_Auy091iVRe4t4tFEM=.f3b8b1c8-7fe0-4d8b-87ff-b5dc839fb7c0@github.com> Message-ID: On Fri, 18 Feb 2022 18:32:31 GMT, Stuart Marks wrote: > Sigh. (I'm sighing at the author of the Enum/ConstantDirectoryOptimalCapacity.java test, not you.) What a mess. See https://bugs.openjdk.java.net/browse/JDK-8282120 which I just filed. The broken test and the OptimalCapacity utilities are mostly useless, so the change to that test and Class.java should be removed this PR, and the test added to the Problem List so it doesn't get run anymore. See test/jdk/ProblemList.txt and add an entry for the now-failing test, with a reference to 8282120. Got it. I would have a try. > I don't think I'll have time to look at the junit rewrite and to run this through our internal build/test system today, so sorry, this may need to wait a week. OK, see you next week~ ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 18 19:06:28 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 19:06:28 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v5] In-Reply-To: References: Message-ID: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. Tyler Steele 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: Changes FileEncodingTest to include hardcoded value for AIX ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7525/files - new: https://git.openjdk.java.net/jdk/pull/7525/files/9341ecb7..56f01452 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=03-04 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7525/head:pull/7525 PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Fri Feb 18 19:08:47 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 18 Feb 2022 19:08:47 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v20] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 18 Feb 2022 18:53:43 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert unrelated changes and add it to ProblemList.txt > > https://bugs.openjdk.java.net/browse/JDK-8282120 I found some other interesting thing using the rewritten test (about IdentityHashMap, also memory related problem), but would investigate it tomorrow. Too late in my time zone today. Would inform you once I have finished my investigation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Feb 18 19:09:52 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 19:09:52 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v5] In-Reply-To: References: Message-ID: <799w__Qrjy7EgZRY9lxCPT1aOUb7YSCbShhN2o3UQek=.05291e6b-cc70-49a9-9fd7-bdbd97e02b85@github.com> On Fri, 18 Feb 2022 19:06:28 GMT, Tyler Steele wrote: >> FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. >> >> According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. >> >> With these changes however, my test systems continue to fail. >> >> - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 >> - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> >> Note that the expected value is populated from native.encoding. >> >> This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). >> >> --- >> >> A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. >> >> Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. > > Tyler Steele 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: > > Changes FileEncodingTest to include hardcoded value for AIX The test now passes on AIX, and Linux/Z. So I believe this change can be merged once reviewed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7525 From naoto at openjdk.java.net Fri Feb 18 19:25:53 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 18 Feb 2022 19:25:53 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v5] In-Reply-To: References: Message-ID: <-aMtivLDt4SecFCMcGDnY7KuPYNcqo_MeVJMsdkYwTQ=.2289d0a8-93dc-41b4-b902-bf6e6249dff2@github.com> On Fri, 18 Feb 2022 19:06:28 GMT, Tyler Steele wrote: >> FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. >> >> According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. >> >> With these changes however, my test systems continue to fail. >> >> - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 >> - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> >> Note that the expected value is populated from native.encoding. >> >> This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). >> >> --- >> >> A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. >> >> Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. > > Tyler Steele 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: > > Changes FileEncodingTest to include hardcoded value for AIX Changes look good. Nit: Please add the issue # to the `@bug` tag, and modify the copyright year to `2021, 2022`. ------------- Changes requested by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7525 From lancea at openjdk.java.net Fri Feb 18 19:26:45 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 18 Feb 2022 19:26:45 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v5] In-Reply-To: References: Message-ID: > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Add additional comments describing how the jars are created ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/d5cf8db8..490c986d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=03-04 Stats: 29 lines in 1 file changed: 28 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Fri Feb 18 19:26:46 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 18 Feb 2022 19:26:46 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:20:26 GMT, Alan Bateman wrote: > > If you feel there is still something lacking for documentation, I can certainly make another pass clarify/add it, but I tried to cover the steps (but I also understand what might be obvious to me might not be as obvious as I thought). > > Yes, I think clear instructions are important to have for tests like this. It doesn't need much but what you know is scattered across a method and a comment on a byte array, just not clear/easy. Ok, thank you for the feedback. I just pushed a change with additional comments on the jar creation which hopefully will address your input above. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Fri Feb 18 19:42:30 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 18 Feb 2022 19:42:30 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v6] In-Reply-To: References: Message-ID: <13Lmzuuv8WyY51hz-z3_N8Pk_8-r25lULVsVCnBfrWM=.c0124f95-234c-45d7-8855-917691e6bd86@github.com> > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: remove trailing space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/490c986d..818c2857 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348 From duke at openjdk.java.net Fri Feb 18 19:50:33 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 19:50:33 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v6] In-Reply-To: References: Message-ID: <3NRF33yXHYPB3h3PY5JvJvfG4ee-3gRYS1VyPvfnhRw=.c626e278-0d11-494b-9eef-265ff33def03@github.com> > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Makes sm changes requested by Naoto ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7525/files - new: https://git.openjdk.java.net/jdk/pull/7525/files/56f01452..2a8651b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7525/head:pull/7525 PR: https://git.openjdk.java.net/jdk/pull/7525 From lancea at openjdk.java.net Fri Feb 18 19:54:23 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 18 Feb 2022 19:54:23 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v7] In-Reply-To: References: Message-ID: > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: remove extra '}' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/818c2857..839d99f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348 From naoto at openjdk.java.net Fri Feb 18 20:07:53 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 18 Feb 2022 20:07:53 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v6] In-Reply-To: <3NRF33yXHYPB3h3PY5JvJvfG4ee-3gRYS1VyPvfnhRw=.c626e278-0d11-494b-9eef-265ff33def03@github.com> References: <3NRF33yXHYPB3h3PY5JvJvfG4ee-3gRYS1VyPvfnhRw=.c626e278-0d11-494b-9eef-265ff33def03@github.com> Message-ID: <3EOpejJWkYE_4_jJG2V8WCct8qVVuePK0MRR0XfeqdU=.278a4dc2-7b81-4bbc-9184-58787931ada8@github.com> On Fri, 18 Feb 2022 19:50:33 GMT, Tyler Steele wrote: >> FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. >> >> According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. >> >> With these changes however, my test systems continue to fail. >> >> - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 >> - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> >> Note that the expected value is populated from native.encoding. >> >> This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). >> >> --- >> >> A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. >> >> Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Makes sm changes requested by Naoto test/jdk/java/lang/System/FileEncodingTest.java line 2: > 1: /* > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. The year should be `2021, 2022`. (year of inception must be preserved) ------------- PR: https://git.openjdk.java.net/jdk/pull/7525 From raffaello.giulietti at gmail.com Fri Feb 18 20:18:22 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 18 Feb 2022 21:18:22 +0100 Subject: Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec In-Reply-To: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> References: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> Message-ID: Hello, to overcome some of the problems with parsing and generating Windows command lines, I implemented two classes [1] that attempt to provide a more sophisticated solution. To be clear, they do not create processes or launch programs. They only serve as a parser and an "escaper". Currently, they are completely outside the OpenJDK codebase to avoid interfering with the current behavior. The intent is to have a concrete basis for a more thorough discussion and some code to experiment with. Later, the code can be integrated into OpenJDK if so desired. Both classes perform a straightforward, one-pass left-to-right processing (each character is read only once) without back-patching. They only make use String, StringBuilder and ArrayList. Two important technical aspects must be kept in mind when later using the outcomes of these classes to start new processes on Windows. Both are related in the interplay between the Windows function CreateProcess() [2] and the C/C++ runtime [3]: * A program can parse the command line as it deems useful. There are no hard rules, only conventions. These classes assume that the program denoted on the command line will perform parsing as done by the Windows C/C++ runtime conventions [3]. If this assumption is invalid, there's no point in using these classes. * In particular, the "shell" cmd.exe parses the command line in a different way. While not currently exposed in these classes, it would be easy to add a specific parser and escaper for cmd.exe as well. * Absent the application name, the initial section of the command line passed to CreateProcess() is parsed by it to locate the program to launch. The way it parses the program part when it is unquoted is too cumbersome and depends on the content of the filesystem [2]. Trying to re-implement this parsing would introduce a potential source of troubles that could later lead in launching an unintended program. Thus, for simplification and caution, these classes assume that the program part is always quoted, throwing otherwise. Greetings Raffaello ---- [1] https://github.com/rgiulietti/experiments [2] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa [3] https://docs.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments On 2022-01-20 19:05, Roger Riggs wrote: > A JEP to Improve safety of process launch by ProcessBuilder and > Runtime.exec on Windows[1]. > > Argument encoding errors have been problematic on Windows systems due to > improperly quoted command arguments. > > The idea is to tighten up quoting and encoding of command line arguments. > > Comments appreciated,? Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8263697 From mandy.chung at oracle.com Fri Feb 18 20:36:34 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Feb 2022 12:36:34 -0800 Subject: Accessing the BCI of Throwable's StackTraceElement In-Reply-To: References: Message-ID: <763e5eb3-91cb-6ea6-7c3c-bb7d5eb9caf1@oracle.com> On 2/18/22 3:42 AM, Eirik Bj?rsn?s wrote: > Hi, > > Currently, StackWalker.StackFrame::getByteCodeIndex provides a way to get > the BCI of stack frames during a stack walk. > > Similarly, it might be useful to get the BCI when inspecting a Throwable's > StackTraceElements. This does however not seem possible, given that > StackTraceElement currently does not expose the BCI. (It exposes the > lineNumber, but that's not useful for my current use case). > > On another note, it seems like calling Throwable.getStackTrace() would be a > wasteful way to just find the BCI of the top stack frame. Would be really > nice if one could do a StackWalk with a Throwable as input, which I imagine > should work a lot more efficiently. > > (My use case here is to attribute any exception to a BCI in the same method > such that I don't need to instrument code to track the BCI myself). > > So I guess I have two questions: > > 1: Would it be reasonable to add a getByteCodeIndex method to > StackTraceElement? Or perhaps even make StackTraceElement implement > StackWalker.StackFrame? It's possible to consider adding a method in StackTraceElement to return BCI but I think having StackWalker to take a Throwable may be a better solution. > 2: Could the StackWalker API be suitable for walking not just the stack of > current threads, but also the stacks of Throwables? Was this discussed > during the development of StackWalker for Java 9? Yes it's tracked by JDK-8189752 [1] and one idea is to provide a way to traverse the backtrace of a Throwable. [1] https://bugs.openjdk.java.net/browse/JDK-8189752 From duke at openjdk.java.net Fri Feb 18 20:54:24 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 20:54:24 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v7] In-Reply-To: References: Message-ID: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Fixes copyright header error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7525/files - new: https://git.openjdk.java.net/jdk/pull/7525/files/2a8651b8..ac38c8f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7525&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7525/head:pull/7525 PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Fri Feb 18 20:54:27 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 20:54:27 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v6] In-Reply-To: <3EOpejJWkYE_4_jJG2V8WCct8qVVuePK0MRR0XfeqdU=.278a4dc2-7b81-4bbc-9184-58787931ada8@github.com> References: <3NRF33yXHYPB3h3PY5JvJvfG4ee-3gRYS1VyPvfnhRw=.c626e278-0d11-494b-9eef-265ff33def03@github.com> <3EOpejJWkYE_4_jJG2V8WCct8qVVuePK0MRR0XfeqdU=.278a4dc2-7b81-4bbc-9184-58787931ada8@github.com> Message-ID: On Fri, 18 Feb 2022 20:04:25 GMT, Naoto Sato wrote: >> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: >> >> Makes sm changes requested by Naoto > > test/jdk/java/lang/System/FileEncodingTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. > > The year should be `2021, 2022`. (year of inception must be preserved) Oops. Thanks for catching that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7525 From naoto at openjdk.java.net Fri Feb 18 21:09:52 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 18 Feb 2022 21:09:52 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v7] In-Reply-To: References: Message-ID: <1jZyXqgLAeaWHXr8PaMzzwALCMM2DfucjR1zJTJPEKY=.8b620a06-b21e-4dc6-90d5-37560ad2f40a@github.com> On Fri, 18 Feb 2022 20:54:24 GMT, Tyler Steele wrote: >> FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. >> >> According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. >> >> With these changes however, my test systems continue to fail. >> >> - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 >> - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> >> Note that the expected value is populated from native.encoding. >> >> This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). >> >> --- >> >> A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. >> >> Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Fixes copyright header error Looks good. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Fri Feb 18 22:09:51 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Feb 2022 22:09:51 GMT Subject: RFR: 8282042: [testbug] FileEncodingTest.java depends on default encoding [v7] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 20:54:24 GMT, Tyler Steele wrote: >> FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. >> >> According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. >> >> With these changes however, my test systems continue to fail. >> >> - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 >> - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 >> >> Note that the expected value is populated from native.encoding. >> >> This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). >> >> --- >> >> A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. >> >> Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Fixes copyright header error > /label remove auto > > Automatic integration is not appropriate and should not be used except in time sensitive cases. It can preempt other reviewers from having a chance to review and comment. Ok. I will avoid using it in the future. I don't have commiter rights, so I was just looking to signal that I am happy for this change to be integrated when it has been reviewed. It seemed to fall under the 'benign changes' category of the `/integrate` command's documentation. If there is other feedback, I am happy to incorporate it ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/7525 From duke at openjdk.java.net Sat Feb 19 05:58:05 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sat, 19 Feb 2022 05:58:05 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline Message-ID: Hi, `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. Should the other `requireNonNull` be `ForceInline` as well? Thank you very much. ------------- Commit messages: - requireNonNull force inline Changes: https://git.openjdk.java.net/jdk/pull/7543/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7543&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282143 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7543/head:pull/7543 PR: https://git.openjdk.java.net/jdk/pull/7543 From alanb at openjdk.java.net Sat Feb 19 11:02:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 19 Feb 2022 11:02:47 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 19:22:27 GMT, Lance Andersen wrote: > Ok, thank you for the feedback. I just pushed a change with additional comments on the jar creation which hopefully will address your input above. It's a bit better but I think it needs a clear step-by-step instructions in a comment before declaration of VALID_ENTRY_NAME to show how the JAR file is created, signed (move the instructions that have been placed on the TestNG setup method), and then converted to the byte array. Further maintainers will thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From duke at openjdk.java.net Sat Feb 19 15:53:20 2022 From: duke at openjdk.java.net (liach) Date: Sat, 19 Feb 2022 15:53:20 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v8] In-Reply-To: References: Message-ID: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. > > This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) liach has updated the pull request incrementally with one additional commit since the last revision: Refine docs, pull members out of the config record ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6889/files - new: https://git.openjdk.java.net/jdk/pull/6889/files/affda902..548946a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=06-07 Stats: 142 lines in 1 file changed: 39 ins; 37 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/6889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889 PR: https://git.openjdk.java.net/jdk/pull/6889 From duke at openjdk.java.net Sat Feb 19 16:06:35 2022 From: duke at openjdk.java.net (liach) Date: Sat, 19 Feb 2022 16:06:35 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v9] In-Reply-To: References: Message-ID: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. > > This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) 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 13 additional commits since the last revision: - Merge branch 'master' into 8261407-reflectionfactory - Whitespace issues - Refine docs, pull members out of the config record - The fast path should always come first. good lesson learned! restore config field comments - Try making the config a record and see if it works - Make config a pojo, move loading code into config class - use peter's model of separate data object - Merge branch 'master' into 8261407-reflectionfactory - Include the stable annotation - Merge branch 'master' into 8261407-reflectionfactory - ... and 3 more: https://git.openjdk.java.net/jdk/compare/4727f4af...e97ea278 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6889/files - new: https://git.openjdk.java.net/jdk/pull/6889/files/548946a7..e97ea278 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6889&range=07-08 Stats: 18722 lines in 492 files changed: 13328 ins; 2982 del; 2412 mod Patch: https://git.openjdk.java.net/jdk/pull/6889.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6889/head:pull/6889 PR: https://git.openjdk.java.net/jdk/pull/6889 From duke at openjdk.java.net Sun Feb 20 03:00:20 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sun, 20 Feb 2022 03:00:20 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v4] In-Reply-To: References: Message-ID: <0Ivebfk2mNR8ME57GX1L5lyhekVjKHqdgZxjDJl2UAM=.3a6a9ebf-4d46-47cd-bc97-ec4a4656e413@github.com> > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with six additional commits since the last revision: - add tests and fix javadoc lint error - Add static function from() and its javadoc - Remove RandomWrapper from jdk.internal.util.random - add RandomWrapper as static nested class - Remove asRandom() from RandomGenerator - Revert "remove tabs" This reverts commit 1bd60648152cbd0ff3ad6c55f015557bedd6da4d. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/ef48bdbd..9f2855ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=02-03 Stats: 381 lines in 4 files changed: 183 ins; 190 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sun Feb 20 03:08:27 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sun, 20 Feb 2022 03:08:27 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v5] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: Remove whitespace and tabs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/9f2855ab..78f55fc5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=03-04 Stats: 22 lines in 1 file changed: 1 ins; 1 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sun Feb 20 03:15:22 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sun, 20 Feb 2022 03:15:22 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: remove missed whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/78f55fc5..5dc0e1ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sun Feb 20 03:15:23 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sun, 20 Feb 2022 03:15:23 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v5] In-Reply-To: References: Message-ID: On Sun, 20 Feb 2022 03:08:27 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > Remove whitespace and tabs Ok so i moved everything to Random.java now, tests were done on RandomTest and they passed ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sun Feb 20 06:43:53 2022 From: duke at openjdk.java.net (liach) Date: Sun, 20 Feb 2022 06:43:53 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6] In-Reply-To: References: Message-ID: On Sun, 20 Feb 2022 03:15:22 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > remove missed whitespace src/java.base/share/classes/java/util/Random.java line 95: > 93: private static class RandomWrapper extends Random implements RandomGenerator { > 94: private final RandomGenerator generator; > 95: private final boolean initialized; Can we create a private or package-private constructor for `Random` for this subclass' constructor to call? The no-arg constructor has some unnecessary calculations, and the `long` constructor calls `setSeed`. A special `Random` constructor for this subclass allows removing this special logic (by not calling `setSeed` at all) and avoid redundant seed initialization. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From aph-open at littlepinkcloud.com Sun Feb 20 16:10:22 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sun, 20 Feb 2022 16:10:22 +0000 Subject: RFR: 8281631: HashMap.putAll can cause redundant space waste [v3] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <870WCTLW8HE34G2RWXn9MQFHJHIJ9k4pkN-7z9s0UhE=.7fb99371-acf9-4ed8-a5ea-9b34e3362801@github.com> Message-ID: <4950ddaa-6575-3647-0fc3-10b894a446db@littlepinkcloud.com> On 2/11/22 19:25, XenoAmess wrote: > On Fri, 11 Feb 2022 18:24:49 GMT, Andrew Haley wrote: > >> Just multiply by 0.75. >> >> On a modern design, floating-point multiply is 4 clocks latency, 4 ops/clock throughput. FP max is 2 clocks latency, conversions int-float and vice versa 3 clocks latency, 4 ops/clock throughput. Long division is 7-9 clocks, 2ops/clock throughput. Shift and add 2 clocks, 2/3 ops/clock througput. Compare is 1 clock, 3 ops/clock throughput, conditional move is 1 clock, 3 ops/clock throughput. >> >> Seems like it's a wash. > > @theRealAph > > no multiply but divide. Well yes, but that doesn't look at all hard to change. > besides, did you count the cost for Math.ceil? it is the heaviest part. Yes. 3 clocks latency, 4 ops/clock throughput. Your hardware may vary. And that instruction does both the ceil() and the float-int conversion. (Having said that, I don't know if we currently generate optimal code for this operation. But of course that can be fixed.) I don't think this is terribly important, but I don't like to see attempts at hand optimization in the standard library. From duke at openjdk.java.net Sun Feb 20 16:20:52 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 16:20:52 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table In-Reply-To: <4950ddaa-6575-3647-0fc3-10b894a446db@littlepinkcloud.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <4950ddaa-6575-3647-0fc3-10b894a446db@littlepinkcloud.com> Message-ID: On Sun, 20 Feb 2022 16:12:08 GMT, Andrew Haley wrote: > I don't think this is terribly important, but I don't like to see attempts at hand optimization in the standard library. OK, we've decided use that Math.ceil() solution. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 18:08:37 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 18:08:37 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with three additional commits since the last revision: - refine test - 1. optimize IdentityHashMap that when calling ::new(Map), do not call map.size() twice but once. 2. delete the this((int) ((1 + m.size()) * 1.1)); as it makes the table over-allocate when size = 19. - refine test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/182c22d7..6d0ab0ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=19-20 Stats: 55 lines in 2 files changed: 37 ins; 3 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 18:08:38 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 18:08:38 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 18:04:50 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with three additional commits since the last revision: > > - refine test > - 1. optimize IdentityHashMap that when calling ::new(Map), do not call map.size() twice but once. > 2. delete the this((int) ((1 + m.size()) * 1.1)); as it makes the table over-allocate when size = 19. > - refine test src/java.base/share/classes/java/util/IdentityHashMap.java line 270: > 268: */ > 269: public IdentityHashMap(Map m) { > 270: this(m, m.size()); I actually do not know if this change shall be in this pr, or in a new issue. But the original codes can cause IdentityHashMap to over-allocate at size == 19. @stuart-marks what do you think about this? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 18:11:51 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 18:11:51 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 18:03:07 GMT, XenoAmess wrote: >> XenoAmess has updated the pull request incrementally with three additional commits since the last revision: >> >> - refine test >> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call map.size() twice but once. >> 2. delete the this((int) ((1 + m.size()) * 1.1)); as it makes the table over-allocate when size = 19. >> - refine test > > src/java.base/share/classes/java/util/IdentityHashMap.java line 270: > >> 268: */ >> 269: public IdentityHashMap(Map m) { >> 270: this(m, m.size()); > > I actually do not know if this change shall be in this pr, or in a new issue. > But the original codes can cause IdentityHashMap to over-allocate at size == 19. > @stuart-marks what do you think about this? I checked this `(int) ((1 + m.size()) * 1.1)`. It is there when the codes original created there at 2007. I don't thik it reasonable. or is there eveidence it be? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 18:23:49 2022 From: duke at openjdk.java.net (liach) Date: Sun, 20 Feb 2022 18:23:49 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 18:08:37 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with three additional commits since the last revision: > > - refine test > - 1. optimize IdentityHashMap that when calling ::new(Map), do not call map.size() twice but once. > 2. delete the this((int) ((1 + m.size()) * 1.1)); as it makes the table over-allocate when size = 19. > - refine test src/java.base/share/classes/java/util/IdentityHashMap.java line 281: > 279: * @throws NullPointerException if the specified map is null > 280: */ > 281: private IdentityHashMap(Map map, int expectedSize) { Why are you writing a new constructor when you can just change the old call to `this(m.size());`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 18:43:46 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 18:43:46 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 18:20:27 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with three additional commits since the last revision: >> >> - refine test >> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call map.size() twice but once. >> 2. delete the this((int) ((1 + m.size()) * 1.1)); as it makes the table over-allocate when size = 19. >> - refine test > > src/java.base/share/classes/java/util/IdentityHashMap.java line 281: > >> 279: * @throws NullPointerException if the specified map is null >> 280: */ >> 281: private IdentityHashMap(Map map, int expectedSize) { > > Why are you writing a new constructor when you can just change the old call to `this(m.size());`? @liach because I don't like to call m.size() twice. the original codes did so: one call at the `public IdentityHashMap(Map map)` , and the second inside of `putAll`. well in most Map implementations `size()` seems O1, and returns a single int number field, but it actually defers in some Map implementations. But java grammar do not allow me to make a local variable before calling constructor in a constructor. In other words, `this()` must be the first line in a constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 18:43:46 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 18:43:46 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 18:38:35 GMT, XenoAmess wrote: >> src/java.base/share/classes/java/util/IdentityHashMap.java line 281: >> >>> 279: * @throws NullPointerException if the specified map is null >>> 280: */ >>> 281: private IdentityHashMap(Map map, int expectedSize) { >> >> Why are you writing a new constructor when you can just change the old call to `this(m.size());`? > > @liach because I don't like to call m.size() twice. > the original codes did so: one call at the `public IdentityHashMap(Map map)` , and the second inside of `putAll`. > well in most Map implementations `size()` seems O1, and returns a single int number field, but it actually defers in some Map implementations. > But java grammar do not allow me to make a local variable before calling constructor in a constructor. > In other words, `this()` must be the first line in a constructor. and adding a private constructor should not cause any trouble I guess? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 18:47:53 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 18:47:53 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 18:20:27 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with three additional commits since the last revision: >> >> - refine test >> - 1. optimize IdentityHashMap that when calling ::new(Map), do not call map.size() twice but once. >> 2. delete the this((int) ((1 + m.size()) * 1.1)); as it makes the table over-allocate when size = 19. >> - refine test > > src/java.base/share/classes/java/util/IdentityHashMap.java line 281: > >> 279: * @throws NullPointerException if the specified map is null >> 280: */ >> 281: private IdentityHashMap(Map map, int expectedSize) { > > Why are you writing a new constructor when you can just change the old call to `this(m.size());`? > @liach implementations `size()` seems O1, and returns a single int number field, but it actually defers in some Map implementations. @liach for example, in ConcurrentSkipListMap and ConcurrentHashMap, `size()` function is far complicated than reading a field, thus calling it twice meaninglessly is not a wise choice. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 19:14:52 2022 From: duke at openjdk.java.net (liach) Date: Sun, 20 Feb 2022 19:14:52 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 18:08:24 GMT, XenoAmess wrote: > I don't thik it reasonable. or is there eveidence it be? If this map is too dense, there may be a lot of hash collisions, and the lookup performance would decrease because this hashmap is linear probe than red-black tree buckets like the regular hash map is using. This was effectively trading some memory for better performance. You should run benchmarks to see how bad the lookup performance degrades after you saves memory used by the hash table. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 19:14:53 2022 From: duke at openjdk.java.net (liach) Date: Sun, 20 Feb 2022 19:14:53 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 18:44:09 GMT, XenoAmess wrote: >> src/java.base/share/classes/java/util/IdentityHashMap.java line 281: >> >>> 279: * @throws NullPointerException if the specified map is null >>> 280: */ >>> 281: private IdentityHashMap(Map map, int expectedSize) { >> >> Why are you writing a new constructor when you can just change the old call to `this(m.size());`? > >> @liach implementations `size()` seems O1, and returns a single int number field, but it actually defers in some Map implementations. > > @liach for example, in ConcurrentSkipListMap and ConcurrentHashMap, `size()` function is far complicated than reading a field, thus calling it twice meaninglessly is not a wise choice. Imo you should just remove the `if (expectedSize == 0)` check than using this somewhat ugly trick to avoid calling `size()` twice (the second call is only used for this relatively useless fast-path, especially for the concurrent collections you refer to) ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 19:22:51 2022 From: duke at openjdk.java.net (liach) Date: Sun, 20 Feb 2022 19:22:51 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 19:08:39 GMT, liach wrote: >>> @liach implementations `size()` seems O1, and returns a single int number field, but it actually defers in some Map implementations. >> >> @liach for example, in ConcurrentSkipListMap and ConcurrentHashMap, `size()` function is far complicated than reading a field, thus calling it twice meaninglessly is not a wise choice. > > Imo you should just remove the `if (expectedSize == 0)` check than using this somewhat ugly trick to avoid calling `size()` twice (the second call is only used for this relatively useless fast-path, especially for the concurrent collections you refer to) In fact, if we do worry about the performance of adding from maps, calling `map.forEach(this::put);` would be a better alternative both in concurrency (as the concurrent map itself takes charage) and object allocation-wise (no allocation of immutable entry objects), but that belongs to another issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 19:45:24 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 19:45:24 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v22] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refine IdentityHashMap ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/6d0ab0ef..e724cc04 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=20-21 Stats: 15 lines in 1 file changed: 0 ins; 11 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 19:45:24 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 19:45:24 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 19:19:16 GMT, liach wrote: >> Imo you should just remove the `if (expectedSize == 0)` check than using this somewhat ugly trick to avoid calling `size()` twice (the second call is only used for this relatively useless fast-path, especially for the concurrent collections you refer to) > > In fact, if we do worry about the performance of adding from maps, calling `map.forEach(this::put);` would be a better alternative both in concurrency (as the concurrent map itself takes charage) and object allocation-wise (no allocation of immutable entry objects), but that belongs to another issue. @liach Hi. please have a look at the latest commit. do you think it be better now? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 19:52:49 2022 From: duke at openjdk.java.net (liach) Date: Sun, 20 Feb 2022 19:52:49 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: <9HiZ4sHd0jS7asQFUxOEK8MNKdfjfb4a8zhntVACDHA=.98ec5cf9-8228-4363-9f61-263f56ddd620@github.com> On Sun, 20 Feb 2022 19:41:22 GMT, XenoAmess wrote: >> In fact, if we do worry about the performance of adding from maps, calling `map.forEach(this::put);` would be a better alternative both in concurrency (as the concurrent map itself takes charage) and object allocation-wise (no allocation of immutable entry objects), but that belongs to another issue. > > @liach Hi. please have a look at the latest commit. > do you think it be better now? Oops, didn't notice there was this helpful `init` method. Does look much more straightforward now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 20:06:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 20:06:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v22] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: On Sun, 20 Feb 2022 19:11:26 GMT, liach wrote: > > I don't thik it reasonable. or is there eveidence it be? > > If this map is too dense, there may be a lot of hash collisions, and the lookup performance would decrease because this hashmap is linear probe than red-black tree buckets like the regular hash map is using. This was effectively trading some memory for better performance. You should run benchmarks to see how bad the lookup performance degrades after you saves memory used by the hash table. @liach 1. `* 1.1` don't seem a very reasonable number for making it non-dense 2. the main reason I argue about is it does not make the resize at `put` and the `map constructor` follow a same resize way. you create an IdentityHashMap `mapA`, put 19 key-value pairs, and build another IdentityHashMap using `mapB = new IdentityHashMap(mapA)`, and you can find mapB's table is twice larger than mapA's. That seems weird and nonsence. I can accept it if mapB's table's length is smaller or equal than mapA, but larger...why need to make it larger when we copy a map? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 20:06:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 20:06:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v22] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> Message-ID: <1x1A2qe5wa8gnE2sjy-pvFBmeixqhsDUtNTe-rE-Q1s=.2e123649-0ae6-41f8-be45-23f586376306@github.com> On Sun, 20 Feb 2022 20:02:09 GMT, XenoAmess wrote: > You should run benchmarks to see how bad the lookup performance degrades after you saves memory used by the hash table. OK, would find some time for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sun Feb 20 20:36:47 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 20 Feb 2022 20:36:47 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v22] In-Reply-To: <1x1A2qe5wa8gnE2sjy-pvFBmeixqhsDUtNTe-rE-Q1s=.2e123649-0ae6-41f8-be45-23f586376306@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> <1x1A2qe5wa8gnE2sjy-pvFBmeixqhsDUtNTe-rE-Q1s=.2e123649-0ae6-41f8-be45-23f586376306@github.com> Message-ID: <053Fv75sYcds75x-_Ae7myLEWxUQZ2WMLvclFIIByds=.de9090e8-5feb-4702-b63c-3eba6532f794@github.com> On Sun, 20 Feb 2022 20:03:07 GMT, XenoAmess wrote: > > You should run benchmarks to see how bad the lookup performance degrades after you saves memory used by the hash table. > > OK, would find some time for it. @liach which jmh test should I run by the way? Or is there some commandline tools for this? I found nothing related to IdentityHashMap under `test/micro` ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Mon Feb 21 06:35:49 2022 From: duke at openjdk.java.net (liach) Date: Mon, 21 Feb 2022 06:35:49 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v22] In-Reply-To: <053Fv75sYcds75x-_Ae7myLEWxUQZ2WMLvclFIIByds=.de9090e8-5feb-4702-b63c-3eba6532f794@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> <1x1A2qe5wa8gnE2sjy-pvFBmeixqhsDUtNTe-rE-Q1s=.2e123649-0ae6-41f8-be45-23f586376306@github.com> <053Fv75sYcds75x-_Ae7myLEWxUQZ2WMLvclFIIByds=.de9090e8-5feb-4702-b63c-3eba6532f794@github.com> Message-ID: <2zpbiZfsQ1hMxhKyepvHP3genrUzzWwrtfaB1suv1cw=.82d11f19-aea3-477b-88f0-ddc12849a538@github.com> On Sun, 20 Feb 2022 20:30:29 GMT, XenoAmess wrote: >>> You should run benchmarks to see how bad the lookup performance degrades after you saves memory used by the hash table. >> >> OK, would find some time for it. > >> > You should run benchmarks to see how bad the lookup performance degrades after you saves memory used by the hash table. >> >> OK, would find some time for it. > > @liach which jmh test should I run by the way? > > Or is there some commandline tools for this? > > I found nothing related to IdentityHashMap under `test/micro` Unfortunately I don't think there is any for now. Maybe someone familiar with the identity hash map can comment on your changes to the expected map size ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Mon Feb 21 07:24:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Mon, 21 Feb 2022 07:24:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v22] In-Reply-To: <2zpbiZfsQ1hMxhKyepvHP3genrUzzWwrtfaB1suv1cw=.82d11f19-aea3-477b-88f0-ddc12849a538@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> <1x1A2qe5wa8gnE2sjy-pvFBmeixqhsDUtNTe-rE-Q1s=.2e123649-0ae6-41f8-be45-23f586376306@github.com> <053Fv75sYcds75x-_Ae7myLEWxUQZ2WMLvclFIIByds=.de9090e8-5feb-4702-b63c-3eba6532f794@github.com> <2zpbiZfsQ1hMxhKyepvHP3genrUzzWwrtfaB1suv1cw=.82d11f19-aea3-477b-88f0-ddc12849a538@github.com> Message-ID: <6O9nZiGSn3BZOCJjgegtOVSt3TV83nkxque70PgO-io=.1047d0e6-666a-4b30-b4eb-4af5683c3412@github.com> On Mon, 21 Feb 2022 06:33:05 GMT, liach wrote: > Unfortunately I don't think there is any for now. @liach Yes. that is why I ask if there be evidence to show `(int) ((1 + m.size()) * 1.1)` be an optimization, but not otherwise. (IMO it is otherwise.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From simonis at openjdk.java.net Mon Feb 21 10:09:51 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 21 Feb 2022 10:09:51 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 08:46:51 GMT, Volker Simonis wrote: > The change looks innocuous so it is probably OK. I would like to kick of our Mach5 runs to see if it shakes out any potential issues. @LanceAndersen , did you manage to get any Mach5 results? Did you find any issues? ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From alanb at openjdk.java.net Mon Feb 21 12:05:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 21 Feb 2022 12:05:50 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: <3fkjjJLZhkVxyyZIdtAgnfSd8M6Ni5Qfu9k3XZb-ITU=.3ec9669b-8913-4e6a-93be-c996aaf0449d@github.com> On Thu, 17 Feb 2022 16:02:42 GMT, Volker Simonis wrote: >> Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). >> >> >> before JDK-8281962 >> ------------------ >> Benchmark (size) Mode Cnt Score Error Units >> InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op >> InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op >> InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op >> >> after JDK-8281962 >> ----------------- >> Benchmark (size) Mode Cnt Score Error Units >> InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op >> InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op >> InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op >> >> >> Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. >> >> As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: >> >> >> int readcount = 0; >> while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { >> outputStream.write(data, 0, bytesRead); >> readCount++; >> } >> if (readCount == 1) { >> return data; // <---- first bytes might be overwritten >> } >> return outputStream.toByteArray(); >> >> >> Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). >> >> [1] https://github.com/spring-projects/spring-framework/issues/27429 >> [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Changed hardcoded constant to JMH parmater and removed non-ASCII chars from comments I think this change is okay. We also have to be super cautious when touching InflaterXXX and friends but I think one is okay. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7492 From aturbanov at openjdk.java.net Mon Feb 21 12:09:27 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Feb 2022 12:09:27 GMT Subject: RFR: 8282188: Unused static field MathContext.DEFAULT_DIGITS Message-ID: <1wrZubD_IPhKTJKupdBIRDQ3-K7JrHCmjobzn2LW6_o=.b5a56106-fc31-41c9-9e79-9656955c6e0d@github.com> 8282188: Unused static field MathContext.DEFAULT_DIGITS ------------- Commit messages: - [PATCH] Remove unused field MathContext.DEFAULT_DIGITS Changes: https://git.openjdk.java.net/jdk/pull/7538/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7538&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282188 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7538.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7538/head:pull/7538 PR: https://git.openjdk.java.net/jdk/pull/7538 From aturbanov at openjdk.java.net Mon Feb 21 12:12:55 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Feb 2022 12:12:55 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: <2CRv7WmchPOB1TD4QQq738ZIJvU5Els5DfhtZv0dQak=.231cd6a0-90f8-4ba2-a984-7e795d73b58b@github.com> On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote: > Method `Class.isAssignableFrom` is often used in form of: > > if (clazz.isAssignableFrom(obj.getClass())) { > Such condition could be simplified to more shorter and performarnt code > > if (clazz.isInstance(obj)) { > > Replacement is equivalent if it's known that `obj != null`. > In JDK codebase there are many such places. > > I tried to measure performance via JMH > > Class integerClass = Integer.class; > Class numberClass = Number.class; > > Object integerObject = 45666; > Object doubleObject = 8777d; > > @Benchmark > public boolean integerInteger_isInstance() { > return integerClass.isInstance(integerObject); > } > > @Benchmark > public boolean integerInteger_isAssignableFrom() { > return integerClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public boolean integerDouble_isInstance() { > return integerClass.isInstance(doubleObject); > } > > @Benchmark > public boolean integerDouble_isAssignableFrom() { > return integerClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberDouble_isInstance() { > return numberClass.isInstance(doubleObject); > } > > @Benchmark > public boolean numberDouble_isAssignableFrom() { > return numberClass.isAssignableFrom(doubleObject.getClass()); > } > > @Benchmark > public boolean numberInteger_isInstance() { > return numberClass.isInstance(integerObject); > } > > @Benchmark > public boolean numberInteger_isAssignableFrom() { > return numberClass.isAssignableFrom(integerObject.getClass()); > } > > @Benchmark > public void numberIntegerDouble_isInstance(Blackhole bh) { > bh.consume(numberClass.isInstance(integerObject)); > bh.consume(numberClass.isInstance(doubleObject)); > } > > @Benchmark > public void integerIntegerDouble_isAssignableFrom(Blackhole bh) { > bh.consume(integerClass.isAssignableFrom(integerObject.getClass())); > bh.consume(integerClass.isAssignableFrom(doubleObject.getClass())); > } > > `isInstance` is a bit faster than `isAssignableFrom` > > Benchmark Mode Cnt Score Error Units > integerDouble_isAssignableFrom avgt 5 1,173 ? 0,026 ns/op > integerDouble_isInstance avgt 5 0,939 ? 0,038 ns/op > integerIntegerDouble_isAssignableFrom avgt 5 2,106 ? 0,068 ns/op > numberIntegerDouble_isInstance avgt 5 1,516 ? 0,046 ns/op > integerInteger_isAssignableFrom avgt 5 1,175 ? 0,029 ns/op > integerInteger_isInstance avgt 5 0,886 ? 0,017 ns/op > numberDouble_isAssignableFrom avgt 5 1,172 ? 0,007 ns/op > numberDouble_isInstance avgt 5 0,891 ? 0,030 ns/op > numberInteger_isAssignableFrom avgt 5 1,169 ? 0,014 ns/op > numberInteger_isInstance avgt 5 0,887 ? 0,016 ns/op First of all, I did check that replace is definitely valid. public static void main(String[] args) { List> classes = List.of(Integer.class, Number.class, Serializable.class, boolean.class, byte.class, short.class, int.class, long.class, char.class, float.class, double.class, Boolean.TYPE, Byte.TYPE, Short.TYPE, Integer.TYPE, Long.TYPE, Character.TYPE, Float.TYPE, Double.TYPE, Boolean.class, Byte.class, Short.class, Integer.class, Long.class, Character.class, Float.class, Double.class); List objects = List.of( new Integer(4), new BigInteger("345345"), new StringBuilder("df"), true, false, (byte)1, (byte)0, (short)1, (short)0, (int)1, (int)0, 1L, 0L, (char)1, (char)0, 1f, 0f, 1d, 0d, new Boolean(true), new Byte((byte)3), new Short((short)4), new Integer(5), new Long(6), new Character((char)7), new Float(8f), new Double(9d), new ClassInstanceAssignableCheck()); for (Class clazz : classes) { System.out.println("Check " + clazz); for (Object object : objects) { checkIsSave(object, clazz); } System.out.println(); } } private static void checkIsSave(@Nonnull Object object, @Nonnull Class clazz) { boolean isInstance = clazz.isInstance(object); boolean assignableFrom = clazz.isAssignableFrom(object.getClass()); System.out.println(" " + object + " of class " + object.getClass().getSimpleName() + " check with " + clazz.getSimpleName() + ": isInstance=" + isInstance + " isAssignableFrom=" + assignableFrom); if (isInstance != assignableFrom) { throw new RuntimeException("Not matched for " + object + " and " + clazz); } } >What client tests have you run that touch the code you are changing ? I did run tier4. It includes all client tests as I know. Some of them failed, when I run in batch. But I rechecked all failed tests one-by-one and they are fine. Can you suggest which test better to run? ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From aturbanov at openjdk.java.net Mon Feb 21 12:19:52 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Feb 2022 12:19:52 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Thu, 20 Jan 2022 01:34:20 GMT, Phil Race wrote: >In short I see insufficient value in the changes here and would prefer you drop the client part so I don't have to worry about it. I think, usage of `isInstance` is much clear for most java developers. Everyone knows about java _instanceof_ operator. And `isInstance` method javadoc is very straight forward: `This method is the dynamic equivalent of the Java language instanceof operator.` Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that: 1. [Wrong isAssignableFrom test when adding Principal to Subject ](https://bugs.openjdk.java.net/browse/JDK-8034820) 2. [isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8254717) 3. [isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8279800) So, it gives all 3 points to prefer isInstance method: it's shorter, it's clearer for most java developers, it's faster. ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From jpai at openjdk.java.net Mon Feb 21 12:49:24 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 21 Feb 2022 12:49:24 GMT Subject: RFR: 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle Message-ID: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> Can I please get a review of this trivial change to the javadoc of `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8282190? ------------- Commit messages: - 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle Changes: https://git.openjdk.java.net/jdk/pull/7556/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7556&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282190 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7556.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7556/head:pull/7556 PR: https://git.openjdk.java.net/jdk/pull/7556 From redestad at openjdk.java.net Mon Feb 21 12:52:52 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 21 Feb 2022 12:52:52 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 16:02:42 GMT, Volker Simonis wrote: >> Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). >> >> >> before JDK-8281962 >> ------------------ >> Benchmark (size) Mode Cnt Score Error Units >> InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op >> InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op >> InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op >> >> after JDK-8281962 >> ----------------- >> Benchmark (size) Mode Cnt Score Error Units >> InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op >> InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op >> InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op >> >> >> Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. >> >> As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: >> >> >> int readcount = 0; >> while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { >> outputStream.write(data, 0, bytesRead); >> readCount++; >> } >> if (readCount == 1) { >> return data; // <---- first bytes might be overwritten >> } >> return outputStream.toByteArray(); >> >> >> Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). >> >> [1] https://github.com/spring-projects/spring-framework/issues/27429 >> [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Changed hardcoded constant to JMH parmater and removed non-ASCII chars from comments Thanks for fixing the microbenchmark to not have hardcoded limitations! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7492 From dfuchs at openjdk.java.net Mon Feb 21 14:05:52 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 21 Feb 2022 14:05:52 GMT Subject: RFR: 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle In-Reply-To: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> References: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> Message-ID: On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change to the javadoc of `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8282190? LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7556 From jpai at openjdk.java.net Mon Feb 21 14:18:19 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 21 Feb 2022 14:18:19 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale Message-ID: Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: Using locale: he for Properties#store(OutputStream) test test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 at org.testng.Assert.fail(Assert.java:87) at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:577) 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:577) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:828) Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) ... 30 more (in the exception above a locale with language `he` is being used) The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. ------------- Commit messages: - fix StoreReproducibilityTest - fix PropertiesStoreTest Changes: https://git.openjdk.java.net/jdk/pull/7558/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282023 Stats: 76 lines in 2 files changed: 56 ins; 2 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7558/head:pull/7558 PR: https://git.openjdk.java.net/jdk/pull/7558 From rriggs at openjdk.java.net Mon Feb 21 15:40:55 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 21 Feb 2022 15:40:55 GMT Subject: RFR: 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle In-Reply-To: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> References: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> Message-ID: <1NUZmCcwVgYuQL-c3ONQXOrOezBXG0uMSTBebyyka_g=.a8055a32-000b-4ff7-a5c8-7509a1c588c1@github.com> On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change to the javadoc of `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8282190? Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7556 From duke at openjdk.java.net Mon Feb 21 16:38:04 2022 From: duke at openjdk.java.net (liach) Date: Mon, 21 Feb 2022 16:38:04 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v9] In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 16:06:35 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > 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 13 additional commits since the last revision: > > - Merge branch 'master' into 8261407-reflectionfactory > - Whitespace issues > - Refine docs, pull members out of the config record > - The fast path should always come first. good lesson learned! > restore config field comments > - Try making the config a record and see if it works > - Make config a pojo, move loading code into config class > - use peter's model of separate data object > - Merge branch 'master' into 8261407-reflectionfactory > - Include the stable annotation > - Merge branch 'master' into 8261407-reflectionfactory > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/36cbf968...e97ea278 peter and mandy, would you mind review again today? ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From lancea at openjdk.java.net Mon Feb 21 17:38:50 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 21 Feb 2022 17:38:50 GMT Subject: RFR: 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle In-Reply-To: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> References: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> Message-ID: On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change to the javadoc of `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8282190? Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7556 From darcy at openjdk.java.net Mon Feb 21 17:46:51 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 21 Feb 2022 17:46:51 GMT Subject: RFR: 8282188: Unused static field MathContext.DEFAULT_DIGITS In-Reply-To: <1wrZubD_IPhKTJKupdBIRDQ3-K7JrHCmjobzn2LW6_o=.b5a56106-fc31-41c9-9e79-9656955c6e0d@github.com> References: <1wrZubD_IPhKTJKupdBIRDQ3-K7JrHCmjobzn2LW6_o=.b5a56106-fc31-41c9-9e79-9656955c6e0d@github.com> Message-ID: On Fri, 18 Feb 2022 19:07:15 GMT, Andrey Turbanov wrote: > 8282188: Unused static field MathContext.DEFAULT_DIGITS Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7538 From lancea at openjdk.java.net Mon Feb 21 18:07:53 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 21 Feb 2022 18:07:53 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 10:06:40 GMT, Volker Simonis wrote: > > The change looks innocuous so it is probably OK. I would like to kick of our Mach5 runs to see if it shakes out any potential issues. > > @LanceAndersen , did you manage to get any Mach5 results? Did you find any issues? Tests are still running so no final results yet (please note that today is also a US holiday) ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From iris at openjdk.java.net Mon Feb 21 19:28:46 2022 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 21 Feb 2022 19:28:46 GMT Subject: RFR: 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle In-Reply-To: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> References: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> Message-ID: On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change to the javadoc of `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8282190? Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7556 From plevart at openjdk.java.net Mon Feb 21 19:36:54 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 21 Feb 2022 19:36:54 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v9] In-Reply-To: References: Message-ID: <4pKi1Cc3wwHHKRDY9eDCpIJsuK0XtHjpZu4dE8TePfU=.c0bb86d6-08c8-4102-bfe1-c531a191d54e@github.com> On Mon, 21 Feb 2022 16:35:09 GMT, liach wrote: >> 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 13 additional commits since the last revision: >> >> - Merge branch 'master' into 8261407-reflectionfactory >> - Whitespace issues >> - Refine docs, pull members out of the config record >> - The fast path should always come first. good lesson learned! >> restore config field comments >> - Try making the config a record and see if it works >> - Make config a pojo, move loading code into config class >> - use peter's model of separate data object >> - Merge branch 'master' into 8261407-reflectionfactory >> - Include the stable annotation >> - Merge branch 'master' into 8261407-reflectionfactory >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/73eb6e94...e97ea278 > > peter and mandy, would you mind review again today? Latest version looks good to me, @liach. Thanks for doing this. Regards, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From plevart at openjdk.java.net Mon Feb 21 20:29:54 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 21 Feb 2022 20:29:54 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Mon, 17 Jan 2022 08:28:35 GMT, Erik Gahlin wrote: >> src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java line 405: >> >>> 403: Object res = m.invoke(a, new Object[0]); >>> 404: if (res instanceof Annotation[]) { >>> 405: for (Annotation rep : (Annotation[]) m.invoke(a, new Object[0])) { >> >> BTW it looks suspicious to have `m.invoke(a, new Object[0])` called again here. Shouldn't it just reuse `res` variable instead? > > It looks unnecessary. Please feel free to fix. Or even use the new pattern matching syntax and remove unnecessary explicit empty array construction: if (m.invoke(a) instanceof Annotation[] anns) { for (Annotation rep : anns) { ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From duke at openjdk.java.net Mon Feb 21 22:27:34 2022 From: duke at openjdk.java.net (liach) Date: Mon, 21 Feb 2022 22:27:34 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v3] In-Reply-To: References: Message-ID: > Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. 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 eight additional commits since the last revision: - Merge branch 'identityhashmap-bench' into identityhashmap-default - Initial identity hash map benchmark - Merge branch 'master' of https://git.openjdk.java.net/jdk into identityhashmap-default - Merge branch 'master' of https://git.openjdk.java.net/jdk into identityhashmap-default - update dates - Also test cme for identity hash map - Fix putIfAbsent - JDK-8277520: Implement JDK-8 default methods for IdentityHashMap ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6532/files - new: https://git.openjdk.java.net/jdk/pull/6532/files/d853ab34..f6ee4fab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6532&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6532&range=01-02 Stats: 70198 lines in 2074 files changed: 48646 ins; 11878 del; 9674 mod Patch: https://git.openjdk.java.net/jdk/pull/6532.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6532/head:pull/6532 PR: https://git.openjdk.java.net/jdk/pull/6532 From duke at openjdk.java.net Mon Feb 21 23:36:19 2022 From: duke at openjdk.java.net (liach) Date: Mon, 21 Feb 2022 23:36:19 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v4] In-Reply-To: References: Message-ID: > Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. liach has updated the pull request incrementally with two additional commits since the last revision: - merge branch 'identityhashmap-bench' of https://github.com/liachmodded/jdk into identityhashmap-default - fix whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6532/files - new: https://git.openjdk.java.net/jdk/pull/6532/files/f6ee4fab..9fe578be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6532&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6532&range=02-03 Stats: 105 lines in 1 file changed: 0 ins; 0 del; 105 mod Patch: https://git.openjdk.java.net/jdk/pull/6532.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6532/head:pull/6532 PR: https://git.openjdk.java.net/jdk/pull/6532 From duke at openjdk.java.net Mon Feb 21 23:36:24 2022 From: duke at openjdk.java.net (liach) Date: Mon, 21 Feb 2022 23:36:24 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v3] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 22:27:34 GMT, liach wrote: >> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. > > 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 eight additional commits since the last revision: > > - Merge branch 'identityhashmap-bench' into identityhashmap-default > - Initial identity hash map benchmark > - Merge branch 'master' of https://git.openjdk.java.net/jdk into identityhashmap-default > - Merge branch 'master' of https://git.openjdk.java.net/jdk into identityhashmap-default > - update dates > - Also test cme for identity hash map > - Fix putIfAbsent > - JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [Baseline results](https://github.com/openjdk/jdk/files/8112532/micro.txt) (See https://github.com/liachmodded/jdk/tree/identityhashmap-bench) [Result with this patch](https://github.com/openjdk/jdk/files/8112533/micro.txt) Seems the benchmark does have some problems within itself. maybe need more consistent data sets for more consistent results (test both put and putIfAbsent against the same data set) ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From mchung at openjdk.java.net Tue Feb 22 01:34:54 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Feb 2022 01:34:54 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v9] In-Reply-To: References: Message-ID: <_hSuMIMy02yuIYK3PifdOCEdjszH19fR4mCS8Aunmzg=.0208f451-660f-4ef4-91ea-f25bd476fe08@github.com> On Sat, 19 Feb 2022 16:06:35 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > 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 13 additional commits since the last revision: > > - Merge branch 'master' into 8261407-reflectionfactory > - Whitespace issues > - Refine docs, pull members out of the config record > - The fast path should always come first. good lesson learned! > restore config field comments > - Try making the config a record and see if it works > - Make config a pojo, move loading code into config class > - use peter's model of separate data object > - Merge branch 'master' into 8261407-reflectionfactory > - Include the stable annotation > - Merge branch 'master' into 8261407-reflectionfactory > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/e523ebbb...e97ea278 Looks good. Thanks for doing this. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6889 From mchung at openjdk.java.net Tue Feb 22 01:38:56 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Feb 2022 01:38:56 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v9] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 16:35:09 GMT, liach wrote: >> 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 13 additional commits since the last revision: >> >> - Merge branch 'master' into 8261407-reflectionfactory >> - Whitespace issues >> - Refine docs, pull members out of the config record >> - The fast path should always come first. good lesson learned! >> restore config field comments >> - Try making the config a record and see if it works >> - Make config a pojo, move loading code into config class >> - use peter's model of separate data object >> - Merge branch 'master' into 8261407-reflectionfactory >> - Include the stable annotation >> - Merge branch 'master' into 8261407-reflectionfactory >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/b26d5ef1...e97ea278 > > peter and mandy, would you mind review again today? @liach You and Peter are the contributors. You can remove me from the contributor list. ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From jpai at openjdk.java.net Tue Feb 22 01:43:46 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 22 Feb 2022 01:43:46 GMT Subject: RFR: 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle In-Reply-To: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> References: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> Message-ID: <_pDQWn9bsr3-EVjgXXrF4tDyYHkTx4Wt6svq7Re33oc=.d41c1b56-e017-4684-b87e-b7930673706f@github.com> On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change to the javadoc of `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8282190? Thank you everyone for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/7556 From jpai at openjdk.java.net Tue Feb 22 01:43:46 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 22 Feb 2022 01:43:46 GMT Subject: Integrated: 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle In-Reply-To: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> References: <85AxKwDuPDS5-P0NHaF5ywUEwE3tbEiEcLtAgjAhjVI=.d7fd261a-09b6-4fa3-8e94-d5d7ea2aad3b@github.com> Message-ID: On Mon, 21 Feb 2022 12:42:37 GMT, Jaikiran Pai wrote: > Can I please get a review of this trivial change to the javadoc of `DateTimeFormatter.getDecimalStyle()` method which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8282190? This pull request has now been integrated. Changeset: e0b49629 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/e0b49629e95c98aabe8b75ec2f7528e7fb6dcffc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8282190: Typo in javadoc of java.time.format.DateTimeFormatter#getDecimalStyle Reviewed-by: dfuchs, rriggs, lancea, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7556 From djelinski at openjdk.java.net Tue Feb 22 07:16:13 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 22 Feb 2022 07:16:13 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build Message-ID: Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. ------------- Commit messages: - Strict strings Changes: https://git.openjdk.java.net/jdk/pull/7565/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281525 Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/7565.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7565/head:pull/7565 PR: https://git.openjdk.java.net/jdk/pull/7565 From simonis at openjdk.java.net Tue Feb 22 08:59:57 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 22 Feb 2022 08:59:57 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 18:05:08 GMT, Lance Andersen wrote: > > > The change looks innocuous so it is probably OK. I would like to kick of our Mach5 runs to see if it shakes out any potential issues. > > > > > > @LanceAndersen , did you manage to get any Mach5 results? Did you find any issues? > > Tests are still running so no final results yet (please note that today is also a US holiday) No problem. Just let me know once the tests have finished. And thanks @AlanBateman, @cl4es for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From ihse at openjdk.java.net Tue Feb 22 11:36:52 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 22 Feb 2022 11:36:52 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski wrote: > Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. > > This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). > > The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. > > I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. make/autoconf/flags-cflags.m4 line 136: > 134: CFLAGS_WARNINGS_ARE_ERRORS="-WX" > 135: > 136: WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings" This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7565 From itakiguchi at openjdk.java.net Tue Feb 22 12:25:11 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Tue, 22 Feb 2022 12:25:11 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX Message-ID: Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. The test was failed by: Incorrect handling of envstrings containing NULs According to my investigation, this issue was happened after following change was applied. JDK-8272600: (test) Use native "sleep" in Basic.java test.nativepath value was added into AIX's LIBPATH during running this testcase. On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. ------------- Commit messages: - 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX Changes: https://git.openjdk.java.net/jdk/pull/7574/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282219 Stats: 18 lines in 1 file changed: 14 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7574/head:pull/7574 PR: https://git.openjdk.java.net/jdk/pull/7574 From dholmes at openjdk.java.net Tue Feb 22 12:26:52 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Feb 2022 12:26:52 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski wrote: > Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. > > This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). > > The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. > > I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. Hi Daniel, Hotspot changes look fine. Some of the casts in other code look odd to me, but I'll leave that for the security-libs folk to comment on. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7565 From jlaskey at openjdk.java.net Tue Feb 22 12:54:48 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Feb 2022 12:54:48 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6] In-Reply-To: References: Message-ID: On Sun, 20 Feb 2022 03:15:22 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > remove missed whitespace At this point I think you should just drop all changes to src/java.base/share/classes/java/util/random/RandomGenerator.java, since they are only cosmetic. Plus you are missing a newline at the end of the file. Otherwise, LGTM. ------------- Changes requested by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7001 From djelinski at openjdk.java.net Tue Feb 22 14:16:49 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 22 Feb 2022 14:16:49 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 11:33:52 GMT, Magnus Ihse Bursie wrote: >> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. >> >> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). >> >> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. >> >> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. > > make/autoconf/flags-cflags.m4 line 136: > >> 134: CFLAGS_WARNINGS_ARE_ERRORS="-WX" >> 135: >> 136: WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings" > > This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/7565 From rriggs at openjdk.java.net Tue Feb 22 15:18:52 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Feb 2022 15:18:52 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 12:17:59 GMT, Ichiroh Takiguchi wrote: > Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > The test was failed by: > Incorrect handling of envstrings containing NULs > > According to my investigation, this issue was happened after following change was applied. > JDK-8272600: (test) Use native "sleep" in Basic.java > > test.nativepath value was added into AIX's LIBPATH during running this testcase. > On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. test/jdk/java/lang/ProcessBuilder/Basic.java line 1891: > 1889: Process p = Runtime.getRuntime().exec(cmdp, envp); > 1890: String expected = Windows.is() ? "=C:=\\,=ExitValue=3,SystemRoot="+systemRoot+"," : "=C:=\\,"; > 1891: expected = AIX.is() ? expected + "LIBPATH="+removeTestNativepathString(libpath)+",": expected; Can line 1878 (and the fix) be moved into the `removeAixExpectedVars` method. 1883: if (AIX.is()) { 1884: commandOutput = removeAixExpectedVars(commandOutput); 1885: } The `replaceAll` used in that method should be just as effective as the more expensive new method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From igraves at openjdk.java.net Tue Feb 22 15:43:05 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 22 Feb 2022 15:43:05 GMT Subject: Integrated: 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java In-Reply-To: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> References: <7E4S98UwaTgYYLKdRQ4N65OK03ALuWKt-t9kKfqcohQ=.1a941524-5fa0-4931-ad6e-d62eac04e196@github.com> Message-ID: On Thu, 17 Feb 2022 18:02:20 GMT, Ian Graves wrote: > Adding a missing period per this doc bug. This pull request has now been integrated. Changeset: 41355e2d Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/41355e2daa43fa8433bf77ed187979c49d453f4a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8276686: Malformed Javadoc inline tags in JDK source in /java/util/regex/Pattern.java Reviewed-by: iris, bpb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7521 From duke at openjdk.java.net Tue Feb 22 15:45:51 2022 From: duke at openjdk.java.net (liach) Date: Tue, 22 Feb 2022 15:45:51 GMT Subject: RFR: 8261407: ReflectionFactory.checkInitted() is not thread-safe [v9] In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 16:06:35 GMT, liach wrote: >> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. >> >> This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) > > 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 13 additional commits since the last revision: > > - Merge branch 'master' into 8261407-reflectionfactory > - Whitespace issues > - Refine docs, pull members out of the config record > - The fast path should always come first. good lesson learned! > restore config field comments > - Try making the config a record and see if it works > - Make config a pojo, move loading code into config class > - use peter's model of separate data object > - Merge branch 'master' into 8261407-reflectionfactory > - Include the stable annotation > - Merge branch 'master' into 8261407-reflectionfactory > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f0786899...e97ea278 peter or mandy, would you do me a favor and sponsor this patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From ihse at openjdk.java.net Tue Feb 22 16:19:17 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 22 Feb 2022 16:19:17 GMT Subject: RFR: 8209784: Include hsdis in the JDK Message-ID: This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK. The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file `lib-hsdis.gmk`, and breaking the functionality up in separate functions per backend. ------------- Commit messages: - Add bundling of hsdis with java.base - Refactor lib-hsdis.gmk by breaking out each backend in a separate function - Break out hsdis setup to separate file Changes: https://git.openjdk.java.net/jdk/pull/7578/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7578&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8209784 Stats: 682 lines in 8 files changed: 390 ins; 281 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7578/head:pull/7578 PR: https://git.openjdk.java.net/jdk/pull/7578 From igraves at openjdk.java.net Tue Feb 22 16:35:52 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 22 Feb 2022 16:35:52 GMT Subject: Integrated: 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 18:45:29 GMT, Ian Graves wrote: > This is a fix in the buggy way CIBackRef traverses unicode characters that could be variable-length. Originally it followed the approach that BackRef does, but failed to account for unicode characters that could be 2 chars-long. The upper bound (groupSize) for the traversing loop is set by the difference between group start and stop indexes. This works for single char characters and it also works for case-sensitive comparisons because byte-by-byte comparisons are acceptable, but it doesn't work for a comparison where some kind of normalization (i.e. case) is required. This fix adjusts the upper bound for the loop that traverses the character when a two-char character is encountered. > > An alternative was to check the length of the group size by scanning the group in advance and converting to code points, but this could potentially result in multiple scans and codepoint conversions of the same matcher group which could be long. The solution that adjusts the loop bounds on the fly avoids this case. This pull request has now been integrated. Changeset: 3cb38678 Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/3cb38678aa7f03356421f5a17c1de4156e206d68 Stats: 25 lines in 2 files changed: 21 ins; 0 del; 4 mod 8281315: Unicode, (?i) flag and backreference throwing IndexOutOfBounds Exception Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7501 From erikj at openjdk.java.net Tue Feb 22 16:41:41 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Feb 2022 16:41:41 GMT Subject: RFR: 8209784: Include hsdis in the JDK In-Reply-To: References: Message-ID: <2FFpuurf7bTp2lmeLBnJtenZNGEjVJBgVnIYW27MqZk=.326d64f6-78fa-47d6-a51a-5d5d2d173130@github.com> On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote: > This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK. > > The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file `lib-hsdis.gmk`, and breaking the functionality up in separate functions per backend. Marked as reviewed by erikj (Reviewer). make/Hsdis.gmk line 186: > 184: $(install-file) > 185: > 186: $(INSTALLED_HSDIS_IMAGE): $(BUILT_HSDIS_LIB) This slipped past me earlier, but the install-hsdis target at the top level does not have any prereq. I believe it needs to depend on jdk-image for installation to the image to work. Otherwise it will just get deleted if the jdk-image target is built after. ------------- PR: https://git.openjdk.java.net/jdk/pull/7578 From djelinski at openjdk.java.net Tue Feb 22 16:43:28 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 22 Feb 2022 16:43:28 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2] In-Reply-To: References: Message-ID: > Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. > > This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). > > The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. > > I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Move strictStrings to toolchain_cflags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7565/files - new: https://git.openjdk.java.net/jdk/pull/7565/files/fe18b41d..0cfbb165 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7565&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7565.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7565/head:pull/7565 PR: https://git.openjdk.java.net/jdk/pull/7565 From ihse at openjdk.java.net Tue Feb 22 16:43:30 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 22 Feb 2022 16:43:30 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 14:13:43 GMT, Daniel Jeli?ski wrote: >> make/autoconf/flags-cflags.m4 line 136: >> >>> 134: CFLAGS_WARNINGS_ARE_ERRORS="-WX" >>> 135: >>> 136: WARNINGS_ENABLE_ALL="-W3 -Zc:strictStrings" >> >> This is not strictly a flag to enable warnings. I'd recommend you move it to line 499 and 500 in the same file, which would align it with the -Zc:wchar_t- switch. Make sure you add it to both TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK. > > Done Did you forget to push the fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/7565 From djelinski at openjdk.java.net Tue Feb 22 16:43:31 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 22 Feb 2022 16:43:31 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2] In-Reply-To: References: Message-ID: <2SOr0Aam68G8M26cjL1kFsz9YEWRr2lNfIsu_9rq-i8=.94d1aba2-a323-4e2d-9916-253dce6c98e7@github.com> On Tue, 22 Feb 2022 16:35:09 GMT, Magnus Ihse Bursie wrote: >> Done > > Did you forget to push the fix? Push works better when connected... this time it's pushed for real. ------------- PR: https://git.openjdk.java.net/jdk/pull/7565 From duke at openjdk.java.net Tue Feb 22 16:53:57 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 22 Feb 2022 16:53:57 GMT Subject: Integrated: 8282042: [testbug] FileEncodingTest.java depends on default encoding In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 22:50:37 GMT, Tyler Steele wrote: > FileEncodingTest expects all non-Windows platforms will have `Charset.defaultCharset().name()` set to US-ASCII when file.encoding is set to COMPAT. This assumption does not hold for AIX where it is ISO-8859-1. > > According to [JEP-400](https://openjdk.java.net/jeps/400), we should expect `Charset.defaultCharset().name()` to equal `System.getProperty("native.encoding")` whenever the COMPAT flag is set. From JEP-400: "... if file.encoding is set to COMPAT on the command line, then the run-time value of file.encoding will be the same as the run-time value of native.encoding...". So one way to resolve this is to choose the value for each system from the native.encoding property. > > With these changes however, my test systems continue to fail. > > - AIX reports: Default Charset: ISO-8859-1, expected: ISO8859-1 > - Linux/Z reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > - Linux/PowerLE reports: Default Charset: US-ASCII, expected: ANSI_X3.4-1968 > > Note that the expected value is populated from native.encoding. > > This implies more work to be done. It looks to me that some modification to java_props_md.c may be needed to ensure that the System properties for native.encoding return [canonical names](http://www.iana.org/assignments/character-sets). > > --- > > A tempting alternative is to set the expected value for AIX to "ISO-8859-1" in the test explicitly, as was done for the Windows expected encoding prior to this proposed change. The main advantage to this alternative is that it is quick and easy, but the disadvantages are that it fails to test that COMPAT behaves as specified in JEP-400, and the approach does not scale well if it happens that other systems require other cases. I wonder if this is the reason non-English locals are excluded by the test. > > Proceeding with this change and the work implied by the new failures it highlights goes beyond the scope of what I thought was a simple testbug. So I'm opening this up for some comments before proceeding down the rabbit hole of further changes. If there is generally positive support for this direction I'm happy to make the modifications necessary to populate native.encoding with canonical names. As I am new to OpenJDK, I am especially looking to ensure that changing the value returned by native.encoding will not have unintended consequences elsewhere in the project. This pull request has now been integrated. Changeset: 58e1882f Author: Tyler Steele Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/58e1882f3ccc648c5f6d216d37cfd1805889b8d8 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8282042: [testbug] FileEncodingTest.java depends on default encoding Adds expected encoding "ISO-8859-1" for AIX in FileEncodingTest.java Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7525 From aph at openjdk.java.net Tue Feb 22 16:57:48 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 22 Feb 2022 16:57:48 GMT Subject: RFR: 8209784: Include hsdis in the JDK In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote: > This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK. Maybe I missed it, but are there instructions somewhere about how to build this, and what should be downloaded? ------------- PR: https://git.openjdk.java.net/jdk/pull/7578 From duke at openjdk.java.net Tue Feb 22 17:01:00 2022 From: duke at openjdk.java.net (liach) Date: Tue, 22 Feb 2022 17:01:00 GMT Subject: Integrated: 8261407: ReflectionFactory.checkInitted() is not thread-safe In-Reply-To: References: Message-ID: <16HaF9Bv043aESQcWkFTSxv8aMpJESdaQ_Zq_9f3FSk=.58f0972f-be02-4f83-9ed9-6e21647824a6@github.com> On Sun, 19 Dec 2021 03:21:55 GMT, liach wrote: > Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407), by design, duplicate initialization of ReflectionFactory should be safe as it performs side-effect-free property read actions, and the suggesting of making the `initted` field volatile cannot prevent concurrent initialization either; however, having `initted == true` published without the other fields' values is a possibility, which this patch addresses. > > This simulates what's done in `CallSite`'s constructor for `ConstantCallSite`. Please feel free to point out the problems with this patch, as I am relatively inexperienced in this field of fences and there are relatively less available documents. (Thanks to https://shipilev.net/blog/2014/on-the-fence-with-dependencies/) This pull request has now been integrated. Changeset: 7feabee4 Author: liach Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/7feabee4265787ea820c1925c0c531933cb0da50 Stats: 125 lines in 1 file changed: 72 ins; 36 del; 17 mod 8261407: ReflectionFactory.checkInitted() is not thread-safe Co-authored-by: Peter Levart Reviewed-by: dholmes, mchung, plevart ------------- PR: https://git.openjdk.java.net/jdk/pull/6889 From ihse at openjdk.java.net Tue Feb 22 17:15:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 22 Feb 2022 17:15:50 GMT Subject: RFR: 8209784: Include hsdis in the JDK In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 16:54:21 GMT, Andrew Haley wrote: > Maybe I missed it, but are there instructions somewhere about how to build this, and what should be downloaded? See https://github.com/openjdk/jdk/blob/master/src/utils/hsdis/README.md ------------- PR: https://git.openjdk.java.net/jdk/pull/7578 From ihse at openjdk.java.net Tue Feb 22 17:16:51 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 22 Feb 2022 17:16:51 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski wrote: >> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. >> >> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). >> >> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. >> >> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Move strictStrings to toolchain_cflags Now the build changes look good. Thanks! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7565 From itakiguchi at openjdk.java.net Tue Feb 22 17:20:25 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Tue, 22 Feb 2022 17:20:25 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2] In-Reply-To: References: Message-ID: > Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > The test was failed by: > Incorrect handling of envstrings containing NULs > > According to my investigation, this issue was happened after following change was applied. > JDK-8272600: (test) Use native "sleep" in Basic.java > > test.nativepath value was added into AIX's LIBPATH during running this testcase. > On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: Use expectedLibpath ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7574/files - new: https://git.openjdk.java.net/jdk/pull/7574/files/9d1faeb7..8b88686d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=00-01 Stats: 31 lines in 1 file changed: 16 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7574/head:pull/7574 PR: https://git.openjdk.java.net/jdk/pull/7574 From itakiguchi at openjdk.java.net Tue Feb 22 17:31:53 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Tue, 22 Feb 2022 17:31:53 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2] In-Reply-To: References: Message-ID: <7v62YquVxulv7D2UNp08n5ikRa7s0EbOQLtsJxUAQzo=.e8e5626f-eddb-4654-a7ea-b13f2e9c8db4@github.com> On Tue, 22 Feb 2022 17:20:25 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Use expectedLibpath @RogerRiggs I appreciate your good suggestion. Since `libpath` is just used on AIX and it's `static final String`. I created `expectedLibpath` for expected result. About `removeAll` method, it requires regular expression string. I think if directory name has `.`, unexpected situation may be happened. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From bpb at openjdk.java.net Tue Feb 22 17:34:48 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 22 Feb 2022 17:34:48 GMT Subject: RFR: 8282188: Unused static field MathContext.DEFAULT_DIGITS In-Reply-To: <1wrZubD_IPhKTJKupdBIRDQ3-K7JrHCmjobzn2LW6_o=.b5a56106-fc31-41c9-9e79-9656955c6e0d@github.com> References: <1wrZubD_IPhKTJKupdBIRDQ3-K7JrHCmjobzn2LW6_o=.b5a56106-fc31-41c9-9e79-9656955c6e0d@github.com> Message-ID: On Fri, 18 Feb 2022 19:07:15 GMT, Andrey Turbanov wrote: > 8282188: Unused static field MathContext.DEFAULT_DIGITS Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7538 From naoto at openjdk.java.net Tue Feb 22 17:38:58 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 22 Feb 2022 17:38:58 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:09:50 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: > - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. > - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. > > All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: > > > Using locale: he for Properties#store(OutputStream) test > test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure > java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 > at org.testng.Assert.fail(Assert.java:87) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) > at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > 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:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:828) > Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) > ... 30 more > > (in the exception above a locale with language `he` is being used) > > The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. Looks good overall. Some nits follow. Please change the copyright year too. test/jdk/java/util/Properties/PropertiesStoreTest.java line 50: > 48: * @test > 49: * @summary tests the order in which the Properties.store() method writes out the properties > 50: * @bug 8231640 Add the bug id, also `@modules jdk.localedata` needs to be added. test/jdk/java/util/Properties/PropertiesStoreTest.java line 104: > 102: for (Locale locale : Locale.getAvailableLocales()) { > 103: // skip ROOT locale and ENGLISH language ones > 104: if (!locale.getLanguage().isEmpty() && !locale.getLanguage().equals(Locale.ENGLISH.getLanguage())) { Could simply compare with "en". test/jdk/java/util/Properties/PropertiesStoreTest.java line 189: > 187: @Test(dataProvider = "localeProvider") > 188: public void testStoreWriterDateComment(final Locale testLocale) throws Exception { > 189: var prevLocale = Locale.getDefault(); Could be done once at the class loading time. test/jdk/java/util/Properties/PropertiesStoreTest.java line 212: > 210: @Test(dataProvider = "localeProvider") > 211: public void testStoreOutputStreamDateComment(final Locale testLocale) throws Exception { > 212: var prevLocale = Locale.getDefault(); Same as the above method test/jdk/java/util/Properties/PropertiesStoreTest.java line 253: > 251: // use a neutral locale for parsing, since when the date comment was written by Properties.store(...), > 252: // it internally calls the Date.toString() which always writes in a locale insensitive manner > 253: DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN).withLocale(Locale.ROOT).parse(comment); This formatter can also be statically initialized. test/jdk/java/util/Properties/StoreReproducibilityTest.java line 430: > 428: // use a neutral locale for parsing, since when the date comment was written by Properties.store(...), > 429: // it internally calls the Date.toString() which always writes in a locale insensitive manner > 430: var df = DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN).withLocale(Locale.ROOT); Same as the above. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From rriggs at openjdk.java.net Tue Feb 22 18:13:50 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Feb 2022 18:13:50 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 17:20:25 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Use expectedLibpath For my curiosity, how is AIX different from other Linux in that the test.nativepath is not/should not be in LIBPATH? test/jdk/java/lang/ProcessBuilder/Basic.java line 81: > 79: /* used for AIX only */ > 80: static final String libpath = System.getenv("LIBPATH"); > 81: static final String expectedLibpath; Can you check the usage of libpath at line 1362. How is this case different from the other two at 1878 and 1943? I would move the change to the `expected` value to move into the block that is already testing AIX.is at line 1367. I would prefer to have a single static with the libpath expected by the 3 places it is used in the test. test/jdk/java/lang/ProcessBuilder/Basic.java line 1900: > 1898: if (AIX.is()) { > 1899: commandOutput = removeAixExpectedVars(commandOutput); > 1900: expected = expected + "LIBPATH="+expectedLibpath+","; Please add spaces around operators +, that is the convention and in this file. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From duke at openjdk.java.net Tue Feb 22 18:29:21 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 22 Feb 2022 18:29:21 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long Message-ID: Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. ------------- Commit messages: - fix trailing white space errors - fix whitespaces - revert comment to original for divmodI - Update rax and rdx register usage in x86_64.ad - 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long Changes: https://git.openjdk.java.net/jdk/pull/7572/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282221 Stats: 741 lines in 16 files changed: 738 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From hchao at openjdk.java.net Tue Feb 22 20:27:22 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 22 Feb 2022 20:27:22 GMT Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are disabled Message-ID: This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. ------------- Commit messages: - 8277474: jarsigner does not check if algorithm parameters are disabled - Testcase updated - 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty Changes: https://git.openjdk.java.net/jdk/pull/7580/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7580&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277474 Stats: 256 lines in 5 files changed: 240 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7580.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7580/head:pull/7580 PR: https://git.openjdk.java.net/jdk/pull/7580 From hchao at openjdk.java.net Tue Feb 22 20:31:50 2022 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 22 Feb 2022 20:31:50 GMT Subject: Withdrawn: 8277474: jarsigner does not check if algorithm parameters are disabled In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 20:18:19 GMT, Hai-May Chao wrote: > This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7580 From darcy at openjdk.java.net Tue Feb 22 21:21:38 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 22 Feb 2022 21:21:38 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v10] In-Reply-To: References: Message-ID: <37y5-Voxao3_elkzwom5XUmXVeL_NwbfZZu2kmUFtf0=.6687e2cc-1ec1-4ace-a1a8-380b78b8e0f9@github.com> > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. 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 16 additional commits since the last revision: - Add test for location disjointness - Minor cleanup. - Merge branch 'master' into JDK-8266670 - Switch to location enum. - Respond to review feedback. - Add support for module flags; fix typo. - Merge branch 'master' into JDK-8266670 - Update JVMS references. - Merge branch 'master' into JDK-8266670 - Reorder constants by mask value per review feedback. - ... and 6 more: https://git.openjdk.java.net/jdk/compare/024b847b...46d4d7ea ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/c3f6b0a4..46d4d7ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=08-09 Stats: 8276 lines in 193 files changed: 5054 ins; 1931 del; 1291 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Tue Feb 22 21:30:24 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 22 Feb 2022 21:30:24 GMT Subject: RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH Message-ID: This test had two failing sections on AIX related to an incorrect expected value for LIBPATH. The two (previously failing) test sections are below. - Test Runtime.exec(...envp...) with envstrings with initial `=' - Test Runtime.exec(...envp...) with envstrings containing NULs This PR modifies the environment passed to the process at ...exec(cmdp, **envp**) to include the LIBPATH of the parent. With this change, the expected libpath matches the libpath returned by the process. ### Alternatives An equivalent change would be to modify the libpath variable used to set the expected value for the test without explicitly setting the LIBPATH in process invocation. This would involve removing the libpath for .../jtreg/native that is added by the test runner by command-line option `-J-Dtest.nativepath=...images/test/jdk/jtreg/native `. This change would be reasonable, but I prefer the approach taken in this PR. ### Testing This test now passes on my test machine running AIX 7.1. ------------- Commit messages: - Fixes testbug causing failure in ProcessBuilder/Basic on AIX Changes: https://git.openjdk.java.net/jdk/pull/7581/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7581&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282239 Stats: 27 lines in 1 file changed: 1 ins; 8 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7581/head:pull/7581 PR: https://git.openjdk.java.net/jdk/pull/7581 From duke at openjdk.java.net Tue Feb 22 22:04:38 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 22 Feb 2022 22:04:38 GMT Subject: RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH [v2] In-Reply-To: References: Message-ID: > This test had two failing sections on AIX related to an incorrect expected value for LIBPATH. The two (previously failing) test sections are below. > > - Test Runtime.exec(...envp...) with envstrings with initial `=' > - Test Runtime.exec(...envp...) with envstrings containing NULs > > This PR modifies the environment passed to the process at ...exec(cmdp, **envp**) to include the LIBPATH of the parent. With this change, the expected libpath matches the libpath returned by the process. > > ### Alternatives > > An equivalent change would be to modify the libpath variable used to set the expected value for the test without explicitly setting the LIBPATH in process invocation. This would involve removing the libpath for .../jtreg/native that is added by the test runner by command-line option `-J-Dtest.nativepath=...images/test/jdk/jtreg/native `. This change would be reasonable, but I prefer the approach taken in this PR. > > ### Testing > > This test now passes on my test machine running AIX 7.1. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Updates copyright year & adds bugid ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7581/files - new: https://git.openjdk.java.net/jdk/pull/7581/files/5d325951..fd3a84ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7581&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7581&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7581/head:pull/7581 PR: https://git.openjdk.java.net/jdk/pull/7581 From lancea at openjdk.java.net Tue Feb 22 22:05:32 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 22 Feb 2022 22:05:32 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v8] In-Reply-To: References: Message-ID: > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Modified and clarified test comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7348/files - new: https://git.openjdk.java.net/jdk/pull/7348/files/839d99f7..e540a3a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7348&range=06-07 Stats: 64 lines in 1 file changed: 34 ins; 18 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7348/head:pull/7348 PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Tue Feb 22 22:05:34 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 22 Feb 2022 22:05:34 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v4] In-Reply-To: References: Message-ID: <7uC177dheUsm1Ky2Tav8-L4BObpjR-0IKzmA455PIjA=.9096eff8-c318-4eb6-999d-0901f8ebb078@github.com> On Sat, 19 Feb 2022 10:59:56 GMT, Alan Bateman wrote: > > Ok, thank you for the feedback. I just pushed a change with additional comments on the jar creation which hopefully will address your input above. > > It's a bit better but I think it needs a clear step-by-step instructions in a comment before declaration of VALID_ENTRY_NAME to show how the JAR file is created, signed (move the instructions that have been placed on the TestNG setup method), and then converted to the byte array. Further maintainers will thank you. Just pushed a revised set of comments. Hopefully this will get us across the goal line. ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From lancea at openjdk.java.net Tue Feb 22 22:11:55 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 22 Feb 2022 22:11:55 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: <8tf4yVjKkNDmKPmp4XUouuxBOC2TqyTB66o4oP9Nsm4=.2e73f29e-51f2-4599-b628-a0e2d57e3808@github.com> On Thu, 17 Feb 2022 16:02:42 GMT, Volker Simonis wrote: >> Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). >> >> >> before JDK-8281962 >> ------------------ >> Benchmark (size) Mode Cnt Score Error Units >> InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op >> InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op >> InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op >> >> after JDK-8281962 >> ----------------- >> Benchmark (size) Mode Cnt Score Error Units >> InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op >> InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op >> InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op >> >> >> Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. >> >> As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: >> >> >> int readcount = 0; >> while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { >> outputStream.write(data, 0, bytesRead); >> readCount++; >> } >> if (readCount == 1) { >> return data; // <---- first bytes might be overwritten >> } >> return outputStream.toByteArray(); >> >> >> Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). >> >> [1] https://github.com/spring-projects/spring-framework/issues/27429 >> [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Changed hardcoded constant to JMH parmater and removed non-ASCII chars from comments Mach5 runs did not raise any issues, so you should be OK to move forward. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7492 From duke at openjdk.java.net Tue Feb 22 22:30:45 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 22 Feb 2022 22:30:45 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2] In-Reply-To: References: Message-ID: <9ZhYkPgAgJm95JAIAIp3LZY9jeVI6B0GTCye82dO8rU=.38689518-8328-4736-b679-6ac2cd36fb45@github.com> On Tue, 22 Feb 2022 17:20:25 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Use expectedLibpath Looks you and I are thinking similarly. https://github.com/openjdk/jdk/pull/7581 ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From rriggs at openjdk.java.net Tue Feb 22 22:55:47 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Feb 2022 22:55:47 GMT Subject: RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:04:38 GMT, Tyler Steele wrote: >> This test had two failing sections on AIX related to an incorrect expected value for LIBPATH. The two (previously failing) test sections are below. >> >> - Test Runtime.exec(...envp...) with envstrings with initial `=' >> - Test Runtime.exec(...envp...) with envstrings containing NULs >> >> This PR modifies the environment passed to the process at ...exec(cmdp, **envp**) to include the LIBPATH of the parent. With this change, the expected libpath matches the libpath returned by the process. >> >> ### Alternatives >> >> An equivalent change would be to modify the libpath variable used to set the expected value for the test without explicitly setting the LIBPATH in process invocation. This would involve removing the libpath for .../jtreg/native that is added by the test runner by command-line option `-J-Dtest.nativepath=...images/test/jdk/jtreg/native `. This change would be reasonable, but I prefer the approach taken in this PR. >> >> ### Testing >> >> This test now passes on my test machine running AIX 7.1. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Updates copyright year & adds bugid > /label add noreg-self fyi, the noreg-* labels apply to the bug report, not the PR. (and yes, they are informative when reviewing). One of [JDK-8282239](https://bugs.openjdk.java.net/browse/JDK-8282239): or [JDK-8282219](https://bugs.openjdk.java.net/browse/JDK-8282219) should be closed as a duplicate. ------------- PR: https://git.openjdk.java.net/jdk/pull/7581 From liangchenblue at gmail.com Tue Feb 22 23:09:24 2022 From: liangchenblue at gmail.com (-) Date: Tue, 22 Feb 2022 17:09:24 -0600 Subject: Replace simple iterations of Map.entrySet with Map.forEach calls Message-ID: Hello, In the patch for 8281631 , xenoamess intentionally avoided repeatedly calling Map::size, for it may not be constant-timed due to being concurrent. This alerted me that the for loops on Map::entrySet may be similarly not thread-safe. I believe that we should migrate for loop on Map::entrySet to Map::forEach calls; concurrent map callees usually have dedicated logic to mitigate such thread-safety issues. Synchronized map callees are benefitted too. Another lesser benefit is reduced object allocation for iteration. While the most popular implementations (HashMap, LinkedHashMap, WeakHashMap, TreeMap) don't need to allocate entries for iteration, many other (EnumMap, IdentityHashMap, concurrent maps) do, and iterating those maps with forEach is less costly. (Note that 8170826 takes care of implementing proper forEach in EnumMap) A JBS issue has already been submitted at https://bugs.openjdk.java.net/browse/JDK-8282178, and I have prepared a patch. This patch modifies the putAll implementations of a few JDK maps to let the callee feed entries through Map::forEach to be put into the maps. Two places of Map::entrySet calls in Collectors has also been updated. For most other existing usages in the JDK, I don't think they will benefit from such a migration: They mostly iterate on the entryset of the popular implementations that already host entries and are single-threaded, and I don't think it's in our best interest to touch those use cases. So, here are my questions: 1. Is such a concept of replacing Map::entrySet calls with Map::forEach calls reasonable, or is there any fundamental flaw? If the concept sounds good, I will submit a patch, so we can answer 2. Is the changes implemented correct for this concept, i.e. targeting code where users supply callee maps? Best regards From duke at openjdk.java.net Tue Feb 22 23:10:48 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 22 Feb 2022 23:10:48 GMT Subject: RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:52:58 GMT, Roger Riggs wrote: > fyi, the noreg-* labels apply to the bug report, not the PR. (and yes, they are informative when reviewing). Thanks for pointing that out. I thought I may have been reading some old documentation. > One of [JDK-8282239](https://bugs.openjdk.java.net/browse/JDK-8282239): or [JDK-8282219](https://bugs.openjdk.java.net/browse/JDK-8282219) should be closed as a duplicate. I agree, but I have no access to JBS as of yet. Could you take care of that @RogerRiggs? One of the PRs should be closed as well. Shall I close mine? ------------- PR: https://git.openjdk.java.net/jdk/pull/7581 From duke at openjdk.java.net Tue Feb 22 23:40:46 2022 From: duke at openjdk.java.net (liach) Date: Tue, 22 Feb 2022 23:40:46 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6] In-Reply-To: References: Message-ID: On Sun, 20 Feb 2022 06:39:26 GMT, liach wrote: >> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: >> >> remove missed whitespace > > src/java.base/share/classes/java/util/Random.java line 95: > >> 93: private static class RandomWrapper extends Random implements RandomGenerator { >> 94: private final RandomGenerator generator; >> 95: private final boolean initialized; > > Can we create a private or package-private constructor for `Random` for this subclass' constructor to call? The no-arg constructor has some unnecessary calculations, and the `long` constructor calls `setSeed`. A special `Random` constructor for this subclass allows removing this special logic (by not calling `setSeed` at all) and avoid redundant seed initialization. More specifically, in Random class, declare // special constructor for RandomWrapper to call private Random(Void unused) { this.seed = new AtomicLong(); } So the randomwrapper can be (with `initialized` field removed): private RandomWrapper(RandomGenerator randomToWrap) { super(null); this.generator = randomToWrap; } @Override public void setSeed(long seed) { throw new UnsupportedOperationException(); } Currently, the RandomWrapper constructor calls the no-arg super constructor implicitly, which has some overheads for unnecessary calculations. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From darcy at openjdk.java.net Wed Feb 23 00:40:44 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 23 Feb 2022 00:40:44 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v11] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add mask to access flag functionality. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/46d4d7ea..bb4a3013 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=09-10 Stats: 80 lines in 2 files changed: 78 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Wed Feb 23 00:45:55 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 23 Feb 2022 00:45:55 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v11] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 00:40:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add mask to access flag functionality. I've pushed an initial version of functionality to map from an integer mask to a set of access flags based on location. I suspect this will be refined and changed a bit before the code goes back. Potential changes I see now: * an ANY_CLASS location allowing the union of the flags for CLASS and INNER_CLASS (or a method providing equivalent functionality) * simple maskToAccessFlags(int mask) method that worked if all the bit positions were unambiguous. @asotona , how does this API look for your use cases? I'll start wiring up the various accessFlag methods on java.lang.Class, java.lang.reflect.* etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Wed Feb 23 00:46:23 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Wed, 23 Feb 2022 00:46:23 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v7] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: Remove changes from RandomGenerator ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/5dc0e1ea..399aa222 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=05-06 Stats: 18 lines in 1 file changed: 10 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Wed Feb 23 01:06:24 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Wed, 23 Feb 2022 01:06:24 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v8] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: check from master branch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/399aa222..65687cde Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=06-07 Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From jpai at openjdk.java.net Wed Feb 23 01:08:22 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Feb 2022 01:08:22 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:09:50 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: > - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. > - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. > > All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: > > > Using locale: he for Properties#store(OutputStream) test > test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure > java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 > at org.testng.Assert.fail(Assert.java:87) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) > at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > 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:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:828) > Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) > ... 30 more > > (in the exception above a locale with language `he` is being used) > > The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. Hello Naoto, thank you for the review. I've updated the PR with the suggested changes. Tests continue to pass with these changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From jpai at openjdk.java.net Wed Feb 23 01:08:21 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Feb 2022 01:08:21 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: > - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. > - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. > > All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: > > > Using locale: he for Properties#store(OutputStream) test > test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure > java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 > at org.testng.Assert.fail(Assert.java:87) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) > at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > 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:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:828) > Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) > ... 30 more > > (in the exception above a locale with language `he` is being used) > > The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - implement review comments - copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7558/files - new: https://git.openjdk.java.net/jdk/pull/7558/files/da0e4fbd..c5dd7f79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=00-01 Stats: 20 lines in 2 files changed: 6 ins; 7 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7558/head:pull/7558 PR: https://git.openjdk.java.net/jdk/pull/7558 From jpai at openjdk.java.net Wed Feb 23 01:15:56 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Feb 2022 01:15:56 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 17:31:14 GMT, Naoto Sato wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - implement review comments >> - copyright years > > test/jdk/java/util/Properties/PropertiesStoreTest.java line 50: > >> 48: * @test >> 49: * @summary tests the order in which the Properties.store() method writes out the properties >> 50: * @bug 8231640 > > Add the bug id, also `@modules jdk.localedata` needs to be added. I have added this to the updated PR. But just to understand why this is needed, I had a look at the jtreg tag specification doc, which states: > > a test will not be run if the system being tested does not contain all of the specified modules So with this `@modules` added, it will no longer run tests where the `jdk.localedata` isn't present. Given that this `PropertiesStoreTest` tests a few other things other than the locale insensitive parsing of the date comment, do you think adding this `@modules` would now skip some of the other testing in this test unnecessarily? Furthermore, since the `provideLocales()` data provider method in this test has necessary checks (via `getAvailableLocales()`) to only use the non-guaranteed locales if they are available, do you think this `@modules` is still needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From sviswanathan at openjdk.java.net Wed Feb 23 01:34:53 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 23 Feb 2022 01:34:53 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v6] In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 17:43:43 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- >> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98 >> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58 >> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56 >> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Fixing for windows failure. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4146: > 4144: vaddpd(xtmp1, src , xtmp1, vec_enc); > 4145: vrndscalepd(dst, xtmp1, 0x4, vec_enc); > 4146: evcvtpd2qq(dst, dst, vec_enc); Why do we need vrndscalepd in between, could we not directly use cvtpd2qq after vaddpd? ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From darcy at openjdk.java.net Wed Feb 23 02:13:21 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 23 Feb 2022 02:13:21 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v12] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Initial support for accessFlags methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/bb4a3013..e8f5b7d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=10-11 Stats: 53 lines in 5 files changed: 34 ins; 1 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From iklam at openjdk.java.net Wed Feb 23 03:57:16 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 23 Feb 2022 03:57:16 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v5] In-Reply-To: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: > **Background:** > > In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: > > > public enum Day { SUNDAY, MONDAY ... } > > > to > > > public class Day extends java.lang.Enum { > public static final SUNDAY = new Day("SUNDAY"); > public static final MONDAY = new Day("MONDAY"); ... > } > > > With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) > > **Fix:** > > During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. > > This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. > > **Verification:** > > To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt > > **Testing:** > > Passed Oracle CI tiers 1-4. WIll run tier 5 as well. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Fixed comments per @calvinccheung review - Merge branch 'master' into 8275731-heapshared-enum - Use InstanceKlass::do_local_static_fields for some field iterations - Merge branch 'master' into 8275731-heapshared-enum - added exclusions needed by "java -Xshare:dump -ea -esa" - Comments from @calvinccheung off-line - 8275731: CDS archived enums objects are recreated at runtime ------------- Changes: https://git.openjdk.java.net/jdk/pull/6653/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=04 Stats: 850 lines in 16 files changed: 807 ins; 2 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/6653.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653 PR: https://git.openjdk.java.net/jdk/pull/6653 From iklam at openjdk.java.net Wed Feb 23 04:15:28 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 23 Feb 2022 04:15:28 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v6] In-Reply-To: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: > **Background:** > > In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: > > > public enum Day { SUNDAY, MONDAY ... } > > > to > > > public class Day extends java.lang.Enum { > public static final SUNDAY = new Day("SUNDAY"); > public static final MONDAY = new Day("MONDAY"); ... > } > > > With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) > > **Fix:** > > During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. > > This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. > > **Verification:** > > To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt > > **Testing:** > > Passed Oracle CI tiers 1-4. WIll run tier 5 as well. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6653/files - new: https://git.openjdk.java.net/jdk/pull/6653/files/4764075e..c6e9be1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6653.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653 PR: https://git.openjdk.java.net/jdk/pull/6653 From jbhateja at openjdk.java.net Wed Feb 23 05:56:52 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 23 Feb 2022 05:56:52 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 09:24:47 GMT, Vamsi Parasa wrote: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. src/hotspot/cpu/x86/x86_64.ad line 8602: > 8600: __ jmp(done); > 8601: __ bind(neg_divisor_fastpath); > 8602: // Fastpath for divisor < 0: Move in macro assembly routine. src/hotspot/cpu/x86/x86_64.ad line 8633: > 8631: __ jmp(done); > 8632: __ bind(neg_divisor_fastpath); > 8633: // Fastpath for divisor < 0: Move in macro assembly rountine. src/hotspot/cpu/x86/x86_64.ad line 8722: > 8720: __ shrl(rax, 31); // quotient > 8721: __ sarl(tmp, 31); > 8722: __ andl(tmp, divisor); Move in macro assembly routine. src/hotspot/cpu/x86/x86_64.ad line 8763: > 8761: __ andnq(rax, rax, rdx); > 8762: __ movq(tmp, rax); > 8763: __ shrq(rax, 63); // quotient Move in macro assembly routine. src/hotspot/cpu/x86/x86_64.ad line 8902: > 8900: __ subl(tmp_rax, divisor); > 8901: __ andnl(tmp_rax, tmp_rax, rdx); > 8902: __ sarl(tmp_rax, 31); Please move this into a macro assembly routine. src/hotspot/cpu/x86/x86_64.ad line 8932: > 8930: // Fastpath when divisor < 0: > 8931: // remainder = dividend - (((dividend & ~(dividend - divisor)) >> (Long.SIZE - 1)) & divisor) > 8932: // See Hacker's Delight (2nd ed), section 9.3 which is implemented in java.lang.Long.remainderUnsigned() Please move it into a macro assembly routine. src/hotspot/share/opto/compile.cpp line 3499: > 3497: Node* d = n->find_similar(Op_UDivI); > 3498: if (d) { > 3499: // Replace them with a fused unsigned divmod if supported Can you explain a bit here, why can't this transformation be handled earlier ? src/hotspot/share/opto/divnode.cpp line 1350: > 1348: return NULL; > 1349: } > 1350: Please remove Value and Ideal routines if no explicit transforms are being done. src/hotspot/share/opto/divnode.cpp line 1362: > 1360: } > 1361: > 1362: //============================================================================= You can remove Ideal routine is not transformation is being done. test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java line 76: > 74: return quotients; > 75: } > 76: Return seems redundant here. test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java line 83: > 81: } > 82: return remainders; > 83: } Return seems redundant here. test/micro/org/openjdk/bench/java/lang/LongDivMod.java line 75: > 73: } > 74: return quotients; > 75: } Do we need to return quotients, since it's a field being explicitly modified. test/micro/org/openjdk/bench/java/lang/LongDivMod.java line 82: > 80: remainders[i] = Long.remainderUnsigned(dividends[i], divisors[i]); > 81: } > 82: return remainders; Same as above ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From asotona at openjdk.java.net Wed Feb 23 08:00:54 2022 From: asotona at openjdk.java.net (Adam Sotona) Date: Wed, 23 Feb 2022 08:00:54 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v12] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 02:13:21 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Initial support for accessFlags methods The API matches our use cases perfectly, I've just tested actual version, including use of the AccessFlag::maskToAccessFlags ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From simonis at openjdk.java.net Wed Feb 23 08:39:57 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Wed, 23 Feb 2022 08:39:57 GMT Subject: RFR: 8281962: Avoid unnecessary native calls in InflaterInputStream [v2] In-Reply-To: References: Message-ID: <5XZxHpGdJgSXFettRjPntlnMDAqb0gMsVg0-OXg2vGg=.ab2de989-2bc6-48c4-a7df-a92f24193bd8@github.com> On Mon, 21 Feb 2022 18:05:08 GMT, Lance Andersen wrote: >>> The change looks innocuous so it is probably OK. I would like to kick of our Mach5 runs to see if it shakes out any potential issues. >> >> @LanceAndersen , did you manage to get any Mach5 results? Did you find any issues? > >> > The change looks innocuous so it is probably OK. I would like to kick of our Mach5 runs to see if it shakes out any potential issues. >> >> @LanceAndersen , did you manage to get any Mach5 results? Did you find any issues? > > Tests are still running so no final results yet (please note that today is also a US holiday) Thanks @LanceAndersen! ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From simonis at openjdk.java.net Wed Feb 23 08:39:58 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Wed, 23 Feb 2022 08:39:58 GMT Subject: Integrated: 8281962: Avoid unnecessary native calls in InflaterInputStream In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 09:30:46 GMT, Volker Simonis wrote: > Currently, `InflaterInputStream::read()` first does a native call to the underlying zlib `inflate()` function and only afterwards checks if the inflater requires input (i.e. `Inflater::needsInput()`) or has finished inflating (`Inflater::finished()`). This leads to an unnecessary native call to `inflate()` when `InflaterInputStream::read()` is invoked for the very first time because `Inflater::fill()` hasn't been called and another unnecessary native call to detect the end of the stream. For small streams/files which completely fit into the output buffer passed to `InflaterInputStream::read()` we can therefore save two out of three native calls. The attached micro benchmark shows that this results in a 5%-10% performance improvement for zip files of sizes between 4096 to 256 bytes (notice that in common jars like Tomcat, Spring-Boot, Maven, Jackson, etc. about 60-80% of the classes are smaller than 4096 bytes). > > > before JDK-8281962 > ------------------ > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.571 ? 0.120 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.861 ? 0.064 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 5.110 ? 0.278 us/op > > after JDK-8281962 > ----------------- > Benchmark (size) Mode Cnt Score Error Units > InflaterInputStreams.inflaterInputStreamRead 256 avgt 5 2.332 ? 0.081 us/op > InflaterInputStreams.inflaterInputStreamRead 512 avgt 5 2.691 ? 0.293 us/op > InflaterInputStreams.inflaterInputStreamRead 4096 avgt 5 4.812 ? 1.038 us/op > > > Tested with the JTreg zip/jar/zipfs and the JCK zip/jar tests. > > As a side effect, this change also fixes an issue with alternative zlib implementations like zlib-Chromium or zlib-Cloudflare which pad the inflated bytes with a specif byte pattern at the end of the output for debugging purpose. This breaks code patterns like the following: > > > int readcount = 0; > while ((bytesRead = inflaterInputStream.read(data, 0, bufferSize)) != -1) { > outputStream.write(data, 0, bytesRead); > readCount++; > } > if (readCount == 1) { > return data; // <---- first bytes might be overwritten > } > return outputStream.toByteArray(); > > > Even if the whole data fits into the `data` array during the first call to `inflaterInputStream.read()`, we still need a second call to `inflaterInputStream.read()` in order to detect the end of the inflater stream. If this second call calls into the native `inflate()` function of Cloudflare/Chromium's zlib version, this will still write some padding bytes at the beginning of the `data` array and overwrite the previously read data. This issue has been reported in Spring [1] and ASM [2] when using these libraries with Cloudflares zlib version (by setting `LD_LIBRARY_PATH` accordingly). > > [1] https://github.com/spring-projects/spring-framework/issues/27429 > [2] https://gitlab.ow2.org/asm/asm/-/issues/317955 This pull request has now been integrated. Changeset: 378fa507 Author: Volker Simonis URL: https://git.openjdk.java.net/jdk/commit/378fa507a29f382e5534226612e154a37618ab91 Stats: 116 lines in 2 files changed: 114 ins; 0 del; 2 mod 8281962: Avoid unnecessary native calls in InflaterInputStream Reviewed-by: clanger, redestad, alanb, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7492 From jbhateja at openjdk.java.net Wed Feb 23 09:03:39 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 23 Feb 2022 09:03:39 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v6] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 01:31:24 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Fixing for windows failure. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4146: > >> 4144: vaddpd(xtmp1, src , xtmp1, vec_enc); >> 4145: vrndscalepd(dst, xtmp1, 0x4, vec_enc); >> 4146: evcvtpd2qq(dst, dst, vec_enc); > > Why do we need vrndscalepd in between, could we not directly use cvtpd2qq after vaddpd? Thanks @sviswa7 , when a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. DONE. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Wed Feb 23 09:03:37 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 23 Feb 2022 09:03:37 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v7] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- > 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98 > 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58 > 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56 > 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Review comments resolved. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/f35ed9cf..6c869c76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=05-06 Stats: 7 lines in 2 files changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From itakiguchi at openjdk.java.net Wed Feb 23 09:46:28 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 23 Feb 2022 09:46:28 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v3] In-Reply-To: References: Message-ID: > Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > The test was failed by: > Incorrect handling of envstrings containing NULs > > According to my investigation, this issue was happened after following change was applied. > JDK-8272600: (test) Use native "sleep" in Basic.java > > test.nativepath value was added into AIX's LIBPATH during running this testcase. > On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: Change LIBPATH usage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7574/files - new: https://git.openjdk.java.net/jdk/pull/7574/files/8b88686d..eff26e8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=01-02 Stats: 11 lines in 1 file changed: 1 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7574/head:pull/7574 PR: https://git.openjdk.java.net/jdk/pull/7574 From itakiguchi at openjdk.java.net Wed Feb 23 10:17:55 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 23 Feb 2022 10:17:55 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2] In-Reply-To: References: Message-ID: <4CBRumLEGvplBvmUdMGSSpt2qoQ2VGGjWYLMepAsEYI=.c27e22c8-8d49-43e0-814d-cd219bb90cc0@github.com> On Tue, 22 Feb 2022 18:10:28 GMT, Roger Riggs wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> Use expectedLibpath > > For my curiosity, how is AIX different from other Linux in that the test.nativepath is not/should not be in LIBPATH? @RogerRiggs Many thanks. that's good point. Only 1st part has `test.nativepath` because of following code. if (AIX.is()) { pb.environment().put("LIBPATH", libpath); } On current condition, parent (main) process have `test.nativepath` setting into LIBPATH environment, but child process does not require `test.nativepath` setting. So just `libpath` value should not have `test.nativepath` related entry. And above code does not require on current condition and this test said "Pass Empty environment to child". So it should be removed. #7581 is exactly same issue. Please choose the appropriate one. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From alanb at openjdk.java.net Wed Feb 23 10:38:56 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 23 Feb 2022 10:38:56 GMT Subject: RFR: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() [v8] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:05:32 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review the attached patch to address >> >> - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter >> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs >> >> Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Modified and clarified test comments Thanks for the update to the test to provide instructions on how to re-create the JAR and sign it. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7348 From redestad at openjdk.java.net Wed Feb 23 12:59:31 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 23 Feb 2022 12:59:31 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v5] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Fix TestCountPositives to correctly allow 0 return when expected != len (for now) - aarch64: fix issue with short inputs divisible by wordSize ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/a5e28b32..a95680cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=03-04 Stats: 23 lines in 3 files changed: 3 ins; 4 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From jlaskey at openjdk.java.net Wed Feb 23 13:16:58 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 23 Feb 2022 13:16:58 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v8] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 01:06:24 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > check from master branch src/java.base/share/classes/java/util/Random.java line 259: > 257: > 258: private static final AtomicLong seedUniquifier > 259: = new AtomicLong(8682522807148012L); This seems (to me) like an odd indentation change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From redestad at openjdk.java.net Wed Feb 23 14:19:20 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 23 Feb 2022 14:19:20 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Resolve merge conflict - Fix TestCountPositives to correctly allow 0 return when expected != len (for now) - aarch64: fix issue with short inputs divisible by wordSize - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step. - Revert micro changes, split out to #7516 - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives - Merge branch 'master' into count_positives - Restore partial vector checks in AVX2 and SSE intrinsic variants - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral - Simplify changes to encodeUTF8 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce ------------- Changes: https://git.openjdk.java.net/jdk/pull/7231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=05 Stats: 532 lines in 29 files changed: 308 ins; 53 del; 171 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From rriggs at openjdk.java.net Wed Feb 23 14:31:46 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Feb 2022 14:31:46 GMT Subject: RFR: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 22:04:38 GMT, Tyler Steele wrote: >> This test had two failing sections on AIX related to an incorrect expected value for LIBPATH. The two (previously failing) test sections are below. >> >> - Test Runtime.exec(...envp...) with envstrings with initial `=' >> - Test Runtime.exec(...envp...) with envstrings containing NULs >> >> This PR modifies the environment passed to the process at ...exec(cmdp, **envp**) to include the LIBPATH of the parent. With this change, the expected libpath matches the libpath returned by the process. >> >> ### Alternatives >> >> An equivalent change would be to modify the libpath variable used to set the expected value for the test without explicitly setting the LIBPATH in process invocation. This would involve removing the libpath for .../jtreg/native that is added by the test runner by command-line option `-J-Dtest.nativepath=...images/test/jdk/jtreg/native `. This change would be reasonable, but I prefer the approach taken in this PR. >> >> ### Testing >> >> This test now passes on my test machine running AIX 7.1. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Updates copyright year & adds bugid ok, I closed JDK-8282239 as a duplicate. This PR can be closed. Comments appreciated on https://github.com/openjdk/jdk/pull/7574. ------------- PR: https://git.openjdk.java.net/jdk/pull/7581 From duke at openjdk.java.net Wed Feb 23 15:03:54 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 23 Feb 2022 15:03:54 GMT Subject: Withdrawn: 8282239 [testbug, AIX] ProcessBuilder/Basic.java fails with incorrect LIBPATH In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 21:22:57 GMT, Tyler Steele wrote: > This test had two failing sections on AIX related to an incorrect expected value for LIBPATH. The two (previously failing) test sections are below. > > - Test Runtime.exec(...envp...) with envstrings with initial `=' > - Test Runtime.exec(...envp...) with envstrings containing NULs > > This PR modifies the environment passed to the process at ...exec(cmdp, **envp**) to include the LIBPATH of the parent. With this change, the expected libpath matches the libpath returned by the process. > > ### Alternatives > > An equivalent change would be to modify the libpath variable used to set the expected value for the test without explicitly setting the LIBPATH in process invocation. This would involve removing the libpath for .../jtreg/native that is added by the test runner by command-line option `-J-Dtest.nativepath=...images/test/jdk/jtreg/native `. This change would be reasonable, but I prefer the approach taken in this PR. > > ### Testing > > This test now passes on my test machine running AIX 7.1. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7581 From duke at openjdk.java.net Wed Feb 23 15:47:53 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 23 Feb 2022 15:47:53 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2] In-Reply-To: <4CBRumLEGvplBvmUdMGSSpt2qoQ2VGGjWYLMepAsEYI=.c27e22c8-8d49-43e0-814d-cd219bb90cc0@github.com> References: <4CBRumLEGvplBvmUdMGSSpt2qoQ2VGGjWYLMepAsEYI=.c27e22c8-8d49-43e0-814d-cd219bb90cc0@github.com> Message-ID: <-OiZx1ZO2SLtoUdho0hSJicSJTeDp4xJGM4f_iPQlmo=.eba18caa-079e-4f1c-b29e-dd0f426d47dd@github.com> On Wed, 23 Feb 2022 10:14:44 GMT, Ichiroh Takiguchi wrote: >> For my curiosity, how is AIX different from other Linux in that the test.nativepath is not/should not be in LIBPATH? > > @RogerRiggs > Many thanks. that's good point. > Only 1st part has `test.nativepath` because of following code. > > if (AIX.is()) { > pb.environment().put("LIBPATH", libpath); > } > > On current condition, parent (main) process have `test.nativepath` setting into LIBPATH environment, but child process does not require `test.nativepath` setting. > So just `libpath` value should not have `test.nativepath` related entry. > And above code does not require on current condition and this test said "Pass Empty environment to child". > So it should be removed. > > #7581 is exactly same issue. > Please choose the appropriate one. Hi @takiguc ??, thanks for your changes. I closed my PR in favour of yours; we definitely don't need two PRs for this issue :-) One comment on the approach you took. I considered modifying the static libpath variable as well, but what really swayed me away from choosing that route is the Windows tests. On Windows, the situation is analogous to AIX in that a static systemroot variable is set by querying the parent environment, but it is explicitly passed to the child process[es] when they are created. This ensures that the systemroot returned by the child process is the same as the expected value. Admittedly it's a bit of a nit-pick, but I think having the Windows version of the test do one thing and AIX version do another make it harder to understand what is going on. It's for that reason that I took the approach that I did in my PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From duke at openjdk.java.net Wed Feb 23 16:33:47 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 23 Feb 2022 16:33:47 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v3] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 09:46:28 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Change LIBPATH usage test/jdk/java/lang/ProcessBuilder/Basic.java line 85: > 83: if (AIX.is()) { > 84: String nativepath = System.getProperty("test.nativepath"); > 85: if (nativepath != null) { I think this null check should be modified. There are two issues at play. - If nativepath is null it will be caught by the filter below. So it is safe to pass it past this point in either case (null or non-null). - If libpathString is null there will be a NullPointerException when split gets called on it below. I believe there are at least two reasonable choices here. The first is to change nativepath -> libpathString in this null check. This option guards against calling String.split on a null value. Alternatively, you could trust that since this code doesn't get called unless AIX.is() returns true, that it's safe to remove this check altogether. This second option is only viable if we know LIBPATH is always set on AIX. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From duke at openjdk.java.net Wed Feb 23 16:58:56 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 23 Feb 2022 16:58:56 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 05:51:52 GMT, Quan Anh Mai wrote: > Should the?other `requireNonNull` be?`ForceInline` as?well? Probably?yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7543 From lancea at openjdk.java.net Wed Feb 23 17:01:01 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 23 Feb 2022 17:01:01 GMT Subject: Integrated: 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen wrote: > Hi all, > > Please review the attached patch to address > > - That JarFile::getInputStream did not check for a null ZipEntry passed as a parameter > - Have Zip/JarFile::getInputStream throw a ZipException in the event that an unexpected exception occurs > > Mach5 tiers1-3 runs are clean as are the TCK java.util.zip and java.util.jar test runs > > Best > Lance This pull request has now been integrated. Changeset: a020b6ba Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/a020b6ba8f38fe85fb26972a51e4c1068408b1c1 Stats: 1103 lines in 3 files changed: 1071 ins; 0 del; 32 mod 8280409: JarFile::getInputStream can fail with NPE accessing ze.getName() Reviewed-by: mullan, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7348 From naoto at openjdk.java.net Wed Feb 23 18:29:46 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 23 Feb 2022 18:29:46 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v2] In-Reply-To: References: Message-ID: <6kKo7ooh94f_NeoidGjtCLQyw_VsMb5kAOYiebCmk5Q=.2aa263a6-71e7-4f06-b9b8-f8957d533f73@github.com> On Wed, 23 Feb 2022 01:08:21 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? >> >> As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: >> - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. >> - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. >> >> All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: >> >> >> Using locale: he for Properties#store(OutputStream) test >> test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure >> java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 >> at org.testng.Assert.fail(Assert.java:87) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) >> at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> 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:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:828) >> Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 >> at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) >> at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) >> ... 30 more >> >> (in the exception above a locale with language `he` is being used) >> >> The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - implement review comments > - copyright years test/jdk/java/util/Properties/PropertiesStoreTest.java line 51: > 49: * @summary tests the order in which the Properties.store() method writes out the properties > 50: * @bug 8231640 8282023 > 51: * @modules jdk.localedata OK, you can remove `@modules jdk.localedata` so that other tests would run. (it'd be unusual setup, but still possible with jlink) test/jdk/java/util/Properties/PropertiesStoreTest.java line 60: > 58: // it internally calls the Date.toString() which always writes in a locale insensitive manner > 59: private static final DateTimeFormatter formatter = DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN) > 60: .withLocale(Locale.ROOT); Should have noticed before, but you can call the convenient overload of `ofPattern(DATE_FORMAT_PATTERN, Locale.ROOT)` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From itakiguchi at openjdk.java.net Wed Feb 23 18:49:22 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 23 Feb 2022 18:49:22 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: > Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > The test was failed by: > Incorrect handling of envstrings containing NULs > > According to my investigation, this issue was happened after following change was applied. > JDK-8272600: (test) Use native "sleep" in Basic.java > > test.nativepath value was added into AIX's LIBPATH during running this testcase. > On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: Add null check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7574/files - new: https://git.openjdk.java.net/jdk/pull/7574/files/eff26e8f..b6d6afe7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7574/head:pull/7574 PR: https://git.openjdk.java.net/jdk/pull/7574 From itakiguchi at openjdk.java.net Wed Feb 23 18:49:23 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Wed, 23 Feb 2022 18:49:23 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v2] In-Reply-To: <-OiZx1ZO2SLtoUdho0hSJicSJTeDp4xJGM4f_iPQlmo=.eba18caa-079e-4f1c-b29e-dd0f426d47dd@github.com> References: <4CBRumLEGvplBvmUdMGSSpt2qoQ2VGGjWYLMepAsEYI=.c27e22c8-8d49-43e0-814d-cd219bb90cc0@github.com> <-OiZx1ZO2SLtoUdho0hSJicSJTeDp4xJGM4f_iPQlmo=.eba18caa-079e-4f1c-b29e-dd0f426d47dd@github.com> Message-ID: On Wed, 23 Feb 2022 15:44:07 GMT, Tyler Steele wrote: >> @RogerRiggs >> Many thanks. that's good point. >> Only 1st part has `test.nativepath` because of following code. >> >> if (AIX.is()) { >> pb.environment().put("LIBPATH", libpath); >> } >> >> On current condition, parent (main) process have `test.nativepath` setting into LIBPATH environment, but child process does not require `test.nativepath` setting. >> So just `libpath` value should not have `test.nativepath` related entry. >> And above code does not require on current condition and this test said "Pass Empty environment to child". >> So it should be removed. >> >> #7581 is exactly same issue. >> Please choose the appropriate one. > > Hi @takiguc ??, thanks for your changes. I closed my PR in favour of yours; we definitely don't need two PRs for this issue :-) > > One comment on the approach you took. I considered modifying the static libpath variable as well, but what really swayed me away from choosing that route is the Windows tests. On Windows, the situation is analogous to AIX in that a static systemroot variable is set by querying the parent environment, but it is explicitly passed to the child process[es] when they are created. This ensures that the systemroot returned by the child process is the same as the expected value. Admittedly it's a bit of a nit-pick, but I think having the Windows version of the test do one thing and AIX version do another make it harder to understand what is going on. It's for that reason that I took the approach that I did in my PR. @backwaterred I applied change. Please check this one ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From rriggs at openjdk.java.net Wed Feb 23 19:21:57 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Feb 2022 19:21:57 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v2] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 01:08:21 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? >> >> As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: >> - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. >> - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. >> >> All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: >> >> >> Using locale: he for Properties#store(OutputStream) test >> test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure >> java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 >> at org.testng.Assert.fail(Assert.java:87) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) >> at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> 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:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:828) >> Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 >> at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) >> at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) >> ... 30 more >> >> (in the exception above a locale with language `he` is being used) >> >> The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - implement review comments > - copyright years test/jdk/java/util/Properties/PropertiesStoreTest.java line 61: > 59: private static final DateTimeFormatter formatter = DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN) > 60: .withLocale(Locale.ROOT); > 61: private static final Locale prevLocale = Locale.getDefault(); By convention, static final field names are uppercase. It make the code using them easier to read. test/jdk/java/util/Properties/PropertiesStoreTest.java line 112: > 110: if (!locale.getLanguage().isEmpty() && !locale.getLanguage().equals("en")) { > 111: nonEnglishLocale = locale; > 112: System.out.println("Selected non-english locale: " + nonEnglishLocale + " for tests"); TestNG includes the arguments in the output when the test is run. test/jdk/java/util/Properties/PropertiesStoreTest.java line 116: > 114: } > 115: } > 116: if (nonEnglishLocale == null) { Alternatively, create a Set, to avoid duplicates, adding the candidates as they are discovered and finally convert the Set to an Object[][]. It may be a bit easier to maintain. private static Object[][] provideLocales() { // pick a non-english locale for testing Set locales = Arrays.stream(Locale.getAvailableLocales()) .filter(l -> !l.getLanguage().isEmpty() && !l.getLanguage().equals("en")) .limit(1) .collect(Collectors.toSet()); locales.add(Locale.getDefault()); locales.add(Locale.US); locales.add(Locale.ROOT); return locales.stream() .map(m -> new Locale[] {m}) .toArray(n -> new Object[n][0]); } ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From rriggs at openjdk.java.net Wed Feb 23 19:45:55 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Feb 2022 19:45:55 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true In-Reply-To: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> Message-ID: On Fri, 18 Feb 2022 15:29:34 GMT, Roger Riggs wrote: > In some Linux configurations, the Linux home directory provided by getpwent is not usable. > The value of the system property `user.home` should fallback to the value of $HOME > if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. > > If $HOME is undefined or empty, the value of the getpwent.user_home is retained. > > There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 > > The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. The CSR has been approved, please review the PR and the Release note: https://bugs.openjdk.java.net/browse/JDK-8282101 ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From rriggs at openjdk.java.net Wed Feb 23 19:55:48 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Feb 2022 19:55:48 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check Which version of AIX is this failing on? I notice that for AIX 5.3, the usage of LIBPATH is being migrated to LD_LIBRARY_PATH with LIBPATH as a fallback. Jtreg when setting up the test with the "/native" on the @run line adds `test.nativepath` to `LIBPATH`. What I'm puzzled by is the original case in which `test.nativepath` was appended to `LIBPATH` and passed to the child and yet the child returns the value of `LIBPATH` without `test.nativepath`. It may not be material to fixing the errors, but does make me curious about what's really going on. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From naoto at openjdk.java.net Wed Feb 23 20:02:51 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 23 Feb 2022 20:02:51 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true In-Reply-To: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> Message-ID: On Fri, 18 Feb 2022 15:29:34 GMT, Roger Riggs wrote: > In some Linux configurations, the Linux home directory provided by getpwent is not usable. > The value of the system property `user.home` should fallback to the value of $HOME > if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. > > If $HOME is undefined or empty, the value of the getpwent.user_home is retained. > > There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 > > The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. src/java.base/unix/native/libjava/java_props_md.c line 498: > 496: if ((user_home != NULL) && (user_home[0] != '\0')) { > 497: sprops.user_home = user_home; > 498: } Is there any possibility where `user.home` is not initialized, and later causes SEGV or NPE? I just wonder the previous version always init to `?` which is odd, but guaranteed not to cause those errors. ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From rriggs at openjdk.java.net Wed Feb 23 20:02:56 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Feb 2022 20:02:56 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check The changes seem ok, modifying both the LIBPATH passed in the environment and the expected return value. Since both of these tests are testing a different condition, the presence/accuracy of LIBPATH is not the point of the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From asemenyuk at openjdk.java.net Wed Feb 23 20:33:54 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 23 Feb 2022 20:33:54 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v4] In-Reply-To: References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Thu, 17 Feb 2022 06:54:33 GMT, Alexander Matveev wrote: >> Added ability to override description for additional launchers via "description" property. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8279995: jpackage --add-launcher option should allow overriding description [v4] test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 165: > 163: > 164: return description; > 165: } How about this: public static String getExecutableDesciption(Path pathToExeFile) { Executor exec = Executor.of("powershell", "-NoLogo", "-NoProfile", "-Command", "(Get-Item \\"" + pathToExeFile.toAbsolutePath() + "\\").VersionInfo | select FileDescription"); var lineIt = exec.dumpOutput().executeAndGetOutput().iterator(); while (lineIt.hasNext()) { var line = lineIt.next(); if (line.trim().equals("FileDescription")) { // Skip "---------------" and move to the description value lineIt.next(); var description = lineIt.next().trim(); if (lineIt.hasNext()) { throw new RuntimeException("Unexpected input"); } return description; } } throw new RuntimeException(String.format( "Failed to get file description of [%s]", pathToExeFile)); } Added `Executor.dumpOutput()` call to save the output of powershell command in the test log for easier debugging. No null initialized `description` variable. No iteration over the list using the index. Check for the end of the output. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From rriggs at openjdk.java.net Wed Feb 23 21:51:44 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Feb 2022 21:51:44 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add a new line to the end of test file for JDK-8282008 Please close this PR; the proposed change to the application should resolve the issue. The issue should be closed as "not-an-issue". ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From rriggs at openjdk.java.net Wed Feb 23 21:58:53 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Feb 2022 21:58:53 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true In-Reply-To: References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> Message-ID: <_JGlXREye3lLm3SpUdRg9F3IiNRZhnSFhYPGWoie83o=.6da73e31-aa9d-474a-a7c8-7f2786e25eaf@github.com> On Wed, 23 Feb 2022 19:59:35 GMT, Naoto Sato wrote: >> In some Linux configurations, the Linux home directory provided by getpwent is not usable. >> The value of the system property `user.home` should fallback to the value of $HOME >> if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. >> >> If $HOME is undefined or empty, the value of the getpwent.user_home is retained. >> >> There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 >> >> The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. > > src/java.base/unix/native/libjava/java_props_md.c line 498: > >> 496: if ((user_home != NULL) && (user_home[0] != '\0')) { >> 497: sprops.user_home = user_home; >> 498: } > > Is there any possibility where `user.home` is not initialized, and later causes SEGV or NPE? I just wonder the previous version always init to `?` which is odd, but guaranteed not to cause those errors. I can't imagine it not being set. But it is easier to track down the source of a "?" than the source of null. I thought of changing from "?" to "UNKNOWN" or "NOHOMEDIR" or something but it seems quite remote after adding the fallback to $HOME. ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From rriggs at openjdk.java.net Wed Feb 23 22:00:19 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Feb 2022 22:00:19 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true [v2] In-Reply-To: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> Message-ID: <-exPyplDA5Yz3A0_wKGc6GNp-UjTwOcpq-3VfXSjQRo=.27d73528-2cdd-4984-8662-929a12f186e7@github.com> > In some Linux configurations, the Linux home directory provided by getpwent is not usable. > The value of the system property `user.home` should fallback to the value of $HOME > if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. > > If $HOME is undefined or empty, the value of the getpwent.user_home is retained. > > There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 > > The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: fallback to '?' for user.home if both the pw_dir and /Users/rriggs are not valid ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7534/files - new: https://git.openjdk.java.net/jdk/pull/7534/files/d67d2c44..ad7c0287 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7534&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7534&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7534.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7534/head:pull/7534 PR: https://git.openjdk.java.net/jdk/pull/7534 From naoto at openjdk.java.net Wed Feb 23 22:16:06 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 23 Feb 2022 22:16:06 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true [v2] In-Reply-To: <_JGlXREye3lLm3SpUdRg9F3IiNRZhnSFhYPGWoie83o=.6da73e31-aa9d-474a-a7c8-7f2786e25eaf@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> <_JGlXREye3lLm3SpUdRg9F3IiNRZhnSFhYPGWoie83o=.6da73e31-aa9d-474a-a7c8-7f2786e25eaf@github.com> Message-ID: On Wed, 23 Feb 2022 21:51:50 GMT, Roger Riggs wrote: >> src/java.base/unix/native/libjava/java_props_md.c line 498: >> >>> 496: if ((user_home != NULL) && (user_home[0] != '\0')) { >>> 497: sprops.user_home = user_home; >>> 498: } >> >> Is there any possibility where `user.home` is not initialized, and later causes SEGV or NPE? I just wonder the previous version always init to `?` which is odd, but guaranteed not to cause those errors. > > I can't imagine it not being set. But it is easier to track down the source of a "?" than the source of null. > I thought of changing from "?" to "UNKNOWN" or "NOHOMEDIR" or something but it seems quite remote > after adding the fallback to $HOME. Another option is an empty string `""`, but I don't have a strong preference if it won't throw any errors. ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From naoto at openjdk.java.net Wed Feb 23 22:16:05 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 23 Feb 2022 22:16:05 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true [v2] In-Reply-To: <-exPyplDA5Yz3A0_wKGc6GNp-UjTwOcpq-3VfXSjQRo=.27d73528-2cdd-4984-8662-929a12f186e7@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> <-exPyplDA5Yz3A0_wKGc6GNp-UjTwOcpq-3VfXSjQRo=.27d73528-2cdd-4984-8662-929a12f186e7@github.com> Message-ID: On Wed, 23 Feb 2022 22:00:19 GMT, Roger Riggs wrote: >> In some Linux configurations, the Linux home directory provided by getpwent is not usable. >> The value of the system property `user.home` should fallback to the value of $HOME >> if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. >> >> If $HOME is undefined or empty, the value of the getpwent.user_home is retained. >> >> There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 >> >> The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > fallback to '?' for user.home if both the pw_dir and /Users/rriggs are not valid Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From duke at openjdk.java.net Wed Feb 23 22:42:22 2022 From: duke at openjdk.java.net (liach) Date: Wed, 23 Feb 2022 22:42:22 GMT Subject: RFR: 8282178: Replace simple iterations of Map.entrySet with Map.forEach calls Message-ID: Replaces simple `for (Map.Entry entry : map.entrySet())` with `map.forEach((k, v) ->)` calls. This change is better for thread-safety and reduces allocation for some map implementations. A more in-depth description of benefits is available at https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086201.html and at the JBS issue itself. A [jmh comparison](https://jmh.morethan.io/?sources=https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/base-results.json,https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/head-results.json) on the performance of the existing `HashMapBench` shows that the performance of `putAll` for `HashMap` has not significantly changed. ------------- Commit messages: - Merge branch 'master' of https://git.openjdk.java.net/jdk into map-foreach - Fix initialization issues - 8282178: Replace simple iterations of Map.entrySet with Map.forEach calls Changes: https://git.openjdk.java.net/jdk/pull/7601/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7601&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282178 Stats: 47 lines in 7 files changed: 26 ins; 6 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/7601.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7601/head:pull/7601 PR: https://git.openjdk.java.net/jdk/pull/7601 From duke at openjdk.java.net Wed Feb 23 22:48:07 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 23 Feb 2022 22:48:07 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 05:43:10 GMT, Jatin Bhateja wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > src/hotspot/cpu/x86/x86_64.ad line 8602: > >> 8600: __ jmp(done); >> 8601: __ bind(neg_divisor_fastpath); >> 8602: // Fastpath for divisor < 0: > > Move in macro assembly routine. Sure, will move it to a macro assembly routine > src/hotspot/cpu/x86/x86_64.ad line 8633: > >> 8631: __ jmp(done); >> 8632: __ bind(neg_divisor_fastpath); >> 8633: // Fastpath for divisor < 0: > > Move in macro assembly rountine. Sure, will move it to a macro assembly routine > src/hotspot/cpu/x86/x86_64.ad line 8902: > >> 8900: __ subl(tmp_rax, divisor); >> 8901: __ andnl(tmp_rax, tmp_rax, rdx); >> 8902: __ sarl(tmp_rax, 31); > > Please move this into a macro assembly routine. Sure, will move it to a macro assembly routine > src/hotspot/cpu/x86/x86_64.ad line 8932: > >> 8930: // Fastpath when divisor < 0: >> 8931: // remainder = dividend - (((dividend & ~(dividend - divisor)) >> (Long.SIZE - 1)) & divisor) >> 8932: // See Hacker's Delight (2nd ed), section 9.3 which is implemented in java.lang.Long.remainderUnsigned() > > Please move it into a macro assembly routine. Sure, will move it to a macro assembly routine > src/hotspot/share/opto/compile.cpp line 3499: > >> 3497: Node* d = n->find_similar(Op_UDivI); >> 3498: if (d) { >> 3499: // Replace them with a fused unsigned divmod if supported > > Can you explain a bit here, why can't this transformation be handled earlier ? This is following the existing approach being used for signed DivMod > test/micro/org/openjdk/bench/java/lang/LongDivMod.java line 75: > >> 73: } >> 74: return quotients; >> 75: } > > Do we need to return quotients, since it's a field being explicitly modified. Will remove it. > test/micro/org/openjdk/bench/java/lang/LongDivMod.java line 82: > >> 80: remainders[i] = Long.remainderUnsigned(dividends[i], divisors[i]); >> 81: } >> 82: return remainders; > > Same as above Will remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Wed Feb 23 22:55:11 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 23 Feb 2022 22:55:11 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 05:52:00 GMT, Jatin Bhateja wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java line 76: > >> 74: return quotients; >> 75: } >> 76: > > Return seems redundant here. Will remove it. > test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java line 83: > >> 81: } >> 82: return remainders; >> 83: } > > Return seems redundant here. Will remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Wed Feb 23 23:11:03 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 23 Feb 2022 23:11:03 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 05:46:45 GMT, Jatin Bhateja wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > src/hotspot/share/opto/divnode.cpp line 1350: > >> 1348: return NULL; >> 1349: } >> 1350: > > Please remove Value and Ideal routines if no explicit transforms are being done. Will remove the unused transformations. > src/hotspot/share/opto/divnode.cpp line 1362: > >> 1360: } >> 1361: >> 1362: //============================================================================= > > You can remove Ideal routine is not transformation is being done. Will remove the unused transformation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Wed Feb 23 23:15:53 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 23 Feb 2022 23:15:53 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v2] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: Move intrinsic code to macro assembly routines; remove unused transformations for div and mod nodes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/fa57175a..7fc18af3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=00-01 Stats: 326 lines in 7 files changed: 137 ins; 176 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From duke at openjdk.java.net Wed Feb 23 23:18:56 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 23 Feb 2022 23:18:56 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v3] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: Fix line at end of file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/7fc18af3..13549290 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From darcy at openjdk.java.net Wed Feb 23 23:35:48 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 23 Feb 2022 23:35:48 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v13] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. 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: - Fix some bugs found by inspection, docs cleanup. - Merge branch 'master' into JDK-8266670 - Initial support for accessFlags methods - Add mask to access flag functionality. - Add test for location disjointness - Minor cleanup. - Merge branch 'master' into JDK-8266670 - Switch to location enum. - Respond to review feedback. - Add support for module flags; fix typo. - ... and 10 more: https://git.openjdk.java.net/jdk/compare/22fa6cf0...a43f7337 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/e8f5b7d7..a43f7337 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=11-12 Stats: 1819 lines in 40 files changed: 1595 ins; 106 del; 118 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From jincheng at ca.ibm.com Thu Feb 24 00:08:30 2022 From: jincheng at ca.ibm.com (Cheng Jin) Date: Thu, 24 Feb 2022 00:08:30 +0000 Subject: Incorrect return value for Java_jdk_internal_loader_NativeLibraries_load() in java.base/share/native/libjava/NativeLibraries.c Message-ID: Hi there, The return value from Java_jdk_internal_loader_NativeLibraries_load() at https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjava/NativeLibraries.c seems incorrect according to the code logic in there. Looking at the calling path from loadLibrary() to load() at src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java as follows: public NativeLibrary loadLibrary(Class fromClass, String name) { ... NativeLibrary lib = findFromPaths(LibraryPaths.SYS_PATHS, fromClass, name); <---------- if (lib == null && searchJavaLibraryPath) { lib = findFromPaths(LibraryPaths.USER_PATHS, fromClass, name); <---- } return lib; } private NativeLibrary findFromPaths(String[] paths, Class fromClass, String name) { for (String path : paths) { <---------------- keep searching the library paths till the library is located at the correct lib path File libfile = new File(path, System.mapLibraryName(name)); NativeLibrary nl = loadLibrary(fromClass, libfile); ? if (nl != null) { return nl; <-------------------- } libfile = ClassLoaderHelper.mapAlternativeName(libfile); if (libfile != null) { nl = loadLibrary(fromClass, libfile); if (nl != null) { return nl; } } } return null; } public NativeLibrary loadLibrary(Class fromClass, File file) { // Check to see if we're attempting to access a static library String name = findBuiltinLib(file.getName()); boolean isBuiltin = (name != null); ... return loadLibrary(fromClass, name, isBuiltin); <------------ } private NativeLibrary loadLibrary(Class fromClass, String name, boolean isBuiltin) { ... NativeLibraryImpl lib = new NativeLibraryImpl(fromClass, name, isBuiltin, isJNI); // load the native library NativeLibraryContext.push(lib); try { if (!lib.open()) { <--------------------- call load() return null; // fail to open the native library } ... // register the loaded native library loadedLibraryNames.add(name); libraries.put(name, lib); return lib; <--------------- return an invalid lib as lib.open() returns true } finally { releaseNativeLibraryLock(name); } ... } /* * Loads the named native library */ boolean open() { ... return load(this, name, isBuiltin, isJNI, loadLibraryOnlyIfPresent); } private static native boolean load(NativeLibraryImpl impl, String name, boolean isBuiltin, boolean isJNI, boolean throwExceptionIfFail); and then native code in java.base/share/native/libjava/NativeLibraries.c Java_jdk_internal_loader_NativeLibraries_load (JNIEnv *env, jobject this, jobject lib, jstring name, jboolean isBuiltin, jboolean isJNI, jboolean throwExceptionIfFail) { const char *cname; jint jniVersion; jthrowable cause; void * handle; jboolean loaded = JNI_FALSE; ... handle = isBuiltin ? procHandle : JVM_LoadLibrary(cname, throwExceptionIfFail); if (isJNI) { ... } (*env)->SetLongField(env, lib, handleID, ptr_to_jlong(handle)); loaded = JNI_TRUE; <----- always return true when isJNI is false and a null handle done: JNU_ReleaseStringPlatformChars(env, name, cname); return loaded; } Assuming there are multiple library paths existing in the jdk/lib which are added to sun.boot.library.path and java.library.path and the expected library (libnative.so) is only placed in jdk/lib. e.g. lib/libA lib/libB lib/libC lib/libnative.so when the code in findFromPaths() searches the library paths set in sun.boot.library.path and java.library.path starting from lib/LibA, it will end up with an invalid value if load() returns true in the case of a false isJNI and a null handle returned from JVM_LoadLibrary() as the library doesn't exist in lib/libA passed to JVM_LoadLibrary(). To ensure findFromPaths() keeps searching the remaining lib paths, the simple fix should look like: Java_jdk_internal_loader_NativeLibraries_load( ...) { ... (*env)->SetLongField(env, lib, handleID, ptr_to_jlong(handle)); if (handle) { <------------------------- return true only for a non-null handle loaded = JNI_TRUE; } ... } Please help check the code around there to see whether the fix is reasonable to avoid the unexpected situation as explained above (the problem was spotted since JDK17) Best Regards Cheng Jin From duke at openjdk.java.net Thu Feb 24 00:10:04 2022 From: duke at openjdk.java.net (PROgrm_JARvis) Date: Thu, 24 Feb 2022 00:10:04 GMT Subject: RFR: 8282178: Replace simple iterations of Map.entrySet with Map.forEach calls In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 22:33:42 GMT, liach wrote: > Replaces simple `for (Map.Entry entry : map.entrySet())` with `map.forEach((k, v) ->)` calls. This change is better for thread-safety and reduces allocation for some map implementations. > > A more in-depth description of benefits is available at https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086201.html and at the JBS issue itself. > > A [jmh comparison](https://jmh.morethan.io/?sources=https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/base-results.json,https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/head-results.json) on the performance of the existing `HashMapBench` shows that the performance of `putAll` for `HashMap` has not significantly changed. Changes requested by JarvisCraft at github.com (no known OpenJDK username). src/java.base/share/classes/java/util/AbstractMap.java line 881: > 879: * used before indy and lambda expressions are ready in initPhase1. > 880: * Regular code can safely use {@code map::put} instead. > 881: */ Looks like `@param ` and `@param ` are missing although Javadoc-comment is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/7601 From duke at openjdk.java.net Thu Feb 24 00:36:09 2022 From: duke at openjdk.java.net (liach) Date: Thu, 24 Feb 2022 00:36:09 GMT Subject: RFR: 8282178: Replace simple iterations of Map.entrySet with Map.forEach calls In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 23:50:49 GMT, PROgrm_JARvis wrote: >> Replaces simple `for (Map.Entry entry : map.entrySet())` with `map.forEach((k, v) ->)` calls. This change is better for thread-safety and reduces allocation for some map implementations. >> >> A more in-depth description of benefits is available at https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086201.html and at the JBS issue itself. >> >> A [jmh comparison](https://jmh.morethan.io/?sources=https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/base-results.json,https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/head-results.json) on the performance of the existing `HashMapBench` shows that the performance of `putAll` for `HashMap` has not significantly changed. > > src/java.base/share/classes/java/util/AbstractMap.java line 881: > >> 879: * used before indy and lambda expressions are ready in initPhase1. >> 880: * Regular code can safely use {@code map::put} instead. >> 881: */ > > Looks like `@param ` and `@param ` are missing although Javadoc-comment is used. This javadoc-style comment is designed like the javadoc for `jdk.internal.` packages or package-private elements in `java.` packages, which only talks about cautions and rationale for this class. It is not rendered in the generated API documentations and not a public API. ------------- PR: https://git.openjdk.java.net/jdk/pull/7601 From darcy at openjdk.java.net Thu Feb 24 00:37:52 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 24 Feb 2022 00:37:52 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v14] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Appease jcheck. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/a43f7337..88728759 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Thu Feb 24 00:39:31 2022 From: duke at openjdk.java.net (ExE Boss) Date: Thu, 24 Feb 2022 00:39:31 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v12] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 02:13:21 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Initial support for accessFlags methods src/java.base/share/classes/java/lang/Class.java line 1331: > 1329: // This likely needs some refinement. Exploration of hidden > 1330: // classes, array classes. Location.CLASS allows SUPER and > 1331: // AccessFlag.MODULE with INNER_CLASS forbids. INNER_CLASS Typo: Suggestion: // AccessFlag.MODULE which INNER_CLASS forbids. INNER_CLASS src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 367: > 365: INTERFACE, ABSTRACT, > 366: SYNTHETIC, ANNOTATION, > 367: ENUM, AccessFlag.MODULE)), I?don?t think?that this?needs to?be?qualified: Suggestion: ENUM, MODULE)), ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From sviswanathan at openjdk.java.net Thu Feb 24 00:47:06 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 24 Feb 2022 00:47:06 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v7] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 09:03:37 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- >> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98 >> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58 >> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56 >> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Review comments resolved. Also curious, how does the performance look with all these changes. src/hotspot/cpu/x86/assembler_x86.hpp line 2254: > 2252: void vroundps(XMMRegister dst, XMMRegister src, int32_t rmode, int vector_len); > 2253: void vrndscaleps(XMMRegister dst, XMMRegister src, int32_t rmode, int vector_len); > 2254: These instructions are not used anymore and can be removed. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4116: > 4114: KRegister ktmp1, KRegister ktmp2, AddressLiteral double_sign_flip, > 4115: Register scratch, int vec_enc) { > 4116: evcvttpd2qq(dst, src, vec_enc); The vcvttpd2qq instruction on overflow sets the result as 2^w -1 where w is 64. Whereas the special case handling is expecting 0x80000..... src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4145: > 4143: evpbroadcastq(xtmp1, scratch, vec_enc); > 4144: vaddpd(xtmp1, src , xtmp1, vec_enc); > 4145: evcvtpd2qq(dst, xtmp1, vec_enc); The vcvtpd2qq instruction on overflow also sets the result as 2^w -1 where w is 64. Whereas the special case handling is expecting 0x80000..... src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4176: > 4174: vpbroadcastd(xtmp1, xtmp1, vec_enc); > 4175: vaddps(xtmp1, src , xtmp1, vec_enc); > 4176: vcvtps2dq(dst, xtmp1, vec_enc); The vcvtps2dq returns 0x7FFFFFFF in case of overflow whereas the special case handling expects 0x80000000 incase of overflow. The same question applies to the corresponding vector_round_float_avx() implementation as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From darcy at openjdk.java.net Thu Feb 24 01:24:49 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 24 Feb 2022 01:24:49 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v15] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Typo fix; add implSpec to Executable. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/88728759..aa2b5eed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=13-14 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Thu Feb 24 01:24:50 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 24 Feb 2022 01:24:50 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v12] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 17:05:58 GMT, ExE Boss wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Initial support for accessFlags methods > > src/java.base/share/classes/java/lang/Class.java line 1331: > >> 1329: // This likely needs some refinement. Exploration of hidden >> 1330: // classes, array classes. Location.CLASS allows SUPER and >> 1331: // AccessFlag.MODULE with INNER_CLASS forbids. INNER_CLASS > > Typo: > Suggestion: > > // AccessFlag.MODULE which INNER_CLASS forbids. INNER_CLASS Thanks; will fix in next push. > src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 367: > >> 365: INTERFACE, ABSTRACT, >> 366: SYNTHETIC, ANNOTATION, >> 367: ENUM, AccessFlag.MODULE)), > > I?don?t think?that this?needs to?be?qualified: > Suggestion: > > ENUM, MODULE)), It does because of the AccessFlags.MODULE constant. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From darcy at openjdk.java.net Thu Feb 24 01:34:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 24 Feb 2022 01:34:07 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v3] In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 21:24:47 GMT, Mandy Chung wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback explicitly stating returned sets are immutable. > > I'm glad to see this proposal moving along to better model the JVM access flags. I think it's right to define a better enhanced API than updating `java.lang.reflect.Modifier` (which is indeed inadequate to provide the sufficient context for modeling). > > I also think `AccessFlag` is a good class name that well represents the `access_flags` in a class file per the JVM spec. @mlchung, @asotona, @RogerRiggs and others: I've synced the current version of the API changes in the CSR: https://bugs.openjdk.java.net/browse/JDK-8281660 Please review the CSR so it can go through the first phase of the process. (I suspect some additional refinement will be needed for the mapping of Class modifiers once some more test are written.) @asotona , I've corrected bugs in the mapping of the flags of various module parts (opens, requires, etc.). Please use the latest version for any additional testing. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From sviswanathan at openjdk.java.net Thu Feb 24 01:47:07 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 24 Feb 2022 01:47:07 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v7] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 09:03:37 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- >> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98 >> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58 >> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56 >> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Review comments resolved. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8984: > 8982: } > 8983: > 8984: void MacroAssembler::round_double(Register dst, XMMRegister src, Register rtmp, Register rcx) { Is it possible to implement this using the similar mxcsr change? In any case comments will help to review round_double and round_float code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From sviswanathan at openjdk.java.net Thu Feb 24 02:00:05 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 24 Feb 2022 02:00:05 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v7] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 09:03:37 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- >> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98 >> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58 >> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56 >> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Review comments resolved. test/hotspot/jtreg/compiler/c2/cr6340864/TestDoubleVect.java line 441: > 439: errn += verify("test_round: ", 1, l0[1], Long.MAX_VALUE); > 440: errn += verify("test_round: ", 2, l0[2], Long.MIN_VALUE); > 441: errn += verify("test_round: ", 3, l0[3], Long.MAX_VALUE); Good to add additional test cases: Case with a1 value >= Long Max and < infinity. Case with a1 value <= Long Min and > -infinity. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Thu Feb 24 02:43:46 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Thu, 24 Feb 2022 02:43:46 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4] In-Reply-To: References: Message-ID: > Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: fix 32bit build issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/13549290..2915b2e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=02-03 Stats: 91 lines in 2 files changed: 49 ins; 42 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572 From jpai at openjdk.java.net Thu Feb 24 05:02:47 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 24 Feb 2022 05:02:47 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: > - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. > - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. > > All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: > > > Using locale: he for Properties#store(OutputStream) test > test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure > java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 > at org.testng.Assert.fail(Assert.java:87) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) > at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > 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:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:828) > Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) > ... 30 more > > (in the exception above a locale with language `he` is being used) > > The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: - use Roger's suggestion of using Stream and Collection based APIs to avoid code duplication in the data provider method of the test - no need for system.out.println since testng add the chosen params to the output logs - review comments: - upper case static final fields in test - use DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN, Locale.ROOT) - remove @modules declaration on the jtreg test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7558/files - new: https://git.openjdk.java.net/jdk/pull/7558/files/c5dd7f79..97c9afd5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=01-02 Stats: 36 lines in 2 files changed: 1 ins; 12 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/7558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7558/head:pull/7558 PR: https://git.openjdk.java.net/jdk/pull/7558 From jpai at openjdk.java.net Thu Feb 24 05:02:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 24 Feb 2022 05:02:49 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v2] In-Reply-To: <6kKo7ooh94f_NeoidGjtCLQyw_VsMb5kAOYiebCmk5Q=.2aa263a6-71e7-4f06-b9b8-f8957d533f73@github.com> References: <6kKo7ooh94f_NeoidGjtCLQyw_VsMb5kAOYiebCmk5Q=.2aa263a6-71e7-4f06-b9b8-f8957d533f73@github.com> Message-ID: <7OITekCS2fnpobDVwnJdBoioPJ6dwlJZu6ws7Zq-FqI=.e1dab0a9-0ac0-40c4-849e-d22ff595c974@github.com> On Wed, 23 Feb 2022 18:22:53 GMT, Naoto Sato wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - implement review comments >> - copyright years > > test/jdk/java/util/Properties/PropertiesStoreTest.java line 51: > >> 49: * @summary tests the order in which the Properties.store() method writes out the properties >> 50: * @bug 8231640 8282023 >> 51: * @modules jdk.localedata > > OK, you can remove `@modules jdk.localedata` so that other tests would run. (it'd be unusual setup, but still possible with jlink) Thank you Naoto. I've removed this in the latest version of the PR. > test/jdk/java/util/Properties/PropertiesStoreTest.java line 60: > >> 58: // it internally calls the Date.toString() which always writes in a locale insensitive manner >> 59: private static final DateTimeFormatter formatter = DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN) >> 60: .withLocale(Locale.ROOT); > > Should have noticed before, but you can call the convenient overload of `ofPattern(DATE_FORMAT_PATTERN, Locale.ROOT)` here. Applies to the other test too. That makes sense. I hadn't noticed that API before. I've updated the PR with this suggested change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From jpai at openjdk.java.net Thu Feb 24 05:02:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 24 Feb 2022 05:02:50 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v2] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 18:37:03 GMT, Roger Riggs wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - implement review comments >> - copyright years > > test/jdk/java/util/Properties/PropertiesStoreTest.java line 61: > >> 59: private static final DateTimeFormatter formatter = DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN) >> 60: .withLocale(Locale.ROOT); >> 61: private static final Locale prevLocale = Locale.getDefault(); > > By convention, static final field names are uppercase. It make the code using them easier to read. Makes sense. Fixed in the latest version of the PR. > test/jdk/java/util/Properties/PropertiesStoreTest.java line 112: > >> 110: if (!locale.getLanguage().isEmpty() && !locale.getLanguage().equals("en")) { >> 111: nonEnglishLocale = locale; >> 112: System.out.println("Selected non-english locale: " + nonEnglishLocale + " for tests"); > > TestNG includes the arguments in the output when the test is run. Removed the System.out.println statement from the latest version of the PR. > test/jdk/java/util/Properties/PropertiesStoreTest.java line 116: > >> 114: } >> 115: } >> 116: if (nonEnglishLocale == null) { > > Alternatively, create a Set, to avoid duplicates, adding the candidates as they are discovered > and finally convert the Set to an Object[][]. It may be a bit easier to maintain. > > private static Object[][] provideLocales() { > // pick a non-english locale for testing > Set locales = Arrays.stream(Locale.getAvailableLocales()) > .filter(l -> !l.getLanguage().isEmpty() && !l.getLanguage().equals("en")) > .limit(1) > .collect(Collectors.toSet()); > locales.add(Locale.getDefault()); > locales.add(Locale.US); > locales.add(Locale.ROOT); > > return locales.stream() > .map(m -> new Locale[] {m}) > .toArray(n -> new Object[n][0]); > } Thank you Roger for this suggestion. This indeed is cleaner. I've updated the PR to use this suggested code. The tests continue to pass with the latest round of changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From itakiguchi at openjdk.java.net Thu Feb 24 05:45:37 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 24 Feb 2022 05:45:37 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 19:59:46 GMT, Roger Riggs wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> Add null check > > The changes seem ok, modifying both the LIBPATH passed in the environment and the expected return value. > > Since both of these tests are testing a different condition, the presence/accuracy of LIBPATH is not the point of the test. @RogerRiggs I'm using AIX 7.1. AIX 5.3 and 6.1 were already in EOL. OK, another way, `LIBPATH=...` can be removed from `result`. Also we can use #7581 . ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From stuefe at openjdk.java.net Thu Feb 24 07:20:05 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 24 Feb 2022 07:20:05 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check I admit I'm confused about this issue. When exactly is jtreg modifying LIBPATH of the parent process? Between initializing the final static `libpath` variable and when we build the "expected" String at line 1361? Or after we built the expected String, when the child is spawned? If its the former, then the issue is that `libpath` is just outdated when we get around to use it? In that case, why not just re-aquiring LIBPATH when building up `expected`? Sorry, I just try to understand the issue. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From itakiguchi at openjdk.java.net Thu Feb 24 07:42:03 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 24 Feb 2022 07:42:03 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check In my investigation, this issue happened after JDK-8272600 was applied. [JDK-8272600](https://bugs.openjdk.java.net/browse/JDK-8272600) (test) Use native "sleep" in Basic.java It added `/native` on `@run` tag. - @run main/othervm/timeout=300 -Djava.security.manager=allow Basic - @run main/othervm/timeout=300 -Djava.security.manager=allow -Djdk.lang.Process.launchMechanism=fork Basic + @run main/othervm/native/timeout=300 -Djava.security.manager=allow Basic + @run main/othervm/native/timeout=300 -Djava.security.manager=allow -Djdk.lang.Process.launchMechanism=fork Basic For this change, `test.nativepath` setting added into `LIBPATH` environment variable on parent (main) process. Older AIX might require parent's `LIBPATH` setting against child process on some of cases. But it seems the current AIX does not require `LIBPATH` setting. #7581 applied parent `LIBPATH` setting against child process. Please choose the appropriate one. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From aturbanov at openjdk.java.net Thu Feb 24 11:08:06 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 24 Feb 2022 11:08:06 GMT Subject: Integrated: 8282188: Unused static field MathContext.DEFAULT_DIGITS In-Reply-To: <1wrZubD_IPhKTJKupdBIRDQ3-K7JrHCmjobzn2LW6_o=.b5a56106-fc31-41c9-9e79-9656955c6e0d@github.com> References: <1wrZubD_IPhKTJKupdBIRDQ3-K7JrHCmjobzn2LW6_o=.b5a56106-fc31-41c9-9e79-9656955c6e0d@github.com> Message-ID: On Fri, 18 Feb 2022 19:07:15 GMT, Andrey Turbanov wrote: > 8282188: Unused static field MathContext.DEFAULT_DIGITS This pull request has now been integrated. Changeset: 3cfffa4f Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/3cfffa4f8e5a0fff7f232130125c549f992b533b Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod 8282188: Unused static field MathContext.DEFAULT_DIGITS Reviewed-by: darcy, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/7538 From jbhateja at openjdk.java.net Thu Feb 24 13:01:58 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 24 Feb 2022 13:01:58 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v8] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- > 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98 > 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58 > 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56 > 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Review comments resolved. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/6c869c76..f7dec3d9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=06-07 Stats: 35 lines in 5 files changed: 8 ins; 22 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Thu Feb 24 13:01:59 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 24 Feb 2022 13:01:59 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v7] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 01:43:27 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Review comments resolved. > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8984: > >> 8982: } >> 8983: >> 8984: void MacroAssembler::round_double(Register dst, XMMRegister src, Register rtmp, Register rcx) { > > Is it possible to implement this using the similar mxcsr change? In any case comments will help to review round_double and round_float code. LDMXCSR has multi-cycle latency and it will degrade the performance of scalar operation's fast path. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From redestad at openjdk.java.net Thu Feb 24 13:12:08 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 24 Feb 2022 13:12:08 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks In-Reply-To: References: Message-ID: <6RwRJJlqvoV6CpkontbIZA-KazNOk1u-TYHyDmVYjq0=.c35eb586-8765-4491-bb54-1af609ad339b@github.com> On Thu, 17 Feb 2022 15:11:11 GMT, Claes Redestad wrote: > Splitting out these micro changes from #7231 > > - Clean up and simplify setup and code > - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. > - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. Ping? ------------- PR: https://git.openjdk.java.net/jdk/pull/7516 From jbhateja at openjdk.java.net Thu Feb 24 14:18:13 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 24 Feb 2022 14:18:13 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 02:43:46 GMT, Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long. > > Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > fix 32bit build issues src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4408: > 4406: jmp(done); > 4407: bind(neg_divisor_fastpath); > 4408: // Fastpath for divisor < 0: How about checking if divisor is +ve or -ve constant and non-constant dividend in identity routine and setting a flag in IR node, which can be used to either emit fast / slow path in a new instruction selection pattern. It will save emitting redundant instructions. src/hotspot/share/opto/divnode.cpp line 881: > 879: return (phase->type( in(2) )->higher_equal(TypeLong::ONE)) ? in(1) : this; > 880: } > 881: //------------------------------Value------------------------------------------ Ideal transform to replace unsigned divide by cheaper logical right shift instruction if divisor is POW will be useful. src/hotspot/share/opto/divnode.cpp line 897: > 895: > 896: // Either input is BOTTOM ==> the result is the local BOTTOM > 897: const Type *bot = bottom_type(); Can we add constant folding handling when both dividend and divisor are constants. ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From rriggs at openjdk.java.net Thu Feb 24 14:47:04 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 24 Feb 2022 14:47:04 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: <18-70asW73zkOaWahaW9C95rqbQ22TWQQ6L6Ee6LJtg=.70c50690-6a07-4da3-acb3-3edad48f69e5@github.com> On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check Jtreg constructs the environment before launching the Agent to run the test. https://github.com/openjdk/jtreg/blob/163ae223409f789cb733d32ed8d33686e14a81d9/src/share/classes/com/sun/javatest/regtest/exec/MainAction.java#L415 For AIX, it appends the `test.nativepath` to LIBPATH. https://github.com/openjdk/jtreg/blob/163ae223409f789cb733d32ed8d33686e14a81d9/src/share/classes/com/sun/javatest/regtest/exec/Action.java#L146 As far as I can tell, the test does not modify the environment and originally passes LIBPATH without modification. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From jlaskey at openjdk.java.net Thu Feb 24 14:55:37 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 24 Feb 2022 14:55:37 GMT Subject: RFR: JDK-8282144 RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes Message-ID: Class: ./java.base/share/classes/jdk/internal/util/random/RandomSupport.java Method: public static long[] convertSeedBytesToLongs(byte[] seed, int n, int z) The method attempts to create an array of longs by consuming the input bytes most significant bit first. New bytes are appended to the existing long using the OR operator on the signed byte. Due to sign extension this will overwrite all the existing bits from 63 to 8 if the next byte is negative. ------------- Commit messages: - JDK-8282144 RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes Changes: https://git.openjdk.java.net/jdk/pull/7614/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7614&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282144 Stats: 72 lines in 2 files changed: 71 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7614.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7614/head:pull/7614 PR: https://git.openjdk.java.net/jdk/pull/7614 From jbhateja at openjdk.java.net Thu Feb 24 14:56:03 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 24 Feb 2022 14:56:03 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v7] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 00:43:27 GMT, Sandhya Viswanathan wrote: > Also curious, how does the performance look with all these changes. Updated new perf numbers. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Thu Feb 24 15:10:12 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 24 Feb 2022 15:10:12 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 07:16:42 GMT, Thomas Stuefe wrote: > If its the former, then the issue is that `libpath` is just outdated when we get around to use it? In that case, why not just re-aquiring LIBPATH when building up `expected`? ^This was my thought at first as well :-) but in my investigation, the libpath in the parent didn't change during the run. I think Roger's solution matches more with my understanding of the failure. I noticed that jtreg adds the extra path to the library when invoking javac to compile the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From rriggs at openjdk.java.net Thu Feb 24 17:04:07 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 24 Feb 2022 17:04:07 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: <-sZRQRPHLWqrT4OWs9UoY-AekQh0Z5l2Jw77YFkpD_Q=.7cdc147a-17dc-4e90-9294-e8fb90b1148c@github.com> On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check Javac is compiling the source to a .class file. The contents of the `java.library.path` do not affect the class file generated. None of the code of the class is executed during compilation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From itakiguchi at openjdk.java.net Thu Feb 24 17:14:04 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Thu, 24 Feb 2022 17:14:04 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: <-sZRQRPHLWqrT4OWs9UoY-AekQh0Z5l2Jw77YFkpD_Q=.7cdc147a-17dc-4e90-9294-e8fb90b1148c@github.com> References: <-sZRQRPHLWqrT4OWs9UoY-AekQh0Z5l2Jw77YFkpD_Q=.7cdc147a-17dc-4e90-9294-e8fb90b1148c@github.com> Message-ID: On Thu, 24 Feb 2022 17:01:13 GMT, Roger Riggs wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> Add null check > > Javac is compiling the source to a .class file. The contents of the `java.library.path` do not affect the class file generated. > None of the code of the class is executed during compilation. Thanks @RogerRiggs I could understand why this issue was happened. You said: > As far as I can tell, the test does not modify the environment and originally passes LIBPATH without modification. I'd like to confirm one thing. My patch did not pass `LIBPATH` environment variable to child process. You mean the testcase should pass parent `LIBPATH` to child process ? If so, it's better to use #7581 . (Please use bugid [8282219](https://bugs.openjdk.java.net/browse/JDK-8282219)) ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From naoto at openjdk.java.net Thu Feb 24 17:19:06 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 24 Feb 2022 17:19:06 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v3] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 05:02:47 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? >> >> As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: >> - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. >> - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. >> >> All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: >> >> >> Using locale: he for Properties#store(OutputStream) test >> test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure >> java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 >> at org.testng.Assert.fail(Assert.java:87) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) >> at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> 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:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:828) >> Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 >> at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) >> at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) >> ... 30 more >> >> (in the exception above a locale with language `he` is being used) >> >> The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: > > - use Roger's suggestion of using Stream and Collection based APIs to avoid code duplication in the data provider method of the test > - no need for system.out.println since testng add the chosen params to the output logs > - review comments: > - upper case static final fields in test > - use DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN, Locale.ROOT) > - remove @modules declaration on the jtreg test test/jdk/java/util/Properties/PropertiesStoreTest.java line 112: > 110: locales.add(Locale.getDefault()); // always test the default locale > 111: locales.add(Locale.US); // guaranteed to be present > 112: locales.add(Locale.ROOT); // guaranteed to be present Can we assume the returned `Set` is mutable? `Collectors.toSet()` javadoc reads no guarantee for mutability. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From duke at openjdk.java.net Thu Feb 24 17:39:05 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 24 Feb 2022 17:39:05 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: <-sZRQRPHLWqrT4OWs9UoY-AekQh0Z5l2Jw77YFkpD_Q=.7cdc147a-17dc-4e90-9294-e8fb90b1148c@github.com> References: <-sZRQRPHLWqrT4OWs9UoY-AekQh0Z5l2Jw77YFkpD_Q=.7cdc147a-17dc-4e90-9294-e8fb90b1148c@github.com> Message-ID: On Thu, 24 Feb 2022 17:01:13 GMT, Roger Riggs wrote: > Javac is compiling the source to a .class file. The contents of the `java.library.path` do not affect the class file generated. None of the code of the class is executed during compilation. Yup. Not the best snippet to include. It is set while calling the jvm as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From mandy.chung at oracle.com Thu Feb 24 17:42:17 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Feb 2022 09:42:17 -0800 Subject: Incorrect return value for Java_jdk_internal_loader_NativeLibraries_load() in java.base/share/native/libjava/NativeLibraries.c In-Reply-To: References: Message-ID: This is not an issue and does not affect the runtiime.? When it fails to load a native library, the VM will throw UnsatisfiedLinkError (see JVM_LoadLibrary).?? The return value is only important for the JNI case and calling System::loadLibrary on the system with dynamic linker cache (Big Sur) since throwExceptionIfFail == false. I agree that the JNI_TRUE return value for non-JNI case (i.e. raw library library mechanism) is confusing to the readers.? We should fix it to return handle != 0L to match the specified return value (true only when succeed). I will file an issue. Mandy On 2/23/22 4:08 PM, Cheng Jin wrote: > Hi there, > > The return value from Java_jdk_internal_loader_NativeLibraries_load() athttps://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjava/NativeLibraries.c > seems incorrect according to the code logic in there. > > Looking at the calling path from loadLibrary() to load() at src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java as follows: > > public NativeLibrary loadLibrary(Class fromClass, String name) { > ... > NativeLibrary lib = findFromPaths(LibraryPaths.SYS_PATHS, fromClass, name); <---------- > if (lib == null && searchJavaLibraryPath) { > lib = findFromPaths(LibraryPaths.USER_PATHS, fromClass, name); <---- > } > return lib; > } > > private NativeLibrary findFromPaths(String[] paths, Class fromClass, String name) { > for (String path : paths) { <---------------- keep searching the library paths till the library is located at the correct lib path > File libfile = new File(path, System.mapLibraryName(name)); > NativeLibrary nl = loadLibrary(fromClass, libfile); ? > if (nl != null) { > return nl; <-------------------- > } > libfile = ClassLoaderHelper.mapAlternativeName(libfile); > if (libfile != null) { > nl = loadLibrary(fromClass, libfile); > if (nl != null) { > return nl; > } > } > } > return null; > } > > public NativeLibrary loadLibrary(Class fromClass, File file) { > // Check to see if we're attempting to access a static library > String name = findBuiltinLib(file.getName()); > boolean isBuiltin = (name != null); > ... > return loadLibrary(fromClass, name, isBuiltin); <------------ > } > > private NativeLibrary loadLibrary(Class fromClass, String name, boolean isBuiltin) { > ... > NativeLibraryImpl lib = new NativeLibraryImpl(fromClass, name, isBuiltin, isJNI); > > // load the native library > NativeLibraryContext.push(lib); > try { > if (!lib.open()) { <--------------------- call load() > return null; // fail to open the native library > } > ... > // register the loaded native library > loadedLibraryNames.add(name); > libraries.put(name, lib); > return lib; <--------------- return an invalid lib as lib.open() returns true > } finally { > releaseNativeLibraryLock(name); > } > ... > } > > /* > * Loads the named native library > */ > boolean open() { > ... > return load(this, name, isBuiltin, isJNI, loadLibraryOnlyIfPresent); > } > > private static native boolean load(NativeLibraryImpl impl, String name, boolean isBuiltin, boolean isJNI, boolean throwExceptionIfFail); > > and then native code in java.base/share/native/libjava/NativeLibraries.c > > Java_jdk_internal_loader_NativeLibraries_load > (JNIEnv *env, jobject this, jobject lib, jstring name, > jboolean isBuiltin, jboolean isJNI, jboolean throwExceptionIfFail) > { > const char *cname; > jint jniVersion; > jthrowable cause; > void * handle; > jboolean loaded = JNI_FALSE; > ... > handle = isBuiltin ? procHandle : JVM_LoadLibrary(cname, throwExceptionIfFail); > if (isJNI) { > ... > } > (*env)->SetLongField(env, lib, handleID, ptr_to_jlong(handle)); > loaded = JNI_TRUE; <----- always return true when isJNI is false and a null handle > > done: > JNU_ReleaseStringPlatformChars(env, name, cname); > return loaded; > } > > Assuming there are multiple library paths existing in the jdk/lib which are added to sun.boot.library.path and java.library.path > and the expected library (libnative.so) is only placed in jdk/lib. e.g. > lib/libA > lib/libB > lib/libC > lib/libnative.so > > when the code in findFromPaths() searches the library paths set in sun.boot.library.path and java.library.path starting from lib/LibA, > it will end up with an invalid value if load() returns true in the case of a false isJNI and a null handle returned from JVM_LoadLibrary() > as the library doesn't exist in lib/libA passed to JVM_LoadLibrary(). > > To ensure findFromPaths() keeps searching the remaining lib paths, the simple fix should look like: > Java_jdk_internal_loader_NativeLibraries_load( ...) > { > ... > (*env)->SetLongField(env, lib, handleID, ptr_to_jlong(handle)); > if (handle) { <------------------------- return true only for a non-null handle > loaded = JNI_TRUE; > } > ... > } > > Please help check the code around there to see whether the fix is reasonable to avoid the unexpected situation as explained above (the problem was spotted since JDK17) > > Best Regards > Cheng Jin From weijun at openjdk.java.net Thu Feb 24 17:51:07 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 24 Feb 2022 17:51:07 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski wrote: >> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. >> >> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). >> >> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. >> >> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Move strictStrings to toolchain_cflags I'm the original author of `sspi.cpp`. All changes look fine to me. Thanks a lot for the enhancement. ------------- PR: https://git.openjdk.java.net/jdk/pull/7565 From djelinski at openjdk.java.net Thu Feb 24 17:56:05 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 24 Feb 2022 17:56:05 GMT Subject: RFR: 8281525: Enable Zc:strictStrings flag in Visual Studio build [v2] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 16:43:28 GMT, Daniel Jeli?ski wrote: >> Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. >> >> This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). >> >> The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. >> >> I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Move strictStrings to toolchain_cflags Great, thanks all for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/7565 From djelinski at openjdk.java.net Thu Feb 24 18:23:06 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 24 Feb 2022 18:23:06 GMT Subject: Integrated: 8281525: Enable Zc:strictStrings flag in Visual Studio build In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 19:55:14 GMT, Daniel Jeli?ski wrote: > Please review this PR that enables [Zc:strictStrings](https://docs.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170) compiler flag, which makes assigning a string literal to a non-const pointer a compile-time error. > > This type of assignment is [disallowed by C++ standard since C++11](https://en.cppreference.com/w/cpp/language/string_literal). Writing to a string literal through a non-const pointer [produces a run-time error](https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#microsoft-specific-1). > > The included code changes are trivial; I added `const` keyword to variable and parameter declarations where needed, and added explicit casts to non-const pointers where adding `const` was not feasible. > > I verified that the build passes both with and without `--enable-debug`, both with VS2017 and VS2019. This pull request has now been integrated. Changeset: 23995f82 Author: Daniel Jeli?ski Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/23995f822e540d799eb4bbc969229422257fbb08 Stats: 23 lines in 6 files changed: 0 ins; 0 del; 23 mod 8281525: Enable Zc:strictStrings flag in Visual Studio build Reviewed-by: dholmes, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/7565 From rriggs at openjdk.java.net Thu Feb 24 18:54:12 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 24 Feb 2022 18:54:12 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check The piece I was missing is that the HotSpot AIX specific code, computes and sets LIBPATH based on the path to the java executable. This computed LIBPATH value is set in the environment unless it is overridden by an existing LIBPATH in the environment. The test cases that failed, do not supply a value for LIBPATH so the launcher provided value is inserted and thereafter reported as the environment from the child process. Since both of these tests are testing a different condition not related to LIBPATH, the presence/accuracy of LIBPATH is not the point of the test. The current solution to remove `test.nativepath` works and is ok by me. (The alternative used by #7581, to include LIBPATH in the environment when launching might be slightly more robust to future changes.) Thanks for the followup. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From duke at openjdk.java.net Thu Feb 24 19:08:08 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Thu, 24 Feb 2022 19:08:08 GMT Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 14:13:47 GMT, Jatin Bhateja wrote: >> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> fix 32bit build issues > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4408: > >> 4406: jmp(done); >> 4407: bind(neg_divisor_fastpath); >> 4408: // Fastpath for divisor < 0: > > How about checking if divisor is +ve or -ve constant and non-constant dividend in identity routine and setting a flag in IR node, which can be used to either emit fast / slow path in a new instruction selection pattern. It will save emitting redundant instructions. Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365 > src/hotspot/share/opto/divnode.cpp line 881: > >> 879: return (phase->type( in(2) )->higher_equal(TypeLong::ONE)) ? in(1) : this; >> 880: } >> 881: //------------------------------Value------------------------------------------ > > Ideal transform to replace unsigned divide by cheaper logical right shift instruction if divisor is POW will be useful. Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365 > src/hotspot/share/opto/divnode.cpp line 897: > >> 895: >> 896: // Either input is BOTTOM ==> the result is the local BOTTOM >> 897: const Type *bot = bottom_type(); > > Can we add constant folding handling when both dividend and divisor are constants. Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365 ------------- PR: https://git.openjdk.java.net/jdk/pull/7572 From omikhaltcova at openjdk.java.net Thu Feb 24 19:18:05 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 24 Feb 2022 19:18:05 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add a new line to the end of test file for JDK-8282008 Roger, writing a test via echo was not a good idea obviously for this particular case because of the fact well shown in the doc "4. Everyone Parses Differently", https://daviddeley.com/autohotkey/parameters/parameters.htm#WINCRULESMSEX. The task is more complicated than it seems at the first glance. The same command line correctly parsed in an app written in C/C++ might be incorrectly parsed in a VBS app etc. The suggestion not to use the path-argument surroundings with `'"'` doesn't fix the issue in case of VBS. It leads to a resulting path-argument ending with the doubled backslash in a VBS app according to the rules "10.1 The WSH Command Line Parameter Parsing Rules", https://daviddeley.com/autohotkey/parameters/parameters.htm#WSH. Below there are some experiments with an app attached to JDK-8282008: NO FIX 1. new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start(); 1.1 allowAmbiguousCommands = false arg[0] = \C:\Program arg[1] = Files\Git1\\\ CreateProcessW: pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git1\\"" Test 1.2 allowAmbiguousCommands = true arg[0] = C:\Program arg[1] = Files\Git1\ CreateProcessW: pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git1"" Test 2. new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", "C:\\Program Files\\Git\", "Test").start(); 2.1 allowAmbiguousCommands = false arg[0] = C:\Program Files\Git1\\ arg[1] = Test CreateProcessW: pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs "C:\Program Files\Git1\" Test 2.2 allowAmbiguousCommands = true arg[0] = C:\Program Files\Git1\\ arg[1] = Test CreateProcessW: pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs "C:\Program Files\Git1\" Test FIXED (as in pr) 1. new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start(); 1.1 allowAmbiguousCommands = false arg[0] = C:\Program Files\Git1\ arg[1] = Test CreateProcessW: pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs "C:\Program Files\Git1" Test 1.2 allowAmbiguousCommands = true arg[0] = C:\Program Files\Git1\ arg[1] = Test CreateProcessW: pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs "C:\Program Files\Git1" Test ``` Reading the code of unQuote() in terms of logic: "no beginning or ending quote, or too short => not quoted", - and it seems that if all these conditions are just opposite (starting and ending quotes and long enough) then a string should be treated as quoted but it's not. One exception was added and it's strange that it's applied even in case of paired quotes. Is it truly necessary for the security fix to skip (=to treat as unquoted) a string starting and ending with `'"'` in case of a `"\\""` tail? This proposed fix returns back possibility (as was previously) to use surrounding with `'"'` as an argument mark-up that allows to pass correctly a path with a space inside in case of VBS. Roger, would you be so kind to take a look at this small fix once again, please, and to pay attention to VBS parsing arguments problem?! ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From alanb at openjdk.java.net Thu Feb 24 19:23:05 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 24 Feb 2022 19:23:05 GMT Subject: RFR: 8280357: user.home = "?" when running with systemd DynamicUser=true [v2] In-Reply-To: <-exPyplDA5Yz3A0_wKGc6GNp-UjTwOcpq-3VfXSjQRo=.27d73528-2cdd-4984-8662-929a12f186e7@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> <-exPyplDA5Yz3A0_wKGc6GNp-UjTwOcpq-3VfXSjQRo=.27d73528-2cdd-4984-8662-929a12f186e7@github.com> Message-ID: On Wed, 23 Feb 2022 22:00:19 GMT, Roger Riggs wrote: >> In some Linux configurations, the Linux home directory provided by getpwent is not usable. >> The value of the system property `user.home` should fallback to the value of $HOME >> if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. >> >> If $HOME is undefined or empty, the value of the getpwent.user_home is retained. >> >> There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 >> >> The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > fallback to '?' for user.home if both the pw_dir and /Users/rriggs are not valid Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From bchristi at openjdk.java.net Thu Feb 24 19:37:11 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 24 Feb 2022 19:37:11 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 15:11:11 GMT, Claes Redestad wrote: > Splitting out these micro changes from #7231 > > - Clean up and simplify setup and code > - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. > - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. Changes requested by bchristi (Reviewer). test/micro/org/openjdk/bench/java/lang/StringDecode.java line 36: > 34: @Warmup(iterations = 5, time = 2) > 35: @Measurement(iterations = 5, time = 3) > 36: @State(Scope.Thread) No change to @Fork and @Warmup (as in the Encode test)? test/micro/org/openjdk/bench/java/lang/StringDecode.java line 49: > 47: public class StringDecode { > 48: > 49: @Param({"US-ASCII", "ISO-8859-1", "UTF-8", "MS932", "ISO-8859-6", "ISO-2022-KR"}) What would you think of retaining the previous set of charset names as a comment -- as a suggestion for someone who wants additional coverage? test/micro/org/openjdk/bench/java/lang/StringDecode.java line 93: > 91: public void decodeAsciiLong(Blackhole bh) throws Exception { > 92: bh.consume(new String(longAsciiString, charset)); > 93: bh.consume(new String(longAsciiString, 0, 1024 + 31, charset)); I imagine the 1024+31 addition gets compiled down, and is not executed during the test, right? test/micro/org/openjdk/bench/java/lang/StringEncode.java line 39: > 37: public class StringEncode { > 38: > 39: @Param({"US-ASCII", "ISO-8859-1", "UTF-8", "MS932", "ISO-8859-6"}) Same, re: keeping list as a comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7516 From rriggs at openjdk.java.net Thu Feb 24 20:16:07 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 24 Feb 2022 20:16:07 GMT Subject: Integrated: 8280357: user.home = "?" when running with systemd DynamicUser=true In-Reply-To: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> References: <05NwmZiKMoYT4aztlHeMeoB4DoquDm_l9H27bF2zlsQ=.264a32ed-d75f-4928-b989-c04684b87470@github.com> Message-ID: On Fri, 18 Feb 2022 15:29:34 GMT, Roger Riggs wrote: > In some Linux configurations, the Linux home directory provided by getpwent is not usable. > The value of the system property `user.home` should fallback to the value of $HOME > if getpwent.user_home is null or less that 2 characters long. "/" is not a valid home directory name. > > If $HOME is undefined or empty, the value of the getpwent.user_home is retained. > > There are more details in the Jira issue: https://bugs.openjdk.java.net/browse/JDK-8280357 > > The fix has been tested manually on Ubuntu 20.0.4 using the suggested systemd command line and variations. This pull request has now been integrated. Changeset: bf19fc65 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/bf19fc65c71cba8cb4383d714fe8993acd01be0a Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod 8280357: user.home = "?" when running with systemd DynamicUser=true Reviewed-by: naoto, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7534 From raffaello.giulietti at gmail.com Thu Feb 24 20:41:59 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 24 Feb 2022 21:41:59 +0100 Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: <6b402430-023d-c07a-a4ef-e966afb7e347@gmail.com> Hi, as far as I know, on Windows every program can obtain the lpCommandLine argument, used in the call of CreateProcess() from its parent, by calling GetCommandLine() and parse that string as it sees fit. This is in stark contrast with how Unix-like systems create and execute programs, where the system call execve(2) accepts an array of arguments, not a single command line. There are no fixed rules on how to parse the command line, as witnessed by the different strategies implemented in the C/C++ runtime (which splits the command line according to the rules outlined in [1] to populate the argv[] array in main()), the cmd.exe shell, the wscript.exe runtime, etc. Consequently, there are no fixed rules on how to encode a command line (specifically, the lpCommandLine argument to CreateProcess()) because it really is up to the invoked program to parse it, whether explicitly or implicitly, according to its own, directly or indirectly implemented rules. Even a C/C++ console program could ignore the result that the runtime automatically provides in argv[] and parse the command line directly, as obtained by GetCommandLine(). Without knowing the parsing rules of the target program, it is not possible to encode a command line correctly for CreateProcess(). I doubt there's a "common denominator" which would cover most cases encountered in practice. The best we can hope is to implement encoders (and decoders) for specific, widely used runtimes. (BTW, for the C/C++ runtime I prepared an implementation mentioned in [2].) Greetings Raffaello ---- [1] https://docs.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086105.html On 2022-02-24 20:18, Olga Mikhaltsova wrote: > On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: > >>> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >>> >>> For example, it's needed to execute the following command on Windows: >>> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >>> it's equal to: >>> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >>> >>> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >>> >>> private static String unQuote(String str) { >>> .. >>> if (str.endsWith("\\"")) { >>> return str; // not properly quoted, treat as unquoted >>> } >>> .. >>> } >>> >>> >>> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >>> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >>> >>> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >>> (jdk.lang.Process.allowAmbiguousCommands = true) >>> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >>> (jdk.lang.Process.allowAmbiguousCommands = false) >>> >>> >>> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. >> >> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a new line to the end of test file for JDK-8282008 > > Roger, writing a test via echo was not a good idea obviously for this particular case because of the fact well shown in the doc "4. Everyone Parses Differently", https://daviddeley.com/autohotkey/parameters/parameters.htm#WINCRULESMSEX. The task is more complicated than it seems at the first glance. The same command line correctly parsed in an app written in C/C++ might be incorrectly parsed in a VBS app etc. > > The suggestion not to use the path-argument surroundings with `'"'` doesn't fix the issue in case of VBS. It leads to a resulting path-argument ending with the doubled backslash in a VBS app according to the rules "10.1 The WSH Command Line Parameter Parsing Rules", https://daviddeley.com/autohotkey/parameters/parameters.htm#WSH. > > Below there are some experiments with an app attached to JDK-8282008: > > NO FIX > > 1. new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start(); > > 1.1 allowAmbiguousCommands = false > arg[0] = \C:\Program > arg[1] = Files\Git1\\\ > CreateProcessW: pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git1\\"" Test > > 1.2 allowAmbiguousCommands = true > arg[0] = C:\Program > arg[1] = Files\Git1\ > CreateProcessW: pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git1"" Test > > 2. new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", "C:\\Program Files\\Git\", "Test").start(); > > 2.1 allowAmbiguousCommands = false > arg[0] = C:\Program Files\Git1\\ > arg[1] = Test > CreateProcessW: pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs "C:\Program Files\Git1\" Test > > 2.2 allowAmbiguousCommands = true > arg[0] = C:\Program Files\Git1\\ > arg[1] = Test > CreateProcessW: pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs "C:\Program Files\Git1\" Test > > > FIXED (as in pr) > > 1. new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start(); > > 1.1 allowAmbiguousCommands = false > arg[0] = C:\Program Files\Git1\ > arg[1] = Test > CreateProcessW: pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs "C:\Program Files\Git1" Test > > 1.2 allowAmbiguousCommands = true > arg[0] = C:\Program Files\Git1\ > arg[1] = Test > CreateProcessW: pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs "C:\Program Files\Git1" Test > ``` > > Reading the code of unQuote() in terms of logic: "no beginning or ending quote, or too short => not quoted", - and it seems that if all these conditions are just opposite (starting and ending quotes and long enough) then a string should be treated as quoted but it's not. One exception was added and it's strange that it's applied even in case of paired quotes. Is it truly necessary for the security fix to skip (=to treat as unquoted) a string starting and ending with `'"'` in case of a `"\\""` tail? > > This proposed fix returns back possibility (as was previously) to use surrounding with `'"'` as an argument mark-up that allows to pass correctly a path with a space inside in case of VBS. Roger, would you be so kind to take a look at this small fix once again, please, and to pay attention to VBS parsing arguments problem?! > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7504 From raffaello.giulietti at gmail.com Thu Feb 24 21:22:49 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 24 Feb 2022 22:22:49 +0100 Subject: Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec In-Reply-To: References: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> Message-ID: <7969ed53-a676-0687-deff-c2086f1d0251@gmail.com> Hi, on Windows, the mechanism to launch a new program is for the parent to call CreateProcess(). This function accepts, among others parameters, a lpApplicationName string and a lpCommandLine string. There's a *single* lpCommandLine that encodes all the arguments to pass to the new program. The exact encoding of the arguments in the command line is imposed by how the *new* program parses (decodes) the command line to get its constituent parts. There are no fixed rules on how this happens. There are some more or less well documented rules for some runtimes (e.g., the C/C++ runtime) or for some specific programs (e.g., cmd.exe., wscript.exe). In general, however, a program can decode in any way it deems useful. Because the encoding is dictated by the target program's decoding, and because the latter is really arbitrary, there's no safe, universal procedure to encode a list of string arguments to a single command line string. It is only when the decoding rules in the target program are known that encoding in the parent becomes feasible. Thus, it might be more useful on Windows platforms to avoid the API points that expose List or String[] for the arguments to the target program and use the ones that accept a single String, instead. The client of those API points would then have to deal with the encoding specific for that program. This is a better match with the underlying OS mechanism, namely CreateProcess(), which accepts a single, already encoded string. In addition, to assist programmers unfamiliar with specific encodings, widely used specific encoders (e.g., for the C/C++ runtime [1], for cmd.exe, etc.) can be implemented separately. Greetings Raffaello ---- [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086105.html From rreddy at openjdk.java.net Fri Feb 25 00:56:38 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Fri, 25 Feb 2022 00:56:38 GMT Subject: RFR: 8281093: JDK 11.0.14 violates Attribute-Value Normalization in the XML specification 1.0 Message-ID: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> While normalizing entity with '\r' , we should be checking if the entity is external before changing the position and offset. ------------- Commit messages: - 8281093: JDK 11.0.14 violates Attribute-Value Normalization in the XML specification 1.0 Changes: https://git.openjdk.java.net/jdk/pull/7617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281093 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7617/head:pull/7617 PR: https://git.openjdk.java.net/jdk/pull/7617 From duke at openjdk.java.net Fri Feb 25 01:13:41 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 25 Feb 2022 01:13:41 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v9] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: - change wrong indentation - change indentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/65687cde..b002205d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=07-08 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Feb 25 01:13:43 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 25 Feb 2022 01:13:43 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v8] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 13:14:07 GMT, Jim Laskey wrote: >> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: >> >> check from master branch > > src/java.base/share/classes/java/util/Random.java line 259: > >> 257: >> 258: private static final AtomicLong seedUniquifier >> 259: = new AtomicLong(8682522807148012L); > > This seems (to me) like an odd indentation change. Reverted the wrong indentation changes sorry about that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From almatvee at openjdk.java.net Fri Feb 25 01:27:52 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 25 Feb 2022 01:27:52 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v6] In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: > Added ability to override description for additional launchers via "description" property. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8279995: jpackage --add-launcher option should allow overriding description [v5] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7399/files - new: https://git.openjdk.java.net/jdk/pull/7399/files/401db249..e4893e57 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7399&range=04-05 Stats: 18 lines in 1 file changed: 6 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7399/head:pull/7399 PR: https://git.openjdk.java.net/jdk/pull/7399 From almatvee at openjdk.java.net Fri Feb 25 01:38:16 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 25 Feb 2022 01:38:16 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v4] In-Reply-To: References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Thu, 17 Feb 2022 17:53:57 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279995: jpackage --add-launcher option should allow overriding description [v4] > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 165: > >> 163: >> 164: return description; >> 165: } > > How about this: > > public static String getExecutableDesciption(Path pathToExeFile) { > Executor exec = Executor.of("powershell", > "-NoLogo", > "-NoProfile", > "-Command", > "(Get-Item \\"" > + pathToExeFile.toAbsolutePath() > + "\\").VersionInfo | select FileDescription"); > > var lineIt = exec.dumpOutput().executeAndGetOutput().iterator(); > while (lineIt.hasNext()) { > var line = lineIt.next(); > if (line.trim().equals("FileDescription")) { > // Skip "---------------" and move to the description value > lineIt.next(); > var description = lineIt.next().trim(); > if (lineIt.hasNext()) { > throw new RuntimeException("Unexpected input"); > } > return description; > } > } > > throw new RuntimeException(String.format( > "Failed to get file description of [%s]", pathToExeFile)); > } > > Added `Executor.dumpOutput()` call to save the output of powershell command in the test log for easier debugging. > No null initialized `description` variable. No iteration over the list using the index. Check for the end of the output. Fixed. Except I removed if (lineIt.hasNext()) { throw new RuntimeException("Unexpected input"); }, since there are empty lines after description in output and this check triggers exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From joehw at openjdk.java.net Fri Feb 25 02:02:59 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 25 Feb 2022 02:02:59 GMT Subject: RFR: 8281093: JDK 11.0.14 violates Attribute-Value Normalization in the XML specification 1.0 In-Reply-To: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> References: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> Message-ID: <4rgMKpqgKTOMZdTNwiGkpsRsEiMuy3RtNZ3PZVvrRHU=.05690018-b8fc-4fe1-bef3-c3817eaad7cc@github.com> On Fri, 25 Feb 2022 00:50:49 GMT, Ravi Reddy wrote: > While normalizing entity with '\r' , we should be checking if the entity is > external before changing the position and offset. Please also update the @LastModified to "Feb 2022" ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7617 From rreddy at openjdk.java.net Fri Feb 25 02:23:40 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Fri, 25 Feb 2022 02:23:40 GMT Subject: RFR: 8281093: JDK 11.0.14 violates Attribute-Value Normalization in the XML specification 1.0 In-Reply-To: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> References: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> Message-ID: <_AaJJl4Zaqi6xGqXhhn-NJJC8Kz1PxbLFL0Ez1zYo-4=.0faacb30-5d2e-4894-8eaa-1665f6bfaa5a@github.com> On Fri, 25 Feb 2022 00:50:49 GMT, Ravi Reddy wrote: > While normalizing entity with '\r' , we should be checking if the entity is > external before changing the position and offset. > Please also update the @lastmodified to "Feb 2022" Thanks , I have updated the tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/7617 From rreddy at openjdk.java.net Fri Feb 25 02:23:39 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Fri, 25 Feb 2022 02:23:39 GMT Subject: RFR: 8281093: JDK 11.0.14 violates Attribute-Value Normalization in the XML specification 1.0 [v2] In-Reply-To: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> References: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> Message-ID: > While normalizing entity with '\r' , we should be checking if the entity is > external before changing the position and offset. Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: Updated @LastModified to Feb 2022 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7617/files - new: https://git.openjdk.java.net/jdk/pull/7617/files/f7de9a23..89440bfb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7617&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7617&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7617/head:pull/7617 PR: https://git.openjdk.java.net/jdk/pull/7617 From rreddy at openjdk.java.net Fri Feb 25 03:09:03 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Fri, 25 Feb 2022 03:09:03 GMT Subject: Withdrawn: 8281093: JDK 11.0.14 violates Attribute-Value Normalization in the XML specification 1.0 In-Reply-To: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> References: <_tN_na00pvOaxzez7tgTr6t13PDRo9aO-AOIKm44Ckc=.d28e9743-839b-4229-b4ed-e1d3a4f07b3a@github.com> Message-ID: On Fri, 25 Feb 2022 00:50:49 GMT, Ravi Reddy wrote: > While normalizing entity with '\r' , we should be checking if the entity is > external before changing the position and offset. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7617 From jpai at openjdk.java.net Fri Feb 25 03:54:32 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 25 Feb 2022 03:54:32 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v4] In-Reply-To: References: Message-ID: > Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: > - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. > - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. > > All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: > > > Using locale: he for Properties#store(OutputStream) test > test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure > java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 > at org.testng.Assert.fail(Assert.java:87) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) > at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > 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:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:828) > Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) > ... 30 more > > (in the exception above a locale with language `he` is being used) > > The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: use Collections.toCollection() instead of Collectors.toSet() to allow for mutability guarantees ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7558/files - new: https://git.openjdk.java.net/jdk/pull/7558/files/97c9afd5..1d14f1c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7558/head:pull/7558 PR: https://git.openjdk.java.net/jdk/pull/7558 From jpai at openjdk.java.net Fri Feb 25 03:54:35 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 25 Feb 2022 03:54:35 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v3] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 17:15:16 GMT, Naoto Sato wrote: >> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision: >> >> - use Roger's suggestion of using Stream and Collection based APIs to avoid code duplication in the data provider method of the test >> - no need for system.out.println since testng add the chosen params to the output logs >> - review comments: >> - upper case static final fields in test >> - use DateTimeFormatter.ofPattern(DATE_FORMAT_PATTERN, Locale.ROOT) >> - remove @modules declaration on the jtreg test > > test/jdk/java/util/Properties/PropertiesStoreTest.java line 112: > >> 110: locales.add(Locale.getDefault()); // always test the default locale >> 111: locales.add(Locale.US); // guaranteed to be present >> 112: locales.add(Locale.ROOT); // guaranteed to be present > > Can we assume the returned `Set` is mutable? `Collectors.toSet()` javadoc reads no guarantee for mutability. That's a very good point. I've updated the PR to now explicitly use a mutable `Set` instead of using `Collectors.toSet()` ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From naoto at openjdk.java.net Fri Feb 25 04:48:04 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Feb 2022 04:48:04 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v4] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 03:54:32 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? >> >> As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: >> - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. >> - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. >> >> All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: >> >> >> Using locale: he for Properties#store(OutputStream) test >> test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure >> java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 >> at org.testng.Assert.fail(Assert.java:87) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) >> at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> 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:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:828) >> Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 >> at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) >> at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) >> ... 30 more >> >> (in the exception above a locale with language `he` is being used) >> >> The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > use Collections.toCollection() instead of Collectors.toSet() to allow for mutability guarantees Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From naoto at openjdk.java.net Fri Feb 25 04:48:05 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Feb 2022 04:48:05 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v3] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 03:51:09 GMT, Jaikiran Pai wrote: >> test/jdk/java/util/Properties/PropertiesStoreTest.java line 112: >> >>> 110: locales.add(Locale.getDefault()); // always test the default locale >>> 111: locales.add(Locale.US); // guaranteed to be present >>> 112: locales.add(Locale.ROOT); // guaranteed to be present >> >> Can we assume the returned `Set` is mutable? `Collectors.toSet()` javadoc reads no guarantee for mutability. > > That's a very good point. I've updated the PR to now explicitly use a mutable `Set` instead of using `Collectors.toSet()` This is ok, although `Collectors.toCollection(HashSet::new)` is a bit concise. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From stuefe at openjdk.java.net Fri Feb 25 05:22:03 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 25 Feb 2022 05:22:03 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check Hi Roger, > The piece I was missing is that the HotSpot AIX specific code, computes and sets LIBPATH based on the path to the java executable. This computed LIBPATH value is set in the environment unless it is overridden by an existing LIBPATH in the environment. Ah, thank you for this missing piece! Now I remember. We modify LIBPATH in the java launcher itself. Since the test executable here is also java we call setenv(LIBPATH,..) in the child process. On AIX we do this unconditionally, that may be the difference to other platforms. The point of this test was not to test `System.getenv()` but that Runtime.exec passes the env vector correctly, right? Then a maybe simpler alternative would have been to spawn `sh -c env`, or a simple little C program printing its env vector, instead of java. Less side effects. Test may be a bit quicker too, since child startup would be faster (probably does not save much in the big scheme of things). Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From jbhateja at openjdk.java.net Fri Feb 25 06:22:42 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 25 Feb 2022 06:22:42 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Adding descriptive comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/f7dec3d9..54d4ea36 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=07-08 Stats: 31 lines in 2 files changed: 14 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From itakiguchi at openjdk.java.net Fri Feb 25 07:32:04 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 25 Feb 2022 07:32:04 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 18:51:08 GMT, Roger Riggs wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> Add null check > > The piece I was missing is that the HotSpot AIX specific code, computes and sets LIBPATH based on > the path to the java executable. This computed LIBPATH value is set in the environment unless > it is overridden by an existing LIBPATH in the environment. > > The test cases that failed, do not supply a value for LIBPATH so the launcher provided value is inserted > and thereafter reported as the environment from the child process. > > Since both of these tests are testing a different condition not related to LIBPATH, > the presence/accuracy of LIBPATH is not the point of the test. > > The current solution to remove `test.nativepath` works and is ok by me. > > (The alternative used by #7581, to include LIBPATH in the environment when launching might be slightly more robust to future changes.) > > Thanks for the followup. Thanks @RogerRiggs and @tstuefe . I appreciate your deeper investigations. Could you give me some advice on what to do next? ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From stuefe at openjdk.java.net Fri Feb 25 07:42:56 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 25 Feb 2022 07:42:56 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 18:51:08 GMT, Roger Riggs wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> Add null check > > The piece I was missing is that the HotSpot AIX specific code, computes and sets LIBPATH based on > the path to the java executable. This computed LIBPATH value is set in the environment unless > it is overridden by an existing LIBPATH in the environment. > > The test cases that failed, do not supply a value for LIBPATH so the launcher provided value is inserted > and thereafter reported as the environment from the child process. > > Since both of these tests are testing a different condition not related to LIBPATH, > the presence/accuracy of LIBPATH is not the point of the test. > > The current solution to remove `test.nativepath` works and is ok by me. > > (The alternative used by #7581, to include LIBPATH in the environment when launching might be slightly more robust to future changes.) > > Thanks for the followup. > Thanks @RogerRiggs and @tstuefe . I appreciate your deeper investigations. Could you give me some advice on what to do next? Hi @takiguc, My preference would be to spawn `sh -c env` instead of java, since it removes all need for second-guessing what the java child does with the environment (java modifies the environment and also conceivably System.getenv() may lie to us at some point in the future since it seems a convenient way to filter environment variables for java programs). That is if my reasoning was correct in the first place. But I do not have a strong preference and defer to Roger and Tyler. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From itakiguchi at openjdk.java.net Fri Feb 25 08:16:03 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 25 Feb 2022 08:16:03 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 18:51:08 GMT, Roger Riggs wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> Add null check > > The piece I was missing is that the HotSpot AIX specific code, computes and sets LIBPATH based on > the path to the java executable. This computed LIBPATH value is set in the environment unless > it is overridden by an existing LIBPATH in the environment. > > The test cases that failed, do not supply a value for LIBPATH so the launcher provided value is inserted > and thereafter reported as the environment from the child process. > > Since both of these tests are testing a different condition not related to LIBPATH, > the presence/accuracy of LIBPATH is not the point of the test. > > The current solution to remove `test.nativepath` works and is ok by me. > > (The alternative used by #7581, to include LIBPATH in the environment when launching might be slightly more robust to future changes.) > > Thanks for the followup. Hello @RogerRiggs , @backwaterred . Could you give me your suggestion, please ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From jpai at openjdk.java.net Fri Feb 25 08:44:42 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 25 Feb 2022 08:44:42 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v5] In-Reply-To: References: Message-ID: <_-XlZDme3lIVFOeuD17Ht6a5qiKxRLibm6EFex2YOn8=.efc1df68-8603-4c7a-b687-b4855f57cbd8@github.com> > Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: > - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. > - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. > > All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: > > > Using locale: he for Properties#store(OutputStream) test > test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure > java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 > at org.testng.Assert.fail(Assert.java:87) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) > at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > 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:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:828) > Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) > ... 30 more > > (in the exception above a locale with language `he` is being used) > > The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: HashSet::new instead of new HashSet() in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7558/files - new: https://git.openjdk.java.net/jdk/pull/7558/files/1d14f1c7..915f12e1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7558&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7558/head:pull/7558 PR: https://git.openjdk.java.net/jdk/pull/7558 From redestad at openjdk.java.net Fri Feb 25 09:08:04 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Feb 2022 09:08:04 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks In-Reply-To: References: Message-ID: <_HEN6ca8p_0ZrUtswCNAMxKl13JeXlksMDoH901fLHU=.acaaa45c-3db8-4a3f-aecc-b97b0cf40bf5@github.com> On Thu, 24 Feb 2022 19:01:32 GMT, Brent Christian wrote: >> Splitting out these micro changes from #7231 >> >> - Clean up and simplify setup and code >> - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. >> - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. > > test/micro/org/openjdk/bench/java/lang/StringDecode.java line 93: > >> 91: public void decodeAsciiLong(Blackhole bh) throws Exception { >> 92: bh.consume(new String(longAsciiString, charset)); >> 93: bh.consume(new String(longAsciiString, 0, 1024 + 31, charset)); > > I imagine the 1024+31 addition gets compiled down, and is not executed during the test, right? Yes, adding two integer literals will be constant folded already by javac: public static void main(String...args) { int foo = 1024 + 31; } javap -v output: ``` stack=1, locals=2, args_size=1 0: sipush 1055 3: istore_1 4: return ------------- PR: https://git.openjdk.java.net/jdk/pull/7516 From redestad at openjdk.java.net Fri Feb 25 09:19:33 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Feb 2022 09:19:33 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks [v2] In-Reply-To: References: Message-ID: > Splitting out these micro changes from #7231 > > - Clean up and simplify setup and code > - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. > - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Brent review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7516/files - new: https://git.openjdk.java.net/jdk/pull/7516/files/54e62eda..0dd04498 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7516&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7516&range=00-01 Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7516/head:pull/7516 PR: https://git.openjdk.java.net/jdk/pull/7516 From aph at openjdk.java.net Fri Feb 25 09:44:03 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 25 Feb 2022 09:44:03 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks [v2] In-Reply-To: References: Message-ID: <1KRXlc3k-c5bBoPN7asHnDLmrOUZZMdIeLUcbY6czoQ=.96b20a14-f879-43b6-bec9-97e6edffd8ae@github.com> On Fri, 25 Feb 2022 09:19:33 GMT, Claes Redestad wrote: >> Splitting out these micro changes from #7231 >> >> - Clean up and simplify setup and code >> - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. >> - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Brent review test/micro/org/openjdk/bench/java/lang/StringDecode.java line 72: > 70: public void setup() { > 71: charset = Charset.forName(charsetName); > 72: asciiString = LOREM.substring(0, 32).getBytes(charset); This is problematic IMO in that it's missing short strings such as "Claes". Average Java strings are about 32 bytes long AFAICR, and people writing (vectorized) ijntrinsics have a nasty habit of optimizing for long strings, to the detriment of typical-length ones. Whether we like it or not, people will optimize for benchmarks, so it's important that benchmark data is realistic. The shortest here is 15 bytes, as far as I can see. I'd certainly include a short string of just a few bytes so that intrinsics don't cause regressions in important cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/7516 From redestad at openjdk.java.net Fri Feb 25 11:08:49 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Feb 2022 11:08:49 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks [v3] In-Reply-To: References: Message-ID: > Splitting out these micro changes from #7231 > > - Clean up and simplify setup and code > - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. > - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Fix typos, add missing short variants to latin1 and utf16 short decode methods - Increase coverage of and weight of short strings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7516/files - new: https://git.openjdk.java.net/jdk/pull/7516/files/0dd04498..fc2a5b05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7516&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7516&range=01-02 Stats: 77 lines in 2 files changed: 62 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/7516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7516/head:pull/7516 PR: https://git.openjdk.java.net/jdk/pull/7516 From redestad at openjdk.java.net Fri Feb 25 11:09:06 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Feb 2022 11:09:06 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks [v2] In-Reply-To: <1KRXlc3k-c5bBoPN7asHnDLmrOUZZMdIeLUcbY6czoQ=.96b20a14-f879-43b6-bec9-97e6edffd8ae@github.com> References: <1KRXlc3k-c5bBoPN7asHnDLmrOUZZMdIeLUcbY6czoQ=.96b20a14-f879-43b6-bec9-97e6edffd8ae@github.com> Message-ID: <40hEOtvUJu6-6_Vb1DNJoMSdRplm7VAg0rVxMPv0QAk=.5ccf1859-09fd-4ed8-b5f0-e919cf8d896f@github.com> On Fri, 25 Feb 2022 09:41:09 GMT, Andrew Haley wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Brent review > > test/micro/org/openjdk/bench/java/lang/StringDecode.java line 72: > >> 70: public void setup() { >> 71: charset = Charset.forName(charsetName); >> 72: asciiString = LOREM.substring(0, 32).getBytes(charset); > > This is problematic IMO in that it's missing short strings such as "Claes". Average Java strings are about 32 bytes long AFAICR, and people writing (vectorized) ijntrinsics have a nasty habit of optimizing for long strings, to the detriment of typical-length ones. > Whether we like it or not, people will optimize for benchmarks, so it's important that benchmark data is realistic. The shortest here is 15 bytes, as far as I can see. I'd certainly include a short string of just a few bytes so that intrinsics don't cause regressions in important cases. All good points. I've added a number of such short variants to all(?) relevant microbenchmarks. The tests should now better cover a mix of input lengths and encodings. ------------- PR: https://git.openjdk.java.net/jdk/pull/7516 From aph at openjdk.java.net Fri Feb 25 11:09:10 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 25 Feb 2022 11:09:10 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks [v2] In-Reply-To: <40hEOtvUJu6-6_Vb1DNJoMSdRplm7VAg0rVxMPv0QAk=.5ccf1859-09fd-4ed8-b5f0-e919cf8d896f@github.com> References: <1KRXlc3k-c5bBoPN7asHnDLmrOUZZMdIeLUcbY6czoQ=.96b20a14-f879-43b6-bec9-97e6edffd8ae@github.com> <40hEOtvUJu6-6_Vb1DNJoMSdRplm7VAg0rVxMPv0QAk=.5ccf1859-09fd-4ed8-b5f0-e919cf8d896f@github.com> Message-ID: On Fri, 25 Feb 2022 10:19:17 GMT, Claes Redestad wrote: >> test/micro/org/openjdk/bench/java/lang/StringDecode.java line 72: >> >>> 70: public void setup() { >>> 71: charset = Charset.forName(charsetName); >>> 72: asciiString = LOREM.substring(0, 32).getBytes(charset); >> >> This is problematic IMO in that it's missing short strings such as "Claes". Average Java strings are about 32 bytes long AFAICR, and people writing (vectorized) ijntrinsics have a nasty habit of optimizing for long strings, to the detriment of typical-length ones. >> Whether we like it or not, people will optimize for benchmarks, so it's important that benchmark data is realistic. The shortest here is 15 bytes, as far as I can see. I'd certainly include a short string of just a few bytes so that intrinsics don't cause regressions in important cases. > > All good points. I've added a number of such short variants to all(?) relevant microbenchmarks. The tests should now better cover a mix of input lengths and encodings. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/7516 From coleenp at openjdk.java.net Fri Feb 25 15:01:53 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 25 Feb 2022 15:01:53 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v6] In-Reply-To: References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: On Wed, 23 Feb 2022 04:15:28 GMT, Ioi Lam wrote: >> **Background:** >> >> In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: >> >> >> public enum Day { SUNDAY, MONDAY ... } >> >> >> to >> >> >> public class Day extends java.lang.Enum { >> public static final SUNDAY = new Day("SUNDAY"); >> public static final MONDAY = new Day("MONDAY"); ... >> } >> >> >> With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) >> >> **Fix:** >> >> During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. >> >> This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. >> >> **Verification:** >> >> To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt >> >> **Testing:** >> >> Passed Oracle CI tiers 1-4. WIll run tier 5 as well. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed whitespace Sorry for the long delay. It's a big change, but a lot in debug so that's ok. Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6653 From coleenp at openjdk.java.net Fri Feb 25 15:01:54 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 25 Feb 2022 15:01:54 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v3] In-Reply-To: <4CLwCQdc_haGT_ueBQGZKzJVasGK26B6iYcO7VtOfAs=.02f3deb9-7ac7-45fd-9a7c-37b0fe4a8ea2@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> <7c6mh2-s3SkpfGG1WptyZsJjTfcDy1wX0Ll0713MLkU=.7df74a01-7ea5-49c1-9bda-f73798df3852@github.com> <4CLwCQdc_haGT_ueBQGZKzJVasGK26B6iYcO7VtOfAs=.02f3deb9-7ac7-45fd-9a7c-37b0fe4a8ea2@github.com> Message-ID: <1B2f3fl1vAMMiwyVKdf5rmn_kmJFhYxXFg71WAkILbw=.22926dc1-4234-4f21-98ee-64b5372c00c6@github.com> On Wed, 19 Jan 2022 05:44:10 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/heapShared.cpp line 433: >> >>> 431: oop mirror = k->java_mirror(); >>> 432: int i = 0; >>> 433: for (JavaFieldStream fs(k); !fs.done(); fs.next()) { >> >> This seems like it should also use InstanceKlass::do_local_static_fields. > > Converting this to InstanceKlass::do_nonstatic_fields() is difficult because the loop body references 7 different variables declared outside of the loop. > > One thing I tried is to add a new version of do_nonstatic_fields2() that supports C++ lambdas. You can see my experiment from here: > > https://github.com/openjdk/jdk/compare/master...iklam:lambda-for-instanceklass-do_local_static_fields2?expand=1 > > I changed all my new code to use the do_nonstatic_fields2() function with lambda. Ok, if it requires lambdas and additional change, never mind then. ------------- PR: https://git.openjdk.java.net/jdk/pull/6653 From rriggs at openjdk.java.net Fri Feb 25 15:07:07 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Feb 2022 15:07:07 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: <95lzzpvok3frmtC_v5bk5rBcfLLPQ4y-xlxw6DNi2TQ=.52e1d935-acbb-494a-9d74-d1575cfca393@github.com> On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check My preference is to pass the unmodified LIBPATH in the environment in each of the three cases. The expected checks already expect the unmodified LIBPATH so the only change is in the setup of the environment to be passed to the child. Already covered at line 1366: Insert at line 1873 in the if/then/else: } else if (AIX.is()) { envp = new String[] {"=ExitValue=3", "=C:=\", "LIBPATH="+libpath}; } else { (Or assign it to a local as is done for windows, your preference). And at line 1921'ish: ``` } else if (AIX.is()) { envp = new String[] {"LC_ALL=C\u0000\u0000", // Yuck! "FO\u0000=B\u0000R", "LIBPATH="+libpath}; I looked using `sh -c env` but I think it would be more work to change the way the output is compared. The output of `env` is different and has some other values that get inserted. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From asemenyuk at openjdk.java.net Fri Feb 25 15:53:55 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 25 Feb 2022 15:53:55 GMT Subject: RFR: 8279995: jpackage --add-launcher option should allow overriding description [v6] In-Reply-To: References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: <2BmhAnZXWbBjt26fCusGnhbtcto4uhkA1ecbn7j3elw=.70934dad-e102-48af-9599-bb0e52e43fd5@github.com> On Fri, 25 Feb 2022 01:27:52 GMT, Alexander Matveev wrote: >> Added ability to override description for additional launchers via "description" property. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8279995: jpackage --add-launcher option should allow overriding description [v5] Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From roger.riggs at oracle.com Fri Feb 25 15:54:50 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 25 Feb 2022 10:54:50 -0500 Subject: Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec In-Reply-To: <7969ed53-a676-0687-deff-c2086f1d0251@gmail.com> References: <3ca2a015-5a16-f34c-0758-4e892d9ad253@oracle.com> <7969ed53-a676-0687-deff-c2086f1d0251@gmail.com> Message-ID: <674b4b6c-a3cd-162e-9980-7387ef79d80c@oracle.com> Hi Raffaello, Runtime.exec and ProcessBuilder have been a challenge from the beginning, on one hand to have a reasonably cross-platform way to invoke processes and on the other to accommodate the platform differences, mostly on Windows due to the various command line parsing decoding of different applications and shells. The idea is to provide greater consistency and a clear guidance about how to invoke applications while guarding against inadvertent mistakes that might refer to files or other applications. Assembling command lines from individual strings is error prone and brittle especially in cases where some of the arguments may be assembled from configuration information, external inputs, and the container or server environment. Given the variations, the API should provide the application enough control and responsibility to customize the encoding to the target application, if it is needed, but handle the usual cases so it does not require developers to hand craft for each platform and target application. Ideally, the customization should be clearly visible in the API and be clear and easy to review and audit. Regards, Roger On 2/24/22 4:22 PM, Raffaello Giulietti wrote: > Hi, > > on Windows, the mechanism to launch a new program is for the parent to > call CreateProcess(). This function accepts, among others parameters, > a lpApplicationName string and a lpCommandLine string. There's a > *single* lpCommandLine that encodes all the arguments to pass to the > new program. > > The exact encoding of the arguments in the command line is imposed by > how the *new* program parses (decodes) the command line to get its > constituent parts. There are no fixed rules on how this happens. There > are some more or less well documented rules for some runtimes (e.g., > the C/C++ runtime) or for some specific programs (e.g., cmd.exe., > wscript.exe). In general, however, a program can decode in any way it > deems useful. > > Because the encoding is dictated by the target program's decoding, and > because the latter is really arbitrary, there's no safe, universal > procedure to encode a list of string arguments to a single command > line string. It is only when the decoding rules in the target program > are known that encoding in the parent becomes feasible. > > Thus, it might be more useful on Windows platforms to avoid the API > points that expose List or String[] for the arguments to the > target program and use the ones that accept a single String, instead. > The client of those API points would then have to deal with the > encoding specific for that program. This is a better match with the > underlying OS mechanism, namely CreateProcess(), which accepts a > single, already encoded string. > > In addition, to assist programmers unfamiliar with specific encodings, > widely used specific encoders (e.g., for the C/C++ runtime [1], for > cmd.exe, etc.) can be implemented separately. > > > Greetings > Raffaello > > ---- > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086105.html From duke at openjdk.java.net Fri Feb 25 16:17:00 2022 From: duke at openjdk.java.net (Maxim Kartashev) Date: Fri, 25 Feb 2022 16:17:00 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add a new line to the end of test file for JDK-8282008 It is apparent there is no one "correct" way to quote, but one of the key features of the Java ecosystem has been its backwards compatibility. In that light, this change allows our clients to continue doing what they did the way they did it without the need for modification of their Java code or their (maybe even foreign) native code. FWIW. Separately from the above, I wonder if this change would make the fix less controversial? - if (str.endsWith("\\"")) { + if (str.endsWith("\\"") && !str.endsWith("\\\\"")) { This way we verify that the end quote is really just an escaped quote, while correctly identifying escaped backslash as having nothing to do with the following quote. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From joe.darcy at oracle.com Fri Feb 25 17:22:40 2022 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 25 Feb 2022 09:22:40 -0800 Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: <95lzzpvok3frmtC_v5bk5rBcfLLPQ4y-xlxw6DNi2TQ=.52e1d935-acbb-494a-9d74-d1575cfca393@github.com> References: <95lzzpvok3frmtC_v5bk5rBcfLLPQ4y-xlxw6DNi2TQ=.52e1d935-acbb-494a-9d74-d1575cfca393@github.com> Message-ID: How about excluding the test from running on AIX? -Joe On 2/25/2022 7:07 AM, Roger Riggs wrote: > On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: > >>> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >>> The test was failed by: >>> Incorrect handling of envstrings containing NULs >>> >>> According to my investigation, this issue was happened after following change was applied. >>> JDK-8272600: (test) Use native "sleep" in Basic.java >>> >>> test.nativepath value was added into AIX's LIBPATH during running this testcase. >>> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> Add null check > My preference is to pass the unmodified LIBPATH in the environment in each of the three cases. > The expected checks already expect the unmodified LIBPATH so the only change is in the setup of the environment to be passed to the child. > > Already covered at line 1366: > > Insert at line 1873 in the if/then/else: > > } else if (AIX.is()) { > envp = new String[] {"=ExitValue=3", "=C:=\", "LIBPATH="+libpath}; > } else { > > (Or assign it to a local as is done for windows, your preference). > > And at line 1921'ish: > ``` } else if (AIX.is()) { > envp = new String[] {"LC_ALL=C\u0000\u0000", // Yuck! > "FO\u0000=B\u0000R", "LIBPATH="+libpath}; > > > I looked using `sh -c env` but I think it would be more work to change the way the output is compared. > The output of `env` is different and has some other values that get inserted. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7574 From thomas.stuefe at gmail.com Fri Feb 25 17:35:56 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 25 Feb 2022 18:35:56 +0100 Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: <95lzzpvok3frmtC_v5bk5rBcfLLPQ4y-xlxw6DNi2TQ=.52e1d935-acbb-494a-9d74-d1575cfca393@github.com> Message-ID: IMHO this is not hard to fix (we already have multiple proposals) and we'd should have this test on AIX too. Cheers, Thomas On Fri, Feb 25, 2022 at 6:23 PM Joe Darcy wrote: > How about excluding the test from running on AIX? > > -Joe > > On 2/25/2022 7:07 AM, Roger Riggs wrote: > > On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi < > itakiguchi at openjdk.org> wrote: > > > >>> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > >>> The test was failed by: > >>> Incorrect handling of envstrings containing NULs > >>> > >>> According to my investigation, this issue was happened after following > change was applied. > >>> JDK-8272600: (test) Use native "sleep" in Basic.java > >>> > >>> test.nativepath value was added into AIX's LIBPATH during running this > testcase. > >>> On AIX, test.nativepath value should be removed from LIBPATH value > before comparing the values. > >> Ichiroh Takiguchi has updated the pull request incrementally with one > additional commit since the last revision: > >> > >> Add null check > > My preference is to pass the unmodified LIBPATH in the environment in > each of the three cases. > > The expected checks already expect the unmodified LIBPATH so the only > change is in the setup of the environment to be passed to the child. > > > > Already covered at line 1366: > > > > Insert at line 1873 in the if/then/else: > > > > } else if (AIX.is()) { > > envp = new String[] {"=ExitValue=3", "=C:=\", > "LIBPATH="+libpath}; > > } else { > > > > (Or assign it to a local as is done for windows, your preference). > > > > And at line 1921'ish: > > ``` } else if (AIX.is()) { > > envp = new String[] {"LC_ALL=C\u0000\u0000", // Yuck! > > "FO\u0000=B\u0000R", "LIBPATH="+libpath}; > > > > > > I looked using `sh -c env` but I think it would be more work to change > the way the output is compared. > > The output of `env` is different and has some other values that get > inserted. > > > > ------------- > > > > PR: https://git.openjdk.java.net/jdk/pull/7574 > From duke at openjdk.java.net Fri Feb 25 17:37:01 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 25 Feb 2022 17:37:01 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 18:49:22 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Add null check I think it's good to keep the test on AIX since we have good solutions to the failure. I added +1 to Roger's suggestion above. Looks like it should work well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From bchristi at openjdk.java.net Fri Feb 25 17:37:07 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 25 Feb 2022 17:37:07 GMT Subject: RFR: 8282047: Enhance StringDecode/Encode microbenchmarks [v3] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 11:08:49 GMT, Claes Redestad wrote: >> Splitting out these micro changes from #7231 >> >> - Clean up and simplify setup and code >> - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. >> - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Fix typos, add missing short variants to latin1 and utf16 short decode methods > - Increase coverage of and weight of short strings Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7516 From itakiguchi at openjdk.java.net Fri Feb 25 17:45:39 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 25 Feb 2022 17:45:39 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v5] In-Reply-To: References: Message-ID: > Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > The test was failed by: > Incorrect handling of envstrings containing NULs > > According to my investigation, this issue was happened after following change was applied. > JDK-8272600: (test) Use native "sleep" in Basic.java > > test.nativepath value was added into AIX's LIBPATH during running this testcase. > On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: Pass LIBPATH setting for AIX ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7574/files - new: https://git.openjdk.java.net/jdk/pull/7574/files/b6d6afe7..60f8e96e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7574&range=03-04 Stats: 27 lines in 1 file changed: 8 ins; 17 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7574.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7574/head:pull/7574 PR: https://git.openjdk.java.net/jdk/pull/7574 From itakiguchi at openjdk.java.net Fri Feb 25 17:50:03 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Fri, 25 Feb 2022 17:50:03 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v4] In-Reply-To: <95lzzpvok3frmtC_v5bk5rBcfLLPQ4y-xlxw6DNi2TQ=.52e1d935-acbb-494a-9d74-d1575cfca393@github.com> References: <95lzzpvok3frmtC_v5bk5rBcfLLPQ4y-xlxw6DNi2TQ=.52e1d935-acbb-494a-9d74-d1575cfca393@github.com> Message-ID: On Fri, 25 Feb 2022 15:03:19 GMT, Roger Riggs wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: >> >> Add null check > > My preference is to pass the unmodified LIBPATH in the environment in each of the three cases. > The expected checks already expect the unmodified LIBPATH so the only change is in the setup of the environment to be passed to the child. > > Already covered at line 1366: > > Insert at line 1873 in the if/then/else: > > } else if (AIX.is()) { > envp = new String[] {"=ExitValue=3", "=C:=\", "LIBPATH="+libpath}; > } else { > > (Or assign it to a local as is done for windows, your preference). > > And at line 1921'ish: > ``` > } else if (AIX.is()) { > envp = new String[] {"LC_ALL=C\u0000\u0000", // Yuck! > "FO\u0000=B\u0000R", "LIBPATH="+libpath}; > > > I looked using `sh -c env` but I think it would be more work to change the way the output is compared. > The output of `env` is different and has some other values that get inserted. Many thanks, @RogerRiggs . I tried your suggested code, it worked fine on my AIX system. Could you review this change again ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From naoto at openjdk.java.net Fri Feb 25 19:11:23 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Feb 2022 19:11:23 GMT Subject: RFR: 8282131: java.time.ZoneId should be a sealed abstract class Message-ID: Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been drafted. ------------- Commit messages: - 8282131: java.time.ZoneId should be a sealed abstract class Changes: https://git.openjdk.java.net/jdk/pull/7625/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7625&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282131 Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7625.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7625/head:pull/7625 PR: https://git.openjdk.java.net/jdk/pull/7625 From iris at openjdk.java.net Fri Feb 25 19:32:53 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 25 Feb 2022 19:32:53 GMT Subject: RFR: 8282131: java.time.ZoneId should be a sealed abstract class In-Reply-To: References: Message-ID: <9Z0RVKNxTOaDr7FoTBVCnYLnsDd--OesVzkISJz_1EE=.41b4141a-614b-4a4a-a7c7-35c2b952b38f@github.com> On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote: > Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been drafted. Associated CSR also reviewed. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7625 From rriggs at openjdk.java.net Fri Feb 25 19:36:54 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Feb 2022 19:36:54 GMT Subject: RFR: 8282131: java.time.ZoneId should be a sealed abstract class In-Reply-To: References: Message-ID: <5gkkDcPG1BbNm32o_nJwKFDn6a41tg65uqBiKXzutQE=.ea593d85-3ace-4ee7-b7e3-cf346eafe7f9@github.com> On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote: > Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been drafted. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7625 From rriggs at openjdk.java.net Fri Feb 25 19:37:56 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Feb 2022 19:37:56 GMT Subject: RFR: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX [v5] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 17:45:39 GMT, Ichiroh Takiguchi wrote: >> Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. >> The test was failed by: >> Incorrect handling of envstrings containing NULs >> >> According to my investigation, this issue was happened after following change was applied. >> JDK-8272600: (test) Use native "sleep" in Basic.java >> >> test.nativepath value was added into AIX's LIBPATH during running this testcase. >> On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. > > Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: > > Pass LIBPATH setting for AIX Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From bpb at openjdk.java.net Fri Feb 25 19:49:52 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 25 Feb 2022 19:49:52 GMT Subject: RFR: 8282131: java.time.ZoneId should be a sealed abstract class In-Reply-To: References: Message-ID: <-y-Vt80WMgRUn_zPDnJ1ZiW44DvG9hco7IkP6FgjRwM=.3425edd0-1756-4ace-856d-e9db2d686132@github.com> On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote: > Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been drafted. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7625 From mchung at openjdk.java.net Fri Feb 25 19:49:53 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 25 Feb 2022 19:49:53 GMT Subject: RFR: 8282131: java.time.ZoneId should be a sealed abstract class In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote: > Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been drafted. Thanks for doing this. Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7625 From bpb at openjdk.java.net Fri Feb 25 20:01:55 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 25 Feb 2022 20:01:55 GMT Subject: RFR: JDK-8282144 RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 14:47:50 GMT, Jim Laskey wrote: > Class: ./java.base/share/classes/jdk/internal/util/random/RandomSupport.java > Method: public static long[] convertSeedBytesToLongs(byte[] seed, int n, int z) > > The method attempts to create an array of longs by consuming the input bytes most significant bit first. New bytes are appended to the existing long using the OR operator on the signed byte. Due to sign extension this will overwrite all the existing bits from 63 to 8 if the next byte is negative. test/jdk/java/util/Random/T8282144.java line 39: > 37: public class T8282144 { > 38: public static void main(String[] args) { > 39: RandomGenerator rng = RandomGeneratorFactory.of("L64X128MixRandom").create(42); Does `rng` always produce the same sequence? If so, then perhaps the seed, `42`, should be a random value that is printed. test/jdk/java/util/Random/T8282144.java line 52: > 50: for (int k = 0; k < existing.length; k++) { > 51: if (existing[k] != testing[k]) { > 52: throw new RuntimeException("convertSeedBytesToLongs incorrect"); Should `i`, `j`, and `k` be included in the exception message? ------------- PR: https://git.openjdk.java.net/jdk/pull/7614 From lancea at openjdk.java.net Fri Feb 25 19:49:53 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 25 Feb 2022 19:49:53 GMT Subject: RFR: 8282131: java.time.ZoneId should be a sealed abstract class In-Reply-To: References: Message-ID: <38JTFauDOgIhS2eNnoNjs8437t5GeYYRyyVtxJJUrQI=.38da9586-c918-4e23-bb16-210b0c956236@github.com> On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote: > Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been drafted. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7625 From almatvee at openjdk.java.net Fri Feb 25 20:53:56 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 25 Feb 2022 20:53:56 GMT Subject: Integrated: 8279995: jpackage --add-launcher option should allow overriding description In-Reply-To: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> References: <7gzW6xQMPQyrgD00HCSBSL1o3Gr4OR1zqi1C4MgPQqk=.d873456b-006f-4916-a4bf-692159237bc5@github.com> Message-ID: On Wed, 9 Feb 2022 07:37:42 GMT, Alexander Matveev wrote: > Added ability to override description for additional launchers via "description" property. This pull request has now been integrated. Changeset: fb8bf818 Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/fb8bf81842b55355f226ac9d8717646abd509721 Stats: 75 lines in 7 files changed: 65 ins; 0 del; 10 mod 8279995: jpackage --add-launcher option should allow overriding description Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/7399 From duke at openjdk.java.net Fri Feb 25 21:28:54 2022 From: duke at openjdk.java.net (iaroslavski) Date: Fri, 25 Feb 2022 21:28:54 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v11] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: <3lSfFIVp6dWOi2vtJUMwmAEuDKsGR5QrUdNcWOza-3Y=.371090e3-1493-4a4f-8e63-4d8f26a93d13@github.com> On Wed, 12 Jan 2022 14:22:03 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) > > * Updated javadoc > * Improved mixed insertion > * Optimized sort networking > * Improved pivot partitioning New update is coming ------------- PR: https://git.openjdk.java.net/jdk/pull/3938 From duke at openjdk.java.net Fri Feb 25 22:15:00 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 25 Feb 2022 22:15:00 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v9] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 01:13:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - change wrong indentation > - change indentation Ok i think all changes are in place, should we consider @liach changes also on this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Feb 25 22:45:54 2022 From: duke at openjdk.java.net (liach) Date: Fri, 25 Feb 2022 22:45:54 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v9] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 01:13:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - change wrong indentation > - change indentation test/jdk/java/util/Random/RandomTest.java line 420: > 418: */ > 419: public void testShufflingList() { > 420: final ArrayList listTest = new ArrayList(); Suggestion: final var listTest = new ArrayList(); Using `ArrayList` is fine too, but right now this is a raw type. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Feb 25 22:56:36 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 25 Feb 2022 22:56:36 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v10] In-Reply-To: References: Message-ID: <9AJL12jUZy5SnqXw0Uui3YqcvVW58HmAES-XMzZ9Bpo=.aa7db78c-d44e-4627-9d7e-77f28f7c9fef@github.com> > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: Use var instead of ArrayList raw Co-authored-by: liach <7806504+liach at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/b002205d..7bc45057 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Feb 25 23:01:54 2022 From: duke at openjdk.java.net (liach) Date: Fri, 25 Feb 2022 23:01:54 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6] In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 23:19:14 GMT, Marcono1234 wrote: >> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: >> >> remove missed whitespace > > src/java.base/share/classes/java/util/Random.java line 298: > >> 296: */ >> 297: public static Random from(RandomGenerator random) { >> 298: return RandomWrapper.wrap(random); > > Might be good to check here or in the called methods / constructors for `null`. Currently `null` would not be noticed until the first method is called on the created `Random`, which makes it difficult for the user to track down bugs in their code. Suggestion: Objects.requireNonNull(random); return RandomWrapper.wrap(random); fyi this is the original change suggested by marcono1234. Notice that this might need a csr update; maybe a javadoc update is needed too ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Feb 25 23:01:54 2022 From: duke at openjdk.java.net (Marcono1234) Date: Fri, 25 Feb 2022 23:01:54 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6] In-Reply-To: References: Message-ID: On Sun, 20 Feb 2022 03:15:22 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > remove missed whitespace src/java.base/share/classes/java/util/Random.java line 298: > 296: */ > 297: public static Random from(RandomGenerator random) { > 298: return RandomWrapper.wrap(random); Might be good to check here or in the called methods / constructors for `null`. Currently `null` would not be noticed until the first method is called on the created `Random`, which makes it difficult for the user to track down bugs in their code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Feb 25 23:16:55 2022 From: duke at openjdk.java.net (Marcono1234) Date: Fri, 25 Feb 2022 23:16:55 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v10] In-Reply-To: <9AJL12jUZy5SnqXw0Uui3YqcvVW58HmAES-XMzZ9Bpo=.aa7db78c-d44e-4627-9d7e-77f28f7c9fef@github.com> References: <9AJL12jUZy5SnqXw0Uui3YqcvVW58HmAES-XMzZ9Bpo=.aa7db78c-d44e-4627-9d7e-77f28f7c9fef@github.com> Message-ID: <8E6Kbkjp8APa7MK47b47Juc-XWsOIzSNGhUSFKndr3g=.c1ba2193-7e23-4de7-9935-7979f439dee7@github.com> On Fri, 25 Feb 2022 22:56:36 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > Use var instead of ArrayList raw > > Co-authored-by: liach <7806504+liach at users.noreply.github.com> src/java.base/share/classes/java/util/Random.java line 92: > 90: */ > 91: > 92: @SuppressWarnings("serial") Is this really fine, or should a `serialVersionUID` be defined? (And maybe `initialized` should be made transient then) src/java.base/share/classes/java/util/Random.java line 93: > 91: > 92: @SuppressWarnings("serial") > 93: private static class RandomWrapper extends Random implements RandomGenerator { Isn't ` implements RandomGenerator` redundant because `Random` already implements `RandomGenerator`? src/java.base/share/classes/java/util/Random.java line 107: > 105: return rand; > 106: > 107: return (Random) new Random.RandomWrapper(random); Isn't the `(Random)` cast redundant? src/java.base/share/classes/java/util/Random.java line 290: > 288: /** > 289: * Returns an instance of {@link Random} based on this > 290: * {@code java.util.random.RandomGenerator}. If this generator is already an instance of Would it make sense to use a `{@link ...}` here instead? (and maybe remove the `{@link ...}` from the `@param` and the `@return`; since that might be rather uncommon for OpenJDK javadoc?) ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Feb 25 23:27:45 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 25 Feb 2022 23:27:45 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v11] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: Update javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/7bc45057..60c1e382 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=09-10 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Feb 25 23:33:58 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 25 Feb 2022 23:33:58 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v10] In-Reply-To: <8E6Kbkjp8APa7MK47b47Juc-XWsOIzSNGhUSFKndr3g=.c1ba2193-7e23-4de7-9935-7979f439dee7@github.com> References: <9AJL12jUZy5SnqXw0Uui3YqcvVW58HmAES-XMzZ9Bpo=.aa7db78c-d44e-4627-9d7e-77f28f7c9fef@github.com> <8E6Kbkjp8APa7MK47b47Juc-XWsOIzSNGhUSFKndr3g=.c1ba2193-7e23-4de7-9935-7979f439dee7@github.com> Message-ID: <0HYZ6B9fXtwmrB93tqUa5c6JxBw6YrJHrjYoAt0kWqs=.0a5beba9-da0c-44a1-8815-6c929792f3c2@github.com> On Fri, 25 Feb 2022 23:05:48 GMT, Marcono1234 wrote: >> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: >> >> Use var instead of ArrayList raw >> >> Co-authored-by: liach <7806504+liach at users.noreply.github.com> > > src/java.base/share/classes/java/util/Random.java line 93: > >> 91: >> 92: @SuppressWarnings("serial") >> 93: private static class RandomWrapper extends Random implements RandomGenerator { > > Isn't ` implements RandomGenerator` redundant because `Random` already implements `RandomGenerator`? I prefered to keep the interface explicit to the reader > src/java.base/share/classes/java/util/Random.java line 107: > >> 105: return rand; >> 106: >> 107: return (Random) new Random.RandomWrapper(random); > > Isn't the `(Random)` cast redundant? Eclipse did not complain about it being redundant, also it does not impact the reading of it and it shows the reader it is a Random instance that is returning ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From scolebourne at openjdk.java.net Fri Feb 25 23:54:52 2022 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Fri, 25 Feb 2022 23:54:52 GMT Subject: RFR: 8282131: java.time.ZoneId should be a sealed abstract class In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote: > Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been drafted. Marked as reviewed by scolebourne (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/7625 From sviswanathan at openjdk.java.net Sat Feb 26 01:33:54 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Sat, 26 Feb 2022 01:33:54 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 06:22:42 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Adding descriptive comments. Other than this the patch looks good to me. What testing have you done? src/hotspot/cpu/x86/x86.ad line 7263: > 7261: __ vector_round_float_avx($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister, > 7262: $xtmp2$$XMMRegister, $xtmp3$$XMMRegister, $xtmp4$$XMMRegister, > 7263: ExternalAddress(vector_float_signflip()), new_mxcsr, $scratch$$Register, vlen_enc); The vector_float_signflip() here should be replaced by vector_all_bits_set(). cvtps2dq description: If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned. src/hotspot/cpu/x86/x86.ad line 7280: > 7278: __ vector_round_float_evex($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister, > 7279: $xtmp2$$XMMRegister, $ktmp1$$KRegister, $ktmp2$$KRegister, > 7280: ExternalAddress(vector_float_signflip()), new_mxcsr, $scratch$$Register, vlen_enc); The vector_float_signflip() here should be replaced by vector_all_bits_set(). src/hotspot/cpu/x86/x86.ad line 7295: > 7293: __ vector_round_double_evex($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister, > 7294: $xtmp2$$XMMRegister, $ktmp1$$KRegister, $ktmp2$$KRegister, > 7295: ExternalAddress(vector_double_signflip()), new_mxcsr, $scratch$$Register, vlen_enc); The vector_double_signflip() here should be replaced by vector_all_bits_set(). vcvtpd2qq description: If a converted result cannot be represented in the destination format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (2w-1, where w represents the number of bits in the destination format) is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Sat Feb 26 02:07:00 2022 From: duke at openjdk.java.net (liach) Date: Sat, 26 Feb 2022 02:07:00 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v10] In-Reply-To: <0HYZ6B9fXtwmrB93tqUa5c6JxBw6YrJHrjYoAt0kWqs=.0a5beba9-da0c-44a1-8815-6c929792f3c2@github.com> References: <9AJL12jUZy5SnqXw0Uui3YqcvVW58HmAES-XMzZ9Bpo=.aa7db78c-d44e-4627-9d7e-77f28f7c9fef@github.com> <8E6Kbkjp8APa7MK47b47Juc-XWsOIzSNGhUSFKndr3g=.c1ba2193-7e23-4de7-9935-7979f439dee7@github.com> <0HYZ6B9fXtwmrB93tqUa5c6JxBw6YrJHrjYoAt0kWqs=.0a5beba9-da0c-44a1-8815-6c929792f3c2@github.com> Message-ID: <8Y2TcK4xiqWKni3rqRehIkdUOHp4aLYi1ZFaGHlD65Q=.53bde647-f5df-4b4c-a35d-5cfcc6ce8c5e@github.com> On Fri, 25 Feb 2022 23:27:28 GMT, Yasser Bazzi wrote: > I prefered to keep the interface explicit to the reader but this object's goal is to serve as a random than a randomgenerator ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From sviswanathan at openjdk.java.net Sat Feb 26 03:05:54 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Sat, 26 Feb 2022 03:05:54 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com> On Sat, 26 Feb 2022 01:06:21 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Adding descriptive comments. > > src/hotspot/cpu/x86/x86.ad line 7263: > >> 7261: __ vector_round_float_avx($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister, >> 7262: $xtmp2$$XMMRegister, $xtmp3$$XMMRegister, $xtmp4$$XMMRegister, >> 7263: ExternalAddress(vector_float_signflip()), new_mxcsr, $scratch$$Register, vlen_enc); > > The vector_float_signflip() here should be replaced by vector_all_bits_set(). > cvtps2dq description: > If a converted result cannot be represented in the destination > format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value > (2w-1, where w represents the number of bits in the destination format) is returned. Clarification, the number in my comments above is (2^w - 1). This is from Intel SDM (https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html). Also you will need to take care when the valid unoverflowed result is -1 i.e. 0xFFFFFFFF (2^32 - 1). ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jpai at openjdk.java.net Sat Feb 26 03:33:53 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 26 Feb 2022 03:33:53 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v5] In-Reply-To: <_-XlZDme3lIVFOeuD17Ht6a5qiKxRLibm6EFex2YOn8=.efc1df68-8603-4c7a-b687-b4855f57cbd8@github.com> References: <_-XlZDme3lIVFOeuD17Ht6a5qiKxRLibm6EFex2YOn8=.efc1df68-8603-4c7a-b687-b4855f57cbd8@github.com> Message-ID: On Fri, 25 Feb 2022 08:44:42 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? >> >> As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: >> - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. >> - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. >> >> All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: >> >> >> Using locale: he for Properties#store(OutputStream) test >> test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure >> java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 >> at org.testng.Assert.fail(Assert.java:87) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) >> at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> 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:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:828) >> Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 >> at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) >> at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) >> ... 30 more >> >> (in the exception above a locale with language `he` is being used) >> >> The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > HashSet::new instead of new HashSet() in test Hello Roger, are the current changes in the PR OK to merge? ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From jpai at openjdk.java.net Sat Feb 26 03:33:53 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 26 Feb 2022 03:33:53 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v3] In-Reply-To: References: Message-ID: <49YV8pJm5B3Jbz1FjM66ifMVWdY5vHptsN2yQHAtqmw=.3bbe03d7-39ce-4fd0-872b-28a59ad9894a@github.com> On Fri, 25 Feb 2022 04:44:45 GMT, Naoto Sato wrote: >> That's a very good point. I've updated the PR to now explicitly use a mutable `Set` instead of using `Collectors.toSet()` > > This is ok, although `Collectors.toCollection(HashSet::new)` is a bit concise. Hello Naoto, I've updated the PR to use `HashSet::new`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From duke at openjdk.java.net Sat Feb 26 03:42:02 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sat, 26 Feb 2022 03:42:02 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: <8mhsd-DL1IccFiqrRigKdck8OJg79sjKgaYXrHc4zwY=.c92cb7f5-8e54-42ab-84f1-9cfa1ce76779@github.com> References: <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com> <8mhsd-DL1IccFiqrRigKdck8OJg79sjKgaYXrHc4zwY=.c92cb7f5-8e54-42ab-84f1-9cfa1ce76779@github.com> Message-ID: On Sat, 26 Feb 2022 03:37:32 GMT, Quan Anh Mai wrote: >> Clarification, the number in my comments above is (2^w - 1). This is from Intel SDM (https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html). >> Also you will need to take care when the valid unoverflowed result is -1 i.e. 0xFFFFFFFF (2^32 - 1). > > I believe the indefinite value should be 2^(w - 1) (a.k.a 0x80000000) and the documentation is typoed. If you look at `cvtss2si`, the indefinite value is also written as 2^w - 1 but yet in `MacroAssembler::convert_f2i` we compare it with 0x80000000. In addition, choosing -1 as an indefinite value is weird enough and to complicate it as 2^w - 1 is really unusual. `MacroAssembler::convert_f2i` https://github.com/openjdk/jdk/blob/c5c6058fd57d4b594012035eaf18a57257f4ad85/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8919 ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Sat Feb 26 03:42:02 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sat, 26 Feb 2022 03:42:02 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com> References: <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com> Message-ID: <8mhsd-DL1IccFiqrRigKdck8OJg79sjKgaYXrHc4zwY=.c92cb7f5-8e54-42ab-84f1-9cfa1ce76779@github.com> On Sat, 26 Feb 2022 03:02:51 GMT, Sandhya Viswanathan wrote: >> src/hotspot/cpu/x86/x86.ad line 7263: >> >>> 7261: __ vector_round_float_avx($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister, >>> 7262: $xtmp2$$XMMRegister, $xtmp3$$XMMRegister, $xtmp4$$XMMRegister, >>> 7263: ExternalAddress(vector_float_signflip()), new_mxcsr, $scratch$$Register, vlen_enc); >> >> The vector_float_signflip() here should be replaced by vector_all_bits_set(). >> cvtps2dq description: >> If a converted result cannot be represented in the destination >> format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value >> (2w-1, where w represents the number of bits in the destination format) is returned. > > Clarification, the number in my comments above is (2^w - 1). This is from Intel SDM (https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html). > Also you will need to take care when the valid unoverflowed result is -1 i.e. 0xFFFFFFFF (2^32 - 1). I believe the indefinite value should be 2^(w - 1) (a.k.a 0x80000000) and the documentation is typoed. If you look at `cvtss2si`, the indefinite value is also written as 2^w - 1 but yet in `MacroAssembler::convert_f2i` we compare it with 0x80000000. In addition, choosing -1 as an indefinite value is weird enough and to complicate it as 2^w - 1 is really unusual. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sat Feb 26 04:57:55 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sat, 26 Feb 2022 04:57:55 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 06:22:42 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Adding descriptive comments. As per SDM, if post conversion a floating point number is non-representable in destination format e.g. a floating point value 3.4028235E10 post integer conversion will overflow the value range of integer primitive type, hence a -0.0 value or 0x80000000 is returned here. Similarly for +/- NaN and +/-Inf post conversion value returns is -0.0. All these cases i.e. post conversion non-representable floating point values and NaN/Inf values are handled in a special manner where algorithm first performs an unordered comparison b/w original source value and returns a 0 in case of NaN, this weeds out the NaN case and for rest of the special values we check the MSB bit of the source and either return an Integer.MAX_VALUE for +ve numbers or a Integer.MIN_VALUE to adhere to the semantics of Math.round API. Existing tests were enhanced to cover various special cases (NaN/Inf/+ve/-ve value/values which may be inexact after adding 0.5/ values which post conversion overflow integer value range). ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From ethan at mccue.dev Sat Feb 26 22:14:19 2022 From: ethan at mccue.dev (Ethan McCue) Date: Sat, 26 Feb 2022 17:14:19 -0500 Subject: Should System.exit be controlled by a Scope Local? Message-ID: I have a feeling this has been considered and I might just be articulating the obvious - but: As called out in JEP 411, one of the remaining legitimate uses of the Security Manager is to intercept calls to System.exit. This seems like a decent use case for the Scope Local mechanism. public class Runtime { ... private final ScopeLocal EXIT = ScopeLocal.newInstance(); ... public void overridingExitBehavior(IntConsumer exit, Runnable run) { ScopeLocal.with(EXIT, exit).run(run); } ... public void exit(int status) { if (EXIT.isBound()) { EXIT.get().accept(status); } else { Shutdown.exit(status); } } } One of the likely minor benefits in the scope of things, but related to the parts of the ecosystem I am doodling with so I'll mention it, is that it would become possible to wrap "naive" cli programs with the ToolProvider SPI without rewriting their code if this System.out, and System.err all became reliably configurable. For instance, Apache Ivy's CLI has a main class that looks like this https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java package org.apache.ivy; public final class Main { ... public static void main(String[] args) throws Exception { try { run(args, true); System.exit(0); } catch (ParseException ex) { System.err.println(ex.getMessage()); System.exit(1); } } } Making these otherwise static parts of the system configurable would enable a third party library to write public final class IvyToolProvider implements ToolProvider { @Override public String name() { return "ivy"; } @Override public int run(PrintWriter out, PrintWriter err, String... args) { var exit = new AtomicInteger(0); Runtime.getRuntime().overridingExitBehavior(exit::set, () -> { System.overridingOut(out, () -> { System.overridingErr(err, Main::main); } }; return exit.get(); } } Whether that would be enough to make it so that people other than Christian Stein use the mechanism is anyone's guess, but might be worth a shot. https://grep.app/search?q=java.util.spi.ToolProvider From forax at univ-mlv.fr Sun Feb 27 13:01:47 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 27 Feb 2022 14:01:47 +0100 (CET) Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: Message-ID: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> Hi Ethan, there is a far simpler solution, call org.apache.ivy.run(args, true) instead of org.apache.ivy.main(args) in your tool provider. regards, R?mi ----- Original Message ----- > From: "Ethan McCue" > To: "core-libs-dev" > Sent: Saturday, February 26, 2022 11:14:19 PM > Subject: Should System.exit be controlled by a Scope Local? > I have a feeling this has been considered and I might just be articulating > the obvious - but: > > As called out in JEP 411, one of the remaining legitimate uses of the > Security Manager is to intercept calls to System.exit. This seems like a > decent use case for the Scope Local mechanism. > > > public class Runtime { > ... > private final ScopeLocal EXIT = > ScopeLocal.newInstance(); > > ... > > public void overridingExitBehavior(IntConsumer exit, Runnable run) { > ScopeLocal.with(EXIT, exit).run(run); > } > > ... > > public void exit(int status) { > if (EXIT.isBound()) { > EXIT.get().accept(status); > } > else { > Shutdown.exit(status); > } > } > } > > > One of the likely minor benefits in the scope of things, but related to the > parts of the ecosystem I am doodling with so I'll mention it, is that it > would become possible to wrap "naive" cli programs with the ToolProvider > SPI without rewriting their code if this System.out, and System.err all > became reliably configurable. > > For instance, Apache Ivy's CLI has a main class that looks like this > > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > > package org.apache.ivy; > > public final class Main { > ... > > public static void main(String[] args) throws Exception { > try { > run(args, true); > System.exit(0); > } catch (ParseException ex) { > System.err.println(ex.getMessage()); > System.exit(1); > } > } > } > > Making these otherwise static parts of the system configurable would enable > a third party library to write > > public final class IvyToolProvider implements ToolProvider { > @Override > public String name() { > return "ivy"; > } > > @Override > public int run(PrintWriter out, PrintWriter err, String... args) { > var exit = new AtomicInteger(0); > Runtime.getRuntime().overridingExitBehavior(exit::set, () -> { > System.overridingOut(out, () -> { > System.overridingErr(err, Main::main); > } > }; > return exit.get(); > } > } > > Whether that would be enough to make it so that people other than Christian > Stein use the mechanism is anyone's guess, but might be worth a shot. > > https://grep.app/search?q=java.util.spi.ToolProvider From ethan at mccue.dev Sun Feb 27 15:06:27 2022 From: ethan at mccue.dev (Ethan McCue) Date: Sun, 27 Feb 2022 10:06:27 -0500 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> References: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> Message-ID: That undermines my point some, but I think the overall shape of the use case still makes sense On Sun, Feb 27, 2022 at 8:01 AM Remi Forax wrote: > Hi Ethan, > there is a far simpler solution, call org.apache.ivy.run(args, true) > instead of org.apache.ivy.main(args) in your tool provider. > > regards, > R?mi > > ----- Original Message ----- > > From: "Ethan McCue" > > To: "core-libs-dev" > > Sent: Saturday, February 26, 2022 11:14:19 PM > > Subject: Should System.exit be controlled by a Scope Local? > > > I have a feeling this has been considered and I might just be > articulating > > the obvious - but: > > > > As called out in JEP 411, one of the remaining legitimate uses of the > > Security Manager is to intercept calls to System.exit. This seems like a > > decent use case for the Scope Local mechanism. > > > > > > public class Runtime { > > ... > > private final ScopeLocal EXIT = > > ScopeLocal.newInstance(); > > > > ... > > > > public void overridingExitBehavior(IntConsumer exit, Runnable > run) { > > ScopeLocal.with(EXIT, exit).run(run); > > } > > > > ... > > > > public void exit(int status) { > > if (EXIT.isBound()) { > > EXIT.get().accept(status); > > } > > else { > > Shutdown.exit(status); > > } > > } > > } > > > > > > One of the likely minor benefits in the scope of things, but related to > the > > parts of the ecosystem I am doodling with so I'll mention it, is that it > > would become possible to wrap "naive" cli programs with the ToolProvider > > SPI without rewriting their code if this System.out, and System.err all > > became reliably configurable. > > > > For instance, Apache Ivy's CLI has a main class that looks like this > > > > > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > > > > package org.apache.ivy; > > > > public final class Main { > > ... > > > > public static void main(String[] args) throws Exception { > > try { > > run(args, true); > > System.exit(0); > > } catch (ParseException ex) { > > System.err.println(ex.getMessage()); > > System.exit(1); > > } > > } > > } > > > > Making these otherwise static parts of the system configurable would > enable > > a third party library to write > > > > public final class IvyToolProvider implements ToolProvider { > > @Override > > public String name() { > > return "ivy"; > > } > > > > @Override > > public int run(PrintWriter out, PrintWriter err, String... args) { > > var exit = new AtomicInteger(0); > > Runtime.getRuntime().overridingExitBehavior(exit::set, () -> { > > System.overridingOut(out, () -> { > > System.overridingErr(err, Main::main); > > } > > }; > > return exit.get(); > > } > > } > > > > Whether that would be enough to make it so that people other than > Christian > > Stein use the mechanism is anyone's guess, but might be worth a shot. > > > > https://grep.app/search?q=java.util.spi.ToolProvider > From zjx001202 at gmail.com Sun Feb 27 15:40:51 2022 From: zjx001202 at gmail.com (Glavo) Date: Sun, 27 Feb 2022 23:40:51 +0800 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> Message-ID: I think there is a problem with this: `System.exit` contains semantics to interrupt the flow of control and exit, and if you implement it that way, you might have some program abnormally execute parts of it that should never be executed. Of course, using exceptions like this should solve part of the problem: class Exit extends Error { final int exitCode; public Exit(int exitCode) { this.exitCode = exitCode; } @Override public synchronized Throwable fillInStackTrace() { return this; } } try { Runtime.getRuntime().overridingExitBehavior(exitCode -> {throw new Exit(exitCode);}, ...); } catch (Exit exit) { ... } However, the calling method may catch this exception unexpectedly, and there may be unexpected behavior under multithreading. Of course, this part of the problem also exists for the security manager. But, if possible, it would be better to have a solution for these situations. (`Continuation` might help us?) On Sun, Feb 27, 2022 at 11:07 PM Ethan McCue wrote: > That undermines my point some, but I think the overall shape of the use > case still makes sense > > On Sun, Feb 27, 2022 at 8:01 AM Remi Forax wrote: > > > Hi Ethan, > > there is a far simpler solution, call org.apache.ivy.run(args, true) > > instead of org.apache.ivy.main(args) in your tool provider. > > > > regards, > > R?mi > > > > ----- Original Message ----- > > > From: "Ethan McCue" > > > To: "core-libs-dev" > > > Sent: Saturday, February 26, 2022 11:14:19 PM > > > Subject: Should System.exit be controlled by a Scope Local? > > > > > I have a feeling this has been considered and I might just be > > articulating > > > the obvious - but: > > > > > > As called out in JEP 411, one of the remaining legitimate uses of the > > > Security Manager is to intercept calls to System.exit. This seems like > a > > > decent use case for the Scope Local mechanism. > > > > > > > > > public class Runtime { > > > ... > > > private final ScopeLocal EXIT = > > > ScopeLocal.newInstance(); > > > > > > ... > > > > > > public void overridingExitBehavior(IntConsumer exit, Runnable > > run) { > > > ScopeLocal.with(EXIT, exit).run(run); > > > } > > > > > > ... > > > > > > public void exit(int status) { > > > if (EXIT.isBound()) { > > > EXIT.get().accept(status); > > > } > > > else { > > > Shutdown.exit(status); > > > } > > > } > > > } > > > > > > > > > One of the likely minor benefits in the scope of things, but related to > > the > > > parts of the ecosystem I am doodling with so I'll mention it, is that > it > > > would become possible to wrap "naive" cli programs with the > ToolProvider > > > SPI without rewriting their code if this System.out, and System.err all > > > became reliably configurable. > > > > > > For instance, Apache Ivy's CLI has a main class that looks like this > > > > > > > > > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > > > > > > package org.apache.ivy; > > > > > > public final class Main { > > > ... > > > > > > public static void main(String[] args) throws Exception { > > > try { > > > run(args, true); > > > System.exit(0); > > > } catch (ParseException ex) { > > > System.err.println(ex.getMessage()); > > > System.exit(1); > > > } > > > } > > > } > > > > > > Making these otherwise static parts of the system configurable would > > enable > > > a third party library to write > > > > > > public final class IvyToolProvider implements ToolProvider { > > > @Override > > > public String name() { > > > return "ivy"; > > > } > > > > > > @Override > > > public int run(PrintWriter out, PrintWriter err, String... > args) { > > > var exit = new AtomicInteger(0); > > > Runtime.getRuntime().overridingExitBehavior(exit::set, () > -> { > > > System.overridingOut(out, () -> { > > > System.overridingErr(err, Main::main); > > > } > > > }; > > > return exit.get(); > > > } > > > } > > > > > > Whether that would be enough to make it so that people other than > > Christian > > > Stein use the mechanism is anyone's guess, but might be worth a shot. > > > > > > https://grep.app/search?q=java.util.spi.ToolProvider > > > From ethan at mccue.dev Sun Feb 27 17:20:34 2022 From: ethan at mccue.dev (Ethan McCue) Date: Sun, 27 Feb 2022 12:20:34 -0500 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> Message-ID: I think continuations could work for the single threaded case, depending on their behavior with "finally" blocks. I'm sure there are more caveats once we add another thread to the mix though. System.exit is a nuclear Thread.interrupt, so replicating that behavior might be a bit daunting private static final class ExitCode { volatile Integer code = null; } private final ScopeLocal EXIT_CODE = ScopeLocal.newInstance(); public void overridingExitBehavior(IntConsumer exit, Runnable run) { var exitCode = new ExitCode(); ScopeLocal.with(EXIT_CODE, exitCode).run(() -> { // by whatever syntax var _ = inContinuation(run); if (exitCode.code != null) { exit.accept(code.exitCode) } }); } public void exit(int status) { if (EXIT_CODE.isBound()) { EXIT_CODE.get().code = status; Continuation.yield(); } else { Shutdown.exit(status); } } On Sun, Feb 27, 2022 at 10:41 AM Glavo wrote: > I think there is a problem with this: `System.exit` contains semantics to > interrupt the flow of control and exit, and if you implement it that way, > you might have some program abnormally execute parts of it that should > never be executed. > > Of course, using exceptions like this should solve part of the problem: > > class Exit extends Error { > final int exitCode; > public Exit(int exitCode) { > this.exitCode = exitCode; > } > > @Override > public synchronized Throwable fillInStackTrace() { > return this; > } > } > > try { > Runtime.getRuntime().overridingExitBehavior(exitCode -> {throw new > Exit(exitCode);}, ...); > } catch (Exit exit) { > ... > } > > However, the calling method may catch this exception unexpectedly, and > there may be unexpected behavior under multithreading. > Of course, this part of the problem also exists for the security manager. > But, if possible, it would be better to have a solution for these > situations. > (`Continuation` might help us?) > > > > On Sun, Feb 27, 2022 at 11:07 PM Ethan McCue wrote: > >> That undermines my point some, but I think the overall shape of the use >> case still makes sense >> >> On Sun, Feb 27, 2022 at 8:01 AM Remi Forax wrote: >> >> > Hi Ethan, >> > there is a far simpler solution, call org.apache.ivy.run(args, true) >> > instead of org.apache.ivy.main(args) in your tool provider. >> > >> > regards, >> > R?mi >> > >> > ----- Original Message ----- >> > > From: "Ethan McCue" >> > > To: "core-libs-dev" >> > > Sent: Saturday, February 26, 2022 11:14:19 PM >> > > Subject: Should System.exit be controlled by a Scope Local? >> > >> > > I have a feeling this has been considered and I might just be >> > articulating >> > > the obvious - but: >> > > >> > > As called out in JEP 411, one of the remaining legitimate uses of the >> > > Security Manager is to intercept calls to System.exit. This seems >> like a >> > > decent use case for the Scope Local mechanism. >> > > >> > > >> > > public class Runtime { >> > > ... >> > > private final ScopeLocal EXIT = >> > > ScopeLocal.newInstance(); >> > > >> > > ... >> > > >> > > public void overridingExitBehavior(IntConsumer exit, Runnable >> > run) { >> > > ScopeLocal.with(EXIT, exit).run(run); >> > > } >> > > >> > > ... >> > > >> > > public void exit(int status) { >> > > if (EXIT.isBound()) { >> > > EXIT.get().accept(status); >> > > } >> > > else { >> > > Shutdown.exit(status); >> > > } >> > > } >> > > } >> > > >> > > >> > > One of the likely minor benefits in the scope of things, but related >> to >> > the >> > > parts of the ecosystem I am doodling with so I'll mention it, is that >> it >> > > would become possible to wrap "naive" cli programs with the >> ToolProvider >> > > SPI without rewriting their code if this System.out, and System.err >> all >> > > became reliably configurable. >> > > >> > > For instance, Apache Ivy's CLI has a main class that looks like this >> > > >> > > >> > >> https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java >> > > >> > > package org.apache.ivy; >> > > >> > > public final class Main { >> > > ... >> > > >> > > public static void main(String[] args) throws Exception { >> > > try { >> > > run(args, true); >> > > System.exit(0); >> > > } catch (ParseException ex) { >> > > System.err.println(ex.getMessage()); >> > > System.exit(1); >> > > } >> > > } >> > > } >> > > >> > > Making these otherwise static parts of the system configurable would >> > enable >> > > a third party library to write >> > > >> > > public final class IvyToolProvider implements ToolProvider { >> > > @Override >> > > public String name() { >> > > return "ivy"; >> > > } >> > > >> > > @Override >> > > public int run(PrintWriter out, PrintWriter err, String... >> args) { >> > > var exit = new AtomicInteger(0); >> > > Runtime.getRuntime().overridingExitBehavior(exit::set, () >> -> { >> > > System.overridingOut(out, () -> { >> > > System.overridingErr(err, Main::main); >> > > } >> > > }; >> > > return exit.get(); >> > > } >> > > } >> > > >> > > Whether that would be enough to make it so that people other than >> > Christian >> > > Stein use the mechanism is anyone's guess, but might be worth a shot. >> > > >> > > https://grep.app/search?q=java.util.spi.ToolProvider >> > >> > From aph-open at littlepinkcloud.com Sun Feb 27 18:47:55 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sun, 27 Feb 2022 18:47:55 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: Message-ID: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> On 2/26/22 22:14, Ethan McCue wrote: > As called out in JEP 411, one of the remaining legitimate uses of the > Security Manager is to intercept calls to System.exit. This seems like a > decent use case for the Scope Local mechanism. It could well be. One problem, at least in the preview version of scope locals, is that scope locals are only inherited in a structured concurrency context, so it wouldn't protect against starting a new Thread which then called System.exit(). I'd like to explore the use of scope locals as a lightweight means to implement a system of permissions and capabilities for things such as this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Sun Feb 27 22:16:24 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Feb 2022 08:16:24 +1000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> Message-ID: <2de9853f-4702-81f3-c6a8-fec599dd1497@oracle.com> On 28/02/2022 3:20 am, Ethan McCue wrote: > I think continuations could work for the single threaded case, depending on > their behavior with "finally" blocks. I'm sure there are more caveats once > we add another thread to the mix though. System.exit is a nuclear > Thread.interrupt, so replicating that behavior might be a bit daunting What has Thread.interrupt got to do with System.exit ? David > private static final class ExitCode { > volatile Integer code = null; > } > > private final ScopeLocal EXIT_CODE = ScopeLocal.newInstance(); > > public void overridingExitBehavior(IntConsumer exit, Runnable run) { > var exitCode = new ExitCode(); > ScopeLocal.with(EXIT_CODE, exitCode).run(() -> { > // by whatever syntax > var _ = inContinuation(run); > if (exitCode.code != null) { > exit.accept(code.exitCode) > } > }); > } > > public void exit(int status) { > if (EXIT_CODE.isBound()) { > EXIT_CODE.get().code = status; > Continuation.yield(); > } > else { > Shutdown.exit(status); > } > } > > > > On Sun, Feb 27, 2022 at 10:41 AM Glavo wrote: > >> I think there is a problem with this: `System.exit` contains semantics to >> interrupt the flow of control and exit, and if you implement it that way, >> you might have some program abnormally execute parts of it that should >> never be executed. >> >> Of course, using exceptions like this should solve part of the problem: >> >> class Exit extends Error { >> final int exitCode; >> public Exit(int exitCode) { >> this.exitCode = exitCode; >> } >> >> @Override >> public synchronized Throwable fillInStackTrace() { >> return this; >> } >> } >> >> try { >> Runtime.getRuntime().overridingExitBehavior(exitCode -> {throw new >> Exit(exitCode);}, ...); >> } catch (Exit exit) { >> ... >> } >> >> However, the calling method may catch this exception unexpectedly, and >> there may be unexpected behavior under multithreading. >> Of course, this part of the problem also exists for the security manager. >> But, if possible, it would be better to have a solution for these >> situations. >> (`Continuation` might help us?) >> >> >> >> On Sun, Feb 27, 2022 at 11:07 PM Ethan McCue wrote: >> >>> That undermines my point some, but I think the overall shape of the use >>> case still makes sense >>> >>> On Sun, Feb 27, 2022 at 8:01 AM Remi Forax wrote: >>> >>>> Hi Ethan, >>>> there is a far simpler solution, call org.apache.ivy.run(args, true) >>>> instead of org.apache.ivy.main(args) in your tool provider. >>>> >>>> regards, >>>> R?mi >>>> >>>> ----- Original Message ----- >>>>> From: "Ethan McCue" >>>>> To: "core-libs-dev" >>>>> Sent: Saturday, February 26, 2022 11:14:19 PM >>>>> Subject: Should System.exit be controlled by a Scope Local? >>>> >>>>> I have a feeling this has been considered and I might just be >>>> articulating >>>>> the obvious - but: >>>>> >>>>> As called out in JEP 411, one of the remaining legitimate uses of the >>>>> Security Manager is to intercept calls to System.exit. This seems >>> like a >>>>> decent use case for the Scope Local mechanism. >>>>> >>>>> >>>>> public class Runtime { >>>>> ... >>>>> private final ScopeLocal EXIT = >>>>> ScopeLocal.newInstance(); >>>>> >>>>> ... >>>>> >>>>> public void overridingExitBehavior(IntConsumer exit, Runnable >>>> run) { >>>>> ScopeLocal.with(EXIT, exit).run(run); >>>>> } >>>>> >>>>> ... >>>>> >>>>> public void exit(int status) { >>>>> if (EXIT.isBound()) { >>>>> EXIT.get().accept(status); >>>>> } >>>>> else { >>>>> Shutdown.exit(status); >>>>> } >>>>> } >>>>> } >>>>> >>>>> >>>>> One of the likely minor benefits in the scope of things, but related >>> to >>>> the >>>>> parts of the ecosystem I am doodling with so I'll mention it, is that >>> it >>>>> would become possible to wrap "naive" cli programs with the >>> ToolProvider >>>>> SPI without rewriting their code if this System.out, and System.err >>> all >>>>> became reliably configurable. >>>>> >>>>> For instance, Apache Ivy's CLI has a main class that looks like this >>>>> >>>>> >>>> >>> https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java >>>>> >>>>> package org.apache.ivy; >>>>> >>>>> public final class Main { >>>>> ... >>>>> >>>>> public static void main(String[] args) throws Exception { >>>>> try { >>>>> run(args, true); >>>>> System.exit(0); >>>>> } catch (ParseException ex) { >>>>> System.err.println(ex.getMessage()); >>>>> System.exit(1); >>>>> } >>>>> } >>>>> } >>>>> >>>>> Making these otherwise static parts of the system configurable would >>>> enable >>>>> a third party library to write >>>>> >>>>> public final class IvyToolProvider implements ToolProvider { >>>>> @Override >>>>> public String name() { >>>>> return "ivy"; >>>>> } >>>>> >>>>> @Override >>>>> public int run(PrintWriter out, PrintWriter err, String... >>> args) { >>>>> var exit = new AtomicInteger(0); >>>>> Runtime.getRuntime().overridingExitBehavior(exit::set, () >>> -> { >>>>> System.overridingOut(out, () -> { >>>>> System.overridingErr(err, Main::main); >>>>> } >>>>> }; >>>>> return exit.get(); >>>>> } >>>>> } >>>>> >>>>> Whether that would be enough to make it so that people other than >>>> Christian >>>>> Stein use the mechanism is anyone's guess, but might be worth a shot. >>>>> >>>>> https://grep.app/search?q=java.util.spi.ToolProvider >>>> >>> >> From ethan at mccue.dev Sun Feb 27 22:20:00 2022 From: ethan at mccue.dev (Ethan McCue) Date: Sun, 27 Feb 2022 17:20:00 -0500 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <2de9853f-4702-81f3-c6a8-fec599dd1497@oracle.com> References: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> <2de9853f-4702-81f3-c6a8-fec599dd1497@oracle.com> Message-ID: My understanding is that when you System.exit all threads associated with the JVM process are killed. That's what I meant by "nuclear Thread.interrupt". It's the same issue as was raised about System.exit implicitly ending control flow or implicitly closing open file handles - a process could be relying on the behavior of implicitly killing all threads and not have another cleanup mechanism On Sun, Feb 27, 2022, 5:16 PM David Holmes wrote: > On 28/02/2022 3:20 am, Ethan McCue wrote: > > I think continuations could work for the single threaded case, depending > on > > their behavior with "finally" blocks. I'm sure there are more caveats > once > > we add another thread to the mix though. System.exit is a nuclear > > Thread.interrupt, so replicating that behavior might be a bit daunting > > What has Thread.interrupt got to do with System.exit ? > > David > > > private static final class ExitCode { > > volatile Integer code = null; > > } > > > > private final ScopeLocal EXIT_CODE = > ScopeLocal.newInstance(); > > > > public void overridingExitBehavior(IntConsumer exit, Runnable run) { > > var exitCode = new ExitCode(); > > ScopeLocal.with(EXIT_CODE, exitCode).run(() -> { > > // by whatever syntax > > var _ = inContinuation(run); > > if (exitCode.code != null) { > > exit.accept(code.exitCode) > > } > > }); > > } > > > > public void exit(int status) { > > if (EXIT_CODE.isBound()) { > > EXIT_CODE.get().code = status; > > Continuation.yield(); > > } > > else { > > Shutdown.exit(status); > > } > > } > > > > > > > > On Sun, Feb 27, 2022 at 10:41 AM Glavo wrote: > > > >> I think there is a problem with this: `System.exit` contains semantics > to > >> interrupt the flow of control and exit, and if you implement it that > way, > >> you might have some program abnormally execute parts of it that should > >> never be executed. > >> > >> Of course, using exceptions like this should solve part of the problem: > >> > >> class Exit extends Error { > >> final int exitCode; > >> public Exit(int exitCode) { > >> this.exitCode = exitCode; > >> } > >> > >> @Override > >> public synchronized Throwable fillInStackTrace() { > >> return this; > >> } > >> } > >> > >> try { > >> Runtime.getRuntime().overridingExitBehavior(exitCode -> {throw new > >> Exit(exitCode);}, ...); > >> } catch (Exit exit) { > >> ... > >> } > >> > >> However, the calling method may catch this exception unexpectedly, and > >> there may be unexpected behavior under multithreading. > >> Of course, this part of the problem also exists for the security > manager. > >> But, if possible, it would be better to have a solution for these > >> situations. > >> (`Continuation` might help us?) > >> > >> > >> > >> On Sun, Feb 27, 2022 at 11:07 PM Ethan McCue wrote: > >> > >>> That undermines my point some, but I think the overall shape of the use > >>> case still makes sense > >>> > >>> On Sun, Feb 27, 2022 at 8:01 AM Remi Forax wrote: > >>> > >>>> Hi Ethan, > >>>> there is a far simpler solution, call org.apache.ivy.run(args, true) > >>>> instead of org.apache.ivy.main(args) in your tool provider. > >>>> > >>>> regards, > >>>> R?mi > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Ethan McCue" > >>>>> To: "core-libs-dev" > >>>>> Sent: Saturday, February 26, 2022 11:14:19 PM > >>>>> Subject: Should System.exit be controlled by a Scope Local? > >>>> > >>>>> I have a feeling this has been considered and I might just be > >>>> articulating > >>>>> the obvious - but: > >>>>> > >>>>> As called out in JEP 411, one of the remaining legitimate uses of the > >>>>> Security Manager is to intercept calls to System.exit. This seems > >>> like a > >>>>> decent use case for the Scope Local mechanism. > >>>>> > >>>>> > >>>>> public class Runtime { > >>>>> ... > >>>>> private final ScopeLocal EXIT = > >>>>> ScopeLocal.newInstance(); > >>>>> > >>>>> ... > >>>>> > >>>>> public void overridingExitBehavior(IntConsumer exit, Runnable > >>>> run) { > >>>>> ScopeLocal.with(EXIT, exit).run(run); > >>>>> } > >>>>> > >>>>> ... > >>>>> > >>>>> public void exit(int status) { > >>>>> if (EXIT.isBound()) { > >>>>> EXIT.get().accept(status); > >>>>> } > >>>>> else { > >>>>> Shutdown.exit(status); > >>>>> } > >>>>> } > >>>>> } > >>>>> > >>>>> > >>>>> One of the likely minor benefits in the scope of things, but related > >>> to > >>>> the > >>>>> parts of the ecosystem I am doodling with so I'll mention it, is that > >>> it > >>>>> would become possible to wrap "naive" cli programs with the > >>> ToolProvider > >>>>> SPI without rewriting their code if this System.out, and System.err > >>> all > >>>>> became reliably configurable. > >>>>> > >>>>> For instance, Apache Ivy's CLI has a main class that looks like this > >>>>> > >>>>> > >>>> > >>> > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > >>>>> > >>>>> package org.apache.ivy; > >>>>> > >>>>> public final class Main { > >>>>> ... > >>>>> > >>>>> public static void main(String[] args) throws Exception { > >>>>> try { > >>>>> run(args, true); > >>>>> System.exit(0); > >>>>> } catch (ParseException ex) { > >>>>> System.err.println(ex.getMessage()); > >>>>> System.exit(1); > >>>>> } > >>>>> } > >>>>> } > >>>>> > >>>>> Making these otherwise static parts of the system configurable would > >>>> enable > >>>>> a third party library to write > >>>>> > >>>>> public final class IvyToolProvider implements ToolProvider { > >>>>> @Override > >>>>> public String name() { > >>>>> return "ivy"; > >>>>> } > >>>>> > >>>>> @Override > >>>>> public int run(PrintWriter out, PrintWriter err, String... > >>> args) { > >>>>> var exit = new AtomicInteger(0); > >>>>> Runtime.getRuntime().overridingExitBehavior(exit::set, () > >>> -> { > >>>>> System.overridingOut(out, () -> { > >>>>> System.overridingErr(err, Main::main); > >>>>> } > >>>>> }; > >>>>> return exit.get(); > >>>>> } > >>>>> } > >>>>> > >>>>> Whether that would be enough to make it so that people other than > >>>> Christian > >>>>> Stein use the mechanism is anyone's guess, but might be worth a shot. > >>>>> > >>>>> https://grep.app/search?q=java.util.spi.ToolProvider > >>>> > >>> > >> > From jlaskey at openjdk.java.net Sun Feb 27 22:35:48 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Sun, 27 Feb 2022 22:35:48 GMT Subject: RFR: JDK-8282144 RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 19:58:13 GMT, Brian Burkhalter wrote: >> Class: ./java.base/share/classes/jdk/internal/util/random/RandomSupport.java >> Method: public static long[] convertSeedBytesToLongs(byte[] seed, int n, int z) >> >> The method attempts to create an array of longs by consuming the input bytes most significant bit first. New bytes are appended to the existing long using the OR operator on the signed byte. Due to sign extension this will overwrite all the existing bits from 63 to 8 if the next byte is negative. > > test/jdk/java/util/Random/T8282144.java line 39: > >> 37: public class T8282144 { >> 38: public static void main(String[] args) { >> 39: RandomGenerator rng = RandomGeneratorFactory.of("L64X128MixRandom").create(42); > > Does `rng` always produce the same sequence? If so, then perhaps the seed, `42`, should be a random value that is printed. 42 was chosen because its is known to produce negative byte values, other random values might not. > test/jdk/java/util/Random/T8282144.java line 52: > >> 50: for (int k = 0; k < existing.length; k++) { >> 51: if (existing[k] != testing[k]) { >> 52: throw new RuntimeException("convertSeedBytesToLongs incorrect"); > > Should `i`, `j`, and `k` be included in the exception message? Correctness is binary - either it works or it doesn't. The values of i, j, k would not assist in isolating issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/7614 From david.holmes at oracle.com Mon Feb 28 00:02:47 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Feb 2022 10:02:47 +1000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> <2de9853f-4702-81f3-c6a8-fec599dd1497@oracle.com> Message-ID: On 28/02/2022 8:20 am, Ethan McCue wrote: > My understanding is that when you System.exit all threads associated > with the JVM process are killed. That's what I meant by "nuclear > Thread.interrupt". The process is terminated, the threads are not individually "killed". All Thread.interrupt does is set a flag and unpark blocked threads (in some specific cases). There's really no comparison at all. David ----- > It's the same issue as was raised about System.exit implicitly ending > control flow or implicitly closing open file handles - a process could > be relying on the behavior of implicitly killing all threads and not > have another cleanup mechanism > > On Sun, Feb 27, 2022, 5:16 PM David Holmes > wrote: > > On 28/02/2022 3:20 am, Ethan McCue wrote: > > I think continuations could work for the single threaded case, > depending on > > their behavior with "finally" blocks. I'm sure there are more > caveats once > > we add another thread to the mix though. System.exit is a nuclear > > Thread.interrupt, so replicating that behavior might be a bit > daunting > > What has Thread.interrupt got to do with System.exit ? > > David > > >? ? ? private static final class ExitCode { > >? ? ? ? ? volatile Integer code = null; > >? ? ? } > > > >? ? ? private final ScopeLocal EXIT_CODE = > ScopeLocal.newInstance(); > > > >? ? ? public void overridingExitBehavior(IntConsumer exit, > Runnable run) { > >? ? ? ? ? var exitCode = new ExitCode(); > >? ? ? ? ? ScopeLocal.with(EXIT_CODE, exitCode).run(() -> { > >? ? ? ? ? ? ? // by whatever syntax > >? ? ? ? ? ? ? var _ = inContinuation(run); > >? ? ? ? ? ? ? if (exitCode.code != null) { > >? ? ? ? ? ? ? ? ? exit.accept(code.exitCode) > >? ? ? ? ? ? ? } > >? ? ? ? ? }); > >? ? ? } > > > >? ? ? public void exit(int status) { > >? ? ? ? ? if (EXIT_CODE.isBound()) { > >? ? ? ? ? ? ? ?EXIT_CODE.get().code = status; > >? ? ? ? ? ? ? ?Continuation.yield(); > >? ? ? ? ? } > >? ? ? ? ? else { > >? ? ? ? ? ? ? Shutdown.exit(status); > >? ? ? ? ? } > >? ? ? } > > > > > > > > On Sun, Feb 27, 2022 at 10:41 AM Glavo > wrote: > > > >> I think there is a problem with this: `System.exit` contains > semantics to > >> interrupt the flow of control and exit, and if you implement it > that way, > >> you might have some program abnormally execute parts of it that > should > >> never be executed. > >> > >> Of course, using exceptions like this should solve part of the > problem: > >> > >> class Exit extends Error { > >>? ? ? final int exitCode; > >>? ? ? public Exit(int exitCode) { > >>? ? ? ? ? this.exitCode = exitCode; > >>? ? ? } > >> > >>? ? ? @Override > >>? ? ? public synchronized Throwable fillInStackTrace() { > >>? ? ? ? ? return this; > >>? ? ? } > >> } > >> > >> try { > >>? ? Runtime.getRuntime().overridingExitBehavior(exitCode -> > {throw new > >> Exit(exitCode);}, ...); > >> } catch (Exit exit) { > >>? ? ... > >> } > >> > >> However, the calling method may catch this exception > unexpectedly, and > >> there may be unexpected behavior under multithreading. > >> Of course, this part of the problem also exists for the security > manager. > >> But, if possible, it would be better to have a solution for these > >> situations. > >> (`Continuation` might help us?) > >> > >> > >> > >> On Sun, Feb 27, 2022 at 11:07 PM Ethan McCue > wrote: > >> > >>> That undermines my point some, but I think the overall shape of > the use > >>> case still makes sense > >>> > >>> On Sun, Feb 27, 2022 at 8:01 AM Remi Forax > wrote: > >>> > >>>> Hi Ethan, > >>>> there is a far simpler solution, call org.apache.ivy.run(args, > true) > >>>> instead of org.apache.ivy.main(args) in your tool provider. > >>>> > >>>> regards, > >>>> R?mi > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Ethan McCue" > > >>>>> To: "core-libs-dev" > > >>>>> Sent: Saturday, February 26, 2022 11:14:19 PM > >>>>> Subject: Should System.exit be controlled by a Scope Local? > >>>> > >>>>> I have a feeling this has been considered and I might just be > >>>> articulating > >>>>> the obvious - but: > >>>>> > >>>>> As called out in JEP 411, one of the remaining legitimate > uses of the > >>>>> Security Manager is to intercept calls to System.exit. This seems > >>> like a > >>>>> decent use case for the Scope Local mechanism. > >>>>> > >>>>> > >>>>>? ? ?public class Runtime { > >>>>>? ? ? ? ?... > >>>>>? ? ? ? ?private final ScopeLocal EXIT = > >>>>> ScopeLocal.newInstance(); > >>>>> > >>>>>? ? ? ? ?... > >>>>> > >>>>>? ? ? ? ?public void overridingExitBehavior(IntConsumer exit, > Runnable > >>>> run) { > >>>>>? ? ? ? ? ? ?ScopeLocal.with(EXIT, exit).run(run); > >>>>>? ? ? ? ?} > >>>>> > >>>>>? ? ? ? ?... > >>>>> > >>>>>? ? ? ? ?public void exit(int status) { > >>>>>? ? ? ? ? ? ?if (EXIT.isBound()) { > >>>>>? ? ? ? ? ? ? ? ?EXIT.get().accept(status); > >>>>>? ? ? ? ? ? ?} > >>>>>? ? ? ? ? ? ?else { > >>>>>? ? ? ? ? ? ? ? ?Shutdown.exit(status); > >>>>>? ? ? ? ? ? ?} > >>>>>? ? ? ? ?} > >>>>>? ? ?} > >>>>> > >>>>> > >>>>> One of the likely minor benefits in the scope of things, but > related > >>> to > >>>> the > >>>>> parts of the ecosystem I am doodling with so I'll mention it, > is that > >>> it > >>>>> would become possible to wrap "naive" cli programs with the > >>> ToolProvider > >>>>> SPI without rewriting their code if this System.out, and > System.err > >>> all > >>>>> became reliably configurable. > >>>>> > >>>>> For instance, Apache Ivy's CLI has a main class that looks > like this > >>>>> > >>>>> > >>>> > >>> > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > > >>>>> > >>>>>? ? ?package org.apache.ivy; > >>>>> > >>>>>? ? ?public final class Main { > >>>>>? ? ? ? ?... > >>>>> > >>>>>? ? ? ? ?public static void main(String[] args) throws Exception { > >>>>>? ? ? ? ? ? ?try { > >>>>>? ? ? ? ? ? ? ? ?run(args, true); > >>>>>? ? ? ? ? ? ? ? ?System.exit(0); > >>>>>? ? ? ? ? ? ?} catch (ParseException ex) { > >>>>>? ? ? ? ? ? ? ? ?System.err.println(ex.getMessage()); > >>>>>? ? ? ? ? ? ? ? ?System.exit(1); > >>>>>? ? ? ? ? ? ?} > >>>>>? ? ? ? ?} > >>>>>? ? ? } > >>>>> > >>>>> Making these otherwise static parts of the system > configurable would > >>>> enable > >>>>> a third party library to write > >>>>> > >>>>>? ? ?public final class IvyToolProvider implements ToolProvider { > >>>>>? ? ? ? ?@Override > >>>>>? ? ? ? ?public String name() { > >>>>>? ? ? ? ? ? ?return "ivy"; > >>>>>? ? ? ? ?} > >>>>> > >>>>>? ? ? ? ?@Override > >>>>>? ? ? ? ?public int run(PrintWriter out, PrintWriter err, > String... > >>> args) { > >>>>>? ? ? ? ? ? ?var exit = new AtomicInteger(0); > >>>>> > ?Runtime.getRuntime().overridingExitBehavior(exit::set, () > >>> -> { > >>>>>? ? ? ? ? ? ? ? ?System.overridingOut(out, () -> { > >>>>>? ? ? ? ? ? ? ? ? ? ? System.overridingErr(err, Main::main); > >>>>>? ? ? ? ? ? ? ? ?} > >>>>>? ? ? ? ? ? ?}; > >>>>>? ? ? ? ? ? ?return exit.get(); > >>>>>? ? ? ? ?} > >>>>>? ? ?} > >>>>> > >>>>> Whether that would be enough to make it so that people other than > >>>> Christian > >>>>> Stein use the mechanism is anyone's guess, but might be worth > a shot. > >>>>> > >>>>> https://grep.app/search?q=java.util.spi.ToolProvider > > >>>> > >>> > >> > From ethan at mccue.dev Mon Feb 28 00:37:59 2022 From: ethan at mccue.dev (Ethan McCue) Date: Sun, 27 Feb 2022 19:37:59 -0500 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: <313175728.8918877.1645966907954.JavaMail.zimbra@u-pem.fr> <2de9853f-4702-81f3-c6a8-fec599dd1497@oracle.com> Message-ID: K. On Sun, Feb 27, 2022, 7:03 PM David Holmes wrote: > On 28/02/2022 8:20 am, Ethan McCue wrote: > > My understanding is that when you System.exit all threads associated > > with the JVM process are killed. That's what I meant by "nuclear > > Thread.interrupt". > > The process is terminated, the threads are not individually "killed". > All Thread.interrupt does is set a flag and unpark blocked threads (in > some specific cases). There's really no comparison at all. > > David > ----- > > > It's the same issue as was raised about System.exit implicitly ending > > control flow or implicitly closing open file handles - a process could > > be relying on the behavior of implicitly killing all threads and not > > have another cleanup mechanism > > > > On Sun, Feb 27, 2022, 5:16 PM David Holmes > > wrote: > > > > On 28/02/2022 3:20 am, Ethan McCue wrote: > > > I think continuations could work for the single threaded case, > > depending on > > > their behavior with "finally" blocks. I'm sure there are more > > caveats once > > > we add another thread to the mix though. System.exit is a nuclear > > > Thread.interrupt, so replicating that behavior might be a bit > > daunting > > > > What has Thread.interrupt got to do with System.exit ? > > > > David > > > > > private static final class ExitCode { > > > volatile Integer code = null; > > > } > > > > > > private final ScopeLocal EXIT_CODE = > > ScopeLocal.newInstance(); > > > > > > public void overridingExitBehavior(IntConsumer exit, > > Runnable run) { > > > var exitCode = new ExitCode(); > > > ScopeLocal.with(EXIT_CODE, exitCode).run(() -> { > > > // by whatever syntax > > > var _ = inContinuation(run); > > > if (exitCode.code != null) { > > > exit.accept(code.exitCode) > > > } > > > }); > > > } > > > > > > public void exit(int status) { > > > if (EXIT_CODE.isBound()) { > > > EXIT_CODE.get().code = status; > > > Continuation.yield(); > > > } > > > else { > > > Shutdown.exit(status); > > > } > > > } > > > > > > > > > > > > On Sun, Feb 27, 2022 at 10:41 AM Glavo > > wrote: > > > > > >> I think there is a problem with this: `System.exit` contains > > semantics to > > >> interrupt the flow of control and exit, and if you implement it > > that way, > > >> you might have some program abnormally execute parts of it that > > should > > >> never be executed. > > >> > > >> Of course, using exceptions like this should solve part of the > > problem: > > >> > > >> class Exit extends Error { > > >> final int exitCode; > > >> public Exit(int exitCode) { > > >> this.exitCode = exitCode; > > >> } > > >> > > >> @Override > > >> public synchronized Throwable fillInStackTrace() { > > >> return this; > > >> } > > >> } > > >> > > >> try { > > >> Runtime.getRuntime().overridingExitBehavior(exitCode -> > > {throw new > > >> Exit(exitCode);}, ...); > > >> } catch (Exit exit) { > > >> ... > > >> } > > >> > > >> However, the calling method may catch this exception > > unexpectedly, and > > >> there may be unexpected behavior under multithreading. > > >> Of course, this part of the problem also exists for the security > > manager. > > >> But, if possible, it would be better to have a solution for these > > >> situations. > > >> (`Continuation` might help us?) > > >> > > >> > > >> > > >> On Sun, Feb 27, 2022 at 11:07 PM Ethan McCue > > wrote: > > >> > > >>> That undermines my point some, but I think the overall shape of > > the use > > >>> case still makes sense > > >>> > > >>> On Sun, Feb 27, 2022 at 8:01 AM Remi Forax > > wrote: > > >>> > > >>>> Hi Ethan, > > >>>> there is a far simpler solution, call org.apache.ivy.run(args, > > true) > > >>>> instead of org.apache.ivy.main(args) in your tool provider. > > >>>> > > >>>> regards, > > >>>> R?mi > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Ethan McCue" >> > > >>>>> To: "core-libs-dev" > > > > >>>>> Sent: Saturday, February 26, 2022 11:14:19 PM > > >>>>> Subject: Should System.exit be controlled by a Scope Local? > > >>>> > > >>>>> I have a feeling this has been considered and I might just be > > >>>> articulating > > >>>>> the obvious - but: > > >>>>> > > >>>>> As called out in JEP 411, one of the remaining legitimate > > uses of the > > >>>>> Security Manager is to intercept calls to System.exit. This > seems > > >>> like a > > >>>>> decent use case for the Scope Local mechanism. > > >>>>> > > >>>>> > > >>>>> public class Runtime { > > >>>>> ... > > >>>>> private final ScopeLocal EXIT = > > >>>>> ScopeLocal.newInstance(); > > >>>>> > > >>>>> ... > > >>>>> > > >>>>> public void overridingExitBehavior(IntConsumer exit, > > Runnable > > >>>> run) { > > >>>>> ScopeLocal.with(EXIT, exit).run(run); > > >>>>> } > > >>>>> > > >>>>> ... > > >>>>> > > >>>>> public void exit(int status) { > > >>>>> if (EXIT.isBound()) { > > >>>>> EXIT.get().accept(status); > > >>>>> } > > >>>>> else { > > >>>>> Shutdown.exit(status); > > >>>>> } > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> > > >>>>> One of the likely minor benefits in the scope of things, but > > related > > >>> to > > >>>> the > > >>>>> parts of the ecosystem I am doodling with so I'll mention it, > > is that > > >>> it > > >>>>> would become possible to wrap "naive" cli programs with the > > >>> ToolProvider > > >>>>> SPI without rewriting their code if this System.out, and > > System.err > > >>> all > > >>>>> became reliably configurable. > > >>>>> > > >>>>> For instance, Apache Ivy's CLI has a main class that looks > > like this > > >>>>> > > >>>>> > > >>>> > > >>> > > > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > > < > https://github.com/apache/ant-ivy/blob/424fa89419147f50a41b4bdc665d8ea92b5da516/src/java/org/apache/ivy/Main.java > > > > >>>>> > > >>>>> package org.apache.ivy; > > >>>>> > > >>>>> public final class Main { > > >>>>> ... > > >>>>> > > >>>>> public static void main(String[] args) throws > Exception { > > >>>>> try { > > >>>>> run(args, true); > > >>>>> System.exit(0); > > >>>>> } catch (ParseException ex) { > > >>>>> System.err.println(ex.getMessage()); > > >>>>> System.exit(1); > > >>>>> } > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> Making these otherwise static parts of the system > > configurable would > > >>>> enable > > >>>>> a third party library to write > > >>>>> > > >>>>> public final class IvyToolProvider implements > ToolProvider { > > >>>>> @Override > > >>>>> public String name() { > > >>>>> return "ivy"; > > >>>>> } > > >>>>> > > >>>>> @Override > > >>>>> public int run(PrintWriter out, PrintWriter err, > > String... > > >>> args) { > > >>>>> var exit = new AtomicInteger(0); > > >>>>> > > Runtime.getRuntime().overridingExitBehavior(exit::set, () > > >>> -> { > > >>>>> System.overridingOut(out, () -> { > > >>>>> System.overridingErr(err, Main::main); > > >>>>> } > > >>>>> }; > > >>>>> return exit.get(); > > >>>>> } > > >>>>> } > > >>>>> > > >>>>> Whether that would be enough to make it so that people other > than > > >>>> Christian > > >>>>> Stein use the mechanism is anyone's guess, but might be worth > > a shot. > > >>>>> > > >>>>> https://grep.app/search?q=java.util.spi.ToolProvider > > > > >>>> > > >>> > > >> > > > From iklam at openjdk.java.net Mon Feb 28 06:34:14 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 28 Feb 2022 06:34:14 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v7] In-Reply-To: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: > **Background:** > > In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: > > > public enum Day { SUNDAY, MONDAY ... } > > > to > > > public class Day extends java.lang.Enum { > public static final SUNDAY = new Day("SUNDAY"); > public static final MONDAY = new Day("MONDAY"); ... > } > > > With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) > > **Fix:** > > During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. > > This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. > > **Verification:** > > To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt > > **Testing:** > > Passed Oracle CI tiers 1-4. WIll run tier 5 as well. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - fixed copyright year - Merge branch 'master' into 8275731-heapshared-enum - fixed whitespace - Fixed comments per @calvinccheung review - Merge branch 'master' into 8275731-heapshared-enum - Use InstanceKlass::do_local_static_fields for some field iterations - Merge branch 'master' into 8275731-heapshared-enum - added exclusions needed by "java -Xshare:dump -ea -esa" - Comments from @calvinccheung off-line - 8275731: CDS archived enums objects are recreated at runtime ------------- Changes: https://git.openjdk.java.net/jdk/pull/6653/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6653&range=06 Stats: 860 lines in 16 files changed: 807 ins; 4 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/6653.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6653/head:pull/6653 PR: https://git.openjdk.java.net/jdk/pull/6653 From duke at openjdk.java.net Mon Feb 28 07:43:48 2022 From: duke at openjdk.java.net (Maxim Kartashev) Date: Mon, 28 Feb 2022 07:43:48 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add a new line to the end of test file for JDK-8282008 Actually, this change should be made even more generic because the string might end with any even number of the backslash characters followed by a free-standing quote, in which case additional quoting should not be required. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From chegar at openjdk.java.net Mon Feb 28 11:20:19 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 28 Feb 2022 11:20:19 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character Message-ID: The module finder implementation incorrectly uses the path-separator character from the default file system, when mapping the relative path of an entry in an exploded module to a package name. This causes problems on Windows [*] when using a module finder with a custom file system that has a path-separator character that differs from that of the default file system, e.g. the zip file system (which uses '/', rather than '\' ). Rather than adding a new test for this, I deciced to just modify an existing one. The existing test exercises the module finder with a custom file system, but does so with modules have trivial single-level packages names. I just expanded the module to have a subpackage. This is sufficient to reproduce the bug, and verify the fix. [*] java.lang.module.FindException: Error reading module: /m2 at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) at ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) at ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) at ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) at ... Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not found in module at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) ... 36 more ------------- Commit messages: - fix file separator in module finder with custom fs Changes: https://git.openjdk.java.net/jdk/pull/7632/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7632&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282444 Stats: 7 lines in 4 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7632/head:pull/7632 PR: https://git.openjdk.java.net/jdk/pull/7632 From duke at openjdk.java.net Mon Feb 28 13:09:45 2022 From: duke at openjdk.java.net (Marcono1234) Date: Mon, 28 Feb 2022 13:09:45 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v10] In-Reply-To: <0HYZ6B9fXtwmrB93tqUa5c6JxBw6YrJHrjYoAt0kWqs=.0a5beba9-da0c-44a1-8815-6c929792f3c2@github.com> References: <9AJL12jUZy5SnqXw0Uui3YqcvVW58HmAES-XMzZ9Bpo=.aa7db78c-d44e-4627-9d7e-77f28f7c9fef@github.com> <8E6Kbkjp8APa7MK47b47Juc-XWsOIzSNGhUSFKndr3g=.c1ba2193-7e23-4de7-9935-7979f439dee7@github.com> <0HYZ6B9fXtwmrB93tqUa5c6JxBw6YrJHrjYoAt0kWqs=.0a5beba9-da0c-44a1-8815-6c929792f3c2@github.com> Message-ID: On Fri, 25 Feb 2022 23:30:35 GMT, Yasser Bazzi wrote: >> src/java.base/share/classes/java/util/Random.java line 107: >> >>> 105: return rand; >>> 106: >>> 107: return (Random) new Random.RandomWrapper(random); >> >> Isn't the `(Random)` cast redundant? > > Eclipse did not complain about it being redundant, also it does not impact the reading of it and it shows the reader it is a Random instance that is returning It is unlikely that any IDE or code scanning tool will report _all_ cases of incorrect or redundant code. However, in this specific case Eclipse does support detecting that (to my knowledge) through its "Clean Up" action (you might to explicitly enable though). But you should always verify that the actions Eclipse (or any other IDE) performs are correct, because there are some reported corner cases where it removes casts which are actually needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From itakiguchi at openjdk.java.net Mon Feb 28 13:17:51 2022 From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi) Date: Mon, 28 Feb 2022 13:17:51 GMT Subject: Integrated: 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 12:17:59 GMT, Ichiroh Takiguchi wrote: > Run jtreg:jdk/java/lang/ProcessBuilder/Basic.java on AIX. > The test was failed by: > Incorrect handling of envstrings containing NULs > > According to my investigation, this issue was happened after following change was applied. > JDK-8272600: (test) Use native "sleep" in Basic.java > > test.nativepath value was added into AIX's LIBPATH during running this testcase. > On AIX, test.nativepath value should be removed from LIBPATH value before comparing the values. This pull request has now been integrated. Changeset: c5c6058f Author: Ichiroh Takiguchi URL: https://git.openjdk.java.net/jdk/commit/c5c6058fd57d4b594012035eaf18a57257f4ad85 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 8282219: jdk/java/lang/ProcessBuilder/Basic.java fails on AIX Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7574 From naoto at openjdk.java.net Mon Feb 28 13:25:52 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Feb 2022 13:25:52 GMT Subject: Integrated: 8282131: java.time.ZoneId should be a sealed abstract class In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 19:02:55 GMT, Naoto Sato wrote: > Refactoring `java.time.ZoneId` class to be a sealed class. A CSR has also been drafted. This pull request has now been integrated. Changeset: 0ae3d1d5 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/0ae3d1d59c44e966e13345b9197fcf067e63900e Stats: 10 lines in 1 file changed: 0 ins; 4 del; 6 mod 8282131: java.time.ZoneId should be a sealed abstract class Reviewed-by: iris, rriggs, bpb, lancea, mchung, scolebourne ------------- PR: https://git.openjdk.java.net/jdk/pull/7625 From Alan.Bateman at oracle.com Mon Feb 28 14:05:16 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Feb 2022 14:05:16 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: Message-ID: On 26/02/2022 22:14, Ethan McCue wrote: > I have a feeling this has been considered and I might just be articulating > the obvious - but: > > As called out in JEP 411, one of the remaining legitimate uses of the > Security Manager is to intercept calls to System.exit. This seems like a > decent use case for the Scope Local mechanism. > I think it was mostly convenience to use the SM to intercept calls to System.exit as it's not really security when all other permissions are granted. There have been a few prototypes of APIs in this area but none made to the level of a good proposal. Using a SL or even TL set/remove is interesting but you might want to survey some of the existing usages to see if they are really stack confined. At least some of the uses have been container applications with plugins that accidentally call System.exit when running code not intended to run that way. I don't think there is any guarantee that they run completely in the same thread but some may do. -Alan From alanb at openjdk.java.net Mon Feb 28 14:37:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 28 Feb 2022 14:37:48 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 11:12:17 GMT, Chris Hegarty wrote: > The module finder implementation incorrectly uses the path-separator > character from the default file system, when mapping the relative path > of an entry in an exploded module to a package name. This causes > problems on Windows [*] when using a module finder with a custom file > system that has a path-separator character that differs from that of the > default file system, e.g. the zip file system (which uses '/', > rather than '\' ). > > Rather than adding a new test for this, I deciced to just modify an > existing one. The existing test exercises the module finder with a > custom file system, but does so with modules have trivial single-level > packages names. I just expanded the module to have a subpackage. This > is sufficient to reproduce the bug, and verify the fix. > > [*] > > java.lang.module.FindException: Error reading module: /m2 > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) > at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) > at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) > at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) > at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) > at ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) > at ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) > at ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) > at ... > Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not found in module > at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) > at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) > at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) > at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) > ... 36 more The update to ModulePath looks okay. The tests for ModulePath with paths to locate files in custom file systems are somewhat minimal and probably should be expanded to ensure that there aren't any other issues. Updating the existing ModulesInCustomFileSystem test to use a deeper package structure is subtle but okay for now but we should create another issue to create more tests for custom file systems. I assume you'll update the date in the copyright header of the changed files. ------------- PR: https://git.openjdk.java.net/jdk/pull/7632 From ethan at mccue.dev Mon Feb 28 14:58:43 2022 From: ethan at mccue.dev (Ethan McCue) Date: Mon, 28 Feb 2022 09:58:43 -0500 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: Message-ID: Where would be a good place to do that sort of surveying? The mechanism does not seem to be that popular in open source software ( though that does make a degree of sense ), or at least the software grep.app scans https://grep.app/search?q=permission.getName%28%29.startsWith%28%22exitVM%22%29 On Mon, Feb 28, 2022 at 9:05 AM Alan Bateman wrote: > On 26/02/2022 22:14, Ethan McCue wrote: > > I have a feeling this has been considered and I might just be > articulating > > the obvious - but: > > > > As called out in JEP 411, one of the remaining legitimate uses of the > > Security Manager is to intercept calls to System.exit. This seems like a > > decent use case for the Scope Local mechanism. > > > I think it was mostly convenience to use the SM to intercept calls to > System.exit as it's not really security when all other permissions are > granted. > > There have been a few prototypes of APIs in this area but none made to > the level of a good proposal. Using a SL or even TL set/remove is > interesting but you might want to survey some of the existing usages to > see if they are really stack confined. At least some of the uses have > been container applications with plugins that accidentally call > System.exit when running code not intended to run that way. I don't > think there is any guarantee that they run completely in the same thread > but some may do. > > -Alan > From sean.mullan at oracle.com Mon Feb 28 15:12:18 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 28 Feb 2022 10:12:18 -0500 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> References: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> Message-ID: <9accb6b2-335b-8c5f-bc7d-afed4f6e6727@oracle.com> On 2/27/22 1:47 PM, Andrew Haley wrote: > I'd like to explore the use of scope locals as a lightweight means to > implement a system of permissions and capabilities for things such as > this. Now you have piqued my curiosity, as I have explored a capability based model for intercepting `System.exit`. Can you say any more about this yet? Thanks, Sean From aph-open at littlepinkcloud.com Mon Feb 28 15:32:45 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 28 Feb 2022 15:32:45 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <9accb6b2-335b-8c5f-bc7d-afed4f6e6727@oracle.com> References: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> <9accb6b2-335b-8c5f-bc7d-afed4f6e6727@oracle.com> Message-ID: <68ea5542-0866-8583-938f-51b2f5512088@littlepinkcloud.com> On 2/28/22 15:12, Sean Mullan wrote: > > On 2/27/22 1:47 PM, Andrew Haley wrote: > >> I'd like to explore the use of scope locals as a lightweight means to >> implement a system of permissions and capabilities for things such as >> this. > > Now you have piqued my curiosity, as I have explored a capability based > model for intercepting `System.exit`. Can you say any more about this yet? I think all we'd need is a set of capabilities bound to a scope local at thread startup, and I guess it'd default to "all capabilities". Trusted code could then override any of those capabilities. We'd have to make sure that capabilities were inherited by threads, and we'd have to think very carefully about thread pools. The problem there is that while it would (I guess) make sense to prevent all code executing in thread pools from calling System.exit(), there's an obvious compatibility problem if it can't. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dfuchs at openjdk.java.net Mon Feb 28 16:21:49 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 28 Feb 2022 16:21:49 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 11:12:17 GMT, Chris Hegarty wrote: > The module finder implementation incorrectly uses the path-separator > character from the default file system, when mapping the relative path > of an entry in an exploded module to a package name. This causes > problems on Windows [*] when using a module finder with a custom file > system that has a path-separator character that differs from that of the > default file system, e.g. the zip file system (which uses '/', > rather than '\' ). > > Rather than adding a new test for this, I deciced to just modify an > existing one. The existing test exercises the module finder with a > custom file system, but does so with modules have trivial single-level > packages names. I just expanded the module to have a subpackage. This > is sufficient to reproduce the bug, and verify the fix. > > [*] > > java.lang.module.FindException: Error reading module: /m2 > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) > at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) > at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) > at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) > at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) > at ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) > at ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) > at ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) > at ... > Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not found in module > at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) > at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) > at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) > at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) > ... 36 more Hi Chris, maybe you should add `@bug 8282444` to `ModulesInCustomFileSystem.java` too? ------------- PR: https://git.openjdk.java.net/jdk/pull/7632 From alanb at openjdk.java.net Mon Feb 28 16:21:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 28 Feb 2022 16:21:50 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:16:31 GMT, Daniel Fuchs wrote: > Hi Chris, maybe you should add `@bug 8282444` to `ModulesInCustomFileSystem.java` too? The downside is that it would make it look like the test was added fro this issue. I think it only works if the original issue for the module system implementation is there too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7632 From chegar at openjdk.java.net Mon Feb 28 16:38:27 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 28 Feb 2022 16:38:27 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character [v2] In-Reply-To: References: Message-ID: > The module finder implementation incorrectly uses the path-separator > character from the default file system, when mapping the relative path > of an entry in an exploded module to a package name. This causes > problems on Windows [*] when using a module finder with a custom file > system that has a path-separator character that differs from that of the > default file system, e.g. the zip file system (which uses '/', > rather than '\' ). > > Rather than adding a new test for this, I deciced to just modify an > existing one. The existing test exercises the module finder with a > custom file system, but does so with modules have trivial single-level > packages names. I just expanded the module to have a subpackage. This > is sufficient to reproduce the bug, and verify the fix. > > [*] > > java.lang.module.FindException: Error reading module: /m2 > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) > at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) > at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) > at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) > at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) > at ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) > at ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) > at ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) > at ... > Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not found in module > at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) > at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) > at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) > at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) > ... 36 more Chris Hegarty has updated the pull request incrementally with two additional commits since the last revision: - update copyright year - add tag with OrigBugId 8178380, and bugFixId 8282444 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7632/files - new: https://git.openjdk.java.net/jdk/pull/7632/files/ca6cdf4c..220c43c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7632&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7632&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7632/head:pull/7632 PR: https://git.openjdk.java.net/jdk/pull/7632 From chegar at openjdk.java.net Mon Feb 28 16:40:49 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 28 Feb 2022 16:40:49 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 14:34:43 GMT, Alan Bateman wrote: > we should create another issue to create more tests for custom file systems. Yeah, that's a good point. I'll take a closer look at this and see how best to expand the coverage (separately). > I assume you'll update the date in the copyright header of the changed files. Done. >> Hi Chris, maybe you should add @bug 8282444 to ModulesInCustomFileSystem.java too? > The downside is that it would make it look like the test was added fro this issue. I think it only works if the original issue for the module system implementation is there too. I added a tag with both the original bugId that introduced the test, 8178380, and bug Fix Id for this issue, 8282444. ------------- PR: https://git.openjdk.java.net/jdk/pull/7632 From rriggs at openjdk.java.net Mon Feb 28 17:32:52 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Feb 2022 17:32:52 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v5] In-Reply-To: <_-XlZDme3lIVFOeuD17Ht6a5qiKxRLibm6EFex2YOn8=.efc1df68-8603-4c7a-b687-b4855f57cbd8@github.com> References: <_-XlZDme3lIVFOeuD17Ht6a5qiKxRLibm6EFex2YOn8=.efc1df68-8603-4c7a-b687-b4855f57cbd8@github.com> Message-ID: On Fri, 25 Feb 2022 08:44:42 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? >> >> As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: >> - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. >> - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. >> >> All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: >> >> >> Using locale: he for Properties#store(OutputStream) test >> test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure >> java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 >> at org.testng.Assert.fail(Assert.java:87) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) >> at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> 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:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:828) >> Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 >> at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) >> at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) >> ... 30 more >> >> (in the exception above a locale with language `he` is being used) >> >> The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > HashSet::new instead of new HashSet() in test Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From pushkar.nk at in.ibm.com Mon Feb 28 18:17:23 2022 From: pushkar.nk at in.ibm.com (Pushkar N Kulkarni) Date: Mon, 28 Feb 2022 18:17:23 +0000 Subject: Future.isCancelled and thread interruption Message-ID: "Future.cancel(true)" cancels the receiver Future and also attempts to interrupt the executor thread that is running this task. However, not all threads may be interrupted. An exception are threads that executing one of the "restart-able blocking system calls" from libnet. Such threads will ignore the thread interrupt(EINTR) and restart the blocking system call that was interrupted. See the system calls wrapped in the BLOCKING_IO_RETURN_INT macro: https://github.com/openjdk/jdk/blob/master/src/java.base/linux/native/libnet/linux_close.c#L352 The javadoc for "java.util.concurrent.Future.cancel(boolean mayInterruptIfRunning)" DOES clarify that this method is an "attempt" to cancel the Future, and that it has no effect if the "task is already completed or cancelled, or could not be cancelled for *some other reason*". It is also made clear that "the return value from this method does not necessarily indicate whether the task is now cancelled". This is good, in the context of this note. The javadoc also presents "Future.isCancelled()" as a definitive way to test if a Future was cancelled. However, it does not comment on the thread interruption attempted by Future.cancel(true). This might lead users to assume that if "Future.isCancelled()" returns true, the related executor thread was also successfully interrupted. This assumption would be invalid if the related executor thread was blocked in one of libnet's restart-able system calls (connect() could block for a couple of minutes). I am attaching a test program that reproduces the mentioned behaviour. The executor thread held a lock and it was assumed that when "Future.isCancelled()" returned true, the executor had been interrupted and the lock released. In reality, the lock was held for a longer time and it blocked the main thread where the invalid assumption was made. I am curious to know what others think of this matter! Any help/corrections/opinions will be appreciated. Thank you! ---------- import java.net.*; import java.util.concurrent.*; public class ConnectionTest { private synchronized Socket connect(String host, int port) throws Exception { InetSocketAddress address = new InetSocketAddress(host, port); Socket s = new Socket(); s.connect(address); // HERE: s.connect(address, T), with any T>0, would resolve the hang! return s; } private Socket connectToMain() throws Exception { System.out.println("Connecting to main..."); return connect("www.google.com", 81); } private Socket connectToAlternate() throws Exception { System.out.println("Connecting to alternate..."); return connect("www.example.com", 80); } public void test() throws Exception { ExecutorService es = Executors.newFixedThreadPool(1); Future f = es.submit(new Callable() { public Socket call() throws Exception { return connectToMain(); } }); try { f.get(2000, TimeUnit.MILLISECONDS); System.out.println("Connected to main!"); return; } catch (TimeoutException e) { System.out.println("Connection to main timed out, cancelling the Future with mayInterruptIfRunning = true"); boolean ret = f.cancel(true); System.out.println("Future.cancel(true) returned " + ret); } System.out.println("Is Future canceled? ..." + f.isCancelled()); if (f.isCancelled()) { connectToAlternate(); System.out.println("Connected to alternate!"); } } public static void main(String [] args) throws Exception { new ConnectionTest().test(); } } ---------- -Pushkar From duke at openjdk.java.net Mon Feb 28 18:26:49 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 28 Feb 2022 18:26:49 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v12] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 01:17:23 GMT, Joe Darcy wrote: > It does because of the AccessFlags.MODULE constant. But?that?s exactly?what the?unqualified `MODULE`?identifier refers?to, and?there?s no?other bare?`MODULE`?identifier in?scope that?would?shadow the?`AccessFlag.MODULE`?constant from?the?POV of?`AccessFlag.LocationToFlags`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From alanb at openjdk.java.net Mon Feb 28 18:53:17 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 28 Feb 2022 18:53:17 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character [v2] In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:38:27 GMT, Chris Hegarty wrote: >> The module finder implementation incorrectly uses the path-separator >> character from the default file system, when mapping the relative path >> of an entry in an exploded module to a package name. This causes >> problems on Windows [*] when using a module finder with a custom file >> system that has a path-separator character that differs from that of the >> default file system, e.g. the zip file system (which uses '/', >> rather than '\' ). >> >> Rather than adding a new test for this, I deciced to just modify an >> existing one. The existing test exercises the module finder with a >> custom file system, but does so with modules have trivial single-level >> packages names. I just expanded the module to have a subpackage. This >> is sufficient to reproduce the bug, and verify the fix. >> >> [*] >> >> java.lang.module.FindException: Error reading module: /m2 >> at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) >> at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) >> at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) >> at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) >> at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) >> at ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) >> at ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) >> at ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) >> at ... >> Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not found in module >> at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) >> at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) >> at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) >> at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) >> at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) >> ... 36 more > > Chris Hegarty has updated the pull request incrementally with two additional commits since the last revision: > > - update copyright year > - add tag with OrigBugId 8178380, and bugFixId 8282444 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7632 From duke at openjdk.java.net Mon Feb 28 19:21:32 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 28 Feb 2022 19:21:32 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v11] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 23:27:45 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > Update javadoc src/java.base/share/classes/java/util/Random.java line 84: > 82: i = 48, j = 0, k = 0, > 83: equidistribution = 0 > 84: ) This?should probably?not be?indented: Suggestion: ) src/java.base/share/classes/java/util/Random.java line 93: > 91: > 92: @SuppressWarnings("serial") > 93: private static class RandomWrapper extends Random implements RandomGenerator { This?class should?also override?all the?default?methods in?`RandomGenerator` and?forward?them to?`this.generator`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Mon Feb 28 19:21:35 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 28 Feb 2022 19:21:35 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v6] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 22:59:05 GMT, liach wrote: >> src/java.base/share/classes/java/util/Random.java line 298: >> >>> 296: */ >>> 297: public static Random from(RandomGenerator random) { >>> 298: return RandomWrapper.wrap(random); >> >> Might be good to check here or in the called methods / constructors for `null`. Currently `null` would not be noticed until the first method is called on the created `Random`, which makes it difficult for the user to track down bugs in their code. > > Suggestion: > > Objects.requireNonNull(random); > return RandomWrapper.wrap(random); > > fyi this is the original change suggested by marcono1234. Notice that this might need a csr update; maybe a javadoc update is needed too Arguably, `RandomWrapper.wrap` should?be?inlined?here, since?it?s not?used anywhere?else: Suggestion: if (Objects.requireNonNull(random, "random") instanceof Random) { return (Random) random; } return new RandomWrapper(random); ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From kasperni at gmail.com Mon Feb 28 20:23:11 2022 From: kasperni at gmail.com (Kasper Nielsen) Date: Mon, 28 Feb 2022 20:23:11 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: Message-ID: Is there really a need to make this so complicated? In all the examples I've seen so far it would be fine to set system-exit restrictions up from the program's main class. So why not just restrict it to the main class by default? I assume this class is under the control of the user or an IDE/Application Server. Add this method to java.lang.Runtime void restrictExit(MethodHandles.Lookup lookup, IntConsumer interceptor) { if (lookup.lookupClass() != "JAVA_MAIN_CLASS" || !lookup.hasFullPrivilegeAccess()) { throw new IllegalArgumentException("Invalid Lookup class"); } ... Register interceptor to be called before System.exit ... } People could then call it, for example, from a static initializer block in the Main class. And use scope locals or whatever they want. static { Runtime.restrictExit(MethodHandles.lookup(), ...) } Ideally, everyone would be using the module system, And we would have some kind of "application module" concept, which would be the module containing the program's entry point. And which could have these special permissions by default. It might even be possible to delegate permissions to other modules if needed. /Kasper On Sat, 26 Feb 2022 at 22:27, Ethan McCue wrote: > I have a feeling this has been considered and I might just be articulating > the obvious - but: > > As called out in JEP 411, one of the remaining legitimate uses of the > Security Manager is to intercept calls to System.exit. This seems like a > decent use case for the Scope Local mechanism. > > > From iklam at openjdk.java.net Mon Feb 28 20:38:24 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 28 Feb 2022 20:38:24 GMT Subject: RFR: 8275731: CDS archived enums objects are recreated at runtime [v4] In-Reply-To: References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: On Thu, 17 Feb 2022 23:20:41 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Use InstanceKlass::do_local_static_fields for some field iterations > > Looks good. Minor comment below. > Also, several files with copyright year 2021 need updating. Thanks @calvinccheung and @coleenp for the review. Passed tiers 1-5. ------------- PR: https://git.openjdk.java.net/jdk/pull/6653 From iklam at openjdk.java.net Mon Feb 28 20:38:24 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 28 Feb 2022 20:38:24 GMT Subject: Integrated: 8275731: CDS archived enums objects are recreated at runtime In-Reply-To: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> References: <9XdQFi_-JzM91ET0nN1gRCp8ZfMGBz1BwXglxqb8phg=.c643d5a5-b99a-4ce2-8616-9c1472e521b7@github.com> Message-ID: On Wed, 1 Dec 2021 20:47:20 GMT, Ioi Lam wrote: > **Background:** > > In the Java Language, Enums can be tested for equality, so the constants in an Enum type must be unique. Javac compiles an enum declaration like this: > > > public enum Day { SUNDAY, MONDAY ... } > > > to > > > public class Day extends java.lang.Enum { > public static final SUNDAY = new Day("SUNDAY"); > public static final MONDAY = new Day("MONDAY"); ... > } > > > With CDS archived heap objects, `Day::` is executed twice: once during `java -Xshare:dump`, and once during normal JVM execution. If the archived heap objects references one of the Enum constants created at dump time, we will violate the uniqueness requirements of the Enum constants at runtime. See the test case in the description of [JDK-8275731](https://bugs.openjdk.java.net/browse/JDK-8275731) > > **Fix:** > > During -Xshare:dump, if we discovered that an Enum constant of type X is archived, we archive all constants of type X. At Runtime, type X will skip the normal execution of `X::`. Instead, we run `HeapShared::initialize_enum_klass()` to retrieve all the constants of X that were saved at dump time. > > This is safe as we know that `X::` has no observable side effect -- it only creates the constants of type X, as well as the synthetic value `X::$VALUES`, which cannot be observed until X is fully initialized. > > **Verification:** > > To avoid future problems, I added a new tool, CDSHeapVerifier, to look for similar problems where the archived heap objects reference a static field that may be recreated at runtime. There are some manual steps involved, but I analyzed the potential problems found by the tool are they are all safe (after the current bug is fixed). See cdsHeapVerifier.cpp for gory details. An example trace of this tool can be found at https://bugs.openjdk.java.net/secure/attachment/97242/enum_warning.txt > > **Testing:** > > Passed Oracle CI tiers 1-4. WIll run tier 5 as well. This pull request has now been integrated. Changeset: d983d108 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/d983d108c565654e717e2811d88aa94d982da2f5 Stats: 860 lines in 16 files changed: 807 ins; 4 del; 49 mod 8275731: CDS archived enums objects are recreated at runtime Reviewed-by: coleenp, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/6653 From rriggs at openjdk.java.net Mon Feb 28 21:38:42 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Feb 2022 21:38:42 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add a new line to the end of test file for JDK-8282008 (I'm still working on a more nuanced fix that works with .exe, .cmd, and with allowAmbiguousCommands both true and false). The suggested workaround was to remove the application quotes and let ProcessBuilder do the quoting. That resulted in an extra backslash "\" at the end of a file path. In my investigation, the extra "\" doesn't prevent the string from being correctly used as a directory path in either VisualBasic or cmd.exe. So I'm curious, in the original application that uncovered this problem, what is/was reported as the error? Was the original application retested with the workaround? The case of the backslash at the end of an argument occurs mainly in a directory path. Yes, the argument is different, but does it make a difference that matters in the context in which it appears. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From naoto at openjdk.java.net Mon Feb 28 23:23:33 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Feb 2022 23:23:33 GMT Subject: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F Message-ID: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted. ------------- Commit messages: - 8282081: java.time.DateTimeFormatter: wrong definition of symbol F Changes: https://git.openjdk.java.net/jdk/pull/7640/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7640&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282081 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7640.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7640/head:pull/7640 PR: https://git.openjdk.java.net/jdk/pull/7640