From vtewari at openjdk.java.net Tue Jun 1 05:34:26 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Tue, 1 Jun 2021 05:34:26 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v9] In-Reply-To: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> References: <9qJLk6We2yEGQiMS0y-A8ggivVfCwcwrD7YP3IVC7qw=.017684f1-3e5f-4ae9-ba1e-c13b62127698@github.com> Message-ID: On Mon, 31 May 2021 14:10:50 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Added missing brace > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Removed trailing whitespace > - 8267670: Remove redundant code from switch > - 8267670: Updated code to use yield > - Merge remote-tracking branch 'origin/master' into JDK-8267670 > - 8267670: Update java.io, java.math, and java.text to use switch expressions Marked as reviewed by vtewari (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From jlahoda at openjdk.java.net Tue Jun 1 07:50:49 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 1 Jun 2021 07:50:49 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v8] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing enum switch with patterns with guards. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/a49b6109..80b1392b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=06-07 Stats: 82 lines in 3 files changed: 80 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From pconcannon at openjdk.java.net Tue Jun 1 08:39:44 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 1 Jun 2021 08:39:44 GMT Subject: RFR: 8267670: Update java.io, java.math, and java.text to use switch expressions [v10] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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: - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Added missing brace - Merge remote-tracking branch 'origin/master' into JDK-8267670 - 8267670: Removed trailing whitespace - 8267670: Remove redundant code from switch - 8267670: Updated code to use yield - Merge remote-tracking branch 'origin/master' into JDK-8267670 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4c495d3b...44f86889 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4182/files - new: https://git.openjdk.java.net/jdk/pull/4182/files/44886603..44f86889 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4182&range=08-09 Stats: 10 lines in 3 files changed: 3 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4182.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4182/head:pull/4182 PR: https://git.openjdk.java.net/jdk/pull/4182 From github.com+26887752+jaroslavtulach at openjdk.java.net Tue Jun 1 09:37:21 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Tue, 1 Jun 2021 09:37:21 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v4] In-Reply-To: References: Message-ID: <4uC5qHdoBI67sXAJL78KkodpfZ3ENxudrxcvyvqWbHU=.5d7827dd-30a2-4a3d-838d-e0753fdf3c54@github.com> On Mon, 31 May 2021 12:02:13 GMT, Peter Levart wrote: > A test could be constructed so that it would mimic the migration of an annotation from CLASS to RUNTIME retention The test is ready for review in #4280 - I am closing this PR without integration as the change of core-libs proposed here hasn't gained enough support. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Tue Jun 1 09:37:22 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Tue, 1 Jun 2021 09:37:22 GMT Subject: Withdrawn: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach wrote: > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. > > This PR provides a new test and a fix to make `Class.getAnnotation(...)` useful when `-XX:+PreserveAllAnnotations` option is on. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4245 From github.com+26887752+jaroslavtulach at openjdk.java.net Tue Jun 1 09:39:39 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Tue, 1 Jun 2021 09:39:39 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested Message-ID: There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. ------------- Commit messages: - Test long time existing behavior of -XX:+PreserveAllAnnotations Changes: https://git.openjdk.java.net/jdk/pull/4280/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4280&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267936 Stats: 172 lines in 1 file changed: 172 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4280/head:pull/4280 PR: https://git.openjdk.java.net/jdk/pull/4280 From pconcannon at openjdk.java.net Tue Jun 1 10:18:26 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Tue, 1 Jun 2021 10:18:26 GMT Subject: Integrated: 8267670: Update java.io, java.math, and java.text to use switch expressions In-Reply-To: References: Message-ID: On Tue, 25 May 2021 09:37:58 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the switch expressions? > > Kind regards, > Patrick This pull request has now been integrated. Changeset: 4eb21682 Author: Patrick Concannon URL: https://git.openjdk.java.net/jdk/commit/4eb216824f39e3c3536972d76d778466c140df50 Stats: 354 lines in 11 files changed: 5 ins; 193 del; 156 mod 8267670: Update java.io, java.math, and java.text to use switch expressions Reviewed-by: darcy, chegar, naoto, iris, dfuchs, lancea, vtewari ------------- PR: https://git.openjdk.java.net/jdk/pull/4182 From alanb at openjdk.java.net Tue Jun 1 12:50:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 12:50:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6] In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com> Message-ID: On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > default behavior reverted to allow System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to implSetSecurityManager and avoid the line break in the middle of the declaration? The usage of System.err usage in setSecurityManager also needs to be re-examined as this will run arbitrary code when System.err can be changed. To fix this will require capturing the stream at startup (as was done with the illegal access logger). It's okay to integrate with what you have for the first push and we can fix this issue with System.err when the warning message is changed to the intended message. ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Tue Jun 1 13:31:20 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 13:31:20 GMT Subject: RFR: 8267569: java.io.File.equals contains misleading Javadoc [v2] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 23:42:39 GMT, Brian Burkhalter wrote: >> Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8267569: Put clarifying verbiage in an @implNote src/java.base/share/classes/java/io/File.java line 2228: > 2226: * @implNote The abstract pathname equality test is equivalent to > 2227: * {@code compareTo((File)obj) == 0}. This method does not > 2228: * access the file system and the file is not required to exist. I think it might be clear to replace this with an apiNote that makes it clear to readers that this method just tests if the abstract paths are equal, it does not access the file system. src/java.base/share/classes/java/io/File.java line 2237: > 2235: * @see #compareTo(File) > 2236: * @see java.nio.file.Files#isSameFile(Path,Path) > 2237: * @see java.nio.file.Path#equals(Object) I think it could be confusing to link to Path.equals here, can this be dropped? ------------- PR: https://git.openjdk.java.net/jdk/pull/4232 From alanb at openjdk.java.net Tue Jun 1 13:43:24 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 13:43:24 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v4] In-Reply-To: References: Message-ID: On Tue, 25 May 2021 16:53:28 GMT, Roger Riggs wrote: >> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. >> The Charset used to encode and decode characters to bytes can be specified or use the >> operating system native encoding as is available from the "native.encoding" system property. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Described charset mapping of malformed chars in outputWriter > Repeated calls to inputReader, errorReader, and outputWriter now return the same instance > and check for inconsistent charset argument > Added warnings about concurrently use of input/output streams and readers/writers. src/java.base/share/classes/java/lang/Process.java line 105: > 103: // Readers and Writers created for this process; so repeated calls return the same object > 104: // All updates must be done while synchronized on this Process. > 105: private BufferedWriter outputWriter = null; No need to explicitly initialise all these fields to null. src/java.base/share/classes/java/lang/Process.java line 131: > 129: * Use {@link #getOutputStream} and {@link #outputWriter} with extreme care. > 130: * Output to the {@code BufferedWriter} may be held in the buffer until > 131: * {@linkplain BufferedWriter#flush flush} is called. I think this will need a bit of wordsmithing to make it clear that its the usage of both streams for the same Process requires great care (as it stands, it reads like the usage of either method is dangerous). src/java.base/share/classes/java/lang/Process.java line 207: > 205: * {@link Charset} named by the {@code native.encoding} > 206: * system property or the {@link Charset#defaultCharset()} if the > 207: * {@code native.encoding} is not supported. "if the native.encoding is not supported". I think this needs an adjustment to make it clear that the value of the property is not a valid charset. src/java.base/share/classes/java/lang/Process.java line 425: > 423: } else { > 424: if (!outputCharset.equals(charset)) > 425: throw new IllegalArgumentException("BufferedWriter was created with charset: " + outputCharset); I'm not sure that IAE is the right exception here, I think it's closer to IllegalStateException because the first usage of outputWriter has the side effect of setting the charset for the Process's writer. Another option here is to just put it into the "unpredictable" bucket that is using getOutputStream and outputWriter at the same time. In that case, it could just return a new BufferedWriter when it doesn't match the charset of the first usage. ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 From brian.goetz at oracle.com Tue Jun 1 14:02:53 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 1 Jun 2021 10:02:53 -0400 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: <75639690-4343-cbd7-7ac0-179bf507ad7d@oracle.com> Since the discussion happened over the holiday weekend, I didn't get a chance to respond until now, but I think that this came to a good outcome.? As Alan's archaeology discovered, this flag appears to be a leftover from the original implementation, and I could find no signs of its usage.? We might consider deprecating it (though, we might also leave sleeping dogs alone), but its good to have a test for the current behavior. Allow me to make a few meta-comments about how we got here, though, before we wrap up. > they are not visible via java.lang.reflect API. I assume that's just an omission. While omissions do sometimes happen, it is usually not the best first theory in a situation like this.? More often than not, there is a good, but often non-obvious, explanation. More importantly, though, the PR-first approach is not how we like to approach such a change, especially when it involves the behaviors of such fundamental APIs such as reflection, because it jumps over the most important steps: ?- What problem are we trying to solve? ?- Is it really a problem that needs to be solved? ?- Is it really a problem that needs to be solved in the JDK? ?- What solutions are there, besides the obvious one? ?- What are the pros, cons, and tradeoffs of the various solutions? ?- Of the proposed solution, what future downsides and risks could we imagine? Going straight to the code of a specific solution is likely to be unsatisfying in both the short term (because its the wrong conversation) or the long term (because it might not be the right solution to the right problem.)? Instead, starting with a discussion of the problem, and of potential solutions and tradeoffs, is likely to yield a better result on both counts. (As an example of the last one, suppose we committed this patch.? One could easily imagine some library later saying "must be run with -Xx:PreserveAllAnnotations" because that's what the author had to do to make it work.? But a behavior change like non-runtime annotations showing up unexpectedly in reflection could confuse existing code, which might not work as expected with the new behavior.? Which might then call for "can we please make the PreserveAllAnnotations flag more selective (e.g., per-class/module/package)" or calls for new flags or ... yuck.? We try to avoid today's solutions becoming tomorrow's problems.? This is not an exact science, of course, but this is the sort of stewardship we strive for.) On 6/1/2021 5:39 AM, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. > > ------------- > > Commit messages: > - Test long time existing behavior of -XX:+PreserveAllAnnotations > > Changes: https://git.openjdk.java.net/jdk/pull/4280/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4280&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8267936 > Stats: 172 lines in 1 file changed: 172 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/4280.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/4280/head:pull/4280 > > PR: https://git.openjdk.java.net/jdk/pull/4280 From alanb at openjdk.java.net Tue Jun 1 14:27:23 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 14:27:23 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v2] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Fri, 28 May 2021 05:47:11 GMT, David Holmes wrote: > The core-libs folks have the experience/expertise with these character encoding issues so I will defer to them. Naoto has agreed to look at this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From weijun at openjdk.java.net Tue Jun 1 15:06:41 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 1 Jun 2021 15:06:41 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v7] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: rename setSecurityManagerDirect to implSetSecurityManager ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4073/files - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Tue Jun 1 15:21:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 1 Jun 2021 15:21:33 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - merge from master - rename setSecurityManagerDirect to implSetSecurityManager - default behavior reverted to allow - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - feedback from Sean, Phil and Alan - add supresswarnings annotations automatically - manual change before automatic annotating - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=07 Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From alanb at openjdk.java.net Tue Jun 1 16:05:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 16:05:29 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - merge from master > - rename setSecurityManagerDirect to implSetSecurityManager > - default behavior reverted to allow > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From joehw at openjdk.java.net Tue Jun 1 16:28:27 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 1 Jun 2021 16:28:27 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8] In-Reply-To: References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. >> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. >> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - merge from master > - rename setSecurityManagerDirect to implSetSecurityManager > - default behavior reverted to allow > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From mchung at openjdk.java.net Tue Jun 1 16:29:26 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 1 Jun 2021 16:29:26 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v6] In-Reply-To: References: Message-ID: On Thu, 27 May 2021 14:31:59 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments The change looks good in general with a minor suggestion to rename `NativeLibraryContext::get` to `NativeLibraryContext::current` which would be clearer as it returns the current native library context (of the current thread). src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 207: > 205: * > 206: * We use a static stack to hold the list of libraries we are > 207: * loading, so that each thread maintains its own stack. line 206: no longer a static stack. line 206-207 can be replaced with: * Each thread maintains its own stack to hold the list of libraries it is loading. src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 213: > 211: * a different class loader, we raise UnsatisfiedLinkError. > 212: */ > 213: for (NativeLibraryImpl lib : NativeLibraryContext.get()) { I suggest to rename the `get` method of `NativeLibraryContext` to `current` that returns the current thread's context. test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/LoadLibraryDeadlock.java line 49: > 47: InstantiationException | > 48: IllegalAccessException ignore) { > 49: System.out.println("Class Class1 not found."); In general a test should let the exception to propagate. In this case, the threads (both t1 and t2) can warp the exception and throw `RuntimeException` as it's an error. test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/LoadLibraryDeadlock.java line 60: > 58: System.out.println("Signed jar loaded."); > 59: } catch (ClassNotFoundException ignore) { > 60: System.out.println("Class Class2 not found."); Same as above test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 28: > 26: * @test > 27: * @bug 8266310 > 28: * @summary deadlock while loading the JNI code please update `@summary` with a description of the test (rather than the synposis of the bug). test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 69: > 67: > 68: private static OutputAnalyzer genKey() throws Throwable { > 69: runCommandInTestClassPath("rm", "-f", KEYSTORE); Can you use `jdk.test.lib.util.FileUtils` instead of exec `rm -f`. test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 84: > 82: > 83: private static OutputAnalyzer createJar(String outputJar, String... classes) throws Throwable { > 84: String jar = JDKToolFinder.getJDKTool("jar"); You can consider using `jdk.test.lib.util.JarUtils` to reduce the test execution time so that it can create the jar without exec'ing another process. test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 141: > 139: try { > 140: return future.get(1000, TimeUnit.MILLISECONDS); > 141: } catch (Exception ignoreAll) { if this is an unexpected error case, it should throw an exception. test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 165: > 163: > 164: runCommandInTestClassPath("rm", "-f", "*.jar") > 165: .shouldHaveExitValue(0); You can use `jdk.test.lib.util.FileUtils` to delete a directory or a given path. test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 31: > 29: * @test > 30: * @bug 8266310 > 31: * @summary deadlock while loading the JNI code please update `@summary` with a description of the test (rather than the synposis of the bug). test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 83: > 81: this.object = fromClass.newInstance(); > 82: this.method = fromClass.getDeclaredMethod("loadLibrary"); > 83: } catch (Exception error) { Nit: `s/Exception/ReflectiveOperationException/` as ROE is the specific checked exception you want to catch here. test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 84: > 82: this.method = fromClass.getDeclaredMethod("loadLibrary"); > 83: } catch (Exception error) { > 84: throw new Error(error); Error is fine. Most tests throw `RuntimeException` that can be another choice. test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 92: > 90: try { > 91: method.invoke(object); > 92: } catch (Exception error) { Same here to catch the `ReflectiveOperationException`. test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 148: > 146: threads = null; > 147: exceptions.clear(); > 148: waitForUnload(wClass); `jdk.test.lib.util.ForceGC` can be used here. You can reference test/jdk/java/lang/ClassLoader/nativeLIbrary/NativeLibraryTest.java. test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java line 32: > 30: * @test > 31: * @bug 8266310 > 32: * @summary deadlock while loading the JNI code Please update `@summary` with a description of the test (rather than the synposis of the bug) ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From psandoz at openjdk.java.net Tue Jun 1 16:33:19 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 1 Jun 2021 16:33:19 GMT Subject: RFR: 8267969: Add vectorized implementation for VectorMask.eq() In-Reply-To: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> References: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> Message-ID: On Mon, 31 May 2021 10:25:26 GMT, Xiaohong Gong wrote: > Currently `"VectorMask.eq()" `is not vectorized: > > public VectorMask eq(VectorMask m) { > // FIXME: Generate good code here. > return bOp(m, (i, a, b) -> a == b); > } > > This can be implemented by calling `"xor(m.not())"` directly. > > The performance improved about 1.4x ~ 1.9x for the following benchmark with different basic types: > > @Benchmark > public Object eq() { > boolean[] ma = fm.apply(size); > boolean[] mb = fmb.apply(size); > boolean[] mt = fmt.apply(size); > VectorMask m = VectorMask.fromArray(SPECIES, mt, 0); > > for (int ic = 0; ic < INVOC_COUNT; ic++) { > for (int i = 0; i < ma.length; i += SPECIES.length()) { > var av = SPECIES.loadMask(ma, i); > var bv = SPECIES.loadMask(mb, i); > > // accumulate results, so JIT can't eliminate relevant computations > m = m.and(av.eq(bv)); > } > } > > return m; > } Looks. Later we may want to consider pushing this down as an intrinsic, perhaps reusing `VectorSupport.compare`. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4272 From naoto at openjdk.java.net Tue Jun 1 16:40:21 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 1 Jun 2021 16:40:21 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v5] In-Reply-To: <_bf5gSg6d_TO3LNPvS1R-1S1EO5E5cY_6v96jAlh1CQ=.98952087-dfcd-4919-8029-f3aaa055f69d@github.com> References: <_bf5gSg6d_TO3LNPvS1R-1S1EO5E5cY_6v96jAlh1CQ=.98952087-dfcd-4919-8029-f3aaa055f69d@github.com> Message-ID: On Sun, 30 May 2021 00:49:56 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource Looks good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4016 From rriggs at openjdk.java.net Tue Jun 1 16:52:26 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Jun 2021 16:52:26 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v5] In-Reply-To: <_bf5gSg6d_TO3LNPvS1R-1S1EO5E5cY_6v96jAlh1CQ=.98952087-dfcd-4919-8029-f3aaa055f69d@github.com> References: <_bf5gSg6d_TO3LNPvS1R-1S1EO5E5cY_6v96jAlh1CQ=.98952087-dfcd-4919-8029-f3aaa055f69d@github.com> Message-ID: On Sun, 30 May 2021 00:49:56 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From mcimadamore at openjdk.java.net Tue Jun 1 17:03:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 1 Jun 2021 17:03:59 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v27] In-Reply-To: References: Message-ID: <2Ea2q8-xz5mHKcvpHDlC9SqoArgaW0Iw32iG4HpQuVs=.c4df006f-e9fe-4438-ada1-abab7e7bd2a8@github.com> > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: - Merge branch 'master' into JEP-412 - Merge branch 'master' into JEP-412 - * Add missing `final` in some static fields * Downgrade native methods in ProgrammableUpcallHandler to package-private - Add sealed modifiers in morally sealed API interfaces - Merge branch 'master' into JEP-412 - Fix VaList test Remove unused code in Utils - Merge pull request #11 from JornVernee/JEP-412-MXCSR Add MXCSR save and restore to upcall stubs for non-windows platforms - Add MXCSR save and restore to upcall stubs for non-windows platforms - Merge branch 'master' into JEP-412 - Fix issue with bounded arena allocator - ... and 28 more: https://git.openjdk.java.net/jdk/compare/36dc268a...10767bc0 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3699/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=26 Stats: 14501 lines in 219 files changed: 8847 ins; 3642 del; 2012 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From rriggs at openjdk.java.net Tue Jun 1 17:35:49 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Jun 2021 17:35:49 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v5] In-Reply-To: References: Message-ID: <1XU7aWSLLSbHq7f64aVnU3TCmQqiXRzaTqDs3eTQs7A=.f725a314-3398-4b0c-a7ab-b71738d248c7@github.com> > Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. > The Charset used to encode and decode characters to bytes can be specified or use the > operating system native encoding as is available from the "native.encoding" system property. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Clarified use of native.encoding property and api notes about useing both writers and streams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4134/files - new: https://git.openjdk.java.net/jdk/pull/4134/files/a5ed7b73..37bfa009 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=03-04 Stats: 74 lines in 1 file changed: 12 ins; 28 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/4134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134 PR: https://git.openjdk.java.net/jdk/pull/4134 From bpb at openjdk.java.net Tue Jun 1 17:43:42 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 1 Jun 2021 17:43:42 GMT Subject: RFR: 8267569: java.io.File.equals contains misleading Javadoc [v3] In-Reply-To: References: Message-ID: > Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8267569: Change @implNote to @apiNote ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4232/files - new: https://git.openjdk.java.net/jdk/pull/4232/files/acd072ab..1e37eacd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4232&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4232&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4232/head:pull/4232 PR: https://git.openjdk.java.net/jdk/pull/4232 From iveresov at openjdk.java.net Tue Jun 1 17:46:25 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 1 Jun 2021 17:46:25 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6] In-Reply-To: References: Message-ID: <8RxYJZEePGo31FEahqK76i4h-q02mTtmfAYBg_3sjAY=.f6ff6a94-31b6-4149-8236-75b65dc82cf8@github.com> On Tue, 25 May 2021 02:44:41 GMT, Yi Yang wrote: >> Looks like now the test fails in the pre-submit tests? > > Thank you @veresov! > > I'm glad to have more comments from hotspot-compiler group. > > Later, I'd like to integrate it if there are no more comments/objections. > > Thanks! > Yang @kelthuzadx Sorry about the delay. Could you please rebase this to the current master and I'll push it. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From alanb at openjdk.java.net Tue Jun 1 17:53:19 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 1 Jun 2021 17:53:19 GMT Subject: RFR: 8267569: java.io.File.equals contains misleading Javadoc [v3] In-Reply-To: References: Message-ID: <_CsOCtTtSa_Sgal8Mmk4MRF5aZ2fFA4_noVTs7WNQ6A=.3defa960-c7a5-4be6-afd4-ff771b162166@github.com> On Tue, 1 Jun 2021 17:43:42 GMT, Brian Burkhalter wrote: >> Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8267569: Change @implNote to @apiNote Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4232 From raffaello.giulietti at gmail.com Tue Jun 1 17:56:07 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 1 Jun 2021 19:56:07 +0200 Subject: java.util.List missing from "Collections Framework Overview" javadoc In-Reply-To: <41ebc855-9767-91ea-aaff-c343846dec4d@gmail.com> References: <41ebc855-9767-91ea-aaff-c343846dec4d@gmail.com> Message-ID: <133fc77a-5e50-ce95-6009-3622d27baae7@gmail.com> Hi, can anybody take a look at this? I would do it myself but I don't have Author status to add an issue to the JBS. Should be a trivial change. Thanks Raffaello On 2021-05-30 18:03, Raffaello Giulietti wrote: > Hello, > > seems like java.util.List is missing from the list in the "Collection > Interfaces" section in > https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-overview.html > > > Should be easy to fix and doesn't seem to require a CSR as the document > is non-normative. > > Greetings > Raffaello From dfuchs at openjdk.java.net Tue Jun 1 18:01:22 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 1 Jun 2021 18:01:22 GMT Subject: RFR: 8267569: java.io.File.equals contains misleading Javadoc [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 17:43:42 GMT, Brian Burkhalter wrote: >> Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8267569: Change @implNote to @apiNote Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4232 From bchristi at openjdk.java.net Tue Jun 1 18:07:23 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 1 Jun 2021 18:07:23 GMT Subject: RFR: 8267569: java.io.File.equals contains misleading Javadoc [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 17:43:42 GMT, Brian Burkhalter wrote: >> Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8267569: Change @implNote to @apiNote Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4232 From psandoz at openjdk.java.net Tue Jun 1 18:07:47 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 1 Jun 2021 18:07:47 GMT Subject: RFR: 8266317: Vector API enhancements [v4] In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> Message-ID: > This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons. > > Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array. > > The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR. Paul Sandoz 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 remote-tracking branch 'upstream/master' into JDK-8266317-vector-api-enhancements - JavaDoc refs for unsigned operators. - Rename method. - Minor clarifications to the specification. - 8266317: Vector API enhancements ------------- Changes: https://git.openjdk.java.net/jdk/pull/3803/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=03 Stats: 10016 lines in 121 files changed: 9084 ins; 190 del; 742 mod Patch: https://git.openjdk.java.net/jdk/pull/3803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3803/head:pull/3803 PR: https://git.openjdk.java.net/jdk/pull/3803 From pavel.rappo at oracle.com Tue Jun 1 18:37:08 2021 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 1 Jun 2021 18:37:08 +0000 Subject: java.util.List missing from "Collections Framework Overview" javadoc In-Reply-To: <133fc77a-5e50-ce95-6009-3622d27baae7@gmail.com> References: <41ebc855-9767-91ea-aaff-c343846dec4d@gmail.com> <133fc77a-5e50-ce95-6009-3622d27baae7@gmail.com> Message-ID: <10A8A8D3-0E18-46F2-9DEA-74A15A5AC4A1@oracle.com> I have created a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8268077 > On 1 Jun 2021, at 18:56, Raffaello Giulietti wrote: > > Hi, > > can anybody take a look at this? > I would do it myself but I don't have Author status to add an issue to the JBS. > > Should be a trivial change. > > Thanks > Raffaello > > > On 2021-05-30 18:03, Raffaello Giulietti wrote: >> Hello, >> seems like java.util.List is missing from the list in the "Collection Interfaces" section in >> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-overview.html Should be easy to fix and doesn't seem to require a CSR as the document is non-normative. >> Greetings >> Raffaello From joe.darcy at oracle.com Tue Jun 1 18:43:12 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 1 Jun 2021 11:43:12 -0700 Subject: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code In-Reply-To: References: Message-ID: <37a7fbaa-b4ea-efa5-bee4-666e96a5be16@oracle.com> On 5/29/2021 12:20 AM, Jaroslav Tulach wrote: > This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. > > Existing `-XX:+PreserveAllAnnotations` option can be very useful for code that needs to access annotations with `RetentionPolicy.CLASS` without the need to parse the .class files manually. While the RuntimeInvisibleAnnotations are kept in the runtime, they are not visible via java.lang.reflect API. I assume that's just an omission. Not having CLASS retention annotations visible through the java.lang.reflect API is not an omission, it is a design choice from JSR 175. If CLASS retention annotations were visible through java.lang.reflec, they would just be RUNTIME retention annotations. -Joe From naoto at openjdk.java.net Tue Jun 1 18:45:22 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 1 Jun 2021 18:45:22 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> Message-ID: On Thu, 27 May 2021 16:14:38 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". >> >> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. >> >> Results from Linux: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> ============================== >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/runtime 746 746 0 0 >> ============================== >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has updated the pull request incrementally with two additional commits since the last revision: > > - Coding style-related corrections. > - Corrected the test to use Platform.sharedLibraryExt() src/hotspot/os/windows/os_windows.cpp line 1491: > 1489: static errno_t convert_UTF8_to_UTF16(char const* utf8_str, LPWSTR* utf16_str) { > 1490: return convert_to_UTF16(utf8_str, CP_UTF8, utf16_str); > 1491: } IIUC, `utf8_str` is the "modified" UTF-8 string in JNI. Using it as the standard UTF-8 (I believe Windows' encoding `CP_UTF8` is the one) may end up in incorrect conversions in some corner cases, e.g., for supplementary characters. test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java line 42: > 40: String nativePathSetting = "-Dtest.nativepath=" + getSystemProperty("test.nativepath"); > 41: ProcessBuilder pb = ProcessTools.createTestJvm(nativePathSetting, LoadLibraryUnicode.class.getName()); > 42: pb.environment().put("LC_ALL", "en_US.UTF-8"); Some environments/user configs may not have `UTF-8` codeset on the platform. May need to gracefully exit in such a case. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From naoto at openjdk.java.net Tue Jun 1 18:49:18 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 1 Jun 2021 18:49:18 GMT Subject: RFR: 8267569: java.io.File.equals contains misleading Javadoc [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 17:43:42 GMT, Brian Burkhalter wrote: >> Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8267569: Change @implNote to @apiNote Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4232 From jbhateja at openjdk.java.net Tue Jun 1 19:02:30 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 1 Jun 2021 19:02:30 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v7] In-Reply-To: References: Message-ID: On Mon, 24 May 2021 05:50:44 GMT, Jatin Bhateja wrote: >> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- >> >> vec1 = lanewise(VectorOperators.LSHL, n) >> vec2 = lanewise(VectorOperators.LSHR, n) >> res = lanewise(VectorOperations.OR, vec1 , vec2) >> >> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. >> >> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. >> >> Please find below the performance data for included JMH benchmark. >> Machine: Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz) >> >> >> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain % >> -- | -- | -- | -- | -- | -- | -- | -- | -- >> ? | ? | ? | ? | ? | ? | ? | ? | ? >> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82 >> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84 >> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90 >> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44 >> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30 >> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14 >> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58 >> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18 >> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02 >> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52 >> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40 >> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16 >> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98 >> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91 >> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34 >> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89 >> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63 >> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16 >> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53 >> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18 >> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64 >> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26 >> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99 >> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54 >> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04 >> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71 >> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66 >> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66 >> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02 >> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06 > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge http://github.com/openjdk/jdk into JDK-8266054 > - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054 > - 8266054: Removing redundant teat templates. > - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform. > - 8266054: Removing redundant test templates. > - 8266054: Review comments resolution. > - 8266054: Review comments resolution. > - 8266054: Review comments resolution. > - Merge http://github.com/openjdk/jdk into JDK-8266054 > - 8266054: Changing gen-src.sh file permissions > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4d26f22b...0439e93e Hi @iwanowww, @neliasso , kindly review compiler side changes and share your feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/3720 From herrick at openjdk.java.net Tue Jun 1 19:16:38 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 1 Jun 2021 19:16:38 GMT Subject: RFR: JDK-8267598: jpackage removes system libraries from java.library.path Message-ID: JDK-8267598: jpackage removes system libraries from java.library.path ------------- Commit messages: - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path Changes: https://git.openjdk.java.net/jdk/pull/4203/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4203&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267598 Stats: 49 lines in 5 files changed: 45 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4203/head:pull/4203 PR: https://git.openjdk.java.net/jdk/pull/4203 From lancea at openjdk.java.net Tue Jun 1 19:19:19 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 1 Jun 2021 19:19:19 GMT Subject: RFR: 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type In-Reply-To: References: Message-ID: On Sat, 29 May 2021 00:12:09 GMT, Joe Wang wrote: > Makes a correction to XPathEvaluationResult.XPathResultType.NODESET mapping. Clarifies the supported types for the evaluateExpression methods. > > Other changes were javadoc tag usages, e.g. s/the code tag/{@code Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4258 From naoto at openjdk.java.net Tue Jun 1 19:55:49 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 1 Jun 2021 19:55:49 GMT Subject: RFR: 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type In-Reply-To: References: Message-ID: On Sat, 29 May 2021 00:12:09 GMT, Joe Wang wrote: > Makes a correction to XPathEvaluationResult.XPathResultType.NODESET mapping. Clarifies the supported types for the evaluateExpression methods. > > Other changes were javadoc tag usages, e.g. s/the code tag/{@code src/java.xml/share/classes/javax/xml/xpath/package-info.java line 276: > 274: * > 275: *

> 276: * Of the subtypes of Number, only {@code Double, Integer} and {@code Long} are supported. Nit: `Number` may also be in @code emphasis. ------------- PR: https://git.openjdk.java.net/jdk/pull/4258 From github.com+70726043+rgiulietti at openjdk.java.net Tue Jun 1 20:00:29 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Tue, 1 Jun 2021 20:00:29 GMT Subject: RFR: 8268077: java.util.List missing from Collections Framework Overview Message-ID: Trivial changes to this non-normative document. ------------- Commit messages: - 8268077: java.util.List missing from Collections Framework Overview Changes: https://git.openjdk.java.net/jdk/pull/4289/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4289&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268077 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4289/head:pull/4289 PR: https://git.openjdk.java.net/jdk/pull/4289 From mcimadamore at openjdk.java.net Tue Jun 1 20:19:19 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 1 Jun 2021 20:19:19 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v8] In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 07:50:49 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing enum switch with patterns with guards. New changes looks good. I suggest to also add tests for strings in switch with guards and numeric with guards, to make sure every kind of switch works well. As discussed offline, we can probably simplify code generation logic for enum switches by leaning on the ConstantBootstraps BSM which allows to create enum constants given a class name and a constant name. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From john.r.rose at oracle.com Tue Jun 1 20:28:12 2021 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Jun 2021 20:28:12 +0000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <75639690-4343-cbd7-7ac0-179bf507ad7d@oracle.com> References: <75639690-4343-cbd7-7ac0-179bf507ad7d@oracle.com> Message-ID: <4EECBA96-3765-44D8-A5D0-A9BC78EDA127@oracle.com> On Jun 1, 2021, at 7:02 AM, Brian Goetz > wrote: As Alan's archaeology discovered, this flag appears to be a leftover from the original implementation, and I could find no signs of its usage. Note to self and other reviewers of future versions of the JVMS: When you see proposed language like the ?unless?? of JVMS 4.7.17, remember today's conversation and try to avoid putting dark corners like that into the JVMS. The RuntimeInvisibleAnnotations attribute is similar to the RuntimeVisibleAnnotations attribute (?4.7.16), except that the annotations represented by a RuntimeInvisibleAnnotations attribute must not be made available for return by reflective APIs, [[WE SHOULD HAVE STOPPED HERE]] unless the Java Virtual Machine has been instructed to retain these annotations via some implementation-specific mechanism such as a command line flag. In the absence of such instructions, the Java Virtual Machine ignores this attribute. https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-4.html#jvms-4.7.17 From joehw at openjdk.java.net Tue Jun 1 20:29:30 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 1 Jun 2021 20:29:30 GMT Subject: RFR: 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type [v2] In-Reply-To: References: Message-ID: <5dGTRBGBGVLXg5obBaPuV7swl7GEYIuXXeAaHwI3_wY=.c9a9a1af-2b0e-4847-a94c-c158e65a7130@github.com> > Makes a correction to XPathEvaluationResult.XPathResultType.NODESET mapping. Clarifies the supported types for the evaluateExpression methods. > > Other changes were javadoc tag usages, e.g. s/the code tag/{@code Joe Wang has updated the pull request incrementally with one additional commit since the last revision: Put Number in @code tag. Thanks Naoto. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4258/files - new: https://git.openjdk.java.net/jdk/pull/4258/files/29dd4923..8ffd4ea3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4258&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4258&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4258.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4258/head:pull/4258 PR: https://git.openjdk.java.net/jdk/pull/4258 From naoto at openjdk.java.net Tue Jun 1 21:13:26 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 1 Jun 2021 21:13:26 GMT Subject: RFR: 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type [v2] In-Reply-To: <5dGTRBGBGVLXg5obBaPuV7swl7GEYIuXXeAaHwI3_wY=.c9a9a1af-2b0e-4847-a94c-c158e65a7130@github.com> References: <5dGTRBGBGVLXg5obBaPuV7swl7GEYIuXXeAaHwI3_wY=.c9a9a1af-2b0e-4847-a94c-c158e65a7130@github.com> Message-ID: On Tue, 1 Jun 2021 20:29:30 GMT, Joe Wang wrote: >> Makes a correction to XPathEvaluationResult.XPathResultType.NODESET mapping. Clarifies the supported types for the evaluateExpression methods. >> >> Other changes were javadoc tag usages, e.g. s/the code tag/{@code > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > Put Number in @code tag. Thanks Naoto. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4258 From jjg at openjdk.java.net Tue Jun 1 22:13:35 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 1 Jun 2021 22:13:35 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov wrote: >> 8267706: bin/idea.sh tries to use cygpath on WSL > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > 8267706: Break long line in make/ide/idea/jdk/idea.gmk The fix fails on a Mac, where `realpath` is not available by default. ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From github.com+9004656+yaaz at openjdk.java.net Tue Jun 1 22:23:36 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Tue, 1 Jun 2021 22:23:36 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: On Tue, 1 Jun 2021 22:10:41 GMT, Jonathan Gibbons wrote: >> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8267706: Break long line in make/ide/idea/jdk/idea.gmk > > The fix fails on a Mac, where `realpath` is not available by default. @jonathan-gibbons this can be fixed with `brew install coreutils`. We probably need to check `realpath` availability in idea.sh and suggest installing `coreutils` if it's not available ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From almatvee at openjdk.java.net Tue Jun 1 23:16:38 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 1 Jun 2021 23:16:38 GMT Subject: RFR: JDK-8267598: jpackage removes system libraries from java.library.path In-Reply-To: References: Message-ID: On Wed, 26 May 2021 11:26:24 GMT, Andy Herrick wrote: > JDK-8267598: jpackage removes system libraries from java.library.path Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4203 From jjg at openjdk.java.net Wed Jun 2 00:22:35 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 00:22:35 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: On Tue, 1 Jun 2021 22:20:25 GMT, Nikita Gubarkov wrote: >> The fix fails on a Mac, where `realpath` is not available by default. > > @jonathan-gibbons this can be fixed with `brew install coreutils`. We probably need to check `realpath` availability in idea.sh and suggest installing `coreutils` if it's not available @YaaZ I'm aware of the workaround, but the current situation is not acceptable and needs to be fixed. @erikj79 is there precedent for requiring the use of `brew` to install packages? ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From lmesnik at openjdk.java.net Wed Jun 2 00:24:04 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 00:24:04 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v2] In-Reply-To: References: Message-ID: > EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'efh' of https://github.com/lmesnik/jdk into efh - updated after comments from Igor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4234/files - new: https://git.openjdk.java.net/jdk/pull/4234/files/68fd69d9..cb1eb944 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=00-01 Stats: 47 lines in 7 files changed: 9 ins; 31 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234 PR: https://git.openjdk.java.net/jdk/pull/4234 From lmesnik at openjdk.java.net Wed Jun 2 00:30:54 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 00:30:54 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v3] In-Reply-To: References: Message-ID: > EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: README updated. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4234/files - new: https://git.openjdk.java.net/jdk/pull/4234/files/cb1eb944..c48542b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234 PR: https://git.openjdk.java.net/jdk/pull/4234 From lmesnik at openjdk.java.net Wed Jun 2 00:44:05 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 00:44:05 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v4] In-Reply-To: References: Message-ID: > EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: remove unused code. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4234/files - new: https://git.openjdk.java.net/jdk/pull/4234/files/c48542b5..57d76163 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234 PR: https://git.openjdk.java.net/jdk/pull/4234 From gbierman at openjdk.java.net Wed Jun 2 00:52:33 2021 From: gbierman at openjdk.java.net (Gavin Bierman) Date: Wed, 2 Jun 2021 00:52:33 GMT Subject: Integrated: 8265130: Make ConstantDesc class hierarchy sealed In-Reply-To: References: Message-ID: On Thu, 20 May 2021 21:07:04 GMT, Gavin Bierman wrote: > Hi all, > > Please review this patch to make the ConstantDesc hierarchy `sealed`, as was promised in its Javadoc, now that sealed classes are finalising in JDK 17. > > Thanks, > Gavin This pull request has now been integrated. Changeset: 379376f0 Author: Gavin Bierman Committer: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/379376f0783facba93e1d11db9b184ef8183a13b Stats: 54 lines in 6 files changed: 16 ins; 29 del; 9 mod 8265130: Make ConstantDesc class hierarchy sealed Reviewed-by: mchung, jvernee, vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/4135 From github.com+9004656+yaaz at openjdk.java.net Wed Jun 2 00:57:35 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Wed, 2 Jun 2021 00:57:35 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: On Wed, 2 Jun 2021 00:19:56 GMT, Jonathan Gibbons wrote: >> @jonathan-gibbons this can be fixed with `brew install coreutils`. We probably need to check `realpath` availability in idea.sh and suggest installing `coreutils` if it's not available > > @YaaZ I'm aware of the workaround, but the current situation is not acceptable and needs to be fixed. A change to fix functionality on Windows should not adversely affect users on other platforms. > > @erikj79 is there precedent for requiring the use of `brew` to install packages? @jonathan-gibbons sure, but these changes also improve project setup process on all platforms, so realpath is required here because it's needed on MacOS as well, not only Windows Also, `brew` is already required to instal `autoconf`: https://openjdk.java.net/groups/build/doc/building.html#autoconf As `idea.sh` only works when project is configured, running it implies that `brew` is already installed, so asking user to install `coreutils` is not a big deal IMO ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From lmesnik at openjdk.java.net Wed Jun 2 01:00:53 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 01:00:53 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5] In-Reply-To: References: Message-ID: > EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: spaces updated. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4234/files - new: https://git.openjdk.java.net/jdk/pull/4234/files/57d76163..e70518bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234 PR: https://git.openjdk.java.net/jdk/pull/4234 From lmesnik at openjdk.java.net Wed Jun 2 01:00:54 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 01:00:54 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 02:20:04 GMT, Igor Ignatyev wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> spaces updated. > > test/failure_handler/Makefile line 41: > >> 39: CONF_DIR = src/share/conf >> 40: >> 41: JAVA_RELEASE = 7 > > could you please update `DEPENDENCES` section in `test/failure_handler/README`? done ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From lmesnik at openjdk.java.net Wed Jun 2 01:11:29 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 01:11:29 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes In-Reply-To: References: Message-ID: <4A_3o38kwqyRGJCTG3TigvK26WhJmdyUFLRR5BqwGWU=.99ef5094-0710-4014-91ab-0adf26b03263@github.com> On Fri, 28 May 2021 00:54:21 GMT, Leonid Mesnik wrote: >> Hi Leonid, >> >> What is EFH? Please update the bug and PR to explain. >> >> Thanks, >> David > >> Hi Leonid, >> >> What is EFH? Please update the bug and PR to explain. >> >> Thanks, >> David > > Updated summary to "Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes". > @lmesnik , how has this been tested? I used it in the loom for several weeks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From smarks at openjdk.java.net Wed Jun 2 01:15:36 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 2 Jun 2021 01:15:36 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry Message-ID: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> I'm fixing this along with a couple intertwined issues. 1. Add Map.Entry::copyOf as an idempotent copy operation. 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not really immutable) but that subclasses can be modifiable. 3. Clarify some confusing, historical wording about Map.Entry instances being obtainable only via iteration of a Map's entry-set view. This was never really true, since anyone could implement the Map.Entry interface, and it certainly was not true since JDK 1.6 when SimpleEntry and SimpleImmutableEntry were added. ------------- Commit messages: - More spec and test tweaks. - Fix up tests. - Spec wordsmithing. - Update specs. Add basic tests. - 8199318: add idempotent copy operation for Map.Entry Changes: https://git.openjdk.java.net/jdk/pull/4295/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4295&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8199318 Stats: 141 lines in 3 files changed: 120 ins; 2 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/4295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4295/head:pull/4295 PR: https://git.openjdk.java.net/jdk/pull/4295 From lmesnik at openjdk.java.net Wed Jun 2 01:21:32 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 01:21:32 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 02:25:59 GMT, Igor Ignatyev wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> spaces updated. > > @lmesnik , how has this been tested? @iignatev, thank you for your comments. I updated all of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From xgong at openjdk.java.net Wed Jun 2 01:41:28 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 2 Jun 2021 01:41:28 GMT Subject: RFR: 8267969: Add vectorized implementation for VectorMask.eq() In-Reply-To: References: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> Message-ID: On Tue, 1 Jun 2021 16:29:58 GMT, Paul Sandoz wrote: > Looks. Later we may want to consider pushing this down as an intrinsic, perhaps reusing `VectorSupport.compare`. Thanks for your review @PaulSandoz ! Yes, reusing `VectorSupport.compare` is an alternative way to do the vectorization. ------------- PR: https://git.openjdk.java.net/jdk/pull/4272 From xgong at openjdk.java.net Wed Jun 2 01:56:00 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 2 Jun 2021 01:56:00 GMT Subject: RFR: 8267969: Add vectorized implementation for VectorMask.eq() [v2] In-Reply-To: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> References: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> Message-ID: <6zmaxCZzzCbYEptpG91NJBAu7REALkAWx3KyVpbChU0=.f4b5b1d7-17f3-4d98-8412-1beb4262c7b2@github.com> > Currently `"VectorMask.eq()" `is not vectorized: > > public VectorMask eq(VectorMask m) { > // FIXME: Generate good code here. > return bOp(m, (i, a, b) -> a == b); > } > > This can be implemented by calling `"xor(m.not())"` directly. > > The performance improved about 1.4x ~ 1.9x for the following benchmark with different basic types: > > @Benchmark > public Object eq() { > boolean[] ma = fm.apply(size); > boolean[] mb = fmb.apply(size); > boolean[] mt = fmt.apply(size); > VectorMask m = VectorMask.fromArray(SPECIES, mt, 0); > > for (int ic = 0; ic < INVOC_COUNT; ic++) { > for (int i = 0; i < ma.length; i += SPECIES.length()) { > var av = SPECIES.loadMask(ma, i); > var bv = SPECIES.loadMask(mb, i); > > // accumulate results, so JIT can't eliminate relevant computations > m = m.and(av.eq(bv)); > } > } > > return m; > } Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'jdk:master' into JDK-8267969 - 8267969: Add vectorized implementation for VectorMask.eq() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4272/files - new: https://git.openjdk.java.net/jdk/pull/4272/files/0e8e0e84..f3a48026 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4272&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4272&range=00-01 Stats: 22530 lines in 577 files changed: 2836 ins; 18744 del; 950 mod Patch: https://git.openjdk.java.net/jdk/pull/4272.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4272/head:pull/4272 PR: https://git.openjdk.java.net/jdk/pull/4272 From yyang at openjdk.java.net Wed Jun 2 02:19:56 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 2 Jun 2021 02:19:56 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v10] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - x86_32 fails - build failed - cmp clobbers its left argument on x86_32 - better check1-4 - AssertionError when expected exception was not thrown - remove extra newline - remove InlineNIOCheckIndex flag - remove java_nio_Buffer in javaClasses.hpp - consolidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/3615/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=09 Stats: 338 lines in 11 files changed: 242 ins; 78 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Wed Jun 2 02:32:54 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 2 Jun 2021 02:32:54 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v11] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - x86_32 fails - build failed - cmp clobbers its left argument on x86_32 - better check1-4 - AssertionError when expected exception was not thrown - remove InlineNIOCheckIndex flag - remove java_nio_Buffer in javaClasses.hpp - consolidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/3615/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=10 Stats: 338 lines in 11 files changed: 242 ins; 78 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From joehw at openjdk.java.net Wed Jun 2 05:00:34 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 2 Jun 2021 05:00:34 GMT Subject: Integrated: 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type In-Reply-To: References: Message-ID: On Sat, 29 May 2021 00:12:09 GMT, Joe Wang wrote: > Makes a correction to XPathEvaluationResult.XPathResultType.NODESET mapping. Clarifies the supported types for the evaluateExpression methods. > > Other changes were javadoc tag usages, e.g. s/the code tag/{@code This pull request has now been integrated. Changeset: 7530c00b Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/7530c00b33aac8918841dbae4d928956b60c261f Stats: 77 lines in 4 files changed: 28 ins; 0 del; 49 mod 8266559: XPathEvaluationResult.XPathResultType.NODESET maps to incorrect type Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4258 From peter.levart at gmail.com Wed Jun 2 05:06:47 2021 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 2 Jun 2021 07:06:47 +0200 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <4EECBA96-3765-44D8-A5D0-A9BC78EDA127@oracle.com> References: <75639690-4343-cbd7-7ac0-179bf507ad7d@oracle.com> <4EECBA96-3765-44D8-A5D0-A9BC78EDA127@oracle.com> Message-ID: <63ad4ad2-2e87-6140-ec1f-81f332b040b2@gmail.com> On 01/06/2021 22:28, John Rose wrote: > On Jun 1, 2021, at 7:02 AM, Brian Goetz > wrote: > > As Alan's archaeology discovered, this flag appears to be a leftover from the original implementation, and I could find no signs of its usage. > > Note to self and other reviewers of future versions > of the JVMS: When you see proposed language like > the ?unless?? of JVMS 4.7.17, remember today's > conversation and try to avoid putting dark corners > like that into the JVMS. > > The RuntimeInvisibleAnnotations attribute is similar to the RuntimeVisibleAnnotations attribute (?4.7.16), except that the annotations represented by a RuntimeInvisibleAnnotations attribute must not be made available for return by reflective APIs, [[WE SHOULD HAVE STOPPED HERE]] unless the Java Virtual Machine has been instructed to retain these annotations via some implementation-specific mechanism such as a command line flag. In the absence of such instructions, the Java Virtual Machine ignores this attribute. > https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-4.html#jvms-4.7.17 Hi, I do think this option, in current form, is useful as an escape hatch for exactly the case that Jaroslav has. Java/JVM as a late-binding runtime does a very good job of keeping the information from source files local in direct compilation artefacts which facilitates separate compilation where changes to and recompilation of one source file have immediate effect on the whole app. There are exceptions to the rule such as compile-time constants, ... and also annotation uses where the information from one source file (annotation retention) is baked into compilation artefacts of other source files (RuntimeVisibleAnnotations vs. RuntimeInvisibleAnnotations). PreserveAllAnnotations option helps to overcome the situation where the annotation has been updated but classes where such annotation is used have not been recompiled (yet). I see the two class file attributes merely as a runtime optimization while both kinds of annotations could be kept in a single attribute. The JVM option just disables this optimization. So I would still keep the option. Regards, Peter From github.com+26887752+jaroslavtulach at openjdk.java.net Wed Jun 2 05:47:32 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Wed, 2 Jun 2021 05:47:32 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. Right Peter, the `AnnotationTypeChangedToRuntimeTest` mimics closely the use-case: > JVM as a late-binding runtime ... There are exceptions to the rule such as compile-time constants, ... and also annotation uses where the information from one source file (annotation retention) is baked into compilation artifacts of other source files (`RuntimeVisibleAnnotations` vs. `RuntimeInvisibleAnnotations`). `PreserveAllAnnotations` option helps to overcome the situation Great formulation of the problem. The late binding allows people to ignore time of compilation when thinking about the running system. Ignoring time makes the mental model of the overall system easier. But when certain information is _baked_ elsewhere, ignoring time is may no longer be possible as the sequence of actions becomes important - an up to date system may see relics of the past (old values of compile-time constants and annotation not being visible even their most recent retention is `RUNTIME`). This PR isn't going to modify behavior of the `-XX:+PreserveAllAnnotations` option in any way. It only provides a test. Having a test is better than having none. Can we consider this PR reviewed? Can somebody with enough merit mark this _change as properly reviewed_? Can somebody restart the _Windows aarch64 - Build_ - the error seems unrelated? ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From david.holmes at oracle.com Wed Jun 2 05:56:55 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Jun 2021 15:56:55 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: <79372ef7-0027-1e7c-326b-a696d026152d@oracle.com> On 2/06/2021 3:47 pm, Jaroslav Tulach wrote: > On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > >> There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. > > Right Peter, the `AnnotationTypeChangedToRuntimeTest` mimics closely the use-case: > >> JVM as a late-binding runtime ... There are exceptions to the rule such > as compile-time constants, ... and also annotation uses where the > information from one source file (annotation retention) is baked into > compilation artifacts of other source files (`RuntimeVisibleAnnotations` > vs. `RuntimeInvisibleAnnotations`). `PreserveAllAnnotations` option helps to > overcome the situation > > Great formulation of the problem. The late binding allows people to ignore time of compilation when thinking about the running system. Ignoring time makes the mental model of the overall system easier. But when certain information is _baked_ elsewhere, ignoring time is may no longer be possible as the sequence of actions becomes important - an up to date system may see relics of the past (old values of compile-time constants and annotation not being visible even their most recent retention is `RUNTIME`). > > This PR isn't going to modify behavior of the `-XX:+PreserveAllAnnotations` option in any way. It only provides a test. Having a test is better than having none. Can we consider this PR reviewed? Can somebody with enough merit mark this _change as properly reviewed_? Can somebody restart the _Windows aarch64 - Build_ - the error seems unrelated? Sorry Jaroslav but I don't really see this test as a basic functional test of the PreserveAllAnnotations flag. There is no need for any dynamic retention mode switch. All you need as I've said previously is a class with all the CLASS retention annotations of interest (8 IIRC) applied and a programs that reads them, and either expects to find them or not, based on the PreserveAllAnnotations flag. I get that you are just trying to not waste a test you already developed. The Windows build issue seems to be a software configuration issue on the Github machines and is outside of our control. I've no idea how to report issues to the Github folk. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4280 > From jjg at openjdk.java.net Wed Jun 2 06:34:42 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 06:34:42 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: <-4FukAOuIanR8Mkpn_I0FtYVUHzeaog6VOQFp63wkZs=.3065f5e6-4d50-45c3-8a2c-30b4ddb75e29@github.com> On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov wrote: >> 8267706: bin/idea.sh tries to use cygpath on WSL > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > 8267706: Break long line in make/ide/idea/jdk/idea.gmk The fix was supposed to be just about disentangling cygwin and WSL on Windows ... not to "improve project setup on all platforms" ... and break project setup on macOS as a result. If nothing else, if you're changing the set of required dependencies, this needs to be documented. And installing `coreutils` seems to bring in a whole lot of unnecessary stuff. ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From Alan.Bateman at oracle.com Wed Jun 2 07:18:22 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jun 2021 08:18:22 +0100 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <4EECBA96-3765-44D8-A5D0-A9BC78EDA127@oracle.com> References: <75639690-4343-cbd7-7ac0-179bf507ad7d@oracle.com> <4EECBA96-3765-44D8-A5D0-A9BC78EDA127@oracle.com> Message-ID: On 01/06/2021 21:28, John Rose wrote: > : > > Note to self and other reviewers of future versions > of the JVMS: When you see proposed language like > the ?unless?? of JVMS 4.7.17, remember today's > conversation and try to avoid putting dark corners > like that into the JVMS. > > The RuntimeInvisibleAnnotations attribute is similar to the RuntimeVisibleAnnotations attribute (?4.7.16), except that the annotations represented by a RuntimeInvisibleAnnotations attribute must not be made available for return by reflective APIs, [[WE SHOULD HAVE STOPPED HERE]] unless the Java Virtual Machine has been instructed to retain these annotations via some implementation-specific mechanism such as a command line flag. In the absence of such instructions, the Java Virtual Machine ignores this attribute. > https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-4.html#jvms-4.7.17 > Maybe the "unless ..." could be dropped from the JVMS in some future release. The XX option could be deprecated now so that it won't be a surprise when it becomes obsolete. On the other hand, maybe it's not worth doing anything as there are more important things to work on. -Alan From forax at openjdk.java.net Wed Jun 2 07:38:27 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 2 Jun 2021 07:38:27 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: On Wed, 2 Jun 2021 00:39:25 GMT, Stuart Marks wrote: > I'm fixing this along with a couple intertwined issues. > > 1. Add Map.Entry::copyOf as an idempotent copy operation. > > 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not really immutable) but that subclasses can be modifiable. > > 3. Clarify some confusing, historical wording about Map.Entry instances being obtainable only via iteration of a Map's entry-set view. This was never really true, since anyone could implement the Map.Entry interface, and it certainly was not true since JDK 1.6 when SimpleEntry and SimpleImmutableEntry were added. LGTM, i wonder if we should not declare SimpleImmutableEntry final, while it's not a backward compatible change, it's may be better on the long term because SimpleImmutableEntry is already used as an immutable type, so instead of documenting the fact that SimpleImmutableEntry is not declared final thus SimpleImmutableEntry as a type does not guarantte shallow immutability, it may be better to fix the root cause. ------------- PR: https://git.openjdk.java.net/jdk/pull/4295 From github.com+9004656+yaaz at openjdk.java.net Wed Jun 2 07:39:37 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Wed, 2 Jun 2021 07:39:37 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: <-4FukAOuIanR8Mkpn_I0FtYVUHzeaog6VOQFp63wkZs=.3065f5e6-4d50-45c3-8a2c-30b4ddb75e29@github.com> References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> <-4FukAOuIanR8Mkpn_I0FtYVUHzeaog6VOQFp63wkZs=.3065f5e6-4d50-45c3-8a2c-30b4ddb75e29@github.com> Message-ID: On Wed, 2 Jun 2021 06:30:11 GMT, Jonathan Gibbons wrote: >> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8267706: Break long line in make/ide/idea/jdk/idea.gmk > > The fix was supposed to be just about disentangling cygwin and WSL on Windows ... not to "improve project setup on all platforms" ... and break project setup on macOS as a result. If nothing else, if you're changing the set of required dependencies, this needs to be documented. And installing `coreutils` seems to bring in a whole lot of unnecessary stuff. @jonathan-gibbons my bad, I should have created another PR for this Regarding documenting changes in dependencies: AFAIK, IDEA project setup is not documented anywhere (at least "IDE support for Java code" section at https://github.com/openjdk/jdk/blob/master/doc/ide.md is WIP). Earlier `idea.sh` required Ant and you wouldn't know about it until it fails at the end of the script :) So could you please clarify, what do you mean by that? ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From neliasso at openjdk.java.net Wed Jun 2 07:53:42 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 2 Jun 2021 07:53:42 GMT Subject: RFR: 8267969: Add vectorized implementation for VectorMask.eq() [v2] In-Reply-To: <6zmaxCZzzCbYEptpG91NJBAu7REALkAWx3KyVpbChU0=.f4b5b1d7-17f3-4d98-8412-1beb4262c7b2@github.com> References: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> <6zmaxCZzzCbYEptpG91NJBAu7REALkAWx3KyVpbChU0=.f4b5b1d7-17f3-4d98-8412-1beb4262c7b2@github.com> Message-ID: On Wed, 2 Jun 2021 01:56:00 GMT, Xiaohong Gong wrote: >> Currently `"VectorMask.eq()" `is not vectorized: >> >> public VectorMask eq(VectorMask m) { >> // FIXME: Generate good code here. >> return bOp(m, (i, a, b) -> a == b); >> } >> >> This can be implemented by calling `"xor(m.not())"` directly. >> >> The performance improved about 1.4x ~ 1.9x for the following benchmark with different basic types: >> >> @Benchmark >> public Object eq() { >> boolean[] ma = fm.apply(size); >> boolean[] mb = fmb.apply(size); >> boolean[] mt = fmt.apply(size); >> VectorMask m = VectorMask.fromArray(SPECIES, mt, 0); >> >> for (int ic = 0; ic < INVOC_COUNT; ic++) { >> for (int i = 0; i < ma.length; i += SPECIES.length()) { >> var av = SPECIES.loadMask(ma, i); >> var bv = SPECIES.loadMask(mb, i); >> >> // accumulate results, so JIT can't eliminate relevant computations >> m = m.and(av.eq(bv)); >> } >> } >> >> return m; >> } > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'jdk:master' into JDK-8267969 > - 8267969: Add vectorized implementation for VectorMask.eq() Looks good. Please wait until you have two reviewers before integrating. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4272 From xgong at openjdk.java.net Wed Jun 2 07:53:43 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 2 Jun 2021 07:53:43 GMT Subject: Integrated: 8267969: Add vectorized implementation for VectorMask.eq() In-Reply-To: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> References: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> Message-ID: On Mon, 31 May 2021 10:25:26 GMT, Xiaohong Gong wrote: > Currently `"VectorMask.eq()" `is not vectorized: > > public VectorMask eq(VectorMask m) { > // FIXME: Generate good code here. > return bOp(m, (i, a, b) -> a == b); > } > > This can be implemented by calling `"xor(m.not())"` directly. > > The performance improved about 1.4x ~ 1.9x for the following benchmark with different basic types: > > @Benchmark > public Object eq() { > boolean[] ma = fm.apply(size); > boolean[] mb = fmb.apply(size); > boolean[] mt = fmt.apply(size); > VectorMask m = VectorMask.fromArray(SPECIES, mt, 0); > > for (int ic = 0; ic < INVOC_COUNT; ic++) { > for (int i = 0; i < ma.length; i += SPECIES.length()) { > var av = SPECIES.loadMask(ma, i); > var bv = SPECIES.loadMask(mb, i); > > // accumulate results, so JIT can't eliminate relevant computations > m = m.and(av.eq(bv)); > } > } > > return m; > } This pull request has now been integrated. Changeset: 496fb90b Author: Xiaohong Gong Committer: Nils Eliasson URL: https://git.openjdk.java.net/jdk/commit/496fb90b3a038f5fe76acc8a98bcd0dac4071cf9 Stats: 254 lines in 32 files changed: 248 ins; 6 del; 0 mod 8267969: Add vectorized implementation for VectorMask.eq() Reviewed-by: psandoz, neliasso ------------- PR: https://git.openjdk.java.net/jdk/pull/4272 From plevart at openjdk.java.net Wed Jun 2 10:33:30 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 10:33:30 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java line 57: > 55: @AnnB > 56: public @interface AnnA_v2 { > 57: } You meant to write: "An alternative version of AnnA_v1 with RUNTIME retention instead", right? ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From plevart at openjdk.java.net Wed Jun 2 10:40:31 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 10:40:31 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java line 81: > 79: " should not be visible at runtime"); > 80: } > 81: } I'm trying to understand why the case of `TestTask.class.getDeclaredAnnotation(AnnA_v1.class)` is different from `AnnB.class.getDeclaredAnnotation(AnnA_v1.class)` ... `TestTask` and `AnnB` are both just types annotated with the same annotation `@AnnA_v1` ... I'll have to debug this to see the point (does it have something to do with the fact that there is circularity of annotation uses: `AnnA_v1` is annotated with `@AnnB` while `AnnB` is annotated with `@AnnA_v1` ? test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java line 102: > 100: */ > 101: static class AltClassLoader extends ClassLoader { > 102: AltClassLoader(ClassLoader parent) { I can't escape the feeling that I already saw this code somewhere. Hm... ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From plevart at openjdk.java.net Wed Jun 2 10:45:30 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 10:45:30 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java line 42: > 40: * {@link RetentionPolicy#CLASS CLASS} retention was changed into > 41: * {@link RetentionPolicy#RUNTIME RUNTIME} and we want to read > 42: * its value during runtime with the help of I would insert the phrase ", but the classes that use the annotation have not been recompiled" after the `RUNTIME`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From mcimadamore at openjdk.java.net Wed Jun 2 10:55:38 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 10:55:38 GMT Subject: Integrated: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 This pull request has now been integrated. Changeset: a223189b Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab Stats: 14500 lines in 219 files changed: 8847 ins; 3642 del; 2011 mod 8264774: Implementation of Foreign Function and Memory API (Incubator) Co-authored-by: Paul Sandoz Co-authored-by: Jorn Vernee Co-authored-by: Vladimir Ivanov Co-authored-by: Athijegannathan Sundararajan Co-authored-by: Chris Hegarty Reviewed-by: psandoz, chegar, mchung, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From plevart at openjdk.java.net Wed Jun 2 11:37:28 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 11:37:28 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: <2t7mhUTeQ4g8yJ8f2vIzGOMCUlm2USBx4EZgJf6PCPI=.3b095d41-29a6-417b-b7c1-945cef40c4fd@github.com> On Wed, 2 Jun 2021 10:36:06 GMT, Peter Levart wrote: >> There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. > > test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java line 81: > >> 79: " should not be visible at runtime"); >> 80: } >> 81: } > > I'm trying to understand why the case of `TestTask.class.getDeclaredAnnotation(AnnA_v1.class)` is different from `AnnB.class.getDeclaredAnnotation(AnnA_v1.class)` ... `TestTask` and `AnnB` are both just types annotated with the same annotation `@AnnA_v1` ... I'll have to debug this to see the point (does it have something to do with the fact that there is circularity of annotation uses: `AnnA_v1` is annotated with `@AnnB` while `AnnB` is annotated with `@AnnA_v1` ? ...hm, it seems that mere presence of any RUNTIME annotation that was RUNTIME already at the use compile time somehow affects -XX:+PreserveAllAnnotations option so that now RUNTIME annotations that were CLASS annotations at use compile time are not returned. Checking VM logic... ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From plevart at openjdk.java.net Wed Jun 2 11:43:27 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 11:43:27 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <2t7mhUTeQ4g8yJ8f2vIzGOMCUlm2USBx4EZgJf6PCPI=.3b095d41-29a6-417b-b7c1-945cef40c4fd@github.com> References: <2t7mhUTeQ4g8yJ8f2vIzGOMCUlm2USBx4EZgJf6PCPI=.3b095d41-29a6-417b-b7c1-945cef40c4fd@github.com> Message-ID: <0TLqQYzwaom2hTQAUuQjHoZcHIB_tCxk3NF3Cnehe1o=.085de794-e4e2-4c6c-820a-4d45ff321eac@github.com> On Wed, 2 Jun 2021 11:34:18 GMT, Peter Levart wrote: >> test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeChangedToRuntimeTest.java line 81: >> >>> 79: " should not be visible at runtime"); >>> 80: } >>> 81: } >> >> I'm trying to understand why the case of `TestTask.class.getDeclaredAnnotation(AnnA_v1.class)` is different from `AnnB.class.getDeclaredAnnotation(AnnA_v1.class)` ... `TestTask` and `AnnB` are both just types annotated with the same annotation `@AnnA_v1` ... I'll have to debug this to see the point (does it have something to do with the fact that there is circularity of annotation uses: `AnnA_v1` is annotated with `@AnnB` while `AnnB` is annotated with `@AnnA_v1` ? > > ...hm, it seems that mere presence of any RUNTIME annotation that was RUNTIME already at the use compile time somehow affects -XX:+PreserveAllAnnotations option so that now RUNTIME annotations that were CLASS annotations at use compile time are not returned. Checking VM logic... For example, if I try this: @Retention(CLASS) public @interface AnnA_v1 {} // An alternative version of AnnA_v1 with RUNTIME retention instead. // Used to simulate separate compilation (see AltClassLoader below). @Retention(RUNTIME) public @interface AnnA_v2 {} @Retention(RUNTIME) public @interface AnnB {} @AnnA_v1 @AnnB public static class TestTask implements Runnable { @Override public void run() { AnnA_v1 ann1 = TestTask.class.getDeclaredAnnotation(AnnA_v1.class); ... then `ann1` is not returned, but if I comment out the `@AnnB` annotation use on TestTask, `ann1` is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From weijun at openjdk.java.net Wed Jun 2 12:01:30 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 12:01:30 GMT Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v9] In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - copyright years - merge from master, resolve one conflict - Merge branch 'master' - merge from master - rename setSecurityManagerDirect to implSetSecurityManager - default behavior reverted to allow - move one annotation to new method - merge from master, two files removed, one needs merge - keep only one systemProperty tag - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java - ... and 4 more: https://git.openjdk.java.net/jdk/compare/19450b99...331389b5 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4073/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=08 Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod Patch: https://git.openjdk.java.net/jdk/pull/4073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073 PR: https://git.openjdk.java.net/jdk/pull/4073 From weijun at openjdk.java.net Wed Jun 2 12:01:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 12:01:33 GMT Subject: Integrated: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com> Message-ID: On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update. > 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically. > 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev. > > Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071. > > Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing. This pull request has now been integrated. Changeset: 6765f902 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1 Stats: 2755 lines in 826 files changed: 1997 ins; 20 del; 738 mod 8266459: Implement JEP 411: Deprecate the Security Manager for Removal Co-authored-by: Sean Mullan Co-authored-by: Lance Andersen Co-authored-by: Weijun Wang Reviewed-by: erikj, darcy, chegar, naoto, joehw, alanb, mchung, kcr, prr, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/4073 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Wed Jun 2 12:02:38 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Wed, 2 Jun 2021 12:02:38 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v3] In-Reply-To: References: Message-ID: On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote: >> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. >> >> The code change shows some common solutions to avoid such too wide annotations: >> >> 1. Extract calls into a method and add annotation on that method >> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. >> 3. Put declaration and assignment into a single statement if possible. >> 4. Rewrite code to achieve #3 above. >> >> I'll add a copyright year update commit before integration. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > update FtpClient.java The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout 8266459 git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 12:07:35 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 12:07:35 GMT Subject: Withdrawn: 8263561: Re-examine uses of LinkedList In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? wrote: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From plevart at openjdk.java.net Wed Jun 2 12:17:30 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 12:17:30 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <0TLqQYzwaom2hTQAUuQjHoZcHIB_tCxk3NF3Cnehe1o=.085de794-e4e2-4c6c-820a-4d45ff321eac@github.com> References: <2t7mhUTeQ4g8yJ8f2vIzGOMCUlm2USBx4EZgJf6PCPI=.3b095d41-29a6-417b-b7c1-945cef40c4fd@github.com> <0TLqQYzwaom2hTQAUuQjHoZcHIB_tCxk3NF3Cnehe1o=.085de794-e4e2-4c6c-820a-4d45ff321eac@github.com> Message-ID: On Wed, 2 Jun 2021 11:40:13 GMT, Peter Levart wrote: >> ...hm, it seems that mere presence of any RUNTIME annotation that was RUNTIME already at the use compile time somehow affects -XX:+PreserveAllAnnotations option so that now RUNTIME annotations that were CLASS annotations at use compile time are not returned. Checking VM logic... > > For example, if I try this: > > @Retention(CLASS) > public @interface AnnA_v1 {} > > // An alternative version of AnnA_v1 with RUNTIME retention instead. > // Used to simulate separate compilation (see AltClassLoader below). > @Retention(RUNTIME) > public @interface AnnA_v2 {} > > @Retention(RUNTIME) > public @interface AnnB {} > > @AnnA_v1 > @AnnB > public static class TestTask implements Runnable { > @Override > public void run() { > AnnA_v1 ann1 = TestTask.class.getDeclaredAnnotation(AnnA_v1.class); > > ... then `ann1` is not returned, but if I comment out the `@AnnB` annotation use on TestTask, `ann1` is returned. I think we found a bug here. After all, this endeavor was not in vain. The bug is in AnnotationParser: https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java#L111 You see, the parser reads a 16bit integer from the start of `rawAnnotations` and interprets it as the number of annotations to parse. But OTOH, `rawAnnotations` may in case when `-XX:+PreserveAllAnnotations` was used, contain two concatenated sets of encoded annotations, each starting with its own count of annotations. See how this concatenation is performed here: https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/hotspot/share/classfile/classFileParser.cpp#L3965 The concatenation is simply joining the arrays of u1 elements into a concatenated array. So when both RuntimeVisibleAnnotations and RuntimeInvisibleAnnotations are present (in case -XX:+PreserveAllAnnotations was used), the concatenated array starts with RuntimeVisibleAnnotations followed by RuntimeInvisibleAnnotations. AnnotationParser should not stop parsing when the 1st loop is finished and the rawAnnotations is not exhausted yet. It should continue with the 2nd round of parsing. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 12:18:42 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 12:18:42 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList Message-ID: After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. ------------- Commit messages: - Merge branch 'master' into 8263561 - Merge branch 'master' into purge-linked-list - 8263561: Use sized constructor where reasonable - 8263561: Use interface List instead of particular type where possible - 8263561: Rename requestList -> requests - 8263561: Re-examine uses of LinkedList Changes: https://git.openjdk.java.net/jdk/pull/4304/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263561 Stats: 48 lines in 9 files changed: 0 ins; 2 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/4304.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304 PR: https://git.openjdk.java.net/jdk/pull/4304 From plevart at openjdk.java.net Wed Jun 2 12:36:27 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 12:36:27 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. I suggest the following patch for the bug in AnnotationParser: Index: src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java b/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java (revision b4371e9bcaa1c8aa394b5eca409c5afc669cc146) +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java (date 1622636986705) @@ -116,6 +116,7 @@ Map, Annotation> result = new LinkedHashMap, Annotation>(); ByteBuffer buf = ByteBuffer.wrap(rawAnnotations); + for (int round = 0; round < 2 && buf.hasRemaining(); round++) { int numAnnotations = buf.getShort() & 0xFFFF; for (int i = 0; i < numAnnotations; i++) { Annotation a = parseAnnotation2(buf, constPool, container, false, selectAnnotationClasses); @@ -128,6 +129,7 @@ } } } + } return result; } ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From plevart at openjdk.java.net Wed Jun 2 12:46:27 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 12:46:27 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 12:33:37 GMT, Peter Levart wrote: > I suggest the following patch for the bug in AnnotationParser: > An alternative would be to change the `ClassFileParser::assemble_annotations` in the VM to no be so "dumb", but to construct correct concatenation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From david.holmes at oracle.com Wed Jun 2 12:47:57 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Jun 2021 22:47:57 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: <2t7mhUTeQ4g8yJ8f2vIzGOMCUlm2USBx4EZgJf6PCPI=.3b095d41-29a6-417b-b7c1-945cef40c4fd@github.com> <0TLqQYzwaom2hTQAUuQjHoZcHIB_tCxk3NF3Cnehe1o=.085de794-e4e2-4c6c-820a-4d45ff321eac@github.com> Message-ID: On 2/06/2021 10:17 pm, Peter Levart wrote: > On Wed, 2 Jun 2021 11:40:13 GMT, Peter Levart wrote: > >>> ...hm, it seems that mere presence of any RUNTIME annotation that was RUNTIME already at the use compile time somehow affects -XX:+PreserveAllAnnotations option so that now RUNTIME annotations that were CLASS annotations at use compile time are not returned. Checking VM logic... >> >> For example, if I try this: >> >> @Retention(CLASS) >> public @interface AnnA_v1 {} >> >> // An alternative version of AnnA_v1 with RUNTIME retention instead. >> // Used to simulate separate compilation (see AltClassLoader below). >> @Retention(RUNTIME) >> public @interface AnnA_v2 {} >> >> @Retention(RUNTIME) >> public @interface AnnB {} >> >> @AnnA_v1 >> @AnnB >> public static class TestTask implements Runnable { >> @Override >> public void run() { >> AnnA_v1 ann1 = TestTask.class.getDeclaredAnnotation(AnnA_v1.class); >> >> ... then `ann1` is not returned, but if I comment out the `@AnnB` annotation use on TestTask, `ann1` is returned. > > I think we found a bug here. After all, this endeavor was not in vain. The bug is in AnnotationParser: > https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java#L111 > > You see, the parser reads a 16bit integer from the start of `rawAnnotations` and interprets it as the number of annotations to parse. But OTOH, `rawAnnotations` may in case when `-XX:+PreserveAllAnnotations` was used, contain two concatenated sets of encoded annotations, each starting with its own count of annotations. See how this concatenation is performed here: > https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/hotspot/share/classfile/classFileParser.cpp#L3965 Two arrays are combined into one array and that is returned. What do you mean by "each starting with its own count" ?? Where is the code that shoves the apparent length into the start of the rawAnnotations byte[] ? Thanks, David ----- > The concatenation is simply joining the arrays of u1 elements into a concatenated array. So when both RuntimeVisibleAnnotations and RuntimeInvisibleAnnotations are present (in case -XX:+PreserveAllAnnotations was used), the concatenated array starts with RuntimeVisibleAnnotations followed by RuntimeInvisibleAnnotations. > > AnnotationParser should not stop parsing when the 1st loop is finished and the rawAnnotations is not exhausted yet. It should continue with the 2nd round of parsing. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4280 > From brian.goetz at oracle.com Wed Jun 2 12:57:49 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 2 Jun 2021 08:57:49 -0400 Subject: RFR: 8265130: Make ConstantDesc class hierarchy sealed [v2] In-Reply-To: <5XPJ9shB0AbhV4Jh7PkxS8JTyChaOckwSFV48ajvITc=.941c7963-7e82-4881-a2f2-c91645bbcbe4@github.com> References: <5XPJ9shB0AbhV4Jh7PkxS8JTyChaOckwSFV48ajvITc=.941c7963-7e82-4881-a2f2-c91645bbcbe4@github.com> Message-ID: The motivation here is that we wanted to preserve the ability to describe "special" indy sites with special objects.? The standard implementation can describe any indy site (bootstrap, static args, invocation name and type), but some indy sites (e.g., lambda capture) are "special".? It would be reasonable for a classfile parser to "uplevel" such sites, so that (a) parsers could provide implementations that interpret the semantics of the bootstrap argument list relative to the known bootstrap method, and (b) so that class generators (including compilers) could provide higher-level descriptions of the indy.? This allows us to abstract away from the details of compiler translation, by "unlowering" translation-by-indy for known bootstraps. On 5/20/2021 7:43 PM, Mandy Chung wrote: > On Thu, 20 May 2021 22:35:38 GMT, Thiago Henrique H?pner wrote: > >>> I should have made it clear. I was expecting `DynamicConstantDesc` should be `sealed`. Do you expect non-JDK implementation class extending `DynamicConstantDesc`? >> From the ConstantDesc Javadoc: >> >> *

Non-platform classes should not implement {@linkplain ConstantDesc} directly. >> * Instead, they should extend {@link DynamicConstantDesc} (as {@link EnumDesc} >> * and {@link VarHandleDesc} do.) > Thanks. I missed this javadoc. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4135 From david.holmes at oracle.com Wed Jun 2 13:22:41 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Jun 2021 23:22:41 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: <2t7mhUTeQ4g8yJ8f2vIzGOMCUlm2USBx4EZgJf6PCPI=.3b095d41-29a6-417b-b7c1-945cef40c4fd@github.com> <0TLqQYzwaom2hTQAUuQjHoZcHIB_tCxk3NF3Cnehe1o=.085de794-e4e2-4c6c-820a-4d45ff321eac@github.com> Message-ID: <2297c0f1-f22a-ad1f-c145-b3222b51ac57@oracle.com> Never mind ... On 2/06/2021 10:47 pm, David Holmes wrote: > On 2/06/2021 10:17 pm, Peter Levart wrote: >> On Wed, 2 Jun 2021 11:40:13 GMT, Peter Levart >> wrote: >> >>>> ...hm, it seems that mere presence of any RUNTIME annotation that >>>> was RUNTIME already at the use compile time somehow affects >>>> -XX:+PreserveAllAnnotations option so that now RUNTIME annotations >>>> that were CLASS annotations at use compile time are not returned. >>>> Checking VM logic... >>> >>> For example, if I try this: >>> >>> ???? @Retention(CLASS) >>> ???? public @interface AnnA_v1 {} >>> >>> ???? // An alternative version of AnnA_v1 with RUNTIME retention >>> instead. >>> ???? // Used to simulate separate compilation (see AltClassLoader >>> below). >>> ???? @Retention(RUNTIME) >>> ???? public @interface AnnA_v2 {} >>> >>> ???? @Retention(RUNTIME) >>> ???? public @interface AnnB {} >>> >>> ???? @AnnA_v1 >>> ???? @AnnB >>> ???? public static class TestTask implements Runnable { >>> ???????? @Override >>> ???????? public void run() { >>> ???????????? AnnA_v1 ann1 = >>> TestTask.class.getDeclaredAnnotation(AnnA_v1.class); >>> >>> ... then `ann1` is not returned, but if I comment out the `@AnnB` >>> annotation use on TestTask, `ann1` is returned. >> >> I think we found a bug here. After all, this endeavor was not in vain. >> The bug is in AnnotationParser: >> https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java#L111 >> >> >> You see, the parser reads a 16bit integer from the start of >> `rawAnnotations` and interprets it as the number of annotations to >> parse. But OTOH, `rawAnnotations` may in case when >> `-XX:+PreserveAllAnnotations` was used, contain two concatenated sets >> of encoded annotations, each starting with its own count of >> annotations. See how this concatenation is performed here: >> https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/hotspot/share/classfile/classFileParser.cpp#L3965 >> > > Two arrays are combined into one array and that is returned. What do you > mean by "each starting with its own count" ?? Where is the code that > shoves the apparent length into the start of the rawAnnotations byte[] ? Sorry now I see what happens. We aren't combining two arrays of annotations we're concatenating two streams of byes, each of which represents a set of annotations, starting with the length. The code that receives this on the JDK side doesn't seem to understand that this is a possibility. Though maybe this isn't a bug, maybe the AnnotationParser is deliberately ignoring the second byte stream. (Though if it were deliberate there should be some commentary to that affect!) David > Thanks, > David > ----- > >> The concatenation is simply joining the arrays of u1 elements into a >> concatenated array. So when both RuntimeVisibleAnnotations and >> RuntimeInvisibleAnnotations are present (in case >> -XX:+PreserveAllAnnotations was used), the concatenated array starts >> with RuntimeVisibleAnnotations followed by RuntimeInvisibleAnnotations. >> >> AnnotationParser should not stop parsing when the 1st loop is finished >> and the rawAnnotations is not exhausted yet. It should continue with >> the 2nd round of parsing. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/4280 >> From erikj at openjdk.java.net Wed Jun 2 13:26:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 13:26:34 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov wrote: >> 8267706: bin/idea.sh tries to use cygpath on WSL > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > 8267706: Break long line in make/ide/idea/jdk/idea.gmk We do not require brew to install packages on mac, the build doc references brew as an easy way to get autoconf. I personally have always built autoconf from source instead (as it's a very simple build that takes a few seconds at most). I agree that adding a new dependency on the build is troublesome. We generally try really hard to avoid depending on tools that aren't default available on all the main build environments. I didn't check this review very closely for such things. I also did say that I wanted people who actually use this script to weigh in, which I didn't see happen before it was integrated. Looking at the patch again, the first realpath use can easily be worked around by generating the relative path to SPEC_DIR from idea.gmk. In make we have a macro to generate relative paths, see RelativePath in common/Utils.gmk. The second realpath is operating on moduleSrcDirs, also generated in idea.gmk. The same thing can be applied here, the RelativePath macro together with a foreach can be used to export the src dirs as relative paths. In general, I think we would have been much better off if this script was just written in make from the start, as we have more platform independent tools available there already. Rewriting it isn't trivial though, and requires quite a bit of knowledge both of GNU make as well as our macros, so I'm not asking for this to happen. I do think we should eliminate the use of realpath though. ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From jvernee at openjdk.java.net Wed Jun 2 13:45:33 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 13:45:33 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. > > [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms The JEP has been integrated, so we can pick this back up (and handle it as a bug for 17 even after the fork). Thank you for your patience. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From alanb at openjdk.java.net Wed Jun 2 13:47:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Jun 2021 13:47:29 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: On Wed, 2 Jun 2021 00:39:25 GMT, Stuart Marks wrote: > I'm fixing this along with a couple intertwined issues. > > 1. Add Map.Entry::copyOf as an idempotent copy operation. > > 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not really immutable) but that subclasses can be modifiable. > > 3. Clarify some confusing, historical wording about Map.Entry instances being obtainable only via iteration of a Map's entry-set view. This was never really true, since anyone could implement the Map.Entry interface, and it certainly was not true since JDK 1.6 when SimpleEntry and SimpleImmutableEntry were added. I read through the javadoc and API notes and it all looks reasonable. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4295 From github.com+9004656+yaaz at openjdk.java.net Wed Jun 2 13:50:36 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Wed, 2 Jun 2021 13:50:36 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: <90yrVyEpxqCqqYoqXmmPA3KZwIpCirYqeN7llEV3ED4=.8e886557-935c-41ef-8f92-84ef0270ab5b@github.com> On Wed, 2 Jun 2021 13:24:00 GMT, Erik Joelsson wrote: >> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8267706: Break long line in make/ide/idea/jdk/idea.gmk > > We do not require brew to install packages on mac, the build doc references brew as an easy way to get autoconf. I personally have always built autoconf from source instead (as it's a very simple build that takes a few seconds at most). I agree that adding a new dependency on the build is troublesome. We generally try really hard to avoid depending on tools that aren't default available on all the main build environments. I didn't check this review very closely for such things. I also did say that I wanted people who actually use this script to weigh in, which I didn't see happen before it was integrated. > > Looking at the patch again, the first realpath use can easily be worked around by generating the relative path to SPEC_DIR from idea.gmk. In make we have a macro to generate relative paths, see RelativePath in common/Utils.gmk. The second realpath is operating on moduleSrcDirs, also generated in idea.gmk. The same thing can be applied here, the RelativePath macro together with a foreach can be used to export the src dirs as relative paths. > > In general, I think we would have been much better off if this script was just written in make from the start, as we have more platform independent tools available there already. Rewriting it isn't trivial though, and requires quite a bit of knowledge both of GNU make as well as our macros, so I'm not asking for this to happen. I do think we should eliminate the use of realpath though. @erikj79 thank you for the hint about `RelativePath` macro, I will rewrite this logic and get rid of `realpath`. Can I reference the same issue in new PR, or do I need a new one? ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From herrick at openjdk.java.net Wed Jun 2 13:57:40 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Wed, 2 Jun 2021 13:57:40 GMT Subject: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Message-ID: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR ------------- Commit messages: - JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Changes: https://git.openjdk.java.net/jdk/pull/4306/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4306&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267764 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4306/head:pull/4306 PR: https://git.openjdk.java.net/jdk/pull/4306 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 14:19:43 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 14:19:43 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com> On Wed, 2 Jun 2021 14:10:38 GMT, ?????? ??????? wrote: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). src/java.base/share/classes/java/util/BitSet.java line 1040: > 1038: h ^= words[i] * (i + 1); > 1039: > 1040: return Long.hashCode(h); Here `>>` instead of `>>>` in original code seems to be a typo ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 14:19:42 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 14:19:42 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible Message-ID: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ------------- Commit messages: - 8268113: Re-use Long.hashCode() where possible Changes: https://git.openjdk.java.net/jdk/pull/4309/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268113 Stats: 10 lines in 7 files changed: 1 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From rriggs at openjdk.java.net Wed Jun 2 14:19:58 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Jun 2021 14:19:58 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v6] In-Reply-To: References: Message-ID: > Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. > The Charset used to encode and decode characters to bytes can be specified or use the > operating system native encoding as is available from the "native.encoding" system property. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Corrected change from IllegalArgumentException to IllegalStateException and tests. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4134/files - new: https://git.openjdk.java.net/jdk/pull/4134/files/37bfa009..bf5fc724 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=04-05 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134 PR: https://git.openjdk.java.net/jdk/pull/4134 From plevart at openjdk.java.net Wed Jun 2 14:39:29 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 14:39:29 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <79372ef7-0027-1e7c-326b-a696d026152d@oracle.com> References: <79372ef7-0027-1e7c-326b-a696d026152d@oracle.com> Message-ID: On Wed, 2 Jun 2021 05:59:05 GMT, David Holmes wrote: > Sorry Jaroslav but I don't really see this test as a basic functional > test of the PreserveAllAnnotations flag. There is no need for any > dynamic retention mode switch. All you need as I've said previously is a > class with all the CLASS retention annotations of interest (8 IIRC) > applied and a programs that reads them, and either expects to find them > or not, based on the PreserveAllAnnotations flag. `CLASS` retention annotations are never returned by reflection regardless of whether the `PreserveAllAnnotations` option was used or not. The only way (apart from hacking into encapsulated state and doing your own parsing) is to compile a class that uses an annotation with `CLASS` retention and then run a test that looks up the annotation on this class after the annotation has been changed to have `RUNTIME` retention, but the class that uses it has not been recompiled. `AltClassLoader` does the trick which replaces the class file of _v1 class with the class file of _v2 class when loading the class which simulates this change and recompilation of the annotation without changing anything else. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From plevart at openjdk.java.net Wed Jun 2 14:48:36 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 14:48:36 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. What I would do is to add a patch for the parser bug and then extend the test in 3 dimensions: - run it with and without the `-XX+PreserveAllAnnotations` option (adapt expected results accordingly) - test annotation use when besides the annotation that changes retention from CLASS -> RUNTIME there is another RUNTIME annotation present on the annotated element or not (this would fail before the bugfix) - test with different annotated elements (Class, Method, Field, Constructor, Parameter) to exercise different code paths in the VM. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From github.com+7806504+liach at openjdk.java.net Wed Jun 2 14:54:31 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Wed, 2 Jun 2021 14:54:31 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: On Wed, 2 Jun 2021 14:10:38 GMT, ?????? ??????? wrote: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). src/java.base/share/classes/java/lang/Double.java line 881: > 879: public static int hashCode(double value) { > 880: long bits = doubleToLongBits(value); > 881: return Long.hashCode(bits); Imo these should be squashed to just return Long.hashCode(doubleToLongBits(value)); since the local variable is no longer meaningful. Previously, they were required as they were retrieved twice in hash code calculation. Same for other usages. src/java.desktop/macosx/classes/apple/laf/JRSUIConstants.java line 115: > 113: public int hashCode() { > 114: final long bits = Double.doubleToLongBits(doubleValue); > 115: return Long.hashCode(bits); This one and the `DoubleDV` one should actually delegate to `Double.hashCode`, which delegates to `Long.hashCode` after this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From rriggs at openjdk.java.net Wed Jun 2 15:00:56 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 2 Jun 2021 15:00:56 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v7] In-Reply-To: References: Message-ID: > Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. > The Charset used to encode and decode characters to bytes can be specified or use the > operating system native encoding as is available from the "native.encoding" system property. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Editorial improvements in outputWriter and inputReader. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4134/files - new: https://git.openjdk.java.net/jdk/pull/4134/files/bf5fc724..45838b13 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4134&range=05-06 Stats: 9 lines in 1 file changed: 4 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4134/head:pull/4134 PR: https://git.openjdk.java.net/jdk/pull/4134 From pconcannon at openjdk.java.net Wed Jun 2 15:33:40 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 2 Jun 2021 15:33:40 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions Message-ID: Hi, Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? Kind regards, Patrick ------------- Commit messages: - 8268124: Update java.lang to use switch expressions Changes: https://git.openjdk.java.net/jdk/pull/4312/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268124 Stats: 551 lines in 22 files changed: 7 ins; 140 del; 404 mod Patch: https://git.openjdk.java.net/jdk/pull/4312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4312/head:pull/4312 PR: https://git.openjdk.java.net/jdk/pull/4312 From plevart at openjdk.java.net Wed Jun 2 15:38:32 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 15:38:32 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <2297c0f1-f22a-ad1f-c145-b3222b51ac57@oracle.com> References: <2297c0f1-f22a-ad1f-c145-b3222b51ac57@oracle.com> Message-ID: <3tBMT73dGX4EXPS6lEhFuqfVobEyxiK0Qnj1MNezzx4=.c0b7749b-0f4d-47cd-aacd-bf6e78fdf378@github.com> On Wed, 2 Jun 2021 13:24:10 GMT, David Holmes wrote: > Sorry now I see what happens. We aren't combining two arrays of > annotations we're concatenating two streams of byes, each of which > represents a set of annotations, starting with the length. > > The code that receives this on the JDK side doesn't seem to understand > that this is a possibility. > > Though maybe this isn't a bug, maybe the AnnotationParser is > deliberately ignoring the second byte stream. (Though if it were > deliberate there should be some commentary to that affect!) > > David I think this is not deliberate. Since `rawAnnotations` may end up having any of the following: - `RuntimeVisibleAnnotations` (when there were just `RUNTIME` annotation usages compiled into the class or `-XX+PreserveAllAnnotations` was not used at runtime) - `RuntimeInvisibleAnnotations` (when there were just `CLASS` annotation usages compiled into the class and `-XX+PreserveAllAnnotations` was used at runtime) - `RuntimeVisibleAnnotations + RuntimeInvisibleAnnotations` (when there were `RUNTIME` and `CLASS` annotation usages compiled into the class and `-XX+PreserveAllAnnotations` was used at runtime) So why would `RuntimeInvisibleAnnotations` be skipped in 3rd case but not in 2nd case? ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From weijun at openjdk.java.net Wed Jun 2 15:40:55 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 15:40:55 GMT Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K [v4] In-Reply-To: References: Message-ID: > The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. > > The code change shows some common solutions to avoid such too wide annotations: > > 1. Extract calls into a method and add annotation on that method > 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. > > I'll add a copyright year update commit before integration. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8267521: Post JEP 411 refactoring: maximum covering > 50K ------------- Changes: https://git.openjdk.java.net/jdk/pull/4138/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=03 Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod Patch: https://git.openjdk.java.net/jdk/pull/4138.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138 PR: https://git.openjdk.java.net/jdk/pull/4138 From alanb at openjdk.java.net Wed Jun 2 15:42:32 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Jun 2021 15:42:32 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v7] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 15:00:56 GMT, Roger Riggs wrote: >> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. >> The Charset used to encode and decode characters to bytes can be specified or use the >> operating system native encoding as is available from the "native.encoding" system property. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Editorial improvements in outputWriter and inputReader. We've gone through a few iterations on the javadoc and I think the latest edition is okay. I don't have time right now for the latest version of the test (I did look at the test in the initial patch). src/java.base/share/classes/java/lang/Process.java line 231: > 229: * > 230: *

The first call to this method creates the {@link BufferedReader BufferedReader}, > 231: * if called again with the same {@code charset} the same {@code BufferedReader} is returned. "the same BufferedReader is returned" - a suggestion here to rephrase this to "then the BufferedReader returned by the first call is returned". ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4134 From weijun at openjdk.java.net Wed Jun 2 15:51:33 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 2 Jun 2021 15:51:33 GMT Subject: Integrated: 8267521: Post JEP 411 refactoring: maximum covering > 50K In-Reply-To: References: Message-ID: On Fri, 21 May 2021 01:52:27 GMT, Weijun Wang wrote: > The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed. > > The code change shows some common solutions to avoid such too wide annotations: > > 1. Extract calls into a method and add annotation on that method > 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded. > 3. Put declaration and assignment into a single statement if possible. > 4. Rewrite code to achieve #3 above. > > I'll add a copyright year update commit before integration. This pull request has now been integrated. Changeset: 508cec75 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/508cec7535cd0ad015d566389bc9e5f53ce4103b Stats: 245 lines in 18 files changed: 140 ins; 39 del; 66 mod 8267521: Post JEP 411 refactoring: maximum covering > 50K Reviewed-by: dfuchs, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/4138 From dfuchs at openjdk.java.net Wed Jun 2 16:01:49 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Jun 2021 16:01:49 GMT Subject: RFR: 8264975: java/net/DatagramSocket/DatagramSocketMulticasting.java fails infrequently Message-ID: Please find below a fix that will make `java/net/DatagramSocket/DatagramSocketMulticasting.java` more resilient to the rare case where addresses bound to a network interfaces are updated while the test is running. Instead of using `NetworkInterface::equals` to compare network interfaces, the test now use `NetworkConfiguration::isSameInterface` which only looks at the network interface name and index and ignore the addresses which are bound to it. ------------- Commit messages: - 8264975: java/net/DatagramSocket/DatagramSocketMulticasting.java fails infrequently Changes: https://git.openjdk.java.net/jdk/pull/4313/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4313&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264975 Stats: 36 lines in 3 files changed: 32 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4313/head:pull/4313 PR: https://git.openjdk.java.net/jdk/pull/4313 From forax at openjdk.java.net Wed Jun 2 16:09:30 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 2 Jun 2021 16:09:30 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1663: > 1661: case D_TYPE -> mv.visitInsn(Opcodes.DCONST_0); > 1662: case L_TYPE -> mv.visitInsn(Opcodes.ACONST_NULL); > 1663: default -> throw new InternalError("unknown type: " + type); perhaps mv.visitInsn(switch(type) { ... ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From forax at openjdk.java.net Wed Jun 2 16:13:33 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 2 Jun 2021 16:13:33 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions In-Reply-To: References: Message-ID: <618GzC0qITXnu_SQ0E-V5FjpoW5nNj1ov7w1vjlemD8=.35c01194-1e74-4172-806e-d85d4aff02df@github.com> On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/lang/invoke/MemberName.java line 331: > 329: assert(false) : this+" != "+MethodHandleNatives.refKindName((byte)originalRefKind); > 330: yield true; > 331: } this code always yield true, better to check if the assert are enabled, do the switch in that case and always return true ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From erikj at openjdk.java.net Wed Jun 2 16:15:36 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 16:15:36 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov wrote: >> 8267706: bin/idea.sh tries to use cygpath on WSL > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > 8267706: Break long line in make/ide/idea/jdk/idea.gmk We require a new issue to be filed. Thank you for looking into fixing this! ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From forax at openjdk.java.net Wed Jun 2 16:17:27 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 2 Jun 2021 16:17:27 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions In-Reply-To: References: Message-ID: <56RtDiVZt5ZyjQj1VSz2zfAACcA9VD4IfjP10EgtDo4=.0b291a16-b7fc-4198-8e78-74fc4fe591c0@github.com> On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 278: > 276: private static boolean isObjectMethod(Method m) { > 277: return switch (m.getName()) { > 278: case "toString" -> (m.getReturnType() == String.class the extra parenthesis are not needed ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From forax at openjdk.java.net Wed Jun 2 16:22:37 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 2 Jun 2021 16:22:37 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 366: > 364: } > 365: default -> throw new IllegalArgumentException(methodName); > 366: }; I thinki it's simpler to have something like that var handle = switch(methodName) { ... }; return methodType != null ? new ConstantCallSite(handle) : handle; ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From jjg at openjdk.java.net Wed Jun 2 16:25:41 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 16:25:41 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 Message-ID: Please review the change to update to using jtreg 6. The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. ------------- Commit messages: - JDK-8266254: Update to use jtreg 6 Changes: https://git.openjdk.java.net/jdk/pull/4315/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4315&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266254 Stats: 17 lines in 11 files changed: 0 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/4315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4315/head:pull/4315 PR: https://git.openjdk.java.net/jdk/pull/4315 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 16:31:56 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 16:31:56 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v2] In-Reply-To: References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: On Wed, 2 Jun 2021 14:51:35 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268113: Delegate to Double.hashCode() > > src/java.desktop/macosx/classes/apple/laf/JRSUIConstants.java line 115: > >> 113: public int hashCode() { >> 114: final long bits = Double.doubleToLongBits(doubleValue); >> 115: return Long.hashCode(bits); > > This one and the `DoubleDV` one should actually delegate to `Double.hashCode`, which delegates to `Long.hashCode` after this change. Good point, done! ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 16:31:55 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 16:31:55 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v2] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8268113: Delegate to Double.hashCode() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/9c7ddc0c..3f5b431d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From lancea at openjdk.java.net Wed Jun 2 16:35:30 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 2 Jun 2021 16:35:30 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From bpb at openjdk.java.net Wed Jun 2 16:36:35 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 2 Jun 2021 16:36:35 GMT Subject: Integrated: 8267569: java.io.File.equals contains misleading Javadoc In-Reply-To: References: Message-ID: On Thu, 27 May 2021 20:33:50 GMT, Brian Burkhalter wrote: > Modify the specification of `java.io.File.equals` to clarify that equality is based only on a comparison of abstract pathnames as opposed to the file system objects that the `File`s represent. This pull request has now been integrated. Changeset: 56b65e4a Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/56b65e4a8d519801d170e16063ccb7dd3069c4be Stats: 14 lines in 1 file changed: 7 ins; 0 del; 7 mod 8267569: java.io.File.equals contains misleading Javadoc Reviewed-by: alanb, dfuchs, bchristi, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4232 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 16:37:49 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 16:37:49 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v3] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8268113: Inline local vars where reasonable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/3f5b431d..df8be00a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=01-02 Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 16:37:51 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 16:37:51 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v3] In-Reply-To: References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: On Wed, 2 Jun 2021 14:50:23 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268113: Inline local vars where reasonable > > src/java.base/share/classes/java/lang/Double.java line 881: > >> 879: public static int hashCode(double value) { >> 880: long bits = doubleToLongBits(value); >> 881: return Long.hashCode(bits); > > Imo these should be squashed to just > > return Long.hashCode(doubleToLongBits(value)); > > since the local variable is no longer meaningful. Previously, they were required as they were retrieved twice in hash code calculation. > > Same for other usages. Done! ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From naoto at openjdk.java.net Wed Jun 2 16:41:31 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 2 Jun 2021 16:41:31 GMT Subject: RFR: 8191441: (Process) add Readers and Writer access to java.lang.Process streams [v7] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 15:00:56 GMT, Roger Riggs wrote: >> Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. >> The Charset used to encode and decode characters to bytes can be specified or use the >> operating system native encoding as is available from the "native.encoding" system property. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Editorial improvements in outputWriter and inputReader. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 From erikj at openjdk.java.net Wed Jun 2 16:52:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 16:52:27 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From joe.darcy at oracle.com Wed Jun 2 16:54:02 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 2 Jun 2021 09:54:02 -0700 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: <0d6d2f1c-d108-f7b8-6d69-e4b3b85573f2@oracle.com> If the reflection runtime doesn't implement the semantics of -XX+PreserveAllAnnotations, I suggest deprecating/obsoleting/etc. that option now. -Joe On 6/2/2021 7:48 AM, Peter Levart wrote: > On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > >> There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. > What I would do is to add a patch for the parser bug and then extend the test in 3 dimensions: > - run it with and without the `-XX+PreserveAllAnnotations` option (adapt expected results accordingly) > - test annotation use when besides the annotation that changes retention from CLASS -> RUNTIME there is another RUNTIME annotation present on the annotated element or not (this would fail before the bugfix) > - test with different annotated elements (Class, Method, Field, Constructor, Parameter) to exercise different code paths in the VM. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4280 From mchung at openjdk.java.net Wed Jun 2 16:56:30 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Jun 2021 16:56:30 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From naoto at openjdk.java.net Wed Jun 2 16:59:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 2 Jun 2021 16:59:30 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick Hi Patrick, some minor comments. src/java.base/share/classes/java/lang/CharacterData.java line 80: > 78: case 2 -> CharacterData02.instance; > 79: case 3 -> CharacterData03.instance; > 80: case 14 -> CharacterData0E.instance; // Private Use Plane 14 is not `private use` src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 90: > 88: // findVirtual etc. > 89: return switch (refKind) { > 90: case REF_invokeSpecial: { Is ':' preferred here (and other cases too) instead of "->"? ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From asemenyuk at openjdk.java.net Wed Jun 2 17:01:30 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Wed, 2 Jun 2021 17:01:30 GMT Subject: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR In-Reply-To: References: Message-ID: <8f2YcN64VOMXEMnH0-qbj5dKrxmT13yi5gs5sbqa6Y0=.979aebd3-c8e6-42ea-9063-7d6063802445@github.com> On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote: > JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4306 From naoto at openjdk.java.net Wed Jun 2 17:05:34 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 2 Jun 2021 17:05:34 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Some of the modified files have copyright year left unchanged. `2021` needs to be appended. ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From darcy at openjdk.java.net Wed Jun 2 17:09:31 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 2 Jun 2021 17:09:31 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick Changes to Math and Long look fine. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4312 From alanb at openjdk.java.net Wed Jun 2 17:12:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 2 Jun 2021 17:12:29 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Looks good, I had expected we would have more tests depending on the automatic module. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4315 From smarks at openjdk.java.net Wed Jun 2 17:15:34 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 2 Jun 2021 17:15:34 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> On Wed, 2 Jun 2021 07:35:25 GMT, R?mi Forax wrote: > i wonder if we should not declare SimpleImmutableEntry final, while it's not a backward compatible change, > it's may be better on the long term because SimpleImmutableEntry is already used as an immutable type, > so instead of documenting the fact that SimpleImmutableEntry is not declared final thus SimpleImmutableEntry as a type does not guarantte shallow immutability, it may be better to fix the root cause. A quick search reveals that Guava has a public subclass of SimpleImmutableEntry: https://guava.dev/releases/30.1.1-jre/api/docs/com/google/common/cache/RemovalNotification.html There are possibly others. It doesn't seem worth the incompatibility to me, as it would break stuff in order to have only a "cleaner" meaning for "immutable." Also, there are other classes in the JDK that claim they are immutable but which can be subclassed, e.g., BigInteger. I don't see a good way of fixing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/4295 From sviswanathan at openjdk.java.net Wed Jun 2 17:23:08 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 2 Jun 2021 17:23:08 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v16] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan 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/3638/files - new: https://git.openjdk.java.net/jdk/pull/3638/files/e5208a18..b229e8b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=14-15 Stats: 18 lines in 1 file changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From forax at openjdk.java.net Wed Jun 2 17:24:30 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 2 Jun 2021 17:24:30 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> Message-ID: On Wed, 2 Jun 2021 17:12:21 GMT, Stuart Marks wrote: > A quick search reveals that Guava has a public subclass of SimpleImmutableEntry: > https://guava.dev/releases/30.1.1-jre/api/docs/com/google/common/cache/RemovalNotification.html >There are possibly others. It doesn't seem worth the incompatibility to me, as it would break stuff in order to have only a "cleaner" meaning for "immutable." Also, there are other classes in the JDK that claim they are immutable but which can be subclassed, e.g., BigInteger. I don't see a good way of fixing this. Thanks, i've done some digging too, I foolishly hoped that nobody would subclass a class with `Immutable` in its name, oh boy i was wrong :) So documenting the existing behavior seems the only possible way. ------------- PR: https://git.openjdk.java.net/jdk/pull/4295 From mcimadamore at openjdk.java.net Wed Jun 2 17:30:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 17:30:08 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries Message-ID: This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. ------------- Commit messages: - Improve javadoc - Initial push Changes: https://git.openjdk.java.net/jdk/pull/4316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268129 Stats: 1278 lines in 44 files changed: 569 ins; 617 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 17:30:09 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 17:30:09 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore wrote: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Some notes on how the *system* lookup is implemented (see class SystemLookup): * On Linux and MacOS, we generate, at build time, an empty shim library. Since this library depends on the C standard libraries, we can, at runtime, load this shim library, and use `dlsym` to lookup symbols in it (since `dlsym` will also look at the dependencies). * Since Windows does not allow for library symbols in dependent libraries to be re-exported, Windows uses a different approach - which loads either `ucrtbase.dll` or `msvcrt.dll` (the former is preferred, if available), and returns a lookup object based on that. In both cases, the required libraries are loaded in a classloader-independent fashion, by taking advantage of the support available in NativeLibraries. Class loader lookups are built on top of ClassLoader::findNative (which is also the method used by JNI to find JNI methods). This patch removes all the native code which was required to support the default lookup abstraction. The implementation changes are relatively straightforward - but several test and microbenchmark updates were required. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From lmesnik at openjdk.java.net Wed Jun 2 17:30:33 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Jun 2021 17:30:33 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5] In-Reply-To: References: Message-ID: On Fri, 28 May 2021 02:14:45 GMT, Igor Ignatyev wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> spaces updated. > > test/failure_handler/src/share/classes/jdk/test/failurehandler/action/PatternAction.java line 63: > >> 61: } >> 62: for (int i = 0, n = args.length; i < n; ++i) { >> 63: args[i] = args[i].replace("%java", helper.findApp("java").getAbsolutePath()); > > are we sure that `java` from `PATH` (which is what `findApp` returns) is the right `java`? The paths contain testJdk and compileJdk before PATH. We use it to find any of our tools. ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From jjg at openjdk.java.net Wed Jun 2 17:41:32 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 17:41:32 GMT Subject: RFR: 8267706: bin/idea.sh tries to use cygpath on WSL [v2] In-Reply-To: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> References: <0DoaFAz7PiavGkIxVLtyz_rIZl33AIZNHghzurXptnU=.82272491-d35c-4cb1-970a-2e2b6134d846@github.com> Message-ID: <37Ug27vhfTZFV2Zaf8ooYa-gYoPqQmmVx3K1ProB9eE=.55266d35-b805-46bc-98f4-db6bce443bef@github.com> On Thu, 27 May 2021 17:45:40 GMT, Nikita Gubarkov wrote: >> 8267706: bin/idea.sh tries to use cygpath on WSL > > Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision: > > 8267706: Break long line in make/ide/idea/jdk/idea.gmk I filed a new issue yesterday, linked to the old one. There should be no need to create another. https://bugs.openjdk.java.net/browse/JDK-8268083 ------------- PR: https://git.openjdk.java.net/jdk/pull/4190 From iris at openjdk.java.net Wed Jun 2 17:51:29 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 2 Jun 2021 17:51:29 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From smarks at openjdk.java.net Wed Jun 2 17:54:06 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 2 Jun 2021 17:54:06 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry [v2] In-Reply-To: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: > I'm fixing this along with a couple intertwined issues. > > 1. Add Map.Entry::copyOf as an idempotent copy operation. > > 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not really immutable) but that subclasses can be modifiable. > > 3. Clarify some confusing, historical wording about Map.Entry instances being obtainable only via iteration of a Map's entry-set view. This was never really true, since anyone could implement the Map.Entry interface, and it certainly was not true since JDK 1.6 when SimpleEntry and SimpleImmutableEntry were added. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Tiny editorial tweaks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4295/files - new: https://git.openjdk.java.net/jdk/pull/4295/files/841a154c..c67b6445 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4295&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4295&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4295/head:pull/4295 PR: https://git.openjdk.java.net/jdk/pull/4295 From psandoz at openjdk.java.net Wed Jun 2 17:55:52 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 17:55:52 GMT Subject: RFR: 8266317: Vector API enhancements [v5] In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> Message-ID: <0DmgZbt9Pi-lIZPNgJ5iHx8wDv6YOTZC3GmPqXbhqtA=.f76153cd-1b1d-4deb-8ff2-f4a90bfd3d23@github.com> > This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons. > > Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array. > > The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Check vlen in bytes for unsigned support ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3803/files - new: https://git.openjdk.java.net/jdk/pull/3803/files/12b23f62..20a9c9ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3803&range=03-04 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3803/head:pull/3803 PR: https://git.openjdk.java.net/jdk/pull/3803 From vtewari at openjdk.java.net Wed Jun 2 18:01:29 2021 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Wed, 2 Jun 2021 18:01:29 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v3] In-Reply-To: References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: On Wed, 2 Jun 2021 16:37:49 GMT, ?????? ??????? wrote: >> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8268113: Inline local vars where reasonable src/java.base/share/classes/java/util/BitSet.java line 105: > 103: * the user knows what he's doing and try harder to preserve it. > 104: */ > 105: private transient boolean sizeIsSticky = false; This change is OK, but it is not related to "8268113", do you really wants to do these changes as part of "8268113" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From dfuchs at openjdk.java.net Wed Jun 2 18:10:35 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Jun 2021 18:10:35 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry [v2] In-Reply-To: References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: On Wed, 2 Jun 2021 17:54:06 GMT, Stuart Marks wrote: >> I'm fixing this along with a couple intertwined issues. >> >> 1. Add Map.Entry::copyOf as an idempotent copy operation. >> >> 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not really immutable) but that subclasses can be modifiable. >> >> 3. Clarify some confusing, historical wording about Map.Entry instances being obtainable only via iteration of a Map's entry-set view. This was never really true, since anyone could implement the Map.Entry interface, and it certainly was not true since JDK 1.6 when SimpleEntry and SimpleImmutableEntry were added. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Tiny editorial tweaks. src/java.base/share/classes/java/util/Map.java line 396: > 394: > 395: /** > 396: * A map entry (key-value pair). The Entry may be unmodifiable, or the In that case then maybe it should be `{@code Entry}` in both places where `entry` was replaced with `Entry` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4295 From chegar at openjdk.java.net Wed Jun 2 18:25:29 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 2 Jun 2021 18:25:29 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From joehw at openjdk.java.net Wed Jun 2 18:25:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 2 Jun 2021 18:25:39 GMT Subject: RFR: 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path Message-ID: Special characters are different in File and URI. Treat File input as File using FileInputStream instead of converting to an URI, but fall back to URI in case of error for compatibility (in error handling). ------------- Commit messages: - 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path Changes: https://git.openjdk.java.net/jdk/pull/4318/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4318&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266019 Stats: 39 lines in 2 files changed: 31 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4318.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4318/head:pull/4318 PR: https://git.openjdk.java.net/jdk/pull/4318 From jvernee at openjdk.java.net Wed Jun 2 18:32:27 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 2 Jun 2021 18:32:27 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: <8PJV-HbcaTXWsbafEWbY3XXSICXLl4YCByOAF0Hypeo=.d1c3ff61-3cda-40cf-aa40-22e4661c9879@github.com> On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore wrote: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. LGTM, minor nit inline test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java line 62: > 60: ); > 61: MH_distance_ptrs = abi.downcallHandle( > 62: lookup.lookup("distance_ptrs").get(), Spurious white space Suggestion: lookup.lookup("distance_ptrs").get(), ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4316 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 2 18:36:28 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 2 Jun 2021 18:36:28 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v3] In-Reply-To: References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: On Wed, 2 Jun 2021 17:58:29 GMT, Vyom Tewari wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268113: Inline local vars where reasonable > > src/java.base/share/classes/java/util/BitSet.java line 105: > >> 103: * the user knows what he's doing and try harder to preserve it. >> 104: */ >> 105: private transient boolean sizeIsSticky = false; > > This change is OK, but it is not related to "8268113", do you really wants to do these changes as part of "8268113" ? This is just a tiny code clean-up, so I think it's ok to go ------------- PR: https://git.openjdk.java.net/jdk/pull/4309 From dfuchs at openjdk.java.net Wed Jun 2 18:54:32 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Jun 2021 18:54:32 GMT Subject: RFR: 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 18:17:43 GMT, Joe Wang wrote: > Special characters are different in File and URI. Treat File input as File using FileInputStream instead of converting to an URI, but fall back to URI in case of error for compatibility (in error handling). I believe this is the wrong fix - or at least an incomplete fix that will hide the bug under the carpet. Looking at TransformImpl I would change line TransformImpl.java:521 to: 521: - String path = uri.getPath(); //decoded String 521: + String path = uri.getRawPath(); //raw String ------------- PR: https://git.openjdk.java.net/jdk/pull/4318 From joehw at openjdk.java.net Wed Jun 2 19:31:39 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 2 Jun 2021 19:31:39 GMT Subject: RFR: 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path In-Reply-To: References: Message-ID: <-Ak4bdR7Mr7IPZRfwB2YMluwAorokqQK3gB2BJno8RY=.4f23a2c2-8a97-4fa9-8919-e80b6f197087@github.com> On Wed, 2 Jun 2021 18:17:43 GMT, Joe Wang wrote: > Special characters are different in File and URI. Treat File input as File using FileInputStream instead of converting to an URI, but fall back to URI in case of error for compatibility (in error handling). I tried, but getRawPath returned output/%23/dom.xml, that in turn resulted in java.io.FileNotFoundException later. For StreamResult, when a String-form systemId is in File protocol, a FileOutputStream will eventually get created. Since StreamResult accepts OutputStream, there's no need for the File -> URI -> systemId -> URL -> File conversion (as did in TransformerImpl). I think it's better to create a FileOutputStream right from the File input. ------------- PR: https://git.openjdk.java.net/jdk/pull/4318 From jjg at openjdk.java.net Wed Jun 2 20:15:55 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 20:15:55 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 [v2] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4315/files - new: https://git.openjdk.java.net/jdk/pull/4315/files/0d1e554a..4ef5614f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4315&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4315&range=00-01 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4315.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4315/head:pull/4315 PR: https://git.openjdk.java.net/jdk/pull/4315 From mcimadamore at openjdk.java.net Wed Jun 2 20:17:20 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 20:17:20 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v2] In-Reply-To: References: Message-ID: <0b1ugeQMfRO1Dp6ARQaDz7f2aUwTzImQmK37Py1Yg1k=.b35b56e3-2b36-4608-8676-13f1cd290a81@github.com> > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/01d9c198..2b668f7c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 20:17:22 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 20:17:22 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: <1RwBnwfTi0XsUzPYQHKHTZ7jxgkhgsJfEG28Q33RahA=.6a992ad3-b289-4c93-9dc9-72a948f67581@github.com> On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore wrote: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > _Mailing list message from [Chapman Flack](mailto:chap at anastigmatix.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_ > > On 06/02/21 13:30, Maurizio Cimadamore wrote: > > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` > > abstraction, a functional interface. Crucially, `SymbolLookup` does not > > concern with library loading, only symbol lookup. For this reason, two > > factories are added: > > Hi, > > While I am thinking about this, what will be the behavior when the JVM > itself has been dynamically loaded into an embedding application, and > launched with the JNI invocation API? > > Will there be a *Lookup flavor that is able to find any exported symbol > known in the embedding environment the JVM was loaded into? (This is the > sort of condition the Mac OS linker checks when given the -bundle_loader > option.) > > Regards, > Chapman Flack (maintainer of a project that happens to work that way) Hi, at the moment we don't have plans to add such a lookup, but I believe it should be possible to build such a lookup using `dlopen` and the linker API. I have provided an example elsewhere of how easy it easy to build a wrapper lookup around dlopen/dlsym: https://gist.github.com/mcimadamore/0883ea6f4836ae0c1d2a31c48197da1a Perhaps something like that could be useful in the use case you mention? ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From dfuchs at openjdk.java.net Wed Jun 2 20:17:37 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Jun 2021 20:17:37 GMT Subject: RFR: 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 18:17:43 GMT, Joe Wang wrote: > Special characters are different in File and URI. Treat File input as File using FileInputStream instead of converting to an URI, but fall back to URI in case of error for compatibility (in error handling). Argh! You're right. It's this line which is horribly wrong: _ostream = new FileOutputStream(url.getFile()); OK - hopefully with your fix this becomes dead code? ------------- PR: https://git.openjdk.java.net/jdk/pull/4318 From naoto at openjdk.java.net Wed Jun 2 20:21:38 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 2 Jun 2021 20:21:38 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:15:55 GMT, Jonathan Gibbons wrote: >> Please review the change to update to using jtreg 6. >> >> The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. >> >> All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From dfuchs at openjdk.java.net Wed Jun 2 20:28:37 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 2 Jun 2021 20:28:37 GMT Subject: RFR: 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 18:17:43 GMT, Joe Wang wrote: > Special characters are different in File and URI. Treat File input as File using FileInputStream instead of converting to an URI, but fall back to URI in case of error for compatibility (in error handling). I now agree that what you propose is the safer route to fix this particular issue. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4318 From psandoz at openjdk.java.net Wed Jun 2 20:40:47 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 20:40:47 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v2] In-Reply-To: <0b1ugeQMfRO1Dp6ARQaDz7f2aUwTzImQmK37Py1Yg1k=.b35b56e3-2b36-4608-8676-13f1cd290a81@github.com> References: <0b1ugeQMfRO1Dp6ARQaDz7f2aUwTzImQmK37Py1Yg1k=.b35b56e3-2b36-4608-8676-13f1cd290a81@github.com> Message-ID: On Wed, 2 Jun 2021 20:17:20 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >> >> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: >> >> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader >> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. >> >> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Update test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java > > Co-authored-by: Jorn Vernee Looks good. Just minor comments to accept/reject. The shim library is an interesting approach. I did wonder if the libvm library could be used, but it might have some weird side-effects or bring in more symbols than necessary. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 138: > 136: *

> 137: * This method is restricted. > 138: * Restricted method are unsafe, and, if used incorrectly, their use might crash Suggestion: * Restricted methods are unsafe, and, if used incorrectly, their use might crash src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 160: > 158: * to allocate structs returned by-value. > 159: * > 160: * @see SymbolLookup For JDK code it is more common for `@See` to occur after the parameters/return/throws, and before any `@Since`. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 418: > 416: private static class AllocHolder { > 417: > 418: private static final CLinker linker = getSystemLinker(); Suggestion: private static final CLinker SYS_LINKER = getSystemLinker(); test/jdk/java/foreign/SafeFunctionAccessTest.java line 53: > 51: ); > 52: > 53: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/StdLibTest.java line 158: > 156: static class StdLibHelper { > 157: > 158: final static SymbolLookup LOOKUP; Suggestion: static final SymbolLookup LOOKUP; test/jdk/java/foreign/TestDowncall.java line 60: > 58: } > 59: > 60: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/TestIllegalLink.java line 48: > 46: public class TestIllegalLink { > 47: > 48: private static final MemoryAddress dummyTarget = MemoryAddress.ofLong(1); Suggestion: private static final MemoryAddress DUMMY_TARGET = MemoryAddress.ofLong(1); test/jdk/java/foreign/TestIntrinsics.java line 60: > 58: } > 59: > 60: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/TestSymbolLookup.java line 50: > 48: } > 49: > 50: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/TestUpcall.java line 69: > 67: static CLinker abi = CLinker.getInstance(); > 68: > 69: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); test/jdk/java/foreign/TestVarArgs.java line 68: > 66: } > 67: > 68: static final MemoryAddress varargsAddr = Suggestion: static final MemoryAddress VARARGS_ADDR = test/jdk/java/foreign/valist/VaListTest.java line 74: > 72: } > 73: > 74: static SymbolLookup lookup = SymbolLookup.loaderLookup(); Suggestion: static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup(); ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4316 From joehw at openjdk.java.net Wed Jun 2 20:51:43 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 2 Jun 2021 20:51:43 GMT Subject: RFR: 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 18:17:43 GMT, Joe Wang wrote: > Special characters are different in File and URI. Treat File input as File using FileInputStream instead of converting to an URI, but fall back to URI in case of error for compatibility (in error handling). Thanks Daniel! For the question, it will not be dead code as it accepts systemId in String form as well. But as least when File is the input, we don't end up going through a convoluted (if not unnecessary) File -URI -URL - File conversion. I think the later has sth. to do with the fact that Apache still supports older JDKs. While we agree not to touch that code for this fix (and also for not changing the mechanisms, e.g. how errors are handled), we'll keep an eye out on it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4318 From mcimadamore at openjdk.java.net Wed Jun 2 20:59:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 20:59:25 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v3] In-Reply-To: References: <0b1ugeQMfRO1Dp6ARQaDz7f2aUwTzImQmK37Py1Yg1k=.b35b56e3-2b36-4608-8676-13f1cd290a81@github.com> Message-ID: On Wed, 2 Jun 2021 18:40:48 GMT, Paul Sandoz wrote: >> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision: >> >> - Update test/jdk/java/foreign/TestIntrinsics.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/valist/VaListTest.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestVarArgs.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestUpcall.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestIllegalLink.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestSymbolLookup.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/TestDowncall.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/StdLibTest.java >> >> Co-authored-by: Paul Sandoz >> - Update test/jdk/java/foreign/SafeFunctionAccessTest.java >> >> Co-authored-by: Paul Sandoz >> - Update src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java >> >> Co-authored-by: Paul Sandoz > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 138: > >> 136: *

>> 137: * This method is restricted. >> 138: * Restricted method are unsafe, and, if used incorrectly, their use might crash > > Suggestion: > > * Restricted methods are unsafe, and, if used incorrectly, their use might crash Ouch - this seems like an issue with _all_ restricted methods. > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 160: > >> 158: * to allocate structs returned by-value. >> 159: * >> 160: * @see SymbolLookup > > For JDK code it is more common for `@See` to occur after the parameters/return/throws, and before any `@Since`. I'll fix ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 20:59:20 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 20:59:20 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v3] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision: - Update test/jdk/java/foreign/TestIntrinsics.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/valist/VaListTest.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestVarArgs.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestUpcall.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestIllegalLink.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestSymbolLookup.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestDowncall.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/StdLibTest.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/SafeFunctionAccessTest.java Co-authored-by: Paul Sandoz - Update src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/2b668f7c..41ab74b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=01-02 Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Wed Jun 2 21:09:24 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 21:09:24 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v4] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/41ab74b6..7be87eae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=02-03 Stats: 42 lines in 13 files changed: 6 ins; 6 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From plevart at openjdk.java.net Wed Jun 2 21:18:37 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Wed, 2 Jun 2021 21:18:37 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <0d6d2f1c-d108-f7b8-6d69-e4b3b85573f2@oracle.com> References: <0d6d2f1c-d108-f7b8-6d69-e4b3b85573f2@oracle.com> Message-ID: On Wed, 2 Jun 2021 16:56:07 GMT, Joe Darcy wrote: > If the reflection runtime doesn't implement the semantics of > -XX+PreserveAllAnnotations, I suggest deprecating/obsoleting/etc. that > option now. > > -Joe What is the -XX+PreserveAllAnnotations semantics in terms of reflection? The VM spec allows it, but reflection spec doesn't mention it or anything close to it. It doesn't violate the reflection spec. It actually makes reflection behave more correctly in some cases. Without it, reflection sometimes doesn't return annotations with RUNTIME retention. It does implement a useful semantics in terms of late binding. It's just buggy in corner case, which apparently hasn't bothered anyone, since nobody officially complained. That doesn't mean it hasn't been or is not used in the way where it behaves in a useful way and it doesn't mean it won't be needed in the future. Jaroslav gave a perfect example of the case where it is needed now. Removing this option means that migrating an annotation from CLASS retention to RUNTIME becomes almost impossible thing in the real world where no single person controls the whole codebase. Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From duke at openjdk.java.net Wed Jun 2 21:23:40 2021 From: duke at openjdk.java.net (duke) Date: Wed, 2 Jun 2021 21:23:40 GMT Subject: Withdrawn: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to an explicit `org.testng`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From mcimadamore at openjdk.java.net Wed Jun 2 21:35:46 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Jun 2021 21:35:46 GMT Subject: RFR: 8268131: 2 java/foreign tests timed out Message-ID: This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds. This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled. ------------- Commit messages: - * Increase timeout for TestUpcall/Downcall Changes: https://git.openjdk.java.net/jdk/pull/4321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4321&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268131 Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4321/head:pull/4321 PR: https://git.openjdk.java.net/jdk/pull/4321 From joe.darcy at oracle.com Wed Jun 2 21:44:06 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 2 Jun 2021 14:44:06 -0700 Subject: RFR: 8268131: 2 java/foreign tests timed out In-Reply-To: References: Message-ID: <3caaaff6-1008-6721-43e9-dcb0dbd53e9b@oracle.com> Can the test cases be broken into pieces or otherwise decomposed into several shorter-running tests? -Joe On 6/2/2021 2:35 PM, Maurizio Cimadamore wrote: > This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds. > > This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled. > > ------------- > > Commit messages: > - * Increase timeout for TestUpcall/Downcall > > Changes: https://git.openjdk.java.net/jdk/pull/4321/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4321&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8268131 > Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jdk/pull/4321.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/4321/head:pull/4321 > > PR: https://git.openjdk.java.net/jdk/pull/4321 From dcubed at openjdk.java.net Wed Jun 2 21:56:02 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 2 Jun 2021 21:56:02 GMT Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source Message-ID: A trivial copyright fix. ------------- Commit messages: - 8268146: fix for JDK-8266254 fails validate-source Changes: https://git.openjdk.java.net/jdk/pull/4323/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4323&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268146 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4323/head:pull/4323 PR: https://git.openjdk.java.net/jdk/pull/4323 From psandoz at openjdk.java.net Wed Jun 2 21:56:02 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 21:56:02 GMT Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 21:39:15 GMT, Daniel D. Daugherty wrote: > A trivial copyright fix. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4323 From dcubed at openjdk.java.net Wed Jun 2 21:56:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 2 Jun 2021 21:56:03 GMT Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 21:40:59 GMT, Paul Sandoz wrote: >> A trivial copyright fix. > > Marked as reviewed by psandoz (Reviewer). @PaulSandoz - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/4323 From wetmore at openjdk.java.net Wed Jun 2 21:56:03 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 2 Jun 2021 21:56:03 GMT Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 21:39:15 GMT, Daniel D. Daugherty wrote: > A trivial copyright fix. LGTM ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4323 From dcubed at openjdk.java.net Wed Jun 2 21:56:03 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 2 Jun 2021 21:56:03 GMT Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 21:39:15 GMT, Daniel D. Daugherty wrote: > A trivial copyright fix. This pull request has now been integrated. Changeset: 76fdf2c8 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/76fdf2c89bb7df9140438fcbaf16ea5fda024551 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8268146: fix for JDK-8266254 fails validate-source Reviewed-by: psandoz, wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/4323 From dcubed at openjdk.java.net Wed Jun 2 21:59:42 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 2 Jun 2021 21:59:42 GMT Subject: Integrated: 8268146: fix for JDK-8266254 fails validate-source In-Reply-To: References: Message-ID: <8feNIHDZ7xnu8UpIdaM-fZFSd-d90ymV7m0KpoPaeLQ=.6d1236a1-3ad0-49bf-93ef-4c0da97483e7@github.com> On Wed, 2 Jun 2021 21:50:24 GMT, Bradford Wetmore wrote: >> A trivial copyright fix. > > LGTM @bradfordwetmore - Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4323 From psandoz at openjdk.java.net Wed Jun 2 22:03:47 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 22:03:47 GMT Subject: RFR: 8267939: Clarify the specification of iterator and spliterator forEachRemaining Message-ID: The specification of `forEachRemaining`, accepting a primitive functional interface, on the primitive iterators is updated to be the same as for `Iterator.forEachRemaining`, specifically the following is added: *

* Subsequent behavior of an iterator is unspecified if the action throws an * exception. In addition the specification of `tryAdvance` and `forEachRemaining` on `Spliterator` and the primitive specializations are also updated to include a similar statement: * Subsequent behavior of a spliterator is unspecified if the action throws * an exception. ------------- Commit messages: - 8267939: Clarifiy the specification of iterator and spliterator forEachRemaining Changes: https://git.openjdk.java.net/jdk/pull/4290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4290&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267939 Stats: 48 lines in 2 files changed: 20 ins; 21 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4290/head:pull/4290 PR: https://git.openjdk.java.net/jdk/pull/4290 From smarks at openjdk.java.net Wed Jun 2 22:03:47 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 2 Jun 2021 22:03:47 GMT Subject: RFR: 8267939: Clarify the specification of iterator and spliterator forEachRemaining In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 19:54:59 GMT, Paul Sandoz wrote: > The specification of `forEachRemaining`, accepting a primitive functional interface, on the primitive iterators is updated to be the same as for `Iterator.forEachRemaining`, specifically the following is added: > > > *

> * Subsequent behavior of an iterator is unspecified if the action throws an > * exception. > > > In addition the specification of `tryAdvance` and `forEachRemaining` on `Spliterator` and the primitive specializations are also updated to include a similar statement: > > > * Subsequent behavior of a spliterator is unspecified if the action throws > * an exception. Generally, adding the "unspecified after an exception" clause in those places seems to be the correct thing to do here. Marked as reviewed by smarks (Reviewer). src/java.base/share/classes/java/util/PrimitiveIterator.java line 77: > 75: *

> 76: * The behavior of an iterator is unspecified if the action modifies the > 77: * collection in any way (even by calling the {@link #remove remove} method It's kind of odd to mention "the collection" here. Iterator is defined as being over a collection, but strictly speaking this isn't true; it can be an iterator over anything. PrimitiveIterator doesn't say anything more specific than this, just that it's a base for iterating primitives... and collections cannot contain primitives. I'm not sure what a better term for this is. Something like, "the underlying source of the Iterator"? ------------- Changes requested by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4290 From psandoz at openjdk.java.net Wed Jun 2 22:03:48 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 22:03:48 GMT Subject: RFR: 8267939: Clarify the specification of iterator and spliterator forEachRemaining In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 21:34:10 GMT, Stuart Marks wrote: >> The specification of `forEachRemaining`, accepting a primitive functional interface, on the primitive iterators is updated to be the same as for `Iterator.forEachRemaining`, specifically the following is added: >> >> >> *

>> * Subsequent behavior of an iterator is unspecified if the action throws an >> * exception. >> >> >> In addition the specification of `tryAdvance` and `forEachRemaining` on `Spliterator` and the primitive specializations are also updated to include a similar statement: >> >> >> * Subsequent behavior of a spliterator is unspecified if the action throws >> * an exception. > > src/java.base/share/classes/java/util/PrimitiveIterator.java line 77: > >> 75: *

>> 76: * The behavior of an iterator is unspecified if the action modifies the >> 77: * collection in any way (even by calling the {@link #remove remove} method > > It's kind of odd to mention "the collection" here. Iterator is defined as being over a collection, but strictly speaking this isn't true; it can be an iterator over anything. PrimitiveIterator doesn't say anything more specific than this, just that it's a base for iterating primitives... and collections cannot contain primitives. > > I'm not sure what a better term for this is. Something like, "the underlying source of the Iterator"? Yeah, well spotted. I agree it's awkward. How about we lean on the behavior of the boxed counterpart: /** * Performs the given action for each remaining element until all elements * have been processed or the action throws an exception. Actions are * performed in the order of iteration, if that order is specified. *

* This primitive-based method conforms to the same behavior as its * boxed counterpart with regards to the action's behavior. ? ------------- PR: https://git.openjdk.java.net/jdk/pull/4290 From smarks at openjdk.java.net Wed Jun 2 22:03:49 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 2 Jun 2021 22:03:49 GMT Subject: RFR: 8267939: Clarify the specification of iterator and spliterator forEachRemaining In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 22:40:53 GMT, Paul Sandoz wrote: >> src/java.base/share/classes/java/util/PrimitiveIterator.java line 77: >> >>> 75: *

>>> 76: * The behavior of an iterator is unspecified if the action modifies the >>> 77: * collection in any way (even by calling the {@link #remove remove} method >> >> It's kind of odd to mention "the collection" here. Iterator is defined as being over a collection, but strictly speaking this isn't true; it can be an iterator over anything. PrimitiveIterator doesn't say anything more specific than this, just that it's a base for iterating primitives... and collections cannot contain primitives. >> >> I'm not sure what a better term for this is. Something like, "the underlying source of the Iterator"? > > Yeah, well spotted. I agree it's awkward. How about we lean on the behavior of the boxed counterpart: > > /** > * Performs the given action for each remaining element until all elements > * have been processed or the action throws an exception. Actions are > * performed in the order of iteration, if that order is specified. > *

> * This primitive-based method conforms to the same behavior as its > * boxed counterpart with regards to the action's behavior. > ? Referring to the "boxed counterpart" is a bit too oblique, I think. The specification of Iterator itself isn't all that good to begin with. It's written as if the only possible source of an Iterator is a collection (which might have been true at first, but it isn't true any longer). But the rest of the Iterator spec refers to "the collection" so it kind of makes sense in that context. Maybe just making a minimal change from "collection" to "source of elements" would make the most sense. * The behavior of an iterator is unspecified if the action modifies the source of * elements in any way (even by calling the {@link #remove remove} method ------------- PR: https://git.openjdk.java.net/jdk/pull/4290 From psandoz at openjdk.java.net Wed Jun 2 22:03:49 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 22:03:49 GMT Subject: RFR: 8267939: Clarify the specification of iterator and spliterator forEachRemaining In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 23:37:10 GMT, Stuart Marks wrote: >> Yeah, well spotted. I agree it's awkward. How about we lean on the behavior of the boxed counterpart: >> >> /** >> * Performs the given action for each remaining element until all elements >> * have been processed or the action throws an exception. Actions are >> * performed in the order of iteration, if that order is specified. >> *

>> * This primitive-based method conforms to the same behavior as its >> * boxed counterpart with regards to the action's behavior. >> ? > > Referring to the "boxed counterpart" is a bit too oblique, I think. The specification of Iterator itself isn't all that good to begin with. It's written as if the only possible source of an Iterator is a collection (which might have been true at first, but it isn't true any longer). But the rest of the Iterator spec refers to "the collection" so it kind of makes sense in that context. > > Maybe just making a minimal change from "collection" to "source of elements" would make the most sense. > > * The behavior of an iterator is unspecified if the action modifies the source of > * elements in any way (even by calling the {@link #remove remove} method Ok, that works for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/4290 From almatvee at openjdk.java.net Wed Jun 2 22:16:37 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 2 Jun 2021 22:16:37 GMT Subject: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote: > JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Marked as reviewed by almatvee (Reviewer). Can we add a simple test for .scr executables? ------------- PR: https://git.openjdk.java.net/jdk/pull/4306 From david.holmes at oracle.com Wed Jun 2 22:20:31 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Jun 2021 08:20:31 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: <79372ef7-0027-1e7c-326b-a696d026152d@oracle.com> Message-ID: <469ed5e2-331a-0014-c9c2-0cc951971cef@oracle.com> On 3/06/2021 12:39 am, Peter Levart wrote: > On Wed, 2 Jun 2021 05:59:05 GMT, David Holmes wrote: > >> Sorry Jaroslav but I don't really see this test as a basic functional >> test of the PreserveAllAnnotations flag. There is no need for any >> dynamic retention mode switch. All you need as I've said previously is a >> class with all the CLASS retention annotations of interest (8 IIRC) >> applied and a programs that reads them, and either expects to find them >> or not, based on the PreserveAllAnnotations flag. > > `CLASS` retention annotations are never returned by reflection regardless of whether the `PreserveAllAnnotations` option was used Sorry yes - my bad. I missed that getRawAnnotations() output was then fed through the AnnotationsParser. Thanks, David ----- or not. The only way (apart from hacking into encapsulated state and doing your own parsing) is to compile a class that uses an annotation with `CLASS` retention and then run a test that looks up the annotation on this class after the annotation has been changed to have `RUNTIME` retention, but the class that uses it has not been recompiled. > `AltClassLoader` does the trick which replaces the class file of _v1 class with the class file of _v2 class when loading the class which simulates this change and recompilation of the annotation without changing anything else. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4280 > From psandoz at openjdk.java.net Wed Jun 2 22:19:37 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 22:19:37 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry [v2] In-Reply-To: References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: On Wed, 2 Jun 2021 17:54:06 GMT, Stuart Marks wrote: >> I'm fixing this along with a couple intertwined issues. >> >> 1. Add Map.Entry::copyOf as an idempotent copy operation. >> >> 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not really immutable) but that subclasses can be modifiable. >> >> 3. Clarify some confusing, historical wording about Map.Entry instances being obtainable only via iteration of a Map's entry-set view. This was never really true, since anyone could implement the Map.Entry interface, and it certainly was not true since JDK 1.6 when SimpleEntry and SimpleImmutableEntry were added. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Tiny editorial tweaks. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4295 From psandoz at openjdk.java.net Wed Jun 2 22:22:55 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 22:22:55 GMT Subject: RFR: 8267939: Clarify the specification of iterator and spliterator forEachRemaining [v2] In-Reply-To: References: Message-ID: > The specification of `forEachRemaining`, accepting a primitive functional interface, on the primitive iterators is updated to be the same as for `Iterator.forEachRemaining`, specifically the following is added: > > > *

> * Subsequent behavior of an iterator is unspecified if the action throws an > * exception. > > > In addition the specification of `tryAdvance` and `forEachRemaining` on `Spliterator` and the primitive specializations are also updated to include a similar statement: > > > * Subsequent behavior of a spliterator is unspecified if the action throws > * an exception. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Use source of elements. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4290/files - new: https://git.openjdk.java.net/jdk/pull/4290/files/fa786a40..97d2e741 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4290&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4290&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4290/head:pull/4290 PR: https://git.openjdk.java.net/jdk/pull/4290 From jjg at openjdk.java.net Wed Jun 2 22:29:47 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 22:29:47 GMT Subject: RFR: JDK-8268147: need to update reference to testng module for jtreg6 Message-ID: Please review a test fix to refer to the new name of the TestNG module. ------------- Commit messages: - JDK-8268147: need to update reference to testng module for jtreg6 Changes: https://git.openjdk.java.net/jdk/pull/4325/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4325&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268147 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4325.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4325/head:pull/4325 PR: https://git.openjdk.java.net/jdk/pull/4325 From dholmes at openjdk.java.net Wed Jun 2 22:37:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Jun 2021 22:37:44 GMT Subject: RFR: JDK-8268147: need to update reference to testng module for jtreg6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 22:22:22 GMT, Jonathan Gibbons wrote: > Please review a test fix to refer to the new name of the TestNG module. Looks good and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4325 From psandoz at openjdk.java.net Wed Jun 2 22:37:44 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Jun 2021 22:37:44 GMT Subject: RFR: JDK-8268147: need to update reference to testng module for jtreg6 In-Reply-To: References: Message-ID: <92ggUSc-rdXyGcvJvuVjs5WkW9l3_867aHwzt5ylQTQ=.b7c455bf-8786-43c9-b5a4-6edf04805e7c@github.com> On Wed, 2 Jun 2021 22:22:22 GMT, Jonathan Gibbons wrote: > Please review a test fix to refer to the new name of the TestNG module. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4325 From naoto at openjdk.java.net Wed Jun 2 22:37:44 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 2 Jun 2021 22:37:44 GMT Subject: RFR: JDK-8268147: need to update reference to testng module for jtreg6 In-Reply-To: References: Message-ID: <84PVbuT_sxJgt_2DUi9uzgOxdPmIFsostUYW_Uy6q6M=.e535f1e5-8aca-474a-a892-0c038af56989@github.com> On Wed, 2 Jun 2021 22:22:22 GMT, Jonathan Gibbons wrote: > Please review a test fix to refer to the new name of the TestNG module. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4325 From jjg at openjdk.java.net Wed Jun 2 22:37:44 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 2 Jun 2021 22:37:44 GMT Subject: Integrated: JDK-8268147: need to update reference to testng module for jtreg6 In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 22:22:22 GMT, Jonathan Gibbons wrote: > Please review a test fix to refer to the new name of the TestNG module. This pull request has now been integrated. Changeset: d46a2c8e Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/d46a2c8ecfac785ae2c935a507c3bcae2e76aba9 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8268147: need to update reference to testng module for jtreg6 Reviewed-by: dholmes, psandoz, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4325 From david.holmes at oracle.com Wed Jun 2 22:42:17 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Jun 2021 08:42:17 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <3tBMT73dGX4EXPS6lEhFuqfVobEyxiK0Qnj1MNezzx4=.c0b7749b-0f4d-47cd-aacd-bf6e78fdf378@github.com> References: <2297c0f1-f22a-ad1f-c145-b3222b51ac57@oracle.com> <3tBMT73dGX4EXPS6lEhFuqfVobEyxiK0Qnj1MNezzx4=.c0b7749b-0f4d-47cd-aacd-bf6e78fdf378@github.com> Message-ID: <420ed833-cb6a-70a5-4db3-7c2b0dc2d2bf@oracle.com> On 3/06/2021 1:38 am, Peter Levart wrote: > On Wed, 2 Jun 2021 13:24:10 GMT, David Holmes wrote: > >> Sorry now I see what happens. We aren't combining two arrays of >> annotations we're concatenating two streams of byes, each of which >> represents a set of annotations, starting with the length. >> >> The code that receives this on the JDK side doesn't seem to understand >> that this is a possibility. >> >> Though maybe this isn't a bug, maybe the AnnotationParser is >> deliberately ignoring the second byte stream. (Though if it were >> deliberate there should be some commentary to that affect!) >> >> David > > I think this is not deliberate. Since `rawAnnotations` may end up having any of the following: > - `RuntimeVisibleAnnotations` (when there were just `RUNTIME` annotation usages compiled into the class or `-XX+PreserveAllAnnotations` was not used at runtime) > - `RuntimeInvisibleAnnotations` (when there were just `CLASS` annotation usages compiled into the class and `-XX+PreserveAllAnnotations` was used at runtime) > - `RuntimeVisibleAnnotations + RuntimeInvisibleAnnotations` (when there were `RUNTIME` and `CLASS` annotation usages compiled into the class and `-XX+PreserveAllAnnotations` was used at runtime) > > So why would `RuntimeInvisibleAnnotations` be skipped in 3rd case but not in 2nd case? Well in the second case there is no way to know it is looking only at invisible annotations, so it has to read them and then discard them as they were in fact CLASS retention. The skipping could be seen as an optimization. The code is confusing because it gives no indication that it is aware that runtime invisible annotations could be present: /** * Parses the annotations described by the specified byte array. * resolving constant references in the specified constant pool. * The array must contain an array of annotations as described * in the RuntimeVisibleAnnotations_attribute: but at the same time it checks for the RUNTIME retention, which means it must have recognised the possibility there could be something else there. That check is day 2 code though, on day 1 there was this comment: /* XXX Uncomment when this meta-attribute on meta-attributes (Neal's putback) if (type.retention() == VisibilityLevel.RUNTIME) XXX */ But the end result is that the code in AnnotationParser correctly filters out all non-RUNTIME annotations, either directly, or by skipping them in the stream in the first place. So in that sense there is no bug, but the code could do with some additional comments. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4280 > From david.holmes at oracle.com Wed Jun 2 22:45:05 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Jun 2021 08:45:05 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <0d6d2f1c-d108-f7b8-6d69-e4b3b85573f2@oracle.com> References: <0d6d2f1c-d108-f7b8-6d69-e4b3b85573f2@oracle.com> Message-ID: <286793f3-9b38-baf6-d93c-2380dc97adeb@oracle.com> On 3/06/2021 2:54 am, Joe Darcy wrote: > If the reflection runtime doesn't implement the semantics of > -XX+PreserveAllAnnotations, I suggest deprecating/obsoleting/etc. that > option now. I have to agree with Joe now. I mistakenly thought the raw annotation stream was exposed to some parts of reflection, but now I see that it all goes through AnnotationParser, which strips out all non-Runtime retention annotations. So the flag is useless as the data it causes to be passed to the JDK is thrown away anyway. Cheers, David > -Joe > > On 6/2/2021 7:48 AM, Peter Levart wrote: >> On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach >> wrote: >> >>> There doesn't seem to be much support for the complete changes in >>> #4245. To get at least something useful from that endeavor I have >>> extracted the test for existing behavior of >>> `-XX:+PreserveAllAnnotations` and I am offering it in this pull >>> request without any changes to the JVM behavior. >> What I would do is to add a patch for the parser bug and then extend >> the test in 3 dimensions: >> - run it with and without the `-XX+PreserveAllAnnotations` option >> (adapt expected results accordingly) >> - test annotation use when besides the annotation that changes >> retention from CLASS -> RUNTIME there is another RUNTIME annotation >> present on the annotated element or not (this would fail before the >> bugfix) >> - test with different annotated elements (Class, Method, Field, >> Constructor, Parameter) to exercise different code paths in the VM. >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/4280 From smarks at openjdk.java.net Wed Jun 2 23:19:37 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 2 Jun 2021 23:19:37 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry [v2] In-Reply-To: References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: On Wed, 2 Jun 2021 18:07:55 GMT, Daniel Fuchs wrote: >> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: >> >> Tiny editorial tweaks. > > src/java.base/share/classes/java/util/Map.java line 396: > >> 394: >> 395: /** >> 396: * A map entry (key-value pair). The Entry may be unmodifiable, or the > > In that case then maybe it should be `{@code Entry}` in both places where `entry` was replaced with `Entry` ? Maybe. We're not terribly consistent about this. A fair amount of the docs just uses a plain-text, capitalized form of a class name, as opposed to the code font. Using the code font everywhere adds clutter to both the markup and to the rendered output. In this case I wanted to distinguish the generic mention of an entry in a map from an instance of an Entry object. In cases where it needs to be absolutely clear, I used `Map.Entry` (the qualified name, in code font). Doing that here seems like it would add too much clutter though. ------------- PR: https://git.openjdk.java.net/jdk/pull/4295 From smarks at openjdk.java.net Wed Jun 2 23:22:36 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 2 Jun 2021 23:22:36 GMT Subject: RFR: 8267939: Clarify the specification of iterator and spliterator forEachRemaining [v2] In-Reply-To: References: Message-ID: <21W6UKbB4rjIOemOQouBXY-DHrYi37-tc3JkdMTB6Ps=.93826138-5749-4cb1-845a-be2d92f575ad@github.com> On Wed, 2 Jun 2021 22:22:55 GMT, Paul Sandoz wrote: >> The specification of `forEachRemaining`, accepting a primitive functional interface, on the primitive iterators is updated to be the same as for `Iterator.forEachRemaining`, specifically the following is added: >> >> >> *

>> * Subsequent behavior of an iterator is unspecified if the action throws an >> * exception. >> >> >> In addition the specification of `tryAdvance` and `forEachRemaining` on `Spliterator` and the primitive specializations are also updated to include a similar statement: >> >> >> * Subsequent behavior of a spliterator is unspecified if the action throws >> * an exception. > > Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: > > Use source of elements. Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4290 From jjg at openjdk.java.net Thu Jun 3 00:55:50 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 3 Jun 2021 00:55:50 GMT Subject: RFR: JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 Message-ID: Please review a small test fix, to include hamcrest.jar, as required by the latest version of JUnit in jtreg 6. ------------- Commit messages: - JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 Changes: https://git.openjdk.java.net/jdk/pull/4328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4328&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268150 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4328/head:pull/4328 PR: https://git.openjdk.java.net/jdk/pull/4328 From almatvee at openjdk.java.net Thu Jun 3 01:08:37 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 3 Jun 2021 01:08:37 GMT Subject: RFR: JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 In-Reply-To: References: Message-ID: <9rLqRnj8Ur9DFTB92PdCCtF4Xwo6_abxp_GS-dnt7J8=.53ff4950-ddb1-42f7-884e-d76d96c4b72d@github.com> On Thu, 3 Jun 2021 00:47:45 GMT, Jonathan Gibbons wrote: > Please review a small test fix, to include hamcrest.jar, as required by the latest version of JUnit in jtreg 6. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4328 From jjg at openjdk.java.net Thu Jun 3 01:13:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 3 Jun 2021 01:13:38 GMT Subject: Integrated: JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 00:47:45 GMT, Jonathan Gibbons wrote: > Please review a small test fix, to include hamcrest.jar, as required by the latest version of JUnit in jtreg 6. This pull request has now been integrated. Changeset: ef01e478 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/ef01e478586c5676747195ea67c1864639305c0f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 Reviewed-by: almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/4328 From sviswanathan at openjdk.java.net Thu Jun 3 01:23:58 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 3 Jun 2021 01:23:58 GMT Subject: RFR: 8268151: Vector API toShuffle optimization Message-ID: The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. The following changes are made: 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. Best Regards, Sandhya ------------- Commit messages: - toShuffle optimization Changes: https://git.openjdk.java.net/jdk/pull/4326/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4326&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268151 Stats: 393 lines in 34 files changed: 314 ins; 42 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/4326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4326/head:pull/4326 PR: https://git.openjdk.java.net/jdk/pull/4326 From xgong at openjdk.java.net Thu Jun 3 02:11:41 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 3 Jun 2021 02:11:41 GMT Subject: RFR: 8267969: Add vectorized implementation for VectorMask.eq() [v2] In-Reply-To: References: <-oNx_BVgkjNGZHqtQhQ2hfnyibAd-NIj14iA3OUMBNk=.7be0c875-fab0-47b2-8af6-603eaf168941@github.com> <6zmaxCZzzCbYEptpG91NJBAu7REALkAWx3KyVpbChU0=.f4b5b1d7-17f3-4d98-8412-1beb4262c7b2@github.com> Message-ID: <0fZHxT2GO1RvbFYsMB0w21LVtzOcsw_m8YrifROVfJg=.7943248c-6e3b-4f8d-af36-2bca300c53c9@github.com> On Wed, 2 Jun 2021 07:48:47 GMT, Nils Eliasson wrote: > Please wait until you have two reviewers before integrating. Sure! Thanks so much for looking at this PR! ------------- PR: https://git.openjdk.java.net/jdk/pull/4272 From xgong at openjdk.java.net Thu Jun 3 02:30:36 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 3 Jun 2021 02:30:36 GMT Subject: RFR: 8268151: Vector API toShuffle optimization In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 00:29:00 GMT, Sandhya Viswanathan wrote: > The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. > > The following changes are made: > 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. > 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. > 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. > > Best Regards, > Sandhya src/hotspot/share/opto/vectornode.cpp line 1246: > 1244: return new VectorLoadMaskNode(value, out_vt); > 1245: } else if (is_vector_shuffle) { > 1246: if (!is_shuffle_to_vector()) { Hi @sviswa7 , thanks for this change! I'm just curious whether `is_shuffle_to_vector()` is still needed for `VectorUnboxNode` with this change? It seems this flag can be removed, doesn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From xgong at openjdk.java.net Thu Jun 3 02:36:41 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 3 Jun 2021 02:36:41 GMT Subject: RFR: 8268151: Vector API toShuffle optimization In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 00:29:00 GMT, Sandhya Viswanathan wrote: > The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. > > The following changes are made: > 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. > 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. > 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. > > Best Regards, > Sandhya src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 335: > 333: @ForceInline > 334: private final > 335: VectorShuffle toShuffleTemplate(AbstractSpecies dsp) { Is it better to move this template method to the super class like other APIs? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 350: > 348: Byte128Shuffle.class, byte.class, VLENGTH, > 349: this, VSPECIES, > 350: Byte128Vector::toShuffleTemplate); ditto ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From yyang at openjdk.java.net Thu Jun 3 02:56:35 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 3 Jun 2021 02:56:35 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6] In-Reply-To: <8RxYJZEePGo31FEahqK76i4h-q02mTtmfAYBg_3sjAY=.f6ff6a94-31b6-4149-8236-75b65dc82cf8@github.com> References: <8RxYJZEePGo31FEahqK76i4h-q02mTtmfAYBg_3sjAY=.f6ff6a94-31b6-4149-8236-75b65dc82cf8@github.com> Message-ID: On Tue, 1 Jun 2021 17:43:45 GMT, Igor Veresov wrote: >> Thank you @veresov! >> >> I'm glad to have more comments from hotspot-compiler group. >> >> Later, I'd like to integrate it if there are no more comments/objections. >> >> Thanks! >> Yang > > @kelthuzadx Sorry about the delay. Could you please rebase this to the current master and I'll push it. Thanks! @veresov I've rebased to the latest commit and resolved all conflicts. Please take a look at this. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From github.com+26887752+jaroslavtulach at openjdk.java.net Thu Jun 3 03:06:37 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Thu, 3 Jun 2021 03:06:37 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. FYI: The current test is a "mirror" copy of [AnnotationTypeRuntimeAssumptionTest.java](https://github.com/openjdk/jdk/blob/0f689ea8f29be113cc8a917a86fd9e0f85f921fc/test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java) with adjustments to cover the `CLASS`->`RUNTIME` migration. > What I would do is to add a patch for the parser bug That's an interesting discovery! I see a patch and I can include it as your commit in this PR, if there is a test... > and then extend the test in 3 dimensions: ...or just take my PR and expand it. Also the checkbox _"Allow edits and access to secrets by maintainers"_ is on - e.g. this PR is open for modifications. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From ngasson at openjdk.java.net Thu Jun 3 03:09:58 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 3 Jun 2021 03:09:58 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v2] In-Reply-To: References: Message-ID: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. > > [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Fixes after JEP integratioN Change-Id: Iaa13b3869522c8814c3f7ef4c1eac8e8267657e6 CustomizedGitHooks: yes - merge master Change-Id: Ic06fec084099ff2053dd251a255cbbf4a64a59d7 CustomizedGitHooks: yes - 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native macOS on Apple silicon uses slightly different ABI conventions to the standard AArch64 ABI. The differences are outlined in [1]. In particular in the standard (AAPCS) ABI, variadic arguments may be passed in either registers or on the stack following the normal calling convention. To handle this, va_list is a struct containing separate pointers for arguments located in integer registers, floating point registers, and on the stack. Apple's ABI simplifies this by passing all variadic arguments on the stack and the va_list type becomes a simple char* pointer. This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to represent the new ABI variant on macOS. StackVaList is based on WinVaList lightly modified to handle the different TypeClasses on AArch64. The original AArch64Linker is renamed to AapcsLinker and is currently used for all non-Mac platforms. I think we also need to add a WinAArch64 CABI but I haven't yet been able to test on a Windows system so will do that later. The macOS ABI also uses a different method of spilling arguments to the stack (the standard ABI pads each argument to a multiple of 8 byte stack slots, but the Mac ABI packs arguments according to their natural alignment). None of the existing tests exercise this so I'll open a new JBS issue and work on that separately. Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. ------------- Changes: https://git.openjdk.java.net/jdk/pull/3617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=01 Stats: 777 lines in 14 files changed: 571 ins; 115 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/3617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3617/head:pull/3617 PR: https://git.openjdk.java.net/jdk/pull/3617 From brian.goetz at oracle.com Thu Jun 3 03:21:23 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 2 Jun 2021 23:21:23 -0400 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: <6350e215-b0b5-8536-c8e7-33144cac1973@oracle.com> It seems pretty clear that this "feature" is a leftover from an early implementation, doesn't clearly say what it is supposed to do, is more complicated than it looks, and is buggily implemented.? While I understand the temptation to "fix" it, at this point we'd realistically be adding a basically entirely new reflection feature that hasn't gone through any sort of design analysis -- we'd just be guessing about what the original intent of this vestigial feature is.? It seems the reasonable options are to either leave it alone, deprecate it, or engage in a much more deliberate redesign.? (And given the fact that I can think of at least 1,000 things that are higher priority, I'd not be inclined to pursue the third option.) On 6/2/2021 11:06 PM, Jaroslav Tulach wrote: > On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > >> There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. > FYI: The current test is a "mirror" copy of [AnnotationTypeRuntimeAssumptionTest.java](https://github.com/openjdk/jdk/blob/0f689ea8f29be113cc8a917a86fd9e0f85f921fc/test/jdk/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java) with adjustments to cover the `CLASS`->`RUNTIME` migration. > >> What I would do is to add a patch for the parser bug > That's an interesting discovery! I see a patch and I can include it as your commit in this PR, if there is a test... > >> and then extend the test in 3 dimensions: > ...or just take my PR and expand it. Also the checkbox _"Allow edits and access to secrets by maintainers"_ is on - e.g. this PR is open for modifications. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4280 From ngasson at openjdk.java.net Thu Jun 3 03:28:56 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 3 Jun 2021 03:28:56 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v3] In-Reply-To: References: Message-ID: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. > > [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: No variadic upcalls Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5 CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3617/files - new: https://git.openjdk.java.net/jdk/pull/3617/files/645ccb3d..251aae68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3617/head:pull/3617 PR: https://git.openjdk.java.net/jdk/pull/3617 From ngasson at openjdk.java.net Thu Jun 3 03:29:04 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 3 Jun 2021 03:29:04 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 03:09:58 GMT, Nick Gasson wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Fixes after JEP integratioN > > Change-Id: Iaa13b3869522c8814c3f7ef4c1eac8e8267657e6 > CustomizedGitHooks: yes > - merge master > > Change-Id: Ic06fec084099ff2053dd251a255cbbf4a64a59d7 > CustomizedGitHooks: yes > - 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native > > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. I've rebased this on the latest master after the JEP integration and fixed the issues above. Should be good to re-review. I've done the suggested renaming to LinuxAArch64Linker, MacOsAArch64Linker, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From smarks at openjdk.java.net Thu Jun 3 03:43:36 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 3 Jun 2021 03:43:36 GMT Subject: RFR: 8268077: java.util.List missing from Collections Framework Overview In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 19:51:39 GMT, Raffaello Giulietti wrote: > Trivial changes to this non-normative document. Marked as reviewed by smarks (Reviewer). Looks good. Thanks for noticing and fixing this! ------------- PR: https://git.openjdk.java.net/jdk/pull/4289 From github.com+26887752+jaroslavtulach at openjdk.java.net Thu Jun 3 04:26:37 2021 From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach) Date: Thu, 3 Jun 2021 04:26:37 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <6350e215-b0b5-8536-c8e7-33144cac1973@oracle.com> References: <6350e215-b0b5-8536-c8e7-33144cac1973@oracle.com> Message-ID: <44QCIe6FpHMkdnUqXv_WogOsH0T0DNTFZ3SWh3KqoXs=.5036d994-278f-42e9-accb-adfaade6d681@github.com> On Thu, 3 Jun 2021 03:23:13 GMT, Brian Goetz wrote: > reasonable options are to either leave it alone, deprecate it, or engage > in a much more deliberate redesign.? My favorite option is to leave it alone and test it a bit with the test already provided in this PR. That however requires one approval, me to type `/integrate` and someone to type `/sponsor` - if my understanding of the skara bot is correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From iveresov at openjdk.java.net Thu Jun 3 04:41:41 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 3 Jun 2021 04:41:41 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v11] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 02:32:54 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - x86_32 fails > - build failed > - cmp clobbers its left argument on x86_32 > - better check1-4 > - AssertionError when expected exception was not thrown > - remove InlineNIOCheckIndex flag > - remove java_nio_Buffer in javaClasses.hpp > - consolidate `test/jdk/java/util/Objects/CheckIndex.java` and `test/jdk/java/util/Objects/CheckLongIndex.java` started failing. Please take a look. test CheckIndex.testCheckIndex(0, -2147483647, false): failure java.lang.AssertionError: Index 0 is out of bounds of [0, -2147483647), but was reported to be within bounds at org.testng.Assert.fail(Assert.java:94) at CheckIndex.lambda$testCheckIndex$3(CheckIndex.java:103) at CheckIndex.testCheckIndex(CheckIndex.java:117) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) at java.base/java.lang.Thread.run(Thread.java:831) test CheckIndex.testCheckIndex(0, -2147483648, false): failure java.lang.AssertionError: Index 0 is out of bounds of [0, -2147483648), but was reported to be within bounds at org.testng.Assert.fail(Assert.java:94) at CheckIndex.lambda$testCheckIndex$3(CheckIndex.java:103) at CheckIndex.testCheckIndex(CheckIndex.java:120) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) at java.base/java.lang.Thread.run(Thread.java:831) test CheckIndex.testCheckIndex(1, -1, false): failure java.lang.AssertionError: Index 1 is out of bounds of [0, -1), but was reported to be within bounds at org.testng.Assert.fail(Assert.java:94) at CheckIndex.lambda$testCheckIndex$3(CheckIndex.java:103) at CheckIndex.testCheckIndex(CheckIndex.java:130) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) at java.base/java.lang.Thread.run(Thread.java:831) ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From darcy at openjdk.java.net Thu Jun 3 05:48:51 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 3 Jun 2021 05:48:51 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 Message-ID: 8267630: Start of release updates for JDK 18 ------------- Commit messages: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Clean langtools test run. - ... and 1 more: https://git.openjdk.java.net/jdk/compare/ef01e478...9c7c88bf Changes: https://git.openjdk.java.net/jdk/pull/4175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267630 Stats: 4946 lines in 62 files changed: 4904 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From darcy at openjdk.java.net Thu Jun 3 05:48:51 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 3 Jun 2021 05:48:51 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 In-Reply-To: References: Message-ID: On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote: > 8267630: Start of release updates for JDK 18 JDK 18 is right around the corner, time for the usual start-of-release changeset for review. Typical structure for these kinds of changes. I'll update the symbol file information of JDK 17 b25 after that build is promoted. Usual updates to SourceVersion, javac, HotSpot, and version-oriented tests. Please also review the related CSRs: JDK-8268156: Add SourceVersion.RELEASE_18 https://bugs.openjdk.java.net/browse/JDK-8268156 JDK-8268157: Add source 18 and target 18 to javac https://bugs.openjdk.java.net/browse/JDK-8268157 ------------- PR: https://git.openjdk.java.net/jdk/pull/4175 From iris at openjdk.java.net Thu Jun 3 05:58:37 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 3 Jun 2021 05:58:37 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 In-Reply-To: References: Message-ID: On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote: > 8267630: Start of release updates for JDK 18 Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4175 From plevart at openjdk.java.net Thu Jun 3 06:49:37 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 3 Jun 2021 06:49:37 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <420ed833-cb6a-70a5-4db3-7c2b0dc2d2bf@oracle.com> References: <420ed833-cb6a-70a5-4db3-7c2b0dc2d2bf@oracle.com> Message-ID: On Wed, 2 Jun 2021 22:44:10 GMT, David Holmes wrote: > > I think this is not deliberate. Since `rawAnnotations` may end up having any of the following: > > - `RuntimeVisibleAnnotations` (when there were just `RUNTIME` annotation usages compiled into the class or `-XX+PreserveAllAnnotations` was not used at runtime) > > - `RuntimeInvisibleAnnotations` (when there were just `CLASS` annotation usages compiled into the class and `-XX+PreserveAllAnnotations` was used at runtime) > > - `RuntimeVisibleAnnotations + RuntimeInvisibleAnnotations` (when there were `RUNTIME` and `CLASS` annotation usages compiled into the class and `-XX+PreserveAllAnnotations` was used at runtime) > > So why would `RuntimeInvisibleAnnotations` be skipped in 3rd case but not in 2nd case? > > Well in the second case there is no way to know it is looking only at > invisible annotations, so it has to read them and then discard them as > they were in fact CLASS retention. The skipping could be seen as an > optimization. Not all annotations in the 2nd case need to be CLASS retention. They were CLASS retention when the class that uses them was compiled, but at runtime, the retention may be different (separate compilation). So they are actually returned by the reflection in that case. > > The code is confusing because it gives no indication that it is aware > that runtime invisible annotations could be present: > > /** > * Parses the annotations described by the specified byte array. > * resolving constant references in the specified constant pool. > * The array must contain an array of annotations as described > * in the RuntimeVisibleAnnotations_attribute: > > but at the same time it checks for the RUNTIME retention, which means it > must have recognised the possibility there could be something else > there. Yes, there could be a CLASS retention annotation there (even though `-XX+PreserveAllAnnotations` was not used at runtime, so rawAnnotations contains the content of `RuntimeVisibleAnnotations` only). Again, such annotation was RUNTIME retention when its use was compiled into a class, but at runtime such annotation may be updated to have CLASS or even SOURCE retention. Such annotation use is filtered out. > That check is day 2 code though, on day 1 there was this comment: > > /* XXX Uncomment when this meta-attribute on meta-attributes (Neal's > putback) > if (type.retention() == VisibilityLevel.RUNTIME) > XXX */ I guess this was just code in creation before release. At some point, the `RetentionPolicy` enum was added, but above comment refers to it by the name `VisibilityLevel`.... > > But the end result is that the code in AnnotationParser correctly > filters out all non-RUNTIME annotations, either directly, or by skipping > them in the stream in the first place. So in that sense there is no bug, > but the code could do with some additional comments. The problem is that it sometimes skips RUNTIME annotations too. I consider this a bug. > > Cheers, > David Regard, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From github.com+28651297+mkartashev at openjdk.java.net Thu Jun 3 06:59:09 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 3 Jun 2021 06:59:09 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v4] In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: <2y1L0zS1OMMm2QZAzbU1T146d_p84L_TSJDh0NRxw5U=.1eeb8ff0-31df-43f2-babf-a2745b96b9c4@github.com> > Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". > > This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. > > Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). > > The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. > > Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. > > Results from Linux: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 > ============================== > TEST SUCCESS > > > Building target 'run-test-only' in configuration 'linux-x86_64-server-release' > Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 > > > Results from Windows 10: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/runtime 746 746 0 0 > ============================== > TEST SUCCESS > Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' > > > Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' > Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision: Updated Java_jdk_internal_loader_NativeLibraries_load() to use a new helper function to get the library name encoded as true UTF-8 (not in "modified UTF-8" form). Also updated the test to automatically pass if "UTF-8" is not supported by NIO on the platform. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4169/files - new: https://git.openjdk.java.net/jdk/pull/4169/files/c8ef8b64..97c918ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=02-03 Stats: 71 lines in 4 files changed: 57 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/4169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169 PR: https://git.openjdk.java.net/jdk/pull/4169 From github.com+28651297+mkartashev at openjdk.java.net Thu Jun 3 06:59:14 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 3 Jun 2021 06:59:14 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> Message-ID: On Tue, 1 Jun 2021 18:24:05 GMT, Naoto Sato wrote: >> Maxim Kartashev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Coding style-related corrections. >> - Corrected the test to use Platform.sharedLibraryExt() > > src/hotspot/os/windows/os_windows.cpp line 1491: > >> 1489: static errno_t convert_UTF8_to_UTF16(char const* utf8_str, LPWSTR* utf16_str) { >> 1490: return convert_to_UTF16(utf8_str, CP_UTF8, utf16_str); >> 1491: } > > IIUC, `utf8_str` is the "modified" UTF-8 string in JNI. Using it as the standard UTF-8 (I believe Windows' encoding `CP_UTF8` is the one) may end up in incorrect conversions in some corner cases, e.g., for supplementary characters. Right; I changed the code in NativeLibraries.c to pass down true UTF-8 instead of "modified UTF-8". Please, take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From github.com+28651297+mkartashev at openjdk.java.net Thu Jun 3 07:01:45 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 3 Jun 2021 07:01:45 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> Message-ID: On Tue, 1 Jun 2021 18:42:34 GMT, Naoto Sato wrote: >> Maxim Kartashev has updated the pull request incrementally with two additional commits since the last revision: >> >> - Coding style-related corrections. >> - Corrected the test to use Platform.sharedLibraryExt() > > test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java line 42: > >> 40: String nativePathSetting = "-Dtest.nativepath=" + getSystemProperty("test.nativepath"); >> 41: ProcessBuilder pb = ProcessTools.createTestJvm(nativePathSetting, LoadLibraryUnicode.class.getName()); >> 42: pb.environment().put("LC_ALL", "en_US.UTF-8"); > > Some environments/user configs may not have `UTF-8` codeset on the platform. May need to gracefully exit in such a case. I added `java.nio.charset.Charset.isSupported("UTF-8")` check to the test. Hope that's enough for the environments without `UTF-8`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From plevart at openjdk.java.net Thu Jun 3 07:02:36 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 3 Jun 2021 07:02:36 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: <286793f3-9b38-baf6-d93c-2380dc97adeb@oracle.com> References: <286793f3-9b38-baf6-d93c-2380dc97adeb@oracle.com> Message-ID: On Wed, 2 Jun 2021 22:47:13 GMT, David Holmes wrote: > On 3/06/2021 2:54 am, Joe Darcy wrote: > > > If the reflection runtime doesn't implement the semantics of > > -XX+PreserveAllAnnotations, I suggest deprecating/obsoleting/etc. that > > option now. > > I have to agree with Joe now. I mistakenly thought the raw annotation > stream was exposed to some parts of reflection, but now I see that it > all goes through AnnotationParser, which strips out all non-Runtime > retention annotations. So the flag is useless as the data it causes to > be passed to the JDK is thrown away anyway. > > Cheers, > David We are constantly dancing around the same problem which is a false assumption that `RuntimeVisibleAnnotations` attribute contains only RUNTIME retention annotations and that `RuntimeInvisibleAnnotations` attribute contains only CLASS retention annotations. This is simply not true in a real world. It is only true in a world where either nothing changes from the day 1 when it is 1st created or in a world where all the sources that compose the application are always recompiled. Those two worlds are ideal worlds that don't exist. In other words, the flag is useless in the dream world(s) but not in the real world. ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From david.holmes at oracle.com Thu Jun 3 07:29:34 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Jun 2021 17:29:34 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: <420ed833-cb6a-70a5-4db3-7c2b0dc2d2bf@oracle.com> Message-ID: On 3/06/2021 4:49 pm, Peter Levart wrote: > On Wed, 2 Jun 2021 22:44:10 GMT, David Holmes wrote: > >>> I think this is not deliberate. Since `rawAnnotations` may end up having any of the following: >>> - `RuntimeVisibleAnnotations` (when there were just `RUNTIME` annotation usages compiled into the class or `-XX+PreserveAllAnnotations` was not used at runtime) >>> - `RuntimeInvisibleAnnotations` (when there were just `CLASS` annotation usages compiled into the class and `-XX+PreserveAllAnnotations` was used at runtime) >>> - `RuntimeVisibleAnnotations + RuntimeInvisibleAnnotations` (when there were `RUNTIME` and `CLASS` annotation usages compiled into the class and `-XX+PreserveAllAnnotations` was used at runtime) >>> So why would `RuntimeInvisibleAnnotations` be skipped in 3rd case but not in 2nd case? >> >> Well in the second case there is no way to know it is looking only at >> invisible annotations, so it has to read them and then discard them as >> they were in fact CLASS retention. The skipping could be seen as an >> optimization. > > Not all annotations in the 2nd case need to be CLASS retention. They were CLASS retention when the class that uses them was compiled, but at runtime, the retention may be different (separate compilation). So they are actually returned by the reflection in that case. > >> >> The code is confusing because it gives no indication that it is aware >> that runtime invisible annotations could be present: >> >> /** >> * Parses the annotations described by the specified byte array. >> * resolving constant references in the specified constant pool. >> * The array must contain an array of annotations as described >> * in the RuntimeVisibleAnnotations_attribute: >> >> but at the same time it checks for the RUNTIME retention, which means it >> must have recognised the possibility there could be something else >> there. > > Yes, there could be a CLASS retention annotation there (even though `-XX+PreserveAllAnnotations` was not used at runtime, so rawAnnotations contains the content of `RuntimeVisibleAnnotations` only). Again, such annotation was RUNTIME retention when its use was compiled into a class, but at runtime such annotation may be updated to have CLASS or even SOURCE retention. Such annotation use is filtered out. Sorry Peter I'm not following you. I am only talking about runtime here. The VM loads a class at runtime and examines the annotation attributes that exist in that classfile. Some will be visible annotations (which implies RUNTIME retention), others may be invisible (which implies !RUNTIME which I assume means CLASS). It provides access to these via the "raw annotations" and the reflection code then processes that through the AnnotationProcessor. I don't know exactly what you mean by an annotation use being compiled into a class, but I assume it is something like the way compile-time constants are compiled in. But I don't see how that relates to the current discussion. David ----- > >> That check is day 2 code though, on day 1 there was this comment: >> >> /* XXX Uncomment when this meta-attribute on meta-attributes (Neal's >> putback) >> if (type.retention() == VisibilityLevel.RUNTIME) >> XXX */ > > I guess this was just code in creation before release. At some point, the `RetentionPolicy` enum was added, but above comment refers to it by the name `VisibilityLevel`.... > >> >> But the end result is that the code in AnnotationParser correctly >> filters out all non-RUNTIME annotations, either directly, or by skipping >> them in the stream in the first place. So in that sense there is no bug, >> but the code could do with some additional comments. > > The problem is that it sometimes skips RUNTIME annotations too. I consider this a bug. >> >> Cheers, >> David > > Regard, Peter > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4280 > From jlahoda at openjdk.java.net Thu Jun 3 07:39:03 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Jun 2021 07:39:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v9] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Enhancing tests as suggested. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/80b1392b..79e3621b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=07-08 Stats: 44 lines in 1 file changed: 44 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From dfranken.jdk at gmail.com Thu Jun 3 07:47:46 2021 From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com) Date: Thu, 03 Jun 2021 09:47:46 +0200 Subject: Some questions about String interning for primitives Message-ID: <25a9daa4d426d6ef3ff0ac98615fab43ddbb922a.camel@gmail.com> Dear readers, Apologies in advance if these questions have been asked and discussed before or if they are on the wrong mailing list, maybe they are more suited for project Valhalla, I'm not sure. I was wondering if it would be possible / feasible to intern primitive values and byte arrays and use these interned values instead of creating a new object for each conversion. Currently, the following code prints 'false' as s1 and s2 are references to different objects: String s1 = Integer.toString(1); s1 = s1.intern(); // Makes no difference whether intern is called String s2 = Integer.toString(1); System.out.println(s1 == s2); I know that there is an integer cache for boxing / unboxing commonly used integers (for numbers ranging from -128 to 127), how about a String cache for commonly converted primitives? We could use the same ranges initially. I.e. when I use Integer.toString(1) I don't really care if I get a newly allocated String, I only care that I get back a String which equals "1" and it's okay if that is a reference to an interned value. Likewise with the mirrored variants such as String.valueOf(..). I was also wondering how byte conversions could work with such a cache. Currently, the only way for me to go from bytes to a String is with? new String(bytes, charset) which guarantees creation of a new String object each time. Well, what if the bytes often contain the same value? Would it be useful to be able to do: ? String s1 = String.valueOf(bytes, UTF_8); String s2 = String.valueOf(bytes, UTF_8); // <-- returns the same refrence as s1 Kind regards, Dave Franken From plevart at openjdk.java.net Thu Jun 3 08:06:43 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 3 Jun 2021 08:06:43 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: > There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior. > _Mailing list message from [Brian Goetz](mailto:brian.goetz at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > It seems pretty clear that this "feature" is a leftover from an early > implementation, doesn't clearly say what it is supposed to do, is more > complicated than it looks, and is buggily implemented.? I agree that this "feature" is poorly documented and buggily implemented, but I can't agree that it was not created for a reason. At least I can't so easily classify it as a "leftover". In particular because it makes sense. > While I > understand the temptation to "fix" it, at this point we'd realistically > be adding a basically entirely new reflection feature that hasn't gone > through any sort of design analysis. That "feature" is there already from JDK 5 days. We would not be adding it. The reason why we are dealing with it here is very simple. It was/is useful for solving a real world problem and a user (looking a Jaroslav) tried to use it, but because it was not documented, the user miss-interpreted its meaning and tried to propose a "patch" that would solve his problem in the wrong way. Through the discussion we established a more correct way to use the "feature" (he just has to modify the annotation). Jaroslav can use it. Nothing has to be done to it. Now because the feature wasn't documented and didn't even have a unit test, Jaroslav volunteered to create a test for it. Reviewing that test, I found an inconsistency and discovered a corner case where the "feature" behaves inconsistently. Now at this point we can either fix this inconsistency or not. I guess not many were affected by it since nobody officially complained and from that we can predict that it is highly unlikely that anybody will. > -- we'd just be guessing about what > the original intent of this vestigial feature is.? The feature makes sense to me. But would it help if we invited original authors (Joshua Bloch and/or Neal Gafter) to explain? Of course, it they're willing to participate and if they remember what the heck they were doing :-) ... > It seems the > reasonable options are to either leave it alone, deprecate it, or engage > in a much more deliberate redesign.? (And given the fact that I can > think of at least 1,000 things that are higher priority, I'd not be > inclined to pursue the third option.) I see deprecating a feature so easily on the terms of "it is not documented and it is buggy" and without even trying to understand the feature and the consequences of its deprecation as a more "ruthless" act than trying to fix its corner-case inconsistency by carefully paying attention to compatibility. The feature is clearly useful (a user is using it to solve the problem). Deprecating it and later removing it would leave such user(s) without a means to solve such problem(s). So I'm at least for leaving it alone at this point. Regards, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From dfuchs at openjdk.java.net Thu Jun 3 08:40:35 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 3 Jun 2021 08:40:35 GMT Subject: RFR: 8199318: add idempotent copy operation for Map.Entry [v2] In-Reply-To: References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: On Wed, 2 Jun 2021 17:54:06 GMT, Stuart Marks wrote: >> I'm fixing this along with a couple intertwined issues. >> >> 1. Add Map.Entry::copyOf as an idempotent copy operation. >> >> 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not really immutable) but that subclasses can be modifiable. >> >> 3. Clarify some confusing, historical wording about Map.Entry instances being obtainable only via iteration of a Map's entry-set view. This was never really true, since anyone could implement the Map.Entry interface, and it certainly was not true since JDK 1.6 when SimpleEntry and SimpleImmutableEntry were added. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Tiny editorial tweaks. Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4295 From plevart at openjdk.java.net Thu Jun 3 08:52:42 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 3 Jun 2021 08:52:42 GMT Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 07:31:14 GMT, David Holmes wrote: > > > The code is confusing because it gives no indication that it is aware > > > that runtime invisible annotations could be present: > > > /** > > > * Parses the annotations described by the specified byte array. > > > * resolving constant references in the specified constant pool. > > > * The array must contain an array of annotations as described > > > * in the RuntimeVisibleAnnotations_attribute: > > > but at the same time it checks for the RUNTIME retention, which means it > > > must have recognised the possibility there could be something else > > > there. > > > > > > Yes, there could be a CLASS retention annotation there (even though `-XX+PreserveAllAnnotations` was not used at runtime, so rawAnnotations contains the content of `RuntimeVisibleAnnotations` only). Again, such annotation was RUNTIME retention when its use was compiled into a class, but at runtime such annotation may be updated to have CLASS or even SOURCE retention. Such annotation use is filtered out. > > Sorry Peter I'm not following you. I am only talking about runtime here. > The VM loads a class at runtime and examines the annotation attributes > that exist in that classfile. Right, but into which annotation attribute (`RuntimeVisibleAnnotations` vs. `RuntimeInvisibleAnnotations`) of that class the annotation use was encoded depends on what retention the annotation had at compile time, because those attributes are created by `javac` compiler. > Some will be visible annotations (which > implies RUNTIME retention), others may be invisible (which implies > !RUNTIME which I assume means CLASS). It provides access to these via > the "raw annotations" and the reflection code then processes that > through the AnnotationProcessor. Right, so reflection code at runtime accesses the annotations that were compiled into the class annotation attributes by parsing them and filtering out all but RUNTIME annotations. But this filtering is done at runtime and uses annotation's current set of meta-annotations values (i.e. `@Retention`) which can differ from what this same annotation had at class compile time. So this is how current RUNTIME annotations can end up in the `RuntimeInvisibleAnnotations` class attribute and how current CLASS annotations can end up in `RuntimeVisibleAnnotations` class attribute. It's the consequence of separate compilation. > > I don't know exactly what you mean by an annotation use being compiled > into a class, but I assume it is something like the way compile-time > constants are compiled in. But I don't see how that relates to the > current discussion. An annotation use is the use of annotation in the source code to annotate something (Class, Method, Field, ...). For example: @AnnA public class Use { ... } `javac` decides into which class attribute (`RuntimeVisibleAnnotations` vs. `RuntimeInvisibleAnnotations`) of Use.class file it will encode the `@AnnA` use by examining `AnnA`'s `@Retention` meta-annotation at that time. Say that at that time the annotation was this: @Retention(CLASS) public @interface AnnA {} `javac` would encode the `Use`'s use of that annotation into the `RuntimeInvisibleAnnotations` attribute of `Use.class`. Now comes runtime. Annotation maintainer decides to lift the retention of `AnnA` annotation to RUNTIME and now it looks like this: @Retention(RUNTIME) public @interface AnnA {} He tries to run some new code to extract the annotation value from `Use` class at runtime via reflection, because now at runtime the annotation is updated to have RUNTIME retention. But he also doesn't have access to `Use.java` to recompile it with updated annotation. He just has access to `Use.class` that was compiled with an old version of the same annotation. As we said, `Use.class` has encoded the annotation use in its `RuntimeInvisibleAnnotations` attribute. Voila, here comes `-XX+PreserveAllAnnotations` option to enable passing `RuntimeInvisibleAnnotations` attribute with encoded annotations to the reflection runtime and annotation parser which would return such annotation use. Now imagine whole libraries with classes that use an annotation which began its life as CLASS annotation because it was paired with AnnotationProcessor(s) that processed those annotation uses at compile time, but now some runtime tool emerges that would like to see those annotations too. The maintainer accepts the proposal to promote annotation's retention from CLASS to RUNTIME in new version of annotation. But who is going to re-compile all those libraries? > > David Regards, Peter ------------- PR: https://git.openjdk.java.net/jdk/pull/4280 From jlahoda at openjdk.java.net Thu Jun 3 09:05:08 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 3 Jun 2021 09:05:08 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v10] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merging master into JDK-8262891 - Enhancing tests as suggested. - Fixing enum switch with patterns with guards. - Fixing tests. - Total pattern dominates the null pattern. - Properly report errors for pattern+default clash. - Avoiding unnecessary StackMap point. - Post-merge fix - need to include jdk.internal.javac in the list of packages used by jdk.compiler again, as we now (again) have a preview feature in javac. - Correcting LineNumberTable for rule switches. - Merging master into JDK-8262891 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/bdeaeb47...fa50b5fb ------------- Changes: https://git.openjdk.java.net/jdk/pull/3863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=09 Stats: 4828 lines in 79 files changed: 4509 ins; 118 del; 201 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Thu Jun 3 09:38:34 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 09:38:34 GMT Subject: RFR: 8268131: 2 java/foreign tests timed out In-Reply-To: References: Message-ID: <470Ie8cYZR3010uszP-dTRu8Y-7cKSDYqmHBqpJXXH8=.181f73f2-22b7-4ce9-b1fd-1990b3cbb464@github.com> On Wed, 2 Jun 2021 21:20:53 GMT, Maurizio Cimadamore wrote: > This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds. > > This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled. > _Mailing list message from [Joe Darcy](mailto:joe.darcy at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > Can the test cases be broken into pieces or otherwise decomposed into > several shorter-running tests? > > -Joe > > On 6/2/2021 2:35 PM, Maurizio Cimadamore wrote: I believe they can - but it would require more work - for now the goal was to bring tier4 testing back to stable. ------------- PR: https://git.openjdk.java.net/jdk/pull/4321 From pconcannon at openjdk.java.net Thu Jun 3 10:14:03 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 3 Jun 2021 10:14:03 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v2] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: Update java.lang to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4312/files - new: https://git.openjdk.java.net/jdk/pull/4312/files/72c93053..d705efbd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=00-01 Stats: 6221 lines in 174 files changed: 4475 ins; 1291 del; 455 mod Patch: https://git.openjdk.java.net/jdk/pull/4312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4312/head:pull/4312 PR: https://git.openjdk.java.net/jdk/pull/4312 From pconcannon at openjdk.java.net Thu Jun 3 11:01:04 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 3 Jun 2021 11:01:04 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:43:25 GMT, Naoto Sato wrote: >> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268124: small refactoring; fixed misplaced comment and added missing lambda operator > > src/java.base/share/classes/java/lang/CharacterData.java line 80: > >> 78: case 2 -> CharacterData02.instance; >> 79: case 3 -> CharacterData03.instance; >> 80: case 14 -> CharacterData0E.instance; // Private Use > > Plane 14 is not `private use` Hi Naoto. Well spotted. I've corrected that now. See a8706b0 > src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 90: > >> 88: // findVirtual etc. >> 89: return switch (refKind) { >> 90: case REF_invokeSpecial: { > > Is ':' preferred here (and other cases too) instead of "->"? My mistake. I've replaced the colon now with the lambda operator. See a8706b0 ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From pconcannon at openjdk.java.net Thu Jun 3 11:01:02 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 3 Jun 2021 11:01:02 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: 8268124: small refactoring; fixed misplaced comment and added missing lambda operator ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4312/files - new: https://git.openjdk.java.net/jdk/pull/4312/files/d705efbd..a8706b02 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=01-02 Stats: 52 lines in 6 files changed: 9 ins; 12 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/4312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4312/head:pull/4312 PR: https://git.openjdk.java.net/jdk/pull/4312 From pconcannon at openjdk.java.net Thu Jun 3 11:01:06 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 3 Jun 2021 11:01:06 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 16:06:42 GMT, R?mi Forax wrote: >> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268124: small refactoring; fixed misplaced comment and added missing lambda operator > > src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 1663: > >> 1661: case D_TYPE -> mv.visitInsn(Opcodes.DCONST_0); >> 1662: case L_TYPE -> mv.visitInsn(Opcodes.ACONST_NULL); >> 1663: default -> throw new InternalError("unknown type: " + type); > > perhaps > > mv.visitInsn(switch(type) { ... Hi Remi, thanks for the suggestion. I've added that in now. See commit a8706b0 > src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 278: > >> 276: private static boolean isObjectMethod(Method m) { >> 277: return switch (m.getName()) { >> 278: case "toString" -> (m.getReturnType() == String.class > > the extra parenthesis are not needed Parenthesis removed, as suggested. See a8706b0 > src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 366: > >> 364: } >> 365: default -> throw new IllegalArgumentException(methodName); >> 366: }; > > I thinki it's simpler to have something like that > > var handle = switch(methodName) { > ... > }; > return methodType != null ? new ConstantCallSite(handle) : handle; I think that looks better. I've made that change now. See a8706b0 ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From forax at openjdk.java.net Thu Jun 3 11:38:40 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 3 Jun 2021 11:38:40 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 10:57:16 GMT, Patrick Concannon wrote: > My mistake. I've replaced the colon now with the lambda operator. Drive by comment, in term of name, `->` is the arrow operator not the lambda operator. - lambda = parameters + arrow + code - arrow case = case + arrow + code The difference is important because a lambda is a function while an arrow case is a block. ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From forax at openjdk.java.net Thu Jun 3 11:43:34 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 3 Jun 2021 11:43:34 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:01:02 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8268124: small refactoring; fixed misplaced comment and added missing lambda operator Looks good to me ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From erikj at openjdk.java.net Thu Jun 3 12:42:40 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Jun 2021 12:42:40 GMT Subject: RFR: JDK-8266254: Update to use jtreg 6 [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:15:55 GMT, Jonathan Gibbons wrote: >> Please review the change to update to using jtreg 6. >> >> The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. >> >> All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to an explicit `org.testng`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years This PR wasn't handled properly when integrated. The change looks like it was pushed correctly and the bug was updated, so we are only missing some book keeping in the PR. I've filed https://bugs.openjdk.java.net/browse/SKARA-1069. ------------- PR: https://git.openjdk.java.net/jdk/pull/4315 From erikj at openjdk.java.net Thu Jun 3 12:51:36 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Jun 2021 12:51:36 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 In-Reply-To: References: Message-ID: <94PX9MLJgRcWFUR1VQtRdowvllf6j9JcTPPPLHXh-JM=.822be67f-5513-42a8-9342-78da0b315807@github.com> On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote: > 8267630: Start of release updates for JDK 18 Build change looks good. Please be aware of the incoming change https://bugs.openjdk.java.net/browse/JDK-8263468 which will add another version field to version-numbers.conf, which may need to be updated too. The exact policy around that is still unclear though. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4175 From david.holmes at oracle.com Thu Jun 3 12:56:02 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Jun 2021 22:56:02 +1000 Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested In-Reply-To: References: Message-ID: <4f33ebe2-b141-2048-c62d-fe69ef161a1c@oracle.com> Hi Peter, On 3/06/2021 6:52 pm, Peter Levart wrote: > On Thu, 3 Jun 2021 07:31:14 GMT, David Holmes wrote: > >>>> The code is confusing because it gives no indication that it is aware >>>> that runtime invisible annotations could be present: >>>> /** >>>> * Parses the annotations described by the specified byte array. >>>> * resolving constant references in the specified constant pool. >>>> * The array must contain an array of annotations as described >>>> * in the RuntimeVisibleAnnotations_attribute: >>>> but at the same time it checks for the RUNTIME retention, which means it >>>> must have recognised the possibility there could be something else >>>> there. >>> >>> >>> Yes, there could be a CLASS retention annotation there (even though `-XX+PreserveAllAnnotations` was not used at runtime, so rawAnnotations contains the content of `RuntimeVisibleAnnotations` only). Again, such annotation was RUNTIME retention when its use was compiled into a class, but at runtime such annotation may be updated to have CLASS or even SOURCE retention. Such annotation use is filtered out. >> >> Sorry Peter I'm not following you. I am only talking about runtime here. >> The VM loads a class at runtime and examines the annotation attributes >> that exist in that classfile. > > Right, but into which annotation attribute (`RuntimeVisibleAnnotations` vs. `RuntimeInvisibleAnnotations`) of that class the annotation use was encoded depends on what retention the annotation had at compile time, because those attributes are created by `javac` compiler. Okay >> Some will be visible annotations (which >> implies RUNTIME retention), others may be invisible (which implies >> !RUNTIME which I assume means CLASS). It provides access to these via >> the "raw annotations" and the reflection code then processes that >> through the AnnotationProcessor. > > Right, so reflection code at runtime accesses the annotations that were compiled into the class annotation attributes by parsing them and filtering out all but RUNTIME annotations. But this filtering is done at runtime and uses annotation's current set of meta-annotations values (i.e. `@Retention`) which can differ from what this same annotation had at class compile time. So this is how current RUNTIME annotations can end up in the `RuntimeInvisibleAnnotations` class attribute and how current CLASS annotations can end up in `RuntimeVisibleAnnotations` class attribute. It's the consequence of separate compilation. Okay I see what you are talking about in regards to separate compilation. >> >> I don't know exactly what you mean by an annotation use being compiled >> into a class, but I assume it is something like the way compile-time >> constants are compiled in. But I don't see how that relates to the >> current discussion. > > An annotation use is the use of annotation in the source code to annotate something (Class, Method, Field, ...). For example: > > > @AnnA > public class Use { ... } > > > `javac` decides into which class attribute (`RuntimeVisibleAnnotations` vs. `RuntimeInvisibleAnnotations`) of Use.class file it will encode the `@AnnA` use by examining `AnnA`'s `@Retention` meta-annotation at that time. Say that at that time the annotation was this: > > > @Retention(CLASS) > public @interface AnnA {} > > > `javac` would encode the `Use`'s use of that annotation into the `RuntimeInvisibleAnnotations` attribute of `Use.class`. > > > Now comes runtime. Annotation maintainer decides to lift the retention of `AnnA` annotation to RUNTIME and now it looks like this: > > > @Retention(RUNTIME) > public @interface AnnA {} > > > He tries to run some new code to extract the annotation value from `Use` class at runtime via reflection, because now at runtime the annotation is updated to have RUNTIME retention. But he also doesn't have access to `Use.java` to recompile it with updated annotation. He just has access to `Use.class` that was compiled with an old version of the same annotation. As we said, `Use.class` has encoded the annotation use in its `RuntimeInvisibleAnnotations` attribute. Voila, here comes `-XX+PreserveAllAnnotations` option to enable passing `RuntimeInvisibleAnnotations` attribute with encoded annotations to the reflection runtime and annotation parser which would return such annotation use. I see the picture you are painting and that things could work that way, but I don't know if I agree that this was an intention or that they should work that way. The separate compilation story with annotations is somewhat different to other separate compilation issues as the JVMS does not really provide any guidance here. The RuntimeInvisibleAnnotations are not even parsed by the VM so it know nothing about which annotation types are referred to, never loads those types or does any checking to see if the properties of that type (like Retention) remain the same. Even RuntimeVisibleAnnotations are only structurally parsed to see of there are annotations the VM has to be aware of (ie @Contended) but those can never be out-of-sync through separate compilation. So in essence these annotations are transparent to the VM and it simply hands them up to the JDK for interpretation. The code in AnnotationParser uses the current definition of the annotation type to determine things like Retention policy and uses that when checking what the VM has returned. > Now imagine whole libraries with classes that use an annotation which began its life as CLASS annotation because it was paired with AnnotationProcessor(s) that processed those annotation uses at compile time, but now some runtime tool emerges that would like to see those annotations too. The maintainer accepts the proposal to promote annotation's retention from CLASS to RUNTIME in new version of annotation. But who is going to re-compile all those libraries? Yes good point. I don't have an answer. I don't know what the evolution philosophy is/was with annotations. Cheers, David ----- >> >> David > > Regards, Peter > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4280 > From herrick at openjdk.java.net Thu Jun 3 12:59:46 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 3 Jun 2021 12:59:46 GMT Subject: RFR: JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6 In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 00:47:45 GMT, Jonathan Gibbons wrote: > Please review a small test fix, to include hamcrest.jar, as required by the latest version of JUnit in jtreg 6. looks fine ------------- PR: https://git.openjdk.java.net/jdk/pull/4328 From roger.riggs at oracle.com Thu Jun 3 13:50:38 2021 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 3 Jun 2021 09:50:38 -0400 Subject: Some questions about String interning for primitives In-Reply-To: <25a9daa4d426d6ef3ff0ac98615fab43ddbb922a.camel@gmail.com> References: <25a9daa4d426d6ef3ff0ac98615fab43ddbb922a.camel@gmail.com> Message-ID: Hi Dave, Have you seen the related thread about Integer.toString()? https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-April/076454.html Allocation is cheap and short lived object storage is quick to be reclaimed. What's missing is data about the cost vs savings in real applications. And it extends all the way down to memory timing changes for recently accessed memory vs not recently accessed memory, multi-level memory caches, etc. Regards, Roger On 6/3/21 3:47 AM, dfranken.jdk at gmail.com wrote: > Dear readers, > > Apologies in advance if these questions have been asked and discussed > before or if they are on the wrong mailing list, maybe they are more > suited for project Valhalla, I'm not sure. > > I was wondering if it would be possible / feasible to intern primitive > values and byte arrays and use these interned values instead of > creating a new object for each conversion. > > Currently, the following code prints 'false' as s1 and s2 are > references to different objects: > > String s1 = Integer.toString(1); > s1 = s1.intern(); // Makes no difference whether intern is called > String s2 = Integer.toString(1); > System.out.println(s1 == s2); > > I know that there is an integer cache for boxing / unboxing commonly > used integers (for numbers ranging from -128 to 127), how about a > String cache for commonly converted primitives? We could use the same > ranges initially. > > I.e. when I use Integer.toString(1) I don't really care if I get a > newly allocated String, I only care that I get back a String which > equals "1" and it's okay if that is a reference to an interned value. > Likewise with the mirrored variants such as String.valueOf(..). > > I was also wondering how byte conversions could work with such a cache. > Currently, the only way for me to go from bytes to a String is with > new String(bytes, charset) which guarantees creation of a new String > object each time. Well, what if the bytes often contain the same value? > > Would it be useful to be able to do: > > String s1 = String.valueOf(bytes, UTF_8); > String s2 = String.valueOf(bytes, UTF_8); // <-- returns the same > refrence as s1 > > Kind regards, > > Dave Franken > > From naoto at openjdk.java.net Thu Jun 3 14:52:37 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 3 Jun 2021 14:52:37 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:01:02 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8268124: small refactoring; fixed misplaced comment and added missing lambda operator LGTM ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4312 From psandoz at openjdk.java.net Thu Jun 3 15:21:44 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 3 Jun 2021 15:21:44 GMT Subject: Integrated: 8266317: Vector API enhancements In-Reply-To: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> References: <9SrHXt3Om3jkyg0A4_X-L3YSMFM4Ib7Y6blBVFcs_Ik=.3122d7fc-e762-4982-ac8c-46cb43b5606a@github.com> Message-ID: On Thu, 29 Apr 2021 21:13:38 GMT, Paul Sandoz wrote: > This PR contains API and implementation changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Enhancements are made to the API for the support of operations on characters, such as for UTF-8 character decoding. Specifically, methods for loading/storing a `short` vector from/to a `char[]` array, and new vector comparison operators for unsigned comparisons with integral vectors. The x64 implementation is enhanced to supported unsigned comparisons. > > Enhancements are made to the API for loading/storing a `byte` vector from/to a `boolean[]` array. > > The testing of loads/stores can be expanded for scatter/gather, but before doing that i think some refactoring of the tests is required to reposition tests in the right classes. I would like to do that work after integration of the PR. This pull request has now been integrated. Changeset: 5982cfc8 Author: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/5982cfc85602862608fae56adb6041794e8c0d59 Stats: 10017 lines in 121 files changed: 9085 ins; 190 del; 742 mod 8266317: Vector API enhancements Co-authored-by: Paul Sandoz Co-authored-by: Sandhya Viswanathan Reviewed-by: jbhateja, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3803 From dcubed at openjdk.java.net Thu Jun 3 15:43:36 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 3 Jun 2021 15:43:36 GMT Subject: RFR: 8268131: 2 java/foreign tests timed out In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 21:20:53 GMT, Maurizio Cimadamore wrote: > This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds. > > This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled. Thumbs up. You might starting with 240 instead of 720 for the initial timeout bump. I would definitely prefer to have Tier4 quiet down for the upcoming code fork so increasing the timeout is good from my GK POV. These two tests were using the default timeout of 120 seconds/2 minutes and with a default timeoutFactor of 4 (set by the test task), the total timeout was 480 seconds/8 minutes. I recommend change the timeout from 720 to 240. That will give you a total timeout of 960 seconds/16 minutes. For the TestDowncall.java failure, that should cover that case. For the TestUpcall.java failure, we don't know if doubling the total timeout will cover that case or not because that test didn't pass while the timeout handler is running. However, doubling is a good start for a bump. Also, using a higher timeout value doesn't hurt anything if the test doesn't timeout. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4321 From herrick at openjdk.java.net Thu Jun 3 16:07:13 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 3 Jun 2021 16:07:13 GMT Subject: RFR: JDK-8267598: jpackage removes system libraries from java.library.path [v2] In-Reply-To: References: Message-ID: > JDK-8267598: jpackage removes system libraries from java.library.path Andy Herrick 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: - JDK-8267598: jpackage removes system libraries from java.library.path - Merge branch 'master' into JDK-8267598 - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4203/files - new: https://git.openjdk.java.net/jdk/pull/4203/files/a0b5c0e8..3639dde4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4203&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4203&range=00-01 Stats: 60464 lines in 2313 files changed: 10695 ins; 45162 del; 4607 mod Patch: https://git.openjdk.java.net/jdk/pull/4203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4203/head:pull/4203 PR: https://git.openjdk.java.net/jdk/pull/4203 From github.com+70726043+rgiulietti at openjdk.java.net Thu Jun 3 16:11:41 2021 From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti) Date: Thu, 3 Jun 2021 16:11:41 GMT Subject: Integrated: 8268077: java.util.List missing from Collections Framework Overview In-Reply-To: References: Message-ID: <4-sW5vUMPrc9vkRgSVV-qg9eltNxc55xc-d2XYakqxc=.380671af-6524-4c1a-8f1b-dac4224f2c14@github.com> On Tue, 1 Jun 2021 19:51:39 GMT, Raffaello Giulietti wrote: > Trivial changes to this non-normative document. This pull request has now been integrated. Changeset: 5405f983 Author: Raffaello Giulietti Committer: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/5405f983db7d359bb65c42366541104c5e9ef7c3 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod 8268077: java.util.List missing from Collections Framework Overview Reviewed-by: smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/4289 From mcimadamore at openjdk.java.net Thu Jun 3 16:23:02 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 16:23:02 GMT Subject: RFR: 8268131: 2 java/foreign tests timed out [v2] In-Reply-To: References: Message-ID: > This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds. > > This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Adjust timeout, according to review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4321/files - new: https://git.openjdk.java.net/jdk/pull/4321/files/b4329076..1ce9ff64 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4321&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4321&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4321/head:pull/4321 PR: https://git.openjdk.java.net/jdk/pull/4321 From mcimadamore at openjdk.java.net Thu Jun 3 16:23:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 16:23:03 GMT Subject: RFR: 8268131: 2 java/foreign tests timed out In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 21:20:53 GMT, Maurizio Cimadamore wrote: > This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds. > > This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled. I've adjusted timeout to 240, following suggestions - let's see what happens. ------------- PR: https://git.openjdk.java.net/jdk/pull/4321 From mcimadamore at openjdk.java.net Thu Jun 3 16:23:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 16:23:03 GMT Subject: Integrated: 8268131: 2 java/foreign tests timed out In-Reply-To: References: Message-ID: <78ruNVks35AQBv2SsnM3Atnz8_XKak3AMhy9KoqlCbo=.b5c0fe65-4d47-40c1-b89f-869eb0ac96ec@github.com> On Wed, 2 Jun 2021 21:20:53 GMT, Maurizio Cimadamore wrote: > This patch increases time out for both TestUpcall and TestDowncall. These tests were already long-running, but with JEP-412, they were beefed up even more, so now they time out on some debug builds. > > This patch also address a minor issue in TestResourceScope which can sometimes lead to intermittent failure, depending on how threads are scheduled. This pull request has now been integrated. Changeset: 52d8215a Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/52d8215a1ec42d67217505fe3167c70460f5a639 Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod 8268131: 2 java/foreign tests timed out Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4321 From duke at openjdk.java.net Thu Jun 3 16:28:41 2021 From: duke at openjdk.java.net (duke) Date: Thu, 3 Jun 2021 16:28:41 GMT Subject: Withdrawn: 8264896: Remove redundant '& 0xFF' from int-to-byte cast In-Reply-To: References: Message-ID: On Thu, 4 Mar 2021 12:16:29 GMT, ?????? ??????? wrote: > When we do > > byte b1 = (byte) (value & 0xFF); > > we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below: > > public class Main { > public static void main(String[] args) throws Exception { > IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> { > byte b1 = (byte) (value & 0xFF); > byte b2 = (byte) value; > if (b1 != b2) { > throw new RuntimeException("" + value); > } > }); > } > > > Also tier1 and tier2 are both OK. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2826 From mcimadamore at openjdk.java.net Thu Jun 3 16:39:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 16:39:25 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v5] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Forgot to add makefile for building shim library ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/7be87eae..6480332c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=03-04 Stats: 53 lines in 1 file changed: 53 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Thu Jun 3 16:43:51 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 16:43:51 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v6] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into symbolLookup - Forgot to add makefile for building shim library - Address review comments - Update test/jdk/java/foreign/TestIntrinsics.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/valist/VaListTest.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestVarArgs.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestUpcall.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestIllegalLink.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestSymbolLookup.java Co-authored-by: Paul Sandoz - Update test/jdk/java/foreign/TestDowncall.java Co-authored-by: Paul Sandoz - ... and 6 more: https://git.openjdk.java.net/jdk/compare/52d8215a...2545e2b6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4316/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=05 Stats: 1351 lines in 47 files changed: 626 ins; 621 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From mchung at openjdk.java.net Thu Jun 3 17:09:39 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Jun 2021 17:09:39 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:01:02 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8268124: small refactoring; fixed misplaced comment and added missing lambda operator Looks good with one minor comment in `DirectMethodHandleDescImpl.java`. src/java.base/share/classes/java/lang/constant/DirectMethodHandleDescImpl.java line 138: > 136: public String lookupDescriptor() { > 137: return switch (kind) { > 138: case VIRTUAL, SPECIAL, Nit: I prefer to have each case in a separate line (in this switch and also the switch in `resolveConstantDesc`. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4312 From iris at openjdk.java.net Thu Jun 3 17:23:39 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 3 Jun 2021 17:23:39 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:01:02 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: > > 8268124: small refactoring; fixed misplaced comment and added missing lambda operator Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From naoto at openjdk.java.net Thu Jun 3 17:51:40 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 3 Jun 2021 17:51:40 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> Message-ID: <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> On Thu, 3 Jun 2021 06:55:26 GMT, Maxim Kartashev wrote: >> src/hotspot/os/windows/os_windows.cpp line 1491: >> >>> 1489: static errno_t convert_UTF8_to_UTF16(char const* utf8_str, LPWSTR* utf16_str) { >>> 1490: return convert_to_UTF16(utf8_str, CP_UTF8, utf16_str); >>> 1491: } >> >> IIUC, `utf8_str` is the "modified" UTF-8 string in JNI. Using it as the standard UTF-8 (I believe Windows' encoding `CP_UTF8` is the one) may end up in incorrect conversions in some corner cases, e.g., for supplementary characters. > > Right; I changed the code in NativeLibraries.c to pass down true UTF-8 instead of "modified UTF-8". Please, take a look. I am not sure we can pass non `modified UTF-8` through `JVM_LoadLibrary()`. Probably some VM folks can enlighten here? ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From sviswanathan at openjdk.java.net Thu Jun 3 17:52:12 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 3 Jun 2021 17:52:12 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v17] In-Reply-To: References: Message-ID: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge master - update javadoc - correct javadoc - Javadoc changes - correct ppc.ad - Merge master - Commit missing changes - Implement Vladimir Ivanov and Paul Sandoz review comments - fix 32-bit build - Add comments explaining naming convention - ... and 11 more: https://git.openjdk.java.net/jdk/compare/52d8215a...03ac3197 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=16 Stats: 416073 lines in 119 files changed: 415886 ins; 124 del; 63 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From naoto at openjdk.java.net Thu Jun 3 17:54:38 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 3 Jun 2021 17:54:38 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> Message-ID: On Thu, 3 Jun 2021 06:59:01 GMT, Maxim Kartashev wrote: >> test/hotspot/jtreg/runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java line 42: >> >>> 40: String nativePathSetting = "-Dtest.nativepath=" + getSystemProperty("test.nativepath"); >>> 41: ProcessBuilder pb = ProcessTools.createTestJvm(nativePathSetting, LoadLibraryUnicode.class.getName()); >>> 42: pb.environment().put("LC_ALL", "en_US.UTF-8"); >> >> Some environments/user configs may not have `UTF-8` codeset on the platform. May need to gracefully exit in such a case. > > I added `java.nio.charset.Charset.isSupported("UTF-8")` check to the test. Hope that's enough for the environments without `UTF-8`. `Charset.isSupported()` returns whether Java encoder/decoder supports it or not, not the platform has the codeset. I think we can simply limit the test platform only to Windows in `@requires` tag in the test. Also, I would see the test case using some supplementary characters. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From jvernee at openjdk.java.net Thu Jun 3 18:06:39 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 3 Jun 2021 18:06:39 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v3] In-Reply-To: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> References: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> Message-ID: On Thu, 3 Jun 2021 03:28:56 GMT, Nick Gasson wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > No variadic upcalls > > Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5 > CustomizedGitHooks: yes Looks very good, thanks! ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3617 From asemenyuk at openjdk.java.net Thu Jun 3 18:23:48 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Thu, 3 Jun 2021 18:23:48 GMT Subject: RFR: JDK-8267598: jpackage removes system libraries from java.library.path [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 16:07:13 GMT, Andy Herrick wrote: >> JDK-8267598: jpackage removes system libraries from java.library.path > > Andy Herrick 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: > > - JDK-8267598: jpackage removes system libraries from java.library.path > - Merge branch 'master' into JDK-8267598 > - JDK-8267598: jpackage removes system libraries from java.library.path > - JDK-8267598: jpackage removes system libraries from java.library.path > - JDK-8267598: jpackage removes system libraries from java.library.path > - JDK-8267598: jpackage removes system libraries from java.library.path > - JDK-8267598: jpackage removes system libraries from java.library.path > - JDK-8267598: jpackage removes system libraries from java.library.path Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4203 From erikj at openjdk.java.net Thu Jun 3 18:24:43 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Jun 2021 18:24:43 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v6] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 16:43:51 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >> >> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: >> >> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader >> * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. >> >> Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into symbolLookup > - Forgot to add makefile for building shim library > - Address review comments > - Update test/jdk/java/foreign/TestIntrinsics.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/valist/VaListTest.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestVarArgs.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestUpcall.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestIllegalLink.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestSymbolLookup.java > > Co-authored-by: Paul Sandoz > - Update test/jdk/java/foreign/TestDowncall.java > > Co-authored-by: Paul Sandoz > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/52d8215a...2545e2b6 Looks pretty good, just a few comments. make/modules/jdk.incubator.foreign/Lib.gmk line 28: > 26: include LibCommon.gmk > 27: > 28: ifeq ($(call isTargetOs, linux), true) Please indent everything inside the ifeq-block 2 spaces. (See http://openjdk.java.net/groups/build/doc/code-conventions.html) make/modules/jdk.incubator.foreign/Lib.gmk line 34: > 32: CFLAGS := $(CFLAGS_JDKLIB), \ > 33: CXXFLAGS := $(CXXFLAGS_JDKLIB), \ > 34: LDFLAGS := -Wl$(COMMA)--no-as-needed -lc -lm -ldl $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN), \ Unless you link with any other library in the JDK (typically libjava and/or libjvm), I don't think there is a need for adding SET_SHARED_LIBRARY_ORIGIN. Please put all the -l* flags in LIBS rather than LDFLAGS. I also recommend putting any additional flags after the general LDFLAGS_JDKLIB. That way you are guaranteed that your flag takes precedence over anything that may be added to LDFLAGS_JDKLIB in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mchung at openjdk.java.net Thu Jun 3 18:27:47 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Jun 2021 18:27:47 GMT Subject: RFR: 8267995: Add reference to JVMS class file format in Lookup::defineHiddenClass Message-ID: Trivial javadoc change to add a reference to JVMS 4.1 in `Lookup::defineHiddenClass` such that the reference like `this_class` would be referred to JVMS for details. ------------- Commit messages: - 8267995: Add reference to JVMS class file format in Lookup::defineHiddenClass Changes: https://git.openjdk.java.net/jdk/pull/4340/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4340&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267995 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4340.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4340/head:pull/4340 PR: https://git.openjdk.java.net/jdk/pull/4340 From darcy at openjdk.java.net Thu Jun 3 18:39:40 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 3 Jun 2021 18:39:40 GMT Subject: RFR: 8267995: Add reference to JVMS class file format in Lookup::defineHiddenClass In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 18:21:31 GMT, Mandy Chung wrote: > Trivial javadoc change to add a reference to JVMS 4.1 in `Lookup::defineHiddenClass` such that the reference like `this_class` would be referred to JVMS for details. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4340 From sviswanathan at openjdk.java.net Thu Jun 3 18:42:37 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 3 Jun 2021 18:42:37 GMT Subject: RFR: 8268151: Vector API toShuffle optimization In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 02:27:35 GMT, Xiaohong Gong wrote: >> The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. >> >> The following changes are made: >> 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. >> 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. >> 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. >> >> Best Regards, >> Sandhya > > src/hotspot/share/opto/vectornode.cpp line 1246: > >> 1244: return new VectorLoadMaskNode(value, out_vt); >> 1245: } else if (is_vector_shuffle) { >> 1246: if (!is_shuffle_to_vector()) { > > Hi @sviswa7 , thanks for this change! I'm just curious whether `is_shuffle_to_vector()` is still needed for `VectorUnboxNode` with this change? It seems this flag can be removed, doesn't it? @XiaohongGong is_shuffle_to_vector is still needed as we shouldn't generate VectorLoadShuffleNode for shuffle.toVector. ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From peter.levart at gmail.com Thu Jun 3 18:49:05 2021 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 3 Jun 2021 20:49:05 +0200 Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> Message-ID: <85e523a7-9d9f-aaf5-7f39-b5bf6f33a8ee@gmail.com> On 02/06/2021 19:24, R?mi Forax wrote: > I foolishly hoped that nobody would subclass a class with `Immutable` in its name, > oh boy i was wrong:) There's nothing wrong in subclassing an immutable class. As long as the subclass keeps being immutable. Was it subclassed and made mutable by that? Peter From raffaello.giulietti at gmail.com Thu Jun 3 18:57:13 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 3 Jun 2021 20:57:13 +0200 Subject: Comment on JDK-826722: SoftReference not cleared on OutOfMemoryError: Requested array size exceeds VM limit Message-ID: <60ca3edc-0c66-cbda-71ab-1a7f20cb21aa@gmail.com> Hi, upon reading [1] I tried a similar scenario, but where OOME are caused by "Java heap space" exhaustion rather than by VM limits. import java.lang.ref.SoftReference; import java.text.DecimalFormat; import java.util.ArrayList; public class Softly { public static void main(String[] args) { var size = Integer.parseInt(args[0]); var format = new DecimalFormat("#,###"); var news = 0; var ref = new SoftReference<>(new ArrayList<>()); for (;;) { byte[] b = null; try { b = new byte[size]; ++news; ref.get().add(b); } catch (NullPointerException __) { System.out.format("totSize = %20s, allocations = %d\n", format.format((long) news * size), news); ref = new SoftReference<>(new ArrayList<>()); ref.get().add(b); } catch (OutOfMemoryError e) { if (ref.refersTo(null)) { throw new AssertionError("allocations = %d".formatted((news)), e); } throw new AssertionError("non-null referent", e); } } } } E.g., java -XX:+UseG1GC -Xms1g -Xmx1g -cp ... Softly 800000000 Depending on the collector and how tight the heap is, I sometimes observe a "Java heap space" OOME but then the referent of ref is null. I never observed a OOME with a non-null referent for ref. Hence, in scenarios where OOME are caused by heap exhaustion, soft refs seem to work as advertised. Tried on AdoptOpenJDK-16.0.1+9 with SerialGC, ParallelGC, G1GC, ZGC and ShenandoahGC with either -Xms1g/-Xmx1g or -Xms2g/-Xmx2g (small heaps) and various byte[] sizes. Thus, the current wording in SoftReference's javadoc: "All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError." could be amended to read: "All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError caused by Java heap space exhaustion." Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8267222 From herrick at openjdk.java.net Thu Jun 3 19:05:57 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 3 Jun 2021 19:05:57 GMT Subject: Integrated: JDK-8267598: jpackage removes system libraries from java.library.path In-Reply-To: References: Message-ID: <2Xa1XBNPyBKHyDIgWjTLMZlseqsIdVwZCJH5hQgv1w8=.d6a4dc1e-6d60-44b4-8319-c8c1211fce76@github.com> On Wed, 26 May 2021 11:26:24 GMT, Andy Herrick wrote: > JDK-8267598: jpackage removes system libraries from java.library.path This pull request has now been integrated. Changeset: af3df630 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/af3df6300efddc8ba12f095b87205cc2fea1f1e8 Stats: 38 lines in 9 files changed: 26 ins; 5 del; 7 mod 8267598: jpackage removes system libraries from java.library.path Reviewed-by: almatvee, asemenyuk ------------- PR: https://git.openjdk.java.net/jdk/pull/4203 From forax at univ-mlv.fr Thu Jun 3 19:46:51 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 3 Jun 2021 21:46:51 +0200 (CEST) Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <85e523a7-9d9f-aaf5-7f39-b5bf6f33a8ee@gmail.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> <85e523a7-9d9f-aaf5-7f39-b5bf6f33a8ee@gmail.com> Message-ID: <1866512166.517025.1622749611477.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Peter Levart" > ?: "R?mi Forax" , "core-libs-dev" > Envoy?: Jeudi 3 Juin 2021 20:49:05 > Objet: Re: RFR: 8199318: add idempotent copy operation for Map.Entry > On 02/06/2021 19:24, R?mi Forax wrote: >> I foolishly hoped that nobody would subclass a class with `Immutable` in its >> name, >> oh boy i was wrong:) > > > There's nothing wrong in subclassing an immutable class. As long as the > subclass keeps being immutable. Was it subclassed and made mutable by that? It has to be immutable all the way up, you have the same issue if the subclass is not final. If you filter out guava an google cache, github get you 12 pages of result and only one stupid code https://github.com/klayders/interlude/blob/95fd59a911d2baa8ac36ae6b877955aa4fbd095e/src/main/java/l2/gameserver/skills/SkillEntry.java#L12 A lot of code uses SimpleImmutableEntry as a pair, my hope is that the introduction of records will clean that practice. That said, there is also several broken codes, mostly two issues, either a.equals(n) is not equivalent to b.equals(a) or a.equals(b) is not equivalent to a.compareTo(b) == 0. I kind of regret that the compiler does not provide automatically an implementation of compareTo if the record implements Comparable. People sucks at writing compareTo and the resulting bugs are hard to find/reproduce. > > > Peter R?mi From sviswanathan at openjdk.java.net Thu Jun 3 20:07:09 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 3 Jun 2021 20:07:09 GMT Subject: Integrated: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 19:07:28 GMT, Sandhya Viswanathan wrote: > This PR contains Short Vector Math Library support related changes for [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), in preparation for when targeted. > > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > Looking forward to your review and feedback. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 This pull request has now been integrated. Changeset: 9f05c411 Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/jdk/commit/9f05c411e6d6bdf612cf0cf8b9fe4ca9ecde50d1 Stats: 416073 lines in 119 files changed: 415886 ins; 124 del; 63 mod 8265783: Create a separate library for x86 Intel SVML assembly intrinsics Co-authored-by: Sandhya Viswanathan Co-authored-by: Rahul Kandu Co-authored-by: Razvan Lupusoru Co-authored-by: Magnus Ihse Bursie Co-authored-by: Jie Fu Co-authored-by: Ahmet Akkas Co-authored-by: Marius Cornea Reviewed-by: erikj, kvn, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/3638 From dlsmith at openjdk.java.net Thu Jun 3 20:12:20 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Thu, 3 Jun 2021 20:12:20 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:03:53 GMT, Dan Smith wrote: > Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. > > Does some renaming of core parameters/fields to better reflect their purpose. > > In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). CSR was completed months ago: JDK-8221255. Just never got around to pushing the changes. Since then, InnerClassLambdaMetafactory was changed significantly, but the the public API is unchanged. In testing, I discovered one issue leading to an internal error: JDK-8268192. I commented out my test case and will follow up on that issue separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From dlsmith at openjdk.java.net Thu Jun 3 20:12:20 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Thu, 3 Jun 2021 20:12:20 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation Message-ID: Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. Does some renaming of core parameters/fields to better reflect their purpose. In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). ------------- Commit messages: - Remove use of ACC_BRIDGE - Comment out failing test cases, will fix separately - Fixes from merge - Merge branch 'master' into 8174222 - 8174222: LambdaMetafactory: validate inputs and improve documentation Changes: https://git.openjdk.java.net/jdk/pull/4346/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4346&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8174222 Stats: 726 lines in 4 files changed: 397 ins; 33 del; 296 mod Patch: https://git.openjdk.java.net/jdk/pull/4346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4346/head:pull/4346 PR: https://git.openjdk.java.net/jdk/pull/4346 From dlsmith at openjdk.java.net Thu Jun 3 20:40:23 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Thu, 3 Jun 2021 20:40:23 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: > Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. > > Does some renaming of core parameters/fields to better reflect their purpose. > > In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Fix accidentally commented-out parts of test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4346/files - new: https://git.openjdk.java.net/jdk/pull/4346/files/81db8e5e..4b8d0dab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4346&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4346&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4346/head:pull/4346 PR: https://git.openjdk.java.net/jdk/pull/4346 From mchung at openjdk.java.net Thu Jun 3 20:46:03 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Jun 2021 20:46:03 GMT Subject: Integrated: 8267995: Add reference to JVMS class file format in Lookup::defineHiddenClass In-Reply-To: References: Message-ID: <5NhutM2GbTTxIXAEyPbxcY2xPtIWAiqrf3Ei7JcnFzk=.ed5d3d14-6483-4c9d-b94f-4ec9f21670ee@github.com> On Thu, 3 Jun 2021 18:21:31 GMT, Mandy Chung wrote: > Trivial javadoc change to add a reference to JVMS 4.1 in `Lookup::defineHiddenClass` such that the reference like `this_class` would be referred to JVMS for details. This pull request has now been integrated. Changeset: b9558655 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/b95586559ca44b040261168cbe5ba90689cab17e Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8267995: Add reference to JVMS class file format in Lookup::defineHiddenClass Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/4340 From mcimadamore at openjdk.java.net Thu Jun 3 20:49:44 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Jun 2021 20:49:44 GMT Subject: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7] In-Reply-To: References: Message-ID: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments on shim lib makefile ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4316/files - new: https://git.openjdk.java.net/jdk/pull/4316/files/2545e2b6..23d66faf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4316&range=05-06 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/4316.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4316/head:pull/4316 PR: https://git.openjdk.java.net/jdk/pull/4316 From john.r.rose at oracle.com Thu Jun 3 20:51:28 2021 From: john.r.rose at oracle.com (John Rose) Date: Thu, 3 Jun 2021 20:51:28 +0000 Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <1866512166.517025.1622749611477.JavaMail.zimbra@u-pem.fr> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> <85e523a7-9d9f-aaf5-7f39-b5bf6f33a8ee@gmail.com> <1866512166.517025.1622749611477.JavaMail.zimbra@u-pem.fr> Message-ID: <929CF9E3-6D4D-4504-8446-5EEE2E00EA76@oracle.com> On Jun 3, 2021, at 12:46 PM, Remi Forax > wrote: I kind of regret that the compiler does not provide automatically an implementation of compareTo if the record implements Comparable. People sucks at writing compareTo and the resulting bugs are hard to find/reproduce. That?s a slippery slope. IIRC we consciously stopped before that step. That said, there are other ways to fix this. We should have utilities (maybe in the JDK but not the JLS) which build such methods and make it easy for users to grab onto them. Maybe something like this: interface ComparableRecord> extends Comparable { ? } record Foo(int x, String y) implements ComparableRecord { ? } http://cr.openjdk.java.net/~jrose/draft/ComparableRecord.java ? John From scolebourne at openjdk.java.net Thu Jun 3 20:59:24 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Thu, 3 Jun 2021 20:59:24 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v6] In-Reply-To: References: Message-ID: > 8266846: Add java.time.InstantSource Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: 8266846: Add java.time.InstantSource ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4016/files - new: https://git.openjdk.java.net/jdk/pull/4016/files/f01c5cdd..d564956c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4016&range=04-05 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4016.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4016/head:pull/4016 PR: https://git.openjdk.java.net/jdk/pull/4016 From joehw at openjdk.java.net Thu Jun 3 21:30:05 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 3 Jun 2021 21:30:05 GMT Subject: Integrated: 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 18:17:43 GMT, Joe Wang wrote: > Special characters are different in File and URI. Treat File input as File using FileInputStream instead of converting to an URI, but fall back to URI in case of error for compatibility (in error handling). This pull request has now been integrated. Changeset: 460ce555 Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/460ce5553c587715ef8244bee7e363b3587d2d0f Stats: 39 lines in 2 files changed: 31 ins; 1 del; 7 mod 8266019: StreamResult(File) writes to incorrect file path if # is part of the file path Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/4318 From henryjen at openjdk.java.net Thu Jun 3 21:32:58 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Thu, 3 Jun 2021 21:32:58 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Mon, 31 May 2021 20:23:53 GMT, Vladimir Kempik wrote: >> src/java.base/macosx/native/libjli/java_md_macosx.m line 727: >> >>> 725: >>> 726: static size_t alignUp(size_t stack_size) { >>> 727: long page_size = sysconf(_SC_PAGESIZE); >> >> In hotspot we use `getpagesize()`. There is also a guard for a very large stack (within a page of SIZE_MAX) so that rounding up does not produce zero. > > sounds like that (getpagesize) should work with m1 mac as well, as they have 16k pages. will it ? sysconf is the portable way based on POSIX, we can use getpagesize give this is macOS specific code, which is BSD based. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From rriggs at openjdk.java.net Thu Jun 3 21:38:02 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 3 Jun 2021 21:38:02 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v6] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:59:24 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From sviswanathan at openjdk.java.net Thu Jun 3 21:43:19 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 3 Jun 2021 21:43:19 GMT Subject: RFR: 8268151: Vector API toShuffle optimization [v2] In-Reply-To: References: Message-ID: > The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. > > The following changes are made: > 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. > 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. > 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. > > Best Regards, > Sandhya Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: Implement review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4326/files - new: https://git.openjdk.java.net/jdk/pull/4326/files/d5652051..ab582a1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4326&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4326&range=00-01 Stats: 657 lines in 38 files changed: 161 ins; 465 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/4326.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4326/head:pull/4326 PR: https://git.openjdk.java.net/jdk/pull/4326 From sviswanathan at openjdk.java.net Thu Jun 3 21:43:21 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 3 Jun 2021 21:43:21 GMT Subject: RFR: 8268151: Vector API toShuffle optimization [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 02:31:51 GMT, Xiaohong Gong wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement review comments > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 335: > >> 333: @ForceInline >> 334: private final >> 335: VectorShuffle toShuffleTemplate(AbstractSpecies dsp) { > > Is it better to move this template method to the super class like other APIs? Yes, can be moved to super class. Done in the updated commit. > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 350: > >> 348: Byte128Shuffle.class, byte.class, VLENGTH, >> 349: this, VSPECIES, >> 350: Byte128Vector::toShuffleTemplate); > > ditto Yes, can be moved to super class. Done in the updated commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From forax at univ-mlv.fr Thu Jun 3 21:49:40 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 3 Jun 2021 23:49:40 +0200 (CEST) Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <929CF9E3-6D4D-4504-8446-5EEE2E00EA76@oracle.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> <85e523a7-9d9f-aaf5-7f39-b5bf6f33a8ee@gmail.com> <1866512166.517025.1622749611477.JavaMail.zimbra@u-pem.fr> <929CF9E3-6D4D-4504-8446-5EEE2E00EA76@oracle.com> Message-ID: <2053163058.530291.1622756980790.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "Remi Forax" > Cc: "Peter Levart" , "R?mi Forax" > , "core-libs-dev" > Envoy?: Jeudi 3 Juin 2021 22:51:28 > Objet: Re: RFR: 8199318: add idempotent copy operation for Map.Entry > On Jun 3, 2021, at 12:46 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> I kind of regret that the compiler does not provide automatically an >> implementation of compareTo if the record implements Comparable. >> People sucks at writing compareTo and the resulting bugs are hard to >> find/reproduce. > That?s a slippery slope. IIRC we consciously stopped > before that step. > That said, there are other ways to fix this. We should > have utilities (maybe in the JDK but not the JLS) which > build such methods and make it easy for users to grab onto > them. Maybe something like this: > interface ComparableRecord> > extends Comparable { ? } > record Foo(int x, String y) implements ComparableRecord { ? } > [ http://cr.openjdk.java.net/~jrose/draft/ComparableRecord.java | > http://cr.openjdk.java.net/~jrose/draft/ComparableRecord.java ] The main issue with this kind of code is that the JIT does not see through the ClassValue. Tweaking a little bit your code, I get (It's a PITA that we have to use a raw type to workaround circularly defined parameter type) import java.util.ArrayList; import java.util.Comparator; import java.util.List; import java.util.stream.Stream; @SuppressWarnings({"rawtypes","unchecked"}) interface ComparableRecord> extends Comparable { @Override default int compareTo(T that) { if (this.getClass() != that.getClass()) { throw new IllegalArgumentException("not same class"); } return COMPARE_TO_METHODS.get(this.getClass()).compare(this, that); } static final ClassValue> COMPARE_TO_METHODS = new ClassValue<>() { @Override protected Comparator computeValue(Class type) { return Stream.of(type.getRecordComponents()) .map(component -> { var accessor = component.getAccessor(); return Comparator.comparing(r -> { try { return (Comparable) accessor.invoke(r); } catch (ReflectiveOperationException ex) { throw new IllegalArgumentException(ex); } }); }) .reduce((r1, r2) -> 0, Comparator::thenComparing, (_1, _2) -> { throw null; }); } }; static void main(String[] args) { record Foo(int x, String y) implements ComparableRecord { } var list = Stream.of(new Foo(2, "foo"), new Foo(2, "bar")) .sorted().toList(); System.out.println(list); } } > ? John From darcy at openjdk.java.net Thu Jun 3 21:50:06 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 3 Jun 2021 21:50:06 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v6] In-Reply-To: References: Message-ID: <2DtCnY5BLnkmkbPI5P-2-mx0SQgOnsPfvh_kCWh7Pps=.d2f44270-b5f4-46d5-bd16-58e5517228be@github.com> On Thu, 3 Jun 2021 20:59:24 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From naoto at openjdk.java.net Thu Jun 3 21:50:07 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 3 Jun 2021 21:50:07 GMT Subject: RFR: 8266846: Add java.time.InstantSource [v6] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:59:24 GMT, Stephen Colebourne wrote: >> 8266846: Add java.time.InstantSource > > Stephen Colebourne has updated the pull request incrementally with one additional commit since the last revision: > > 8266846: Add java.time.InstantSource Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From henryjen at openjdk.java.net Thu Jun 3 22:02:03 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Thu, 3 Jun 2021 22:02:03 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS In-Reply-To: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: <55QzA7l_EivRHfR3SVZglTN-Zldc4OzWvRKzMWnUeYk=.23265afe-8902-4bb4-8a4a-906e34200519@github.com> On Fri, 28 May 2021 21:55:24 GMT, Henry Jen wrote: > ?d on macOS > > This patch simply round up the specified stack size to multiple of the system page size. > > Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. > > ```code:java > public class StackLeak { > public int depth = 0; > public void stackLeak() { > depth++; > stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Withdraw for keep current behavior for compatibility. It would be preferred for user to specify proper value than we change the value on user's behalf. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From henryjen at openjdk.java.net Thu Jun 3 22:02:03 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Thu, 3 Jun 2021 22:02:03 GMT Subject: Withdrawn: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS In-Reply-To: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Fri, 28 May 2021 21:55:24 GMT, Henry Jen wrote: > ?d on macOS > > This patch simply round up the specified stack size to multiple of the system page size. > > Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. > > ```code:java > public class StackLeak { > public int depth = 0; > public void stackLeak() { > depth++; > stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From psandoz at openjdk.java.net Thu Jun 3 22:03:56 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 3 Jun 2021 22:03:56 GMT Subject: RFR: 8268151: Vector API toShuffle optimization [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 21:43:19 GMT, Sandhya Viswanathan wrote: >> The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. >> >> The following changes are made: >> 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. >> 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. >> 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. >> >> Best Regards, >> Sandhya > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Implement review comments Java changes look good. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4326 From psandoz at openjdk.java.net Thu Jun 3 22:07:01 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 3 Jun 2021 22:07:01 GMT Subject: Integrated: 8267939: Clarify the specification of iterator and spliterator forEachRemaining In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 19:54:59 GMT, Paul Sandoz wrote: > The specification of `forEachRemaining`, accepting a primitive functional interface, on the primitive iterators is updated to be the same as for `Iterator.forEachRemaining`, specifically the following is added: > > > *

> * Subsequent behavior of an iterator is unspecified if the action throws an > * exception. > > > In addition the specification of `tryAdvance` and `forEachRemaining` on `Spliterator` and the primitive specializations are also updated to include a similar statement: > > > * Subsequent behavior of a spliterator is unspecified if the action throws > * an exception. This pull request has now been integrated. Changeset: c1f3094f Author: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/c1f3094f814a4f3586222aad50ed314906b5bc9c Stats: 48 lines in 2 files changed: 20 ins; 21 del; 7 mod 8267939: Clarify the specification of iterator and spliterator forEachRemaining Reviewed-by: smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/4290 From forax at univ-mlv.fr Thu Jun 3 22:17:01 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 4 Jun 2021 00:17:01 +0200 (CEST) Subject: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <929CF9E3-6D4D-4504-8446-5EEE2E00EA76@oracle.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> <85e523a7-9d9f-aaf5-7f39-b5bf6f33a8ee@gmail.com> <1866512166.517025.1622749611477.JavaMail.zimbra@u-pem.fr> <929CF9E3-6D4D-4504-8446-5EEE2E00EA76@oracle.com> Message-ID: <1427667238.532375.1622758621090.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "Remi Forax" < forax at univ-mlv.fr > > Cc: "Peter Levart" < peter.levart at gmail.com >, "R?mi Forax" < > forax at openjdk.java.net >, "core-libs-dev" < core-libs-dev at openjdk.java.net > > Envoy?: Jeudi 3 Juin 2021 22:51:28 > Objet: Re: RFR: 8199318: add idempotent copy operation for Map.Entry > On Jun 3, 2021, at 12:46 PM, Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> I kind of regret that the compiler does not provide automatically an >> implementation of compareTo if the record implements Comparable. >> People sucks at writing compareTo and the resulting bugs are hard to >> find/reproduce. > That?s a slippery slope. IIRC we consciously stopped > before that step. > That said, there are other ways to fix this. We should > have utilities (maybe in the JDK but not the JLS) which > build such methods and make it easy for users to grab onto > them. Maybe something like this: > interface ComparableRecord> > extends Comparable { ? } > record Foo(int x, String y) implements ComparableRecord { ? } > [ http://cr.openjdk.java.net/~jrose/draft/ComparableRecord.java | > http://cr.openjdk.java.net/~jrose/draft/ComparableRecord.java ] [repost with a link] The main issue with this kind of code is that the JIT does not see through the ClassValue. Tweaking a little bit your code, I get https://gist.github.com/forax/e76367e1a90bf011692ee9bec65ff0f8 (It's a PITA that we have to use a raw type to workaround circularly defined parameter type) > ? John R?mi From sviswanathan at openjdk.java.net Thu Jun 3 22:34:59 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 3 Jun 2021 22:34:59 GMT Subject: RFR: 8268151: Vector API toShuffle optimization [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 22:01:12 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement review comments > > Java changes look good. @PaulSandoz Thanks a lot for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From mchung at openjdk.java.net Thu Jun 3 23:07:58 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Jun 2021 23:07:58 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote: >> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. >> >> Does some renaming of core parameters/fields to better reflect their purpose. >> >> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Fix accidentally commented-out parts of test Looks fine to me. The CSR was approved for 13 and its fixVersion should be updated to 17. test/jdk/java/lang/invoke/lambda/MetafactoryArgValidationTest.java line 2: > 1: /* > 2: * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. copyright year needs update. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4346 From psandoz at openjdk.java.net Thu Jun 3 23:07:58 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 3 Jun 2021 23:07:58 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote: >> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. >> >> Does some renaming of core parameters/fields to better reflect their purpose. >> >> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Fix accidentally commented-out parts of test Code looks good, nice test. ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From joe.darcy at oracle.com Thu Jun 3 23:31:49 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 3 Jun 2021 16:31:49 -0700 Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: Yes, the CSR should be re-reviewed before the change goes in. I've changed the CSR status to indicate it needs another review. -Joe On 6/3/2021 4:07 PM, Mandy Chung wrote: > On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote: > >>> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. >>> >>> Does some renaming of core parameters/fields to better reflect their purpose. >>> >>> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix accidentally commented-out parts of test > Looks fine to me. The CSR was approved for 13 and its fixVersion should be updated to 17. > > test/jdk/java/lang/invoke/lambda/MetafactoryArgValidationTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. > copyright year needs update. > > ------------- > > Marked as reviewed by mchung (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/4346 From john.r.rose at oracle.com Fri Jun 4 00:05:41 2021 From: john.r.rose at oracle.com (John Rose) Date: Fri, 4 Jun 2021 00:05:41 +0000 Subject: [External] : Re: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <1427667238.532375.1622758621090.JavaMail.zimbra@u-pem.fr> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> <85e523a7-9d9f-aaf5-7f39-b5bf6f33a8ee@gmail.com> <1866512166.517025.1622749611477.JavaMail.zimbra@u-pem.fr> <929CF9E3-6D4D-4504-8446-5EEE2E00EA76@oracle.com> <1427667238.532375.1622758621090.JavaMail.zimbra@u-pem.fr> Message-ID: <9FDCA856-5585-427E-87EC-5D069DAAD08F@oracle.com> On Jun 3, 2021, at 3:17 PM, forax at univ-mlv.fr wrote: ________________________________ De: "John Rose" > ?: "Remi Forax" > Cc: "Peter Levart" >, "R?mi Forax" >, "core-libs-dev" > Envoy?: Jeudi 3 Juin 2021 22:51:28 Objet: Re: RFR: 8199318: add idempotent copy operation for Map.Entry ... interface ComparableRecord> extends Comparable { ? } record Foo(int x, String y) implements ComparableRecord { ? } http://cr.openjdk.java.net/~jrose/draft/ComparableRecord.java [repost with a link] The main issue with this kind of code is that the JIT does not see through the ClassValue. Wow, it?s almost as if we?ve discussed this already! ;-) So, https://bugs.openjdk.java.net/browse/JDK-8238260 Part of my agenda here is finding more reasons why JDK-8238260 deserves some love. Currently, the translation strategy for Records requires a lot of boilerplate generated into each subclass for toString, equals, and hashCode. It is partially declarative, because it uses indy. So, yay for that. But it is also a bad smell (IMO) that the trick needs to be played in each subclass. If ClassValue were performant, we could have just one method in Record for each of toString, equals, and hashCode, and have them DTRT. The user code would then be able to call super.toString() to get the standard behavior in a refining wrapper method in a subclass. Looking further, it would be nice to have methods which (a) inherit from supers as reusable code ought to, but (b) re-specialize themselves once per subclass indy-style. This is a VM trick I hope to look into after we do specialization. For now, ClassValue is the way to simulate that. Tweaking a little bit your code, I get https://gist.github.com/forax/e76367e1a90bf011692ee9bec65ff0f8 (It's a PITA that we have to use a raw type to workaround circularly defined parameter type) I tried to DTRT and got into Inference Hell, surrounded by a swarms of unfriendly wildcards with pitchforks. Glad it wasn?t just me. Inspired by your more whole-hearted use of streams to build the code, I updated my example. Thanks. ? John From darcy at openjdk.java.net Fri Jun 4 00:07:32 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Jun 2021 00:07:32 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v2] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/388f8dae...e584c467 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/9c7c88bf..e584c467 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=00-01 Stats: 428395 lines in 342 files changed: 426299 ins; 917 del; 1179 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From mchung at openjdk.java.net Fri Jun 4 00:12:58 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Jun 2021 00:12:58 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: <2pALT6FW7TiuwdgD4JJuEzZe7iEnv1DBwWXMptFkEWQ=.65c7c670-f3fe-4a84-8f46-c6c48ceb4a49@github.com> On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote: >> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. >> >> Does some renaming of core parameters/fields to better reflect their purpose. >> >> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Fix accidentally commented-out parts of test src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 457: > 455: * @return a CallSite whose target can be used to perform capture, generating > 456: * instances of the interface named by {@code factoryType} > 457: * @throws LambdaConversionException If {@code caller} does not have private One additional comment: The lookup access has been extended since 14 to include `MODULE` and `ORIGINAL` access. `Lookup::hasFullPrivilegeAccess` returns true if the lookup has `PRIVATE` and `MODULE` which means that this lookup is not teleported from another module via `Lookup::in` and `MethodHandles::privateLookupIn`. What privilege do you expect the `caller` lookup should have? I believe full privilege access is the appropriate privilege. The `ORIGINAL` access is stricter as the lookup must be created from the original lookup class. [1] shows what access a `Lookup` has when being produced via different APIs. [1] https://download.java.net/java/early_access/jdk17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#access-modes ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From forax at univ-mlv.fr Fri Jun 4 00:32:59 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 4 Jun 2021 02:32:59 +0200 (CEST) Subject: [External] : Re: RFR: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <9FDCA856-5585-427E-87EC-5D069DAAD08F@oracle.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> <-LWUCCc9l-DZ8HrV271ywG3mHkX9GnAzaYJVjo9BLpc=.83bf8fc7-eafa-4e54-b9cb-65fe407f82dd@github.com> <85e523a7-9d9f-aaf5-7f39-b5bf6f33a8ee@gmail.com> <1866512166.517025.1622749611477.JavaMail.zimbra@u-pem.fr> <929CF9E3-6D4D-4504-8446-5EEE2E00EA76@oracle.com> <1427667238.532375.1622758621090.JavaMail.zimbra@u-pem.fr> <9FDCA856-5585-427E-87EC-5D069DAAD08F@oracle.com> Message-ID: <790497720.536657.1622766779573.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "Remi Forax" > Cc: "Peter Levart" , "R?mi Forax" > , "core-libs-dev" > Envoy?: Vendredi 4 Juin 2021 02:05:41 > Objet: Re: [External] : Re: RFR: 8199318: add idempotent copy operation for > Map.Entry > On Jun 3, 2021, at 3:17 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > wrote: >>> De: "John Rose" >>> ?: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > >>> Cc: "Peter Levart" < [ mailto:peter.levart at gmail.com | peter.levart at gmail.com ] >>> >, "R?mi Forax" < [ mailto:forax at openjdk.java.net | forax at openjdk.java.net ] >, >>> "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net | >>> core-libs-dev at openjdk.java.net ] > >>> Envoy?: Jeudi 3 Juin 2021 22:51:28 >>> Objet: Re: RFR: 8199318: add idempotent copy operation for Map.Entry >>> ... >>> interface ComparableRecord> >>> extends Comparable { ? } >>> record Foo(int x, String y) implements ComparableRecord { ? } >>> [ http://cr.openjdk.java.net/~jrose/draft/ComparableRecord.java | >>> http://cr.openjdk.java.net/~jrose/draft/ComparableRecord.java ] >> [repost with a link] >> The main issue with this kind of code is that the JIT does not see through the >> ClassValue. > Wow, it?s almost as if we?ve discussed this already! ;-) > So, [ https://bugs.openjdk.java.net/browse/JDK-8238260 | > https://bugs.openjdk.java.net/browse/JDK-8238260 ] > Part of my agenda here is finding more reasons why > JDK-8238260 deserves some love. > Currently, the translation strategy for Records > requires a lot of boilerplate generated into each > subclass for toString, equals, and hashCode. > It is partially declarative, because it uses indy. > So, yay for that. But it is also a bad smell (IMO) > that the trick needs to be played in each subclass. > If ClassValue were performant, we could have > just one method in Record for each of toString, > equals, and hashCode, and have them DTRT. > The user code would then be able to call > super.toString() to get the standard behavior > in a refining wrapper method in a subclass. > Looking further, it would be nice to have methods > which (a) inherit from supers as reusable code > ought to, but (b) re-specialize themselves once > per subclass indy-style. This is a VM trick I hope > to look into after we do specialization. For now, > ClassValue is the way to simulate that. yes, it's a specialization problem. I wonder if it an be resolved using a combination of a species-static variable and magic shibboleth to ask the type parameter to be always reified interface ComparableRecord > extends Comparable< T > { species-static Comparator COMPARATOR; // a parameteric condy ? species-static { COMPARATOR = ... } default int compareTo(T other) { return COMPARATOR.compare(this, other); } } >> Tweaking a little bit your code, I get >> [ >> https://urldefense.com/v3/__https://gist.github.com/forax/e76367e1a90bf011692ee9bec65ff0f8__;!!GqivPVa7Brio!MheW9rHDHXlXYNKUju7v5G0vXlpj1YOoDWFjG9AcpnXnVz2TxlMYDM7i86yFtT_B$ >> | https://gist.github.com/forax/e76367e1a90bf011692ee9bec65ff0f8 ] >> (It's a PITA that we have to use a raw type to workaround circularly defined >> parameter type) > I tried to DTRT and got into Inference Hell, surrounded > by a swarms of unfriendly wildcards with pitchforks. > Glad it wasn?t just me. > Inspired by your more whole-hearted use of streams > to build the code, I updated my example. Thanks. > ? John R?mi From darcy at openjdk.java.net Fri Jun 4 01:12:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Jun 2021 01:12:11 GMT Subject: RFR: 8268224: Cleanup references to "strictfp" in core lib comments Message-ID: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> With the right baseline this time, as noticed by John Rose, after JEP 306 removing non-strict floating-point was integrated, a few stale references were left to "strictfp" and "value sets" in core library comments. This changeset removes those stray references. ------------- Commit messages: - 8268224: Cleanup references to "strictfp" in core lib comments Changes: https://git.openjdk.java.net/jdk/pull/4349/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4349&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268224 Stats: 56 lines in 2 files changed: 0 ins; 45 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4349/head:pull/4349 PR: https://git.openjdk.java.net/jdk/pull/4349 From darcy at openjdk.java.net Fri Jun 4 01:12:11 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Jun 2021 01:12:11 GMT Subject: RFR: 8268224: Cleanup references to "strictfp" in core lib comments In-Reply-To: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> References: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> Message-ID: <4bWbz22WSyBs6EMxiN_uGMhrSvYBGvUpxuecUe1l3Ho=.d94b8275-8f49-4b62-8fe5-27ac8f7becf7@github.com> On Fri, 4 Jun 2021 01:04:39 GMT, Joe Darcy wrote: > With the right baseline this time, as noticed by John Rose, after JEP 306 removing non-strict floating-point was integrated, a few stale references were left to "strictfp" and "value sets" in core library comments. This changeset removes those stray references. PS I'll re-flow the paragraph before pushing. I left them un-re-flowed to ease review. ------------- PR: https://git.openjdk.java.net/jdk/pull/4349 From github.com+7806504+liach at openjdk.java.net Fri Jun 4 01:25:58 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Fri, 4 Jun 2021 01:25:58 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote: >> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. >> >> Does some renaming of core parameters/fields to better reflect their purpose. >> >> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Fix accidentally commented-out parts of test src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 547: > 545: throw new IllegalArgumentException("argument has wrong type"); > 546: } > 547: return type.cast(result); Can we just use a `return (T) result` as there will always be a checked cast on the caller's end, and this call seems redundant? The only shortcoming is that the call will raise an unchecked warning that needs to be suppressed. Or is this negligible after hotspot optimization? ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From jrose at openjdk.java.net Fri Jun 4 01:26:56 2021 From: jrose at openjdk.java.net (John R Rose) Date: Fri, 4 Jun 2021 01:26:56 GMT Subject: RFR: 8268224: Cleanup references to "strictfp" in core lib comments In-Reply-To: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> References: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> Message-ID: <3DQA2Fs6Ef5mUC3imrI9zkL9BTV0ncLBdOg7BlJSfVs=.5199f4f8-82ad-403a-b8fd-82d215bdf13e@github.com> On Fri, 4 Jun 2021 01:04:39 GMT, Joe Darcy wrote: > With the right baseline this time, as noticed by John Rose, after JEP 306 removing non-strict floating-point was integrated, a few stale references were left to "strictfp" and "value sets" in core library comments. This changeset removes those stray references. Good. I note that `strictfp` occurs in a few other places, notably two files in `java.lang.reflect`. But (as you explain) those occurrences are necessary to support the contents of old-format class files. ------------- Marked as reviewed by jrose (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4349 From darcy at openjdk.java.net Fri Jun 4 01:48:17 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Jun 2021 01:48:17 GMT Subject: RFR: 8268224: Cleanup references to "strictfp" in core lib comments [v2] In-Reply-To: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> References: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> Message-ID: <4In7Lkxg2ZCVQnPzYdnea8AAyF7Lgc1sAGUEI1WRc2U=.3c73a908-6cc5-40d2-aa41-0d1a9cbc4d4c@github.com> > With the right baseline this time, as noticed by John Rose, after JEP 306 removing non-strict floating-point was integrated, a few stale references were left to "strictfp" and "value sets" in core library comments. This changeset removes those stray references. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Reflow paragraphs. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4349/files - new: https://git.openjdk.java.net/jdk/pull/4349/files/7ab8f9f2..596971e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4349&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4349&range=00-01 Stats: 50 lines in 2 files changed: 0 ins; 5 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/4349.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4349/head:pull/4349 PR: https://git.openjdk.java.net/jdk/pull/4349 From darcy at openjdk.java.net Fri Jun 4 02:07:01 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Jun 2021 02:07:01 GMT Subject: Integrated: 8268224: Cleanup references to "strictfp" in core lib comments In-Reply-To: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> References: <7zi_bJidpG_Y5XOKV_jhqY59nXSUcpEAOf1QbjTLa9I=.dee7e664-0e52-4038-afea-f69ecc88c582@github.com> Message-ID: On Fri, 4 Jun 2021 01:04:39 GMT, Joe Darcy wrote: > With the right baseline this time, as noticed by John Rose, after JEP 306 removing non-strict floating-point was integrated, a few stale references were left to "strictfp" and "value sets" in core library comments. This changeset removes those stray references. This pull request has now been integrated. Changeset: 05df1727 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/05df1727b529992aeac666b4984d0681d61ebb31 Stats: 97 lines in 2 files changed: 0 ins; 50 del; 47 mod 8268224: Cleanup references to "strictfp" in core lib comments Reviewed-by: jrose ------------- PR: https://git.openjdk.java.net/jdk/pull/4349 From dholmes at openjdk.java.net Fri Jun 4 02:16:04 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 4 Jun 2021 02:16:04 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> Message-ID: On Thu, 3 Jun 2021 17:48:59 GMT, Naoto Sato wrote: >> Right; I changed the code in NativeLibraries.c to pass down true UTF-8 instead of "modified UTF-8". Please, take a look. > > I am not sure we can pass non `modified UTF-8` through `JVM_LoadLibrary()`. Probably some VM folks can enlighten here? Not an expert by my understanding is that the VM only deals with modified UTF-8, as does JNI. So the incoming string should be modified-UTF8 IMO and then converted to UTF16. That said, this is shared code being modified on the JDK side so you can't just change the type of string being passed in without updating all the implementations of os::dll_load to support that! ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From xgong at openjdk.java.net Fri Jun 4 03:37:02 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 4 Jun 2021 03:37:02 GMT Subject: RFR: 8268151: Vector API toShuffle optimization [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 18:40:09 GMT, Sandhya Viswanathan wrote: >> src/hotspot/share/opto/vectornode.cpp line 1246: >> >>> 1244: return new VectorLoadMaskNode(value, out_vt); >>> 1245: } else if (is_vector_shuffle) { >>> 1246: if (!is_shuffle_to_vector()) { >> >> Hi @sviswa7 , thanks for this change! I'm just curious whether `is_shuffle_to_vector()` is still needed for `VectorUnboxNode` with this change? It seems this flag can be removed, doesn't it? > > @XiaohongGong is_shuffle_to_vector is still needed as we shouldn't generate VectorLoadShuffleNode for shuffle.toVector. OK, got it. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From xgong at openjdk.java.net Fri Jun 4 03:37:01 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 4 Jun 2021 03:37:01 GMT Subject: RFR: 8268151: Vector API toShuffle optimization [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 21:43:19 GMT, Sandhya Viswanathan wrote: >> The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. >> >> The following changes are made: >> 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. >> 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. >> 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. >> >> Best Regards, >> Sandhya > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Implement review comments Looks good to me. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From darcy at openjdk.java.net Fri Jun 4 04:47:22 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Jun 2021 04:47:22 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v3] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 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 13 additional commits since the last revision: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/662de459...fc4d8725 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/e584c467..fc4d8725 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=01-02 Stats: 112 lines in 5 files changed: 10 ins; 50 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From joehw at openjdk.java.net Fri Jun 4 05:22:11 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 4 Jun 2021 05:22:11 GMT Subject: RFR: 8268222: javax/xml/jaxp/unittest/transform/Bug6216226Test.java failed, cannot delete file Message-ID: Revert changes in StreamResult.java made through https://github.com/openjdk/jdk/pull/4318 since it was creating a file stream on behalf of the Transformer, which resulted in a leaking file handle because the Transformer would only close files it opened. This change instead replace the problematic file-uri-url-file conversion code with nio Paths. While we generally don't make such changes if it's not necessary as Apache still supports older versions of the JDK, we are okay with a code level 8. ------------- Commit messages: - 8268222: javax/xml/jaxp/unittest/transform/Bug6216226Test.java failed, cannot delete file Changes: https://git.openjdk.java.net/jdk/pull/4353/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4353&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268222 Stats: 37 lines in 2 files changed: 2 ins; 24 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/4353.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4353/head:pull/4353 PR: https://git.openjdk.java.net/jdk/pull/4353 From plevart at openjdk.java.net Fri Jun 4 06:19:59 2021 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 4 Jun 2021 06:19:59 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:40:23 GMT, Dan Smith wrote: >> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. >> >> Does some renaming of core parameters/fields to better reflect their purpose. >> >> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Fix accidentally commented-out parts of test src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java line 69: > 67: final boolean isSerializable; // Should the returned instance be serializable > 68: final Class[] interfaces; // Additional interfaces to be implemented > 69: final MethodType[] bridges; // Signatures of additional methods to bridge If you are removing ACC_BRIDGE from additional generated methods, then perhaps this parameter name could also be changed? `altMethods` (as alternative methods perhaps?) ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From dfuchs at openjdk.java.net Fri Jun 4 08:54:59 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 4 Jun 2021 08:54:59 GMT Subject: RFR: 8268222: javax/xml/jaxp/unittest/transform/Bug6216226Test.java failed, cannot delete file In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:14:13 GMT, Joe Wang wrote: > Revert changes in StreamResult.java made through https://github.com/openjdk/jdk/pull/4318 since it was creating a file stream on behalf of the Transformer, which resulted in a leaking file handle because the Transformer would only close files it opened. > > This change instead replace the problematic file-uri-url-file conversion code with nio Paths. While we generally don't make such changes if it's not necessary as Apache still supports older versions of the JDK, we are okay with a code level 8. Using `Path` instead of trying to handcraft a URL is a much better alternative. src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java line 52: > 50: import java.net.UnknownServiceException; > 51: import java.nio.file.Path; > 52: import java.nio.file.Paths; Nit: you should not need to use Paths. `Paths.get(URI)` just calls `Path.of(URI)` src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java line 516: > 514: if (systemId.startsWith("file:")) { > 515: try{ > 516: Path p = Paths.get(new URI(systemId)); I suggest using `Path.of(new URI(systemId));` here. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4353 From jlahoda at openjdk.java.net Fri Jun 4 09:01:27 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 09:01:27 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v11] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Tweaking SwitchBootstraps javadoc, as suggested. - Improving javadoc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/fa50b5fb..216b87c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=09-10 Stats: 66 lines in 2 files changed: 40 ins; 9 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From mcimadamore at openjdk.java.net Fri Jun 4 09:38:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 09:38:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v11] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:01:27 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: > > - Tweaking SwitchBootstraps javadoc, as suggested. > - Improving javadoc. Re-approving to keep the bots happy ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 09:46:31 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 09:46:31 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/216b87c2..8d4c02b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From ngasson at openjdk.java.net Fri Jun 4 10:08:58 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 4 Jun 2021 10:08:58 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: Message-ID: <-F7LENGc9jPrpXXB3gJVIiDIOcUcqVAdOL98a_4CmmU=.e629ff30-4a23-4bbf-ab9b-1c7e8d12ec58@github.com> On Wed, 2 Jun 2021 13:42:22 GMT, Jorn Vernee wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > The JEP has been integrated, so we can pick this back up (and handle it as a bug for 17 even after the fork). > > Thank you for your patience. Thanks @JornVernee! I noticed VaListTest has started failing on Windows with this error: test VaListTest.testUpcall(java.lang.invoke.BoundMethodHandle$Species_LLLLLLL at 198ebce4, MethodHandle(VaList)void): success test VaListTest.testUpcall(java.lang.invoke.BoundMethodHandle$Species_LLLLLLL at 7a97cd30, MethodHandle(VaList)void): success Uncaught exception: java.lang.IllegalArgumentException {0x00000000d6506c20} - klass: 'java/lang/IllegalArgumentException' # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (universalUpcallHandler.cpp:113), pid=13972, tid=23500 # Error: ShouldNotReachHere() # I guess it must be related to the two new cases I added and the Windows code is now throwing an IllegalArgumentException but I can't see where from. Any ideas? ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From jvernee at openjdk.java.net Fri Jun 4 10:38:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 10:38:58 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: <-F7LENGc9jPrpXXB3gJVIiDIOcUcqVAdOL98a_4CmmU=.e629ff30-4a23-4bbf-ab9b-1c7e8d12ec58@github.com> References: <-F7LENGc9jPrpXXB3gJVIiDIOcUcqVAdOL98a_4CmmU=.e629ff30-4a23-4bbf-ab9b-1c7e8d12ec58@github.com> Message-ID: <17d2bzWkYl3iGpTUKOpCK2IO5_RyyO7AC3V0aOATt-4=.1aa4d509-10ff-4bd2-86be-88d0b53a80fe@github.com> On Fri, 4 Jun 2021 10:06:26 GMT, Nick Gasson wrote: >> The JEP has been integrated, so we can pick this back up (and handle it as a bug for 17 even after the fork). >> >> Thank you for your patience. > > Thanks @JornVernee! I noticed VaListTest has started failing on Windows with this error: > > test VaListTest.testUpcall(java.lang.invoke.BoundMethodHandle$Species_LLLLLLL at 198ebce4, MethodHandle(VaList)void): success > test VaListTest.testUpcall(java.lang.invoke.BoundMethodHandle$Species_LLLLLLL at 7a97cd30, MethodHandle(VaList)void): success > Uncaught exception: > java.lang.IllegalArgumentException > {0x00000000d6506c20} - klass: 'java/lang/IllegalArgumentException' > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (universalUpcallHandler.cpp:113), pid=13972, tid=23500 > # Error: ShouldNotReachHere() > # > > > I guess it must be related to the two new cases I added and the Windows code is now throwing an IllegalArgumentException but I can't see where from. Any ideas? Hey @nick-arm I'm on Windows, so I can take a look here. We recently added a patch that handles these exceptions better and actually prints the stack trace as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From mcimadamore at openjdk.java.net Fri Jun 4 11:01:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 11:01:15 GMT Subject: RFR: 8268227: java/foreign/TestUpcall.java still times out Message-ID: Turns out that adding more timeout is a lost cause here. The root cause of the slowdown when running the test in debug build is: https://bugs.openjdk.java.net/browse/JDK-8266074 Which has also caused related test issues: https://bugs.openjdk.java.net/browse/JDK-8268095 So, the fix (at least temporarily) is to run method handle-heavy tests with the -XX:-VerifyDependency options. On my machine, execution time of these tests on debug goes from 10 minutes down to less than 1. Since `-XX:-VerifyDependencies` cannot be specified on non-debug build, the `-XX:+IgnoreUnrecognizedVMOptions` is also passed (thanks Vlad for the tip!). ------------- Commit messages: - Disable VerifyDependencies on TestUpcall/Downcall (when in debug mode) Changes: https://git.openjdk.java.net/jdk/pull/4355/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4355&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268227 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4355.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4355/head:pull/4355 PR: https://git.openjdk.java.net/jdk/pull/4355 From jvernee at openjdk.java.net Fri Jun 4 11:10:59 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 11:10:59 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v3] In-Reply-To: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> References: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> Message-ID: On Thu, 3 Jun 2021 03:28:56 GMT, Nick Gasson wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > No variadic upcalls > > Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5 > CustomizedGitHooks: yes test/jdk/java/foreign/valist/VaListTest.java line 706: > 704: vaList.skip(BigPoint_LAYOUT); > 705: assertEquals((long) vaList.vargAsLong(C_LONG), 42); > 706: })}, Looks like a carrier size mismatch here: java.lang.IllegalArgumentException: Carrier size mismatch: long != b32[abi/kind=LONG] at jdk.incubator.foreign/jdk.internal.foreign.Utils.checkPrimitiveCarrierCompat(Utils.java:111) at jdk.incubator.foreign/jdk.internal.foreign.abi.SharedUtils.checkCompatibleType(SharedUtils.java:231) at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.read(WinVaList.java:114) at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.read(WinVaList.java:109) at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.vargAsLong(WinVaList.java:84) at VaListTest.lambda$upcalls$58(VaListTest.java:705) at jdk.incubator.foreign/jdk.internal.foreign.abi.ProgrammableInvoker.invokeNative(Native Method) at jdk.incubator.foreign/jdk.internal.foreign.abi.ProgrammableInvoker.invokeMoves(ProgrammableInvoker.java:290) at VaListTest.testUpcall(VaListTest.java:530) Need to use `C_LONG_LONG` to be cross-platform compatible. (sorry for not noticing this). Suggestion: { linkVaListCB("upcallBigStructPlusScalar"), VaListConsumer.mh(vaList -> { MemorySegment struct = vaList.vargAsSegment(BigPoint_LAYOUT, ResourceScope.newImplicitScope()); assertEquals((long) VH_BigPoint_x.get(struct), 8); assertEquals((long) VH_BigPoint_y.get(struct), 16); assertEquals((long) vaList.vargAsLong(C_LONG_LONG), 42); })}, { linkVaListCB("upcallBigStructPlusScalar"), VaListConsumer.mh(vaList -> { vaList.skip(BigPoint_LAYOUT); assertEquals((long) vaList.vargAsLong(C_LONG_LONG), 42); })}, ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From jvernee at openjdk.java.net Fri Jun 4 11:11:00 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 11:11:00 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v3] In-Reply-To: References: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> Message-ID: On Fri, 4 Jun 2021 11:04:33 GMT, Jorn Vernee wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> No variadic upcalls >> >> Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5 >> CustomizedGitHooks: yes > > test/jdk/java/foreign/valist/VaListTest.java line 706: > >> 704: vaList.skip(BigPoint_LAYOUT); >> 705: assertEquals((long) vaList.vargAsLong(C_LONG), 42); >> 706: })}, > > Looks like a carrier size mismatch here: > > > java.lang.IllegalArgumentException: Carrier size mismatch: long != b32[abi/kind=LONG] > at jdk.incubator.foreign/jdk.internal.foreign.Utils.checkPrimitiveCarrierCompat(Utils.java:111) > at jdk.incubator.foreign/jdk.internal.foreign.abi.SharedUtils.checkCompatibleType(SharedUtils.java:231) > at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.read(WinVaList.java:114) > at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.read(WinVaList.java:109) > at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.vargAsLong(WinVaList.java:84) > at VaListTest.lambda$upcalls$58(VaListTest.java:705) > at jdk.incubator.foreign/jdk.internal.foreign.abi.ProgrammableInvoker.invokeNative(Native Method) > at jdk.incubator.foreign/jdk.internal.foreign.abi.ProgrammableInvoker.invokeMoves(ProgrammableInvoker.java:290) > at VaListTest.testUpcall(VaListTest.java:530) > > > Need to use `C_LONG_LONG` to be cross-platform compatible. (sorry for not noticing this). > > Suggestion: > > { linkVaListCB("upcallBigStructPlusScalar"), VaListConsumer.mh(vaList -> { > MemorySegment struct = vaList.vargAsSegment(BigPoint_LAYOUT, ResourceScope.newImplicitScope()); > assertEquals((long) VH_BigPoint_x.get(struct), 8); > assertEquals((long) VH_BigPoint_y.get(struct), 16); > > assertEquals((long) vaList.vargAsLong(C_LONG_LONG), 42); > })}, > { linkVaListCB("upcallBigStructPlusScalar"), VaListConsumer.mh(vaList -> { > vaList.skip(BigPoint_LAYOUT); > assertEquals((long) vaList.vargAsLong(C_LONG_LONG), 42); > })}, Also, it looks like the cast to `(long)` on the `vaList.vargAsLong` lines is redundant (thanks IntelliJ). ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From mcimadamore at openjdk.java.net Fri Jun 4 11:17:00 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 11:17:00 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v3] In-Reply-To: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> References: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> Message-ID: On Thu, 3 Jun 2021 03:28:56 GMT, Nick Gasson wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > No variadic upcalls > > Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5 > CustomizedGitHooks: yes Looks good - except for the issue raised by Jorn (carrier mismatch on test) ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From github.com+10835776+stsypanov at openjdk.java.net Fri Jun 4 11:53:10 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 4 Jun 2021 11:53:10 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList [v2] In-Reply-To: References: Message-ID: > After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it. ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into 8263561 - Merge branch 'master' into 8263561 # Conflicts: # src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java - Merge branch 'master' into purge-linked-list - 8263561: Use sized constructor where reasonable - 8263561: Use interface List instead of particular type where possible - 8263561: Rename requestList -> requests - 8263561: Re-examine uses of LinkedList ------------- Changes: https://git.openjdk.java.net/jdk/pull/4304/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=01 Stats: 48 lines in 9 files changed: 0 ins; 2 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/4304.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304 PR: https://git.openjdk.java.net/jdk/pull/4304 From github.com+10835776+stsypanov at openjdk.java.net Fri Jun 4 11:54:31 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 4 Jun 2021 11:54:31 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v4] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? 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 8268113 - 8268113: Inline local vars where reasonable - 8268113: Delegate to Double.hashCode() - 8268113: Re-use Long.hashCode() where possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/df8be00a..7dc5020e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=02-03 Stats: 454615 lines in 1482 files changed: 442781 ins; 7489 del; 4345 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From ngasson at openjdk.java.net Fri Jun 4 12:36:29 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 4 Jun 2021 12:36:29 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v4] In-Reply-To: References: Message-ID: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. > > [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/foreign/valist/VaListTest.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3617/files - new: https://git.openjdk.java.net/jdk/pull/3617/files/251aae68..185f114f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3617/head:pull/3617 PR: https://git.openjdk.java.net/jdk/pull/3617 From ngasson at openjdk.java.net Fri Jun 4 12:41:11 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 4 Jun 2021 12:41:11 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v5] In-Reply-To: References: Message-ID: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. > > [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Redundant cast to long - Merge master Change-Id: I49bef0437b4c47bef8bf74d192299d06b25e1555 CustomizedGitHooks: yes - Update test/jdk/java/foreign/valist/VaListTest.java Co-authored-by: Jorn Vernee - No variadic upcalls Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5 CustomizedGitHooks: yes - Fixes after JEP integratioN Change-Id: Iaa13b3869522c8814c3f7ef4c1eac8e8267657e6 CustomizedGitHooks: yes - merge master Change-Id: Ic06fec084099ff2053dd251a255cbbf4a64a59d7 CustomizedGitHooks: yes - 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native macOS on Apple silicon uses slightly different ABI conventions to the standard AArch64 ABI. The differences are outlined in [1]. In particular in the standard (AAPCS) ABI, variadic arguments may be passed in either registers or on the stack following the normal calling convention. To handle this, va_list is a struct containing separate pointers for arguments located in integer registers, floating point registers, and on the stack. Apple's ABI simplifies this by passing all variadic arguments on the stack and the va_list type becomes a simple char* pointer. This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to represent the new ABI variant on macOS. StackVaList is based on WinVaList lightly modified to handle the different TypeClasses on AArch64. The original AArch64Linker is renamed to AapcsLinker and is currently used for all non-Mac platforms. I think we also need to add a WinAArch64 CABI but I haven't yet been able to test on a Windows system so will do that later. The macOS ABI also uses a different method of spilling arguments to the stack (the standard ABI pads each argument to a multiple of 8 byte stack slots, but the Mac ABI packs arguments according to their natural alignment). None of the existing tests exercise this so I'll open a new JBS issue and work on that separately. Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. ------------- Changes: https://git.openjdk.java.net/jdk/pull/3617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=04 Stats: 777 lines in 14 files changed: 571 ins; 115 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/3617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3617/head:pull/3617 PR: https://git.openjdk.java.net/jdk/pull/3617 From mcimadamore at openjdk.java.net Fri Jun 4 12:56:02 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 12:56:02 GMT Subject: Integrated: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 17:19:06 GMT, Maurizio Cimadamore wrote: > This patch overhauls the library loading mechanism used by the Foreign Linker API. We realized that, while handy, the *default* lookup abstraction (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. > > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` abstraction, a functional interface. Crucially, `SymbolLookup` does not concern with library loading, only symbol lookup. For this reason, two factories are added: > > * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to lookup symbols in libraries loaded by current loader > * `CLinker::systemLookup` - a more stable replacement for the *default* lookup, which looks for symbols in libc.so (or its equivalent in other platforms). The contents of this lookup are unspecified. > > Both factories are *restricted*, so they can only be called when `--enable-native-access` is set. This pull request has now been integrated. Changeset: 59a539fe Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/59a539fef12dec6ba8af8a41000829402e7e9b72 Stats: 1351 lines in 47 files changed: 626 ins; 621 del; 104 mod 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries Reviewed-by: jvernee, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/4316 From mcimadamore at openjdk.java.net Fri Jun 4 13:00:05 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 4 Jun 2021 13:00:05 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: <-F7LENGc9jPrpXXB3gJVIiDIOcUcqVAdOL98a_4CmmU=.e629ff30-4a23-4bbf-ab9b-1c7e8d12ec58@github.com> References: <-F7LENGc9jPrpXXB3gJVIiDIOcUcqVAdOL98a_4CmmU=.e629ff30-4a23-4bbf-ab9b-1c7e8d12ec58@github.com> Message-ID: On Fri, 4 Jun 2021 10:06:26 GMT, Nick Gasson wrote: >> The JEP has been integrated, so we can pick this back up (and handle it as a bug for 17 even after the fork). >> >> Thank you for your patience. > > Thanks @JornVernee! I noticed VaListTest has started failing on Windows with this error: > > test VaListTest.testUpcall(java.lang.invoke.BoundMethodHandle$Species_LLLLLLL at 198ebce4, MethodHandle(VaList)void): success > test VaListTest.testUpcall(java.lang.invoke.BoundMethodHandle$Species_LLLLLLL at 7a97cd30, MethodHandle(VaList)void): success > Uncaught exception: > java.lang.IllegalArgumentException > {0x00000000d6506c20} - klass: 'java/lang/IllegalArgumentException' > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (universalUpcallHandler.cpp:113), pid=13972, tid=23500 > # Error: ShouldNotReachHere() > # > > > I guess it must be related to the two new cases I added and the Windows code is now throwing an IllegalArgumentException but I can't see where from. Any ideas? @nick-arm, I've just integrated a fix which, I believe will create a minor build issue with the changes in this patch: https://git.openjdk.java.net/jdk/pull/4316 That fix has a switch on the ABI type in the SystemLookup class (a new class introduced by that fix). I believe that switch will no longer compile with the changes in this PR as the ABI enum constants have changed - hopefully the fix should be easy - e.g. just replace the case label with references AARCH64 with a compound case label which covers both ARM/linux and ARM/MacOS. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From vlivanov at openjdk.java.net Fri Jun 4 13:06:00 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Jun 2021 13:06:00 GMT Subject: RFR: 8268151: Vector API toShuffle optimization [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 21:43:19 GMT, Sandhya Viswanathan wrote: >> The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. >> >> The following changes are made: >> 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. >> 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. >> 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. >> >> Best Regards, >> Sandhya > > Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: > > Implement review comments Looks good. One inefficiency I noticed is that repeated `toVector()`/`toShuffle` leave a trail of redundant `VectorCastB2X`/`VectorCast[S..L]2X` nodes behind. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4326 From github.com+28651297+mkartashev at openjdk.java.net Fri Jun 4 13:36:27 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Fri, 4 Jun 2021 13:36:27 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v5] In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: > Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". > > This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. > > Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). > > The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. > > Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. > > Results from Linux: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 > ============================== > TEST SUCCESS > > > Building target 'run-test-only' in configuration 'linux-x86_64-server-release' > Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 > > > Results from Windows 10: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/runtime 746 746 0 0 > ============================== > TEST SUCCESS > Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' > > > Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' > Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision: Updated the test to run on Windows only and to use a character from the supplementary plane in the path name. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4169/files - new: https://git.openjdk.java.net/jdk/pull/4169/files/97c918ca..a5d45dca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4169&range=03-04 Stats: 8 lines in 2 files changed: 1 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4169/head:pull/4169 PR: https://git.openjdk.java.net/jdk/pull/4169 From github.com+28651297+mkartashev at openjdk.java.net Fri Jun 4 13:36:28 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Fri, 4 Jun 2021 13:36:28 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> Message-ID: On Thu, 3 Jun 2021 17:51:54 GMT, Naoto Sato wrote: > I think we can simply limit the test platform only to Windows in @requires tag in the test. Also, I would see the test case using some supplementary characters. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From github.com+28651297+mkartashev at openjdk.java.net Fri Jun 4 14:03:05 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Fri, 4 Jun 2021 14:03:05 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> Message-ID: On Fri, 4 Jun 2021 02:12:42 GMT, David Holmes wrote: >> I am not sure we can pass non `modified UTF-8` through `JVM_LoadLibrary()`. Probably some VM folks can enlighten here? > > Not an expert by my understanding is that the VM only deals with modified UTF-8, as does JNI. So the incoming string should be modified-UTF8 IMO and then converted to UTF16. > > That said, this is shared code being modified on the JDK side so you can't just change the type of string being passed in without updating all the implementations of os::dll_load to support that! I think we need to establish some common ground before proceeding further with this fix. It's a bit of a long read; please, bear with me. The path name starts its life as a `jstring` in `Java_jdk_internal_loader_NativeLibraries_load()`, its encoding is irrelevant at this point. Next, the name has to be passed down to `JVM_LoadLibrary()` that takes `char*`. So we need to convert form `jstring` to `char*` (point (a)). Following that, `os::dll_load()` that actually performs loading in a platform-specific manner also receives `char*`. All platform implementations of `os::dll_load()` pass the path name down to their respective platform's APIs unmodified, but I think that's just incidental and here we have another possible point of conversion (point (b)). Other consumers of the path name are exception(c) and logging(d) messages; they also take `char*`, but potentially of a different encoding. Let me try to enumerate all conceivably valid conversions for `JVM_LoadLibrary()` consumption (point (a)): 1. jstring -> platform-specific encoding (status quo meaning possibly lossy encoding on Windows and UTF-8 elsewhere AFAICT), 2. jstring -> modified UTF-8, 3. jstring -> UTF-8. This bug [8195129](https://bugs.openjdk.java.net/browse/JDK-8195129) occurs because conversion (1) may loose information on Windows if the platform encoding happens to be NOT UTF-8 (which it often - or even always - is). So that's a no-go and we are left with either (2) or (3). On MacOS and Linux, "platform" encoding already is UTF-8 and since all the platform APIs happily consume UTF-8, no further conversion is necessary (neither for actual library loading, nor for log or exception messages; the latter have to convert to UTF-16, but do that under the hood). On Windows, we require at least these variants of the path name: 1. UTF16 for library loading (Unicode Windows API), 2. "platform" encoding for logging (yes, loosing information here, but that's tolerable), 3. "platform" (lossy) or UTF8 (lossless) encoding for exception messages (prefer lossless). This is what's behind my choice of UTF-8 for the path name encoding as it gets passed down to `JVM_LoadLibrary()`. We can go with modified UTF-8, of course, in which case all platforms - not just Windows - will have to do the conversion on their own, loosing the benefit of the knowledge about the original string encoding (the String.coder field of jstring). ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From mbaesken at openjdk.java.net Fri Jun 4 14:10:20 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 4 Jun 2021 14:10:20 GMT Subject: RFR: JDK-8266918: merge_stack in check_code.c add NULL check [v2] In-Reply-To: References: Message-ID: > Hello, please review this small Sonar finding. > Sonar reports a potential NULL pointer dereference here : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&types=BUG > "Access to field 'item' results in a dereference of a null pointer (loaded from variable 'new')" > It would be better to add a check . Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Replace check by assertion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3979/files - new: https://git.openjdk.java.net/jdk/pull/3979/files/eeff35ef..d58c996e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3979&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3979&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3979.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3979/head:pull/3979 PR: https://git.openjdk.java.net/jdk/pull/3979 From rschmelter at openjdk.java.net Fri Jun 4 14:15:57 2021 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Fri, 4 Jun 2021 14:15:57 GMT Subject: RFR: JDK-8266918: merge_stack in check_code.c add NULL check [v2] In-Reply-To: References: Message-ID: <2raQMeUwoKO0oY0o7VDlv0hlXM-etRwf9NWR1tTPDQM=.66658ae6-fde1-4032-8db5-91207fccbb1b@github.com> On Fri, 4 Jun 2021 14:10:20 GMT, Matthias Baesken wrote: >> Hello, please review this small Sonar finding. >> Sonar reports a potential NULL pointer dereference here : >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&types=BUG >> "Access to field 'item' results in a dereference of a null pointer (loaded from variable 'new')" >> It would be better to add a check . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Replace check by assertion The change looks good to me. ------------- Marked as reviewed by rschmelter (Committer). PR: https://git.openjdk.java.net/jdk/pull/3979 From ngasson at openjdk.java.net Fri Jun 4 15:10:18 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 4 Jun 2021 15:10:18 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v6] In-Reply-To: References: Message-ID: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. > > [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Fix build after merge - Merge master - Redundant cast to long - Merge master Change-Id: I49bef0437b4c47bef8bf74d192299d06b25e1555 CustomizedGitHooks: yes - Update test/jdk/java/foreign/valist/VaListTest.java Co-authored-by: Jorn Vernee - No variadic upcalls Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5 CustomizedGitHooks: yes - Fixes after JEP integratioN Change-Id: Iaa13b3869522c8814c3f7ef4c1eac8e8267657e6 CustomizedGitHooks: yes - merge master Change-Id: Ic06fec084099ff2053dd251a255cbbf4a64a59d7 CustomizedGitHooks: yes - 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native macOS on Apple silicon uses slightly different ABI conventions to the standard AArch64 ABI. The differences are outlined in [1]. In particular in the standard (AAPCS) ABI, variadic arguments may be passed in either registers or on the stack following the normal calling convention. To handle this, va_list is a struct containing separate pointers for arguments located in integer registers, floating point registers, and on the stack. Apple's ABI simplifies this by passing all variadic arguments on the stack and the va_list type becomes a simple char* pointer. This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to represent the new ABI variant on macOS. StackVaList is based on WinVaList lightly modified to handle the different TypeClasses on AArch64. The original AArch64Linker is renamed to AapcsLinker and is currently used for all non-Mac platforms. I think we also need to add a WinAArch64 CABI but I haven't yet been able to test on a Windows system so will do that later. The macOS ABI also uses a different method of spilling arguments to the stack (the standard ABI pads each argument to a multiple of 8 byte stack slots, but the Mac ABI packs arguments according to their natural alignment). None of the existing tests exercise this so I'll open a new JBS issue and work on that separately. Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. ------------- Changes: https://git.openjdk.java.net/jdk/pull/3617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3617&range=05 Stats: 778 lines in 15 files changed: 571 ins; 115 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/3617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3617/head:pull/3617 PR: https://git.openjdk.java.net/jdk/pull/3617 From ngasson at openjdk.java.net Fri Jun 4 15:10:18 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 4 Jun 2021 15:10:18 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: <-F7LENGc9jPrpXXB3gJVIiDIOcUcqVAdOL98a_4CmmU=.e629ff30-4a23-4bbf-ab9b-1c7e8d12ec58@github.com> Message-ID: On Fri, 4 Jun 2021 12:57:17 GMT, Maurizio Cimadamore wrote: > > That fix has a switch on the ABI type in the SystemLookup class (a new class introduced by that fix). I believe that switch will no longer compile with the changes in this PR as the ABI enum constants have changed - hopefully the fix should be easy - e.g. just replace the case label with references AARCH64 with a compound case label which covers both ARM/linux and ARM/MacOS. OK sure, the last commit fixes that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From ngasson at openjdk.java.net Fri Jun 4 15:10:19 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 4 Jun 2021 15:10:19 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v3] In-Reply-To: References: <3PNY6FHnS6KiSznmQZpTLkeWYQ1bruh50ohSaIoXGt0=.29075c04-1efd-487d-85c9-fbfbbc66d75d@github.com> Message-ID: <6aJdz8E-hz7SaLYedPwS80gAz9m00MuZ9p3EbEdtKSc=.ef9dd54d-c4c7-4e10-9335-1a4699a2f1c3@github.com> On Fri, 4 Jun 2021 11:07:27 GMT, Jorn Vernee wrote: >> test/jdk/java/foreign/valist/VaListTest.java line 706: >> >>> 704: vaList.skip(BigPoint_LAYOUT); >>> 705: assertEquals((long) vaList.vargAsLong(C_LONG), 42); >>> 706: })}, >> >> Looks like a carrier size mismatch here: >> >> >> java.lang.IllegalArgumentException: Carrier size mismatch: long != b32[abi/kind=LONG] >> at jdk.incubator.foreign/jdk.internal.foreign.Utils.checkPrimitiveCarrierCompat(Utils.java:111) >> at jdk.incubator.foreign/jdk.internal.foreign.abi.SharedUtils.checkCompatibleType(SharedUtils.java:231) >> at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.read(WinVaList.java:114) >> at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.read(WinVaList.java:109) >> at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.vargAsLong(WinVaList.java:84) >> at VaListTest.lambda$upcalls$58(VaListTest.java:705) >> at jdk.incubator.foreign/jdk.internal.foreign.abi.ProgrammableInvoker.invokeNative(Native Method) >> at jdk.incubator.foreign/jdk.internal.foreign.abi.ProgrammableInvoker.invokeMoves(ProgrammableInvoker.java:290) >> at VaListTest.testUpcall(VaListTest.java:530) >> >> >> Need to use `C_LONG_LONG` to be cross-platform compatible. (sorry for not noticing this). >> >> Suggestion: >> >> { linkVaListCB("upcallBigStructPlusScalar"), VaListConsumer.mh(vaList -> { >> MemorySegment struct = vaList.vargAsSegment(BigPoint_LAYOUT, ResourceScope.newImplicitScope()); >> assertEquals((long) VH_BigPoint_x.get(struct), 8); >> assertEquals((long) VH_BigPoint_y.get(struct), 16); >> >> assertEquals((long) vaList.vargAsLong(C_LONG_LONG), 42); >> })}, >> { linkVaListCB("upcallBigStructPlusScalar"), VaListConsumer.mh(vaList -> { >> vaList.skip(BigPoint_LAYOUT); >> assertEquals((long) vaList.vargAsLong(C_LONG_LONG), 42); >> })}, > > Also, it looks like the cast to `(long)` on the `vaList.vargAsLong` lines is redundant (thanks IntelliJ). Thanks for your help! These are both fixed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From jvernee at openjdk.java.net Fri Jun 4 15:14:01 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 4 Jun 2021 15:14:01 GMT Subject: RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v6] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 15:10:18 GMT, Nick Gasson wrote: >> macOS on Apple silicon uses slightly different ABI conventions to the >> standard AArch64 ABI. The differences are outlined in [1]. In >> particular in the standard (AAPCS) ABI, variadic arguments may be passed >> in either registers or on the stack following the normal calling >> convention. To handle this, va_list is a struct containing separate >> pointers for arguments located in integer registers, floating point >> registers, and on the stack. Apple's ABI simplifies this by passing all >> variadic arguments on the stack and the va_list type becomes a simple >> char* pointer. >> >> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to >> represent the new ABI variant on macOS. StackVaList is based on >> WinVaList lightly modified to handle the different TypeClasses on >> AArch64. The original AArch64Linker is renamed to AapcsLinker and is >> currently used for all non-Mac platforms. I think we also need to add a >> WinAArch64 CABI but I haven't yet been able to test on a Windows system >> so will do that later. >> >> The macOS ABI also uses a different method of spilling arguments to the >> stack (the standard ABI pads each argument to a multiple of 8 byte stack >> slots, but the Mac ABI packs arguments according to their natural >> alignment). None of the existing tests exercise this so I'll open a new >> JBS issue and work on that separately. >> >> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. >> >> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms > > Nick Gasson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Fix build after merge > - Merge master > - Redundant cast to long > - Merge master > > Change-Id: I49bef0437b4c47bef8bf74d192299d06b25e1555 > CustomizedGitHooks: yes > - Update test/jdk/java/foreign/valist/VaListTest.java > > Co-authored-by: Jorn Vernee > - No variadic upcalls > > Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5 > CustomizedGitHooks: yes > - Fixes after JEP integratioN > > Change-Id: Iaa13b3869522c8814c3f7ef4c1eac8e8267657e6 > CustomizedGitHooks: yes > - merge master > > Change-Id: Ic06fec084099ff2053dd251a255cbbf4a64a59d7 > CustomizedGitHooks: yes > - 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native > > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From pconcannon at openjdk.java.net Fri Jun 4 15:25:58 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 4 Jun 2021 15:25:58 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 11:35:13 GMT, R?mi Forax wrote: >> My mistake. I've replaced the colon now with the lambda operator. See a8706b0 > >> My mistake. I've replaced the colon now with the lambda operator. > > Drive by comment, in term of name, `->` is the arrow operator not the lambda operator. > - lambda = parameters + arrow + code > - arrow case = case + arrow + code > > The difference is important because a lambda is a function while an arrow case is a block. Ah OK, good to know. Thanks Remi! ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From psandoz at openjdk.java.net Fri Jun 4 15:54:00 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 4 Jun 2021 15:54:00 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing typo. A really nice feature, and a significant amount of work in javac. I mostly focused on the bootstrap and API aspects, and left some minor comments (most of which you can choose to apply or not as you see fit). I suspect the bootstrap might evolve as we get feedback and switch is enhanced with further forms of matching. But, at the moment it looks good. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 87: > 85: * returns {@literal -1}. > 86: *

> 87: * the {@code target} is not {@code null}, then the method of the call site Suggestion: * If the {@code target} is not {@code null}, then the method of the call site src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 92: > 90: *

    > 91: *
  • the element is of type {@code Class} and the target value > 92: * is a subtype of this {@code Class}; or
    • Suggestion: *
  • the element is of type {@code Class} that is assignable * from the target's class; or
    • src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 162: > 160: return i; > 161: } else { > 162: if (label instanceof Integer constant) { Minor suggestion: use `else if` rather than nest src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 166: > 164: return i; > 165: } > 166: if (target instanceof Character input && constant.intValue() == input.charValue()) { Use `else if` src/jdk.compiler/share/classes/com/sun/source/tree/CaseLabelTree.java line 31: > 29: > 30: /**A marker interface for {@code Tree}s that may be used as {@link CaseTree} labels. > 31: * Suggestion: /** * A marker interface for {@code Tree}s that may be used as {@link CaseTree} labels. * src/jdk.compiler/share/classes/com/sun/source/tree/DefaultCaseLabelTree.java line 30: > 28: > 29: /** A case label that marks {@code default} in {@code case null, default}. > 30: * @since 17 Suggestion: /** * A case label that marks {@code default} in {@code case null, default}. * * @since 17 test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 55: > 53: catch (NoSuchMethodException | IllegalAccessException e) { > 54: throw new RuntimeException(e); > 55: } Suggestion: catch (ReflectiveOperationException e) { throw new AssertionError(e, "Should not happen"); } test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 73: > 71: } > 72: > 73: public void testTypes() throws Throwable { As a follow up issue consider adding tests for `null` values test/langtools/tools/javac/patterns/DisambiguateParenthesizedPattern.java line 72: > 70: SwitchTree st = (SwitchTree) method.getBody().getStatements().get(0); > 71: CaseLabelTree label = st.getCases().get(0).getLabels().get(0); > 72: ExpressionType actualType = switch (label) { Should the test be careful of using a pattern match switch? ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From joehw at openjdk.java.net Fri Jun 4 16:06:59 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 4 Jun 2021 16:06:59 GMT Subject: RFR: 8268222: javax/xml/jaxp/unittest/transform/Bug6216226Test.java failed, cannot delete file In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 08:50:09 GMT, Daniel Fuchs wrote: >> Revert changes in StreamResult.java made through https://github.com/openjdk/jdk/pull/4318 since it was creating a file stream on behalf of the Transformer, which resulted in a leaking file handle because the Transformer would only close files it opened. >> >> This change instead replace the problematic file-uri-url-file conversion code with nio Paths. While we generally don't make such changes if it's not necessary as Apache still supports older versions of the JDK, we are okay with a code level 8. > > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java line 52: > >> 50: import java.net.UnknownServiceException; >> 51: import java.nio.file.Path; >> 52: import java.nio.file.Paths; > > Nit: you should not need to use Paths. `Paths.get(URI)` just calls `Path.of(URI)` Right, but Path.of was introduced in JDK 11. I hope to avoid more advanced features if we can keep the code level at 8. There had been previous cases where we stayed at 8. So far, only a few classes need to be modified for java.xml to compile at 8. ------------- PR: https://git.openjdk.java.net/jdk/pull/4353 From joehw at openjdk.java.net Fri Jun 4 16:35:01 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 4 Jun 2021 16:35:01 GMT Subject: Integrated: 8268222: javax/xml/jaxp/unittest/transform/Bug6216226Test.java failed, cannot delete file In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:14:13 GMT, Joe Wang wrote: > Revert changes in StreamResult.java made through https://github.com/openjdk/jdk/pull/4318 since it was creating a file stream on behalf of the Transformer, which resulted in a leaking file handle because the Transformer would only close files it opened. > > This change instead replace the problematic file-uri-url-file conversion code with nio Paths. While we generally don't make such changes if it's not necessary as Apache still supports older versions of the JDK, we are okay with a code level 8. This pull request has now been integrated. Changeset: b27599b3 Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/b27599b3ec3fd344fa9fa97b7ecde85d5662ca6c Stats: 37 lines in 2 files changed: 2 ins; 24 del; 11 mod 8268222: javax/xml/jaxp/unittest/transform/Bug6216226Test.java failed, cannot delete file Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/4353 From mchung at openjdk.java.net Fri Jun 4 16:53:03 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Jun 2021 16:53:03 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing typo. I reviewed the `java.base` change namely, SwitchBootstraps.java. Looks good. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 47: > 45: * of the {@code switch}, implicitly numbered sequentially from {@code [0..N)}. > 46: * > 47: *

    The bootstrap call site accepts a single parameter of the type of the It takes 2 parameters (not single parameter). Perhaps you can take out this paragraph since it's specified in the `typeSwitch` method. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 110: > 108: * @return a {@code CallSite} returning the first matching element as described above > 109: * > 110: * @throws NullPointerException if any argument is null Suggestion: * @throws NullPointerException if any argument is {@code null} same formatting nit for other occurrenace of "null" ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3863 From smarks at openjdk.java.net Fri Jun 4 17:16:03 2021 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 4 Jun 2021 17:16:03 GMT Subject: Integrated: 8199318: add idempotent copy operation for Map.Entry In-Reply-To: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> References: <_z1EJZgTT3SCqfJPBTDRBy4uMCB1mPK2h_rCtmDH0iM=.c326a527-bb8d-4c7f-bf6d-e282c2e586d6@github.com> Message-ID: On Wed, 2 Jun 2021 00:39:25 GMT, Stuart Marks wrote: > I'm fixing this along with a couple intertwined issues. > > 1. Add Map.Entry::copyOf as an idempotent copy operation. > > 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not really immutable) but that subclasses can be modifiable. > > 3. Clarify some confusing, historical wording about Map.Entry instances being obtainable only via iteration of a Map's entry-set view. This was never really true, since anyone could implement the Map.Entry interface, and it certainly was not true since JDK 1.6 when SimpleEntry and SimpleImmutableEntry were added. This pull request has now been integrated. Changeset: cd0678fc Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/cd0678fcf6bc00ecda3e61d959617c67d02dba3c Stats: 141 lines in 3 files changed: 120 ins; 2 del; 19 mod 8199318: add idempotent copy operation for Map.Entry Reviewed-by: alanb, psandoz, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/4295 From naoto at openjdk.java.net Fri Jun 4 17:35:58 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Jun 2021 17:35:58 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> Message-ID: <7KY_RquUMSy0puIyhxlDQ6NRkJyr2-rQCVmcxbff2m8=.4f423fd2-5aea-43eb-b539-af28e5f5084e@github.com> On Fri, 4 Jun 2021 14:00:25 GMT, Maxim Kartashev wrote: >> Not an expert by my understanding is that the VM only deals with modified UTF-8, as does JNI. So the incoming string should be modified-UTF8 IMO and then converted to UTF16. >> >> That said, this is shared code being modified on the JDK side so you can't just change the type of string being passed in without updating all the implementations of os::dll_load to support that! > > I think we need to establish some common ground before proceeding further with this fix. It's a bit of a long read; please, bear with me. > > The path name starts its life as a `jstring` in `Java_jdk_internal_loader_NativeLibraries_load()`, its encoding is irrelevant at this point. > > Next, the name has to be passed down to `JVM_LoadLibrary()` that takes `char*`. So we need to convert form `jstring` to `char*` (point (a)). Following that, `os::dll_load()` that actually performs loading in a platform-specific manner also receives `char*`. All platform implementations of `os::dll_load()` pass the path name down to their respective platform's APIs unmodified, but I think that's just incidental and here we have another possible point of conversion (point (b)). Other consumers of the path name are exception(c) and logging(d) messages; they also take `char*`, but potentially of a different encoding. > > Let me try to enumerate all conceivably valid conversions for `JVM_LoadLibrary()` consumption (point (a)): > 1. jstring -> platform-specific encoding (status quo meaning possibly lossy encoding on Windows and UTF-8 elsewhere AFAICT), > 2. jstring -> modified UTF-8, > 3. jstring -> UTF-8. > > This bug [8195129](https://bugs.openjdk.java.net/browse/JDK-8195129) occurs because conversion (1) may loose information on Windows if the platform encoding happens to be NOT UTF-8 (which it often - or even always - is). So that's a no-go and we are left with either (2) or (3). > > On MacOS and Linux, "platform" encoding already is UTF-8 and since all the platform APIs happily consume UTF-8, no further conversion is necessary (neither for actual library loading, nor for log or exception messages; the latter have to convert to UTF-16, but do that under the hood). > > On Windows, we require at least these variants of the path name: > 1. UTF16 for library loading (Unicode Windows API), > 2. "platform" encoding for logging (yes, loosing information here, but that's tolerable), > 3. "platform" (lossy) or UTF8 (lossless) encoding for exception messages (prefer lossless). > > This is what's behind my choice of UTF-8 for the path name encoding as it gets passed down to `JVM_LoadLibrary()`. We can go with modified UTF-8, of course, in which case all platforms - not just Windows - will have to do the conversion on their own, loosing the benefit of the knowledge about the original string encoding (the String.coder field of jstring). I think I am hesitant to change the JVM interface from modified UTF-8 to standard UTF-8, as it would be the only location in JNI/JVM interface that uses the standard UTF-8. Instead, I would implement `convert_UTF8_to_UTF16` or rather `convert_mUTF8_to_UTF16` with a fairly simple arithmetic logic. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From naoto at openjdk.java.net Fri Jun 4 17:35:59 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Jun 2021 17:35:59 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v5] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Fri, 4 Jun 2021 13:36:27 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". >> >> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. >> >> Results from Linux: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> ============================== >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/runtime 746 746 0 0 >> ============================== >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision: > > Updated the test to run on Windows only and to use a character from the > supplementary plane in the path name. src/java.base/share/native/libjava/jni_util.c line 680: > 678: utf8Encoding).z; > 679: return isUTF8EncodingSupported; > 680: } It would be moot if we choose not to modify the JVM_ interface to standard UTF-8, but this function is not necessary. UTF-8 encoding is guaranteed in every Java implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From sviswanathan at openjdk.java.net Fri Jun 4 18:20:05 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 4 Jun 2021 18:20:05 GMT Subject: RFR: 8268151: Vector API toShuffle optimization [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 13:03:24 GMT, Vladimir Ivanov wrote: >> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement review comments > > Looks good. > > One inefficiency I noticed is that repeated `toVector()`/`toShuffle` leave a trail of redundant `VectorCastB2X`/`VectorCast[S..L]2X` nodes behind. @iwanowww @XiaohongGong Thanks a lot for the review. @iwanowww I will take up the redundant VectorCastB2X/VectorCast[S..L]2X conversion optimizations separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From sviswanathan at openjdk.java.net Fri Jun 4 18:20:05 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 4 Jun 2021 18:20:05 GMT Subject: Integrated: 8268151: Vector API toShuffle optimization In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 00:29:00 GMT, Sandhya Viswanathan wrote: > The Vector API toShuffle method can be optimized using existing vector conversion intrinsic. > > The following changes are made: > 1) vector.toShuffle java implementation is changed to call VectorSupport.convert. > 2) The conversion intrinsic (inline_vector_convert()) in vectorIntrinsics.cpp is changed to allow shuffle as a destination type. > 3) The shuffle.toVector intrinsic (inline_vector_shuffle_to_vector()) in vectorIntrinsics.cpp now explicitly generates conversion node instead of performing conversion during unbox. This is to remove unnecessary boxing during back to back vector.toShuffle and shuffle.toVector calls. > > Best Regards, > Sandhya This pull request has now been integrated. Changeset: 20b63127 Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/jdk/commit/20b631278c0c89ccd9c16f2a29d47eb8414aacd5 Stats: 399 lines in 41 files changed: 165 ins; 197 del; 37 mod 8268151: Vector API toShuffle optimization Reviewed-by: psandoz, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/4326 From vromero at openjdk.java.net Fri Jun 4 18:27:01 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 4 Jun 2021 18:27:01 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing typo. test/langtools/tools/javac/patterns/SealedTypeChanges.java line 58: > 56: void statement(SealedTypeChangesIntf obj) { > 57: switch (obj) { > 58: case A a -> System.err.println(1); what about having tests with a case that matches the sealed class? test/langtools/tools/javac/patterns/SealedTypeChanges.java line 71: > 69: } > 70: > 71: sealed interface SealedTypeChangesIntf permits SealedTypeChanges.A {} just for completeness shouldn't we have a test with sealed, non-abstract classes? ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From henryjen at openjdk.java.net Fri Jun 4 19:07:19 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Fri, 4 Jun 2021 19:07:19 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v2] In-Reply-To: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: > ?d on macOS > > This patch simply round up the specified stack size to multiple of the system page size. > > Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. > > ```code:java > public class StackLeak { > public int depth = 0; > public void stackLeak() { > depth++; > stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Avoid overflow on page size ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4256/files - new: https://git.openjdk.java.net/jdk/pull/4256/files/fb9b22d5..39b041d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=00-01 Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4256/head:pull/4256 PR: https://git.openjdk.java.net/jdk/pull/4256 From mandy.chung at oracle.com Fri Jun 4 19:16:43 2021 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 4 Jun 2021 12:16:43 -0700 Subject: Comment on JDK-826722: SoftReference not cleared on OutOfMemoryError: Requested array size exceeds VM limit In-Reply-To: <60ca3edc-0c66-cbda-71ab-1a7f20cb21aa@gmail.com> References: <60ca3edc-0c66-cbda-71ab-1a7f20cb21aa@gmail.com> Message-ID: <82fe9919-90de-0f60-96e5-994d29d006af@oracle.com> I'm not sure if the spec should be updated.? JDK-8267222 needs the GC team to evaluate. I have added my comment in this JBS issue. The SoftReference spec has the guarantee: ????All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError.? This is a reasonable guarantee expected by design in response to memory demand. For the OOME thrown due to "requested array size exceeds VM limit", it seems that this is a fast-path throwing OOME without really going through the object allocation request (where reference processing will be performed in GC cycle). The question to the GC team is whether VM implementation can and should support this soft reference guarantee. Note that the soft reference objects are cleared as specified, the large object allocation exceeding VM limit would fail any way. If the implementation is feasible, I'm inclined to clear the soft reference objects when OOME is thrown as specified even the object allocation request is known to fail. Mandy On 6/3/21 11:57 AM, Raffaello Giulietti wrote: > Hi, > > upon reading [1] I tried a similar scenario, but where OOME are caused > by "Java heap space" exhaustion rather than by VM limits. > > > import java.lang.ref.SoftReference; > import java.text.DecimalFormat; > import java.util.ArrayList; > > public class Softly { > > ??? public static void main(String[] args) { > ??????? var size = Integer.parseInt(args[0]); > ??????? var format = new DecimalFormat("#,###"); > ??????? var news = 0; > ??????? var ref = new SoftReference<>(new ArrayList<>()); > ??????? for (;;) { > ??????????? byte[] b = null; > ??????????? try { > ??????????????? b = new byte[size]; > ??????????????? ++news; > ??????????????? ref.get().add(b); > ??????????? } catch (NullPointerException __) { > ??????????????? System.out.format("totSize = %20s, allocations = > %d\n", format.format((long) news * size), news); > ??????????????? ref = new SoftReference<>(new ArrayList<>()); > ??????????????? ref.get().add(b); > ??????????? } catch (OutOfMemoryError e) { > ??????????????? if (ref.refersTo(null)) { > ??????????????????? throw new AssertionError("allocations = > %d".formatted((news)), e); > ??????????????? } > ??????????????? throw new AssertionError("non-null referent", e); > ??????????? } > ??????? } > ??? } > > } > > > E.g., > java -XX:+UseG1GC -Xms1g -Xmx1g -cp ... Softly 800000000 > > > Depending on the collector and how tight the heap is, I sometimes > observe a "Java heap space" OOME but then the referent of ref is null. > I never observed a OOME with a non-null referent for ref. Hence, in > scenarios where OOME are caused by heap exhaustion, soft refs seem to > work as advertised. > > Tried on AdoptOpenJDK-16.0.1+9 with SerialGC, ParallelGC, G1GC, ZGC > and ShenandoahGC with either -Xms1g/-Xmx1g or -Xms2g/-Xmx2g (small > heaps) and various byte[] sizes. > > Thus, the current wording in SoftReference's javadoc: > > "All soft references to softly-reachable objects are guaranteed to > have been cleared before the virtual machine throws an OutOfMemoryError." > > could be amended to read: > > "All soft references to softly-reachable objects are guaranteed to > have been cleared before the virtual machine throws an > OutOfMemoryError caused by Java heap space exhaustion." > > > Greetings > Raffaello > > ---- > > [1] https://bugs.openjdk.java.net/browse/JDK-8267222 From jlahoda at openjdk.java.net Fri Jun 4 20:20:27 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 20:20:27 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: <3V_zMXiJp7WrQ3RTA9T5XdwDYsHCPluTNVva7q5BLWA=.69ff5e7e-b2b8-4588-aa09-eedf19b1ba9b@github.com> On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Fixing typo. Thanks a lot for all the feedback. I've tried to do the requested changes in the recent commits. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 20:20:26 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 20:20:26 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v13] In-Reply-To: References: Message-ID: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Applying review feedback. - Tweaking javadoc. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3863/files - new: https://git.openjdk.java.net/jdk/pull/3863/files/8d4c02b4..e3c29759 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3863&range=11-12 Stats: 125 lines in 8 files changed: 91 ins; 10 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/3863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3863/head:pull/3863 PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 20:20:28 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 20:20:28 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 15:46:32 GMT, Paul Sandoz wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing typo. > > test/langtools/tools/javac/patterns/DisambiguateParenthesizedPattern.java line 72: > >> 70: SwitchTree st = (SwitchTree) method.getBody().getStatements().get(0); >> 71: CaseLabelTree label = st.getCases().get(0).getLabels().get(0); >> 72: ExpressionType actualType = switch (label) { > > Should the test be careful of using a pattern match switch? I don't think using the new feature in the tests is problematic (esp. javac tests related to the feature). It helps to ensure the feature really works on real code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From jlahoda at openjdk.java.net Fri Jun 4 20:20:29 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 4 Jun 2021 20:20:29 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 18:23:28 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing typo. > > test/langtools/tools/javac/patterns/SealedTypeChanges.java line 71: > >> 69: } >> 70: >> 71: sealed interface SealedTypeChangesIntf permits SealedTypeChanges.A {} > > just for completeness shouldn't we have a test with sealed, non-abstract classes? Note that for sealed non-abstract classes, the permits is not checked (as an instance of the non-abstract class may be created and passed to the switch, the switch needs to contain a case that will cover the class anyway). I've added tests that check the behavior for abstract class, and non-abstract classes (error is produced in the latter case). ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From raffaello.giulietti at gmail.com Fri Jun 4 20:24:33 2021 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 4 Jun 2021 22:24:33 +0200 Subject: Comment on JDK-826722: SoftReference not cleared on OutOfMemoryError: Requested array size exceeds VM limit In-Reply-To: <82fe9919-90de-0f60-96e5-994d29d006af@oracle.com> References: <60ca3edc-0c66-cbda-71ab-1a7f20cb21aa@gmail.com> <82fe9919-90de-0f60-96e5-994d29d006af@oracle.com> Message-ID: <920fc3ce-3388-e7b8-74ba-1f1c319bbbc6@gmail.com> Hi Mandy, the OOME thrown for VM limits reasons is not related to any purported heap exhaustion but to the VM refusing to allocate an array of size Integer.MAX_VALUE or Integer.MAX_VALUE - 1, *even* if there's plenty of space. For example, with 8 GiB of heap and a size of Integer.MAX_VALUE - 2 the small program runs without fuss: java -XX:+UseG1GC -Xms8g -Xmx8g -cp ... Softly 2147483645 But when the argument is increased by 1 to Integer.MAX_VALUE - 1 java -XX:+UseG1GC -Xms8g -Xmx8g -cp ... Softly 2147483646 you immediately get: Exception in thread "main" java.lang.AssertionError: non-null referent at Softly.main(Softly.java:26) Caused by: java.lang.OutOfMemoryError: Requested array size exceeds VM limit at Softly.main(Softly.java:15) In other words, OOME is "abused" in such cases. A VM limit error should really throw another kind of error, not OOME, because contrary to its name there's not necessarily a lack of memory space, as shown here. To parallel current behavior, thus, the spec should be amended as proposed "... an OutOfMemoryError caused by Java heap space exhaustion." or a similar wording. Alternatively, to maintain the current spec untouched, the VM should throw another kind of error for VM limits. Not sure if this has any adverse impact on existing code in the wild. Greetings Raffaello On 2021-06-04 21:16, Mandy Chung wrote: > I'm not sure if the spec should be updated.? JDK-8267222 needs the GC > team to evaluate. > > I have added my comment in this JBS issue. > > The SoftReference spec has the guarantee: > ????All soft references to softly-reachable objects are guaranteed to > have been cleared before the virtual machine throws an OutOfMemoryError.? > > This is a reasonable guarantee expected by design in response to memory > demand. > > For the OOME thrown due to "requested array size exceeds VM limit", it > seems that this is a fast-path throwing OOME without really going > through the object allocation request (where reference processing will > be performed in GC cycle). > > The question to the GC team is whether VM implementation can and should > support this soft reference guarantee. Note that the soft reference > objects are cleared as specified, the large object allocation exceeding > VM limit would fail any way. If the implementation is feasible, I'm > inclined to clear the soft reference objects when OOME is thrown as > specified even the object allocation request is known to fail. > > Mandy > > On 6/3/21 11:57 AM, Raffaello Giulietti wrote: >> Hi, >> >> upon reading [1] I tried a similar scenario, but where OOME are caused >> by "Java heap space" exhaustion rather than by VM limits. >> >> >> import java.lang.ref.SoftReference; >> import java.text.DecimalFormat; >> import java.util.ArrayList; >> >> public class Softly { >> >> ??? public static void main(String[] args) { >> ??????? var size = Integer.parseInt(args[0]); >> ??????? var format = new DecimalFormat("#,###"); >> ??????? var news = 0; >> ??????? var ref = new SoftReference<>(new ArrayList<>()); >> ??????? for (;;) { >> ??????????? byte[] b = null; >> ??????????? try { >> ??????????????? b = new byte[size]; >> ??????????????? ++news; >> ??????????????? ref.get().add(b); >> ??????????? } catch (NullPointerException __) { >> ??????????????? System.out.format("totSize = %20s, allocations = >> %d\n", format.format((long) news * size), news); >> ??????????????? ref = new SoftReference<>(new ArrayList<>()); >> ??????????????? ref.get().add(b); >> ??????????? } catch (OutOfMemoryError e) { >> ??????????????? if (ref.refersTo(null)) { >> ??????????????????? throw new AssertionError("allocations = >> %d".formatted((news)), e); >> ??????????????? } >> ??????????????? throw new AssertionError("non-null referent", e); >> ??????????? } >> ??????? } >> ??? } >> >> } >> >> >> E.g., >> java -XX:+UseG1GC -Xms1g -Xmx1g -cp ... Softly 800000000 >> >> >> Depending on the collector and how tight the heap is, I sometimes >> observe a "Java heap space" OOME but then the referent of ref is null. >> I never observed a OOME with a non-null referent for ref. Hence, in >> scenarios where OOME are caused by heap exhaustion, soft refs seem to >> work as advertised. >> >> Tried on AdoptOpenJDK-16.0.1+9 with SerialGC, ParallelGC, G1GC, ZGC >> and ShenandoahGC with either -Xms1g/-Xmx1g or -Xms2g/-Xmx2g (small >> heaps) and various byte[] sizes. >> >> Thus, the current wording in SoftReference's javadoc: >> >> "All soft references to softly-reachable objects are guaranteed to >> have been cleared before the virtual machine throws an OutOfMemoryError." >> >> could be amended to read: >> >> "All soft references to softly-reachable objects are guaranteed to >> have been cleared before the virtual machine throws an >> OutOfMemoryError caused by Java heap space exhaustion." >> >> >> Greetings >> Raffaello >> >> ---- >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8267222 > From github.com+9004656+yaaz at openjdk.java.net Fri Jun 4 21:32:10 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Fri, 4 Jun 2021 21:32:10 GMT Subject: RFR: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac Message-ID: I got rid of `realpath` usage as discussed in https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro instead, however there were quite a few problems with this macro, here's the example: $(call RelativePath,/foo/bar,/foo/bar/baz) -> " ..//foo/bar" $(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT $(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> " ./baz/banan" $(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> " ../baz" As you can see, 1st case is just plain wrong, 2nd crashes make because of infinite loop, 3rd can be simplified and all of them have leading whitespaces First commit in this PR fixes all these issues and adds corresponding test cases and second commit replaces usage of `realpath` in idea.sh with `RelativePath` macro in idea.gmk and fixes problems, when paths are incorrectly treated by IDEA ------------- Commit messages: - 8268083: Got rid of realpath usage in bin/idea.sh - 8268083: Fix FindCommonPathPrefix and RelativePath macros in make/common/Utils.gmk Changes: https://git.openjdk.java.net/jdk/pull/4369/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4369&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268083 Stats: 219 lines in 11 files changed: 107 ins; 47 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/4369.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4369/head:pull/4369 PR: https://git.openjdk.java.net/jdk/pull/4369 From dlsmith at openjdk.java.net Fri Jun 4 21:33:57 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 4 Jun 2021 21:33:57 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: <2pALT6FW7TiuwdgD4JJuEzZe7iEnv1DBwWXMptFkEWQ=.65c7c670-f3fe-4a84-8f46-c6c48ceb4a49@github.com> References: <2pALT6FW7TiuwdgD4JJuEzZe7iEnv1DBwWXMptFkEWQ=.65c7c670-f3fe-4a84-8f46-c6c48ceb4a49@github.com> Message-ID: <1NnwFzxqed_jMja6qvPwZBp8cJgAFYoIEAIgG5jHQt0=.13794a40-960c-4082-b2f3-58444cd16076@github.com> On Fri, 4 Jun 2021 00:08:41 GMT, Mandy Chung wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix accidentally commented-out parts of test > > src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 457: > >> 455: * @return a CallSite whose target can be used to perform capture, generating >> 456: * instances of the interface named by {@code factoryType} >> 457: * @throws LambdaConversionException If {@code caller} does not have private > > One additional comment: > > The lookup access has been extended since 14 to include `MODULE` and `ORIGINAL` access. > `Lookup::hasFullPrivilegeAccess` returns true if the lookup has `PRIVATE` and `MODULE` which means that this lookup is not teleported from another module via `Lookup::in` and `MethodHandles::privateLookupIn`. > > What privilege do you expect the `caller` lookup should have? I believe full privilege access is the appropriate privilege. The `ORIGINAL` access is stricter as the lookup must be created from the original lookup class. > > [1] shows what access a `Lookup` has when being produced via different APIs. > > [1] https://download.java.net/java/early_access/jdk17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#access-modes Thanks, yes I think `hasFullPrivilegeAccess` is what we want. I updated the javadoc, along with the actual check. Thanks for catching! > test/jdk/java/lang/invoke/lambda/MetafactoryArgValidationTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. > > copyright year needs update. Fixed. And I bumped it on the other files, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From dlsmith at openjdk.java.net Fri Jun 4 21:38:59 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 4 Jun 2021 21:38:59 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 01:22:05 GMT, liach wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix accidentally commented-out parts of test > > src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 547: > >> 545: throw new IllegalArgumentException("argument has wrong type"); >> 546: } >> 547: return type.cast(result); > > Can we just use a `return (T) result` as there will always be a checked cast on the caller's end, and this call seems redundant? The only shortcoming is that the call will raise an unchecked warning that needs to be suppressed. Or is this negligible after hotspot optimization? Eh, the scale here is quite small (never more than, say, 20 items), and an instanceof + a cast is a routine coding style that I'd expect to be optimized away. Doesn't seem worth the maintenance noise of a `@SuppressWarnings`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From erikj at openjdk.java.net Fri Jun 4 21:55:02 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 4 Jun 2021 21:55:02 GMT Subject: RFR: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov wrote: > I got rid of `realpath` usage as discussed in https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro instead, however there were quite a few problems with this macro, here's the example: > > $(call RelativePath,/foo/bar,/foo/bar/baz) -> " ..//foo/bar" > $(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT > $(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> " ./baz/banan" > $(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> " ../baz" > > As you can see, 1st case is just plain wrong, 2nd crashes make because of infinite loop, 3rd can be simplified and all of them have leading whitespaces > First commit in this PR fixes all these issues and adds corresponding test cases and second commit replaces usage of `realpath` in idea.sh with `RelativePath` macro in idea.gmk and fixes problems, when paths are incorrectly treated by IDEA Nice work, this looks great! Thank you for improving the RelativePath macro. Since this is touching some very core and sensitive build functionality, I'm going to run it through all our internal builds just to be safe. ------------- PR: https://git.openjdk.java.net/jdk/pull/4369 From dlsmith at openjdk.java.net Fri Jun 4 22:04:19 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 4 Jun 2021 22:04:19 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v3] In-Reply-To: References: Message-ID: <-6zG1vORDQmf7hiaJuDnx3QO0Vv9IqVobSYdpd3QBlg=.3369e391-1478-4176-935a-4e0472415c16@github.com> > Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. > > Does some renaming of core parameters/fields to better reflect their purpose. > > In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Address reviewer comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4346/files - new: https://git.openjdk.java.net/jdk/pull/4346/files/4b8d0dab..b8b4ac14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4346&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4346&range=01-02 Stats: 73 lines in 4 files changed: 0 ins; 0 del; 73 mod Patch: https://git.openjdk.java.net/jdk/pull/4346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4346/head:pull/4346 PR: https://git.openjdk.java.net/jdk/pull/4346 From dlsmith at openjdk.java.net Fri Jun 4 22:04:20 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 4 Jun 2021 22:04:20 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 06:16:45 GMT, Peter Levart wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix accidentally commented-out parts of test > > src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java line 69: > >> 67: final boolean isSerializable; // Should the returned instance be serializable >> 68: final Class[] interfaces; // Additional interfaces to be implemented >> 69: final MethodType[] bridges; // Signatures of additional methods to bridge > > If you are removing ACC_BRIDGE from additional generated methods, then perhaps this parameter name could also be changed? `altMethods` (as alternative methods perhaps?) Yes, it was sort of a half-done move. You're right, we should rename these (and, more importantly, in the public LambdaMetafactory API). Done. Also renamed `interfaces` --> `altInterfaces`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From mchung at openjdk.java.net Fri Jun 4 22:12:56 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Jun 2021 22:12:56 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v3] In-Reply-To: <-6zG1vORDQmf7hiaJuDnx3QO0Vv9IqVobSYdpd3QBlg=.3369e391-1478-4176-935a-4e0472415c16@github.com> References: <-6zG1vORDQmf7hiaJuDnx3QO0Vv9IqVobSYdpd3QBlg=.3369e391-1478-4176-935a-4e0472415c16@github.com> Message-ID: On Fri, 4 Jun 2021 22:04:19 GMT, Dan Smith wrote: >> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. >> >> Does some renaming of core parameters/fields to better reflect their purpose. >> >> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Address reviewer comments Can you also rename the parameter names in `java.lang.invoke.LambdaProxyClassArchive` methods to match the new ones? src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 312: > 310: * @return a CallSite whose target can be used to perform capture, generating > 311: * instances of the interface named by {@code factoryType} > 312: * @throws LambdaConversionException If {@code caller} does not have full privilege Suggestion: * @throws LambdaConversionException If {@code caller} does not have {@linkplain Lookup#hasFullPrivilegeAccess full privilege} ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From dlsmith at openjdk.java.net Fri Jun 4 23:44:01 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Fri, 4 Jun 2021 23:44:01 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v3] In-Reply-To: References: <-6zG1vORDQmf7hiaJuDnx3QO0Vv9IqVobSYdpd3QBlg=.3369e391-1478-4176-935a-4e0472415c16@github.com> Message-ID: On Fri, 4 Jun 2021 22:06:49 GMT, Mandy Chung wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Address reviewer comments > > src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 312: > >> 310: * @return a CallSite whose target can be used to perform capture, generating >> 311: * instances of the interface named by {@code factoryType} >> 312: * @throws LambdaConversionException If {@code caller} does not have full privilege > > Suggestion: > > * @throws LambdaConversionException If {@code caller} does not have {@linkplain Lookup#hasFullPrivilegeAccess full privilege} It's hard to see in the diff, but this link just appeared in the javadoc a few lines above. Stylistically, doesn't seem like it should be linked again. ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From ngasson at openjdk.java.net Fri Jun 4 23:58:06 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 4 Jun 2021 23:58:06 GMT Subject: Integrated: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote: > macOS on Apple silicon uses slightly different ABI conventions to the > standard AArch64 ABI. The differences are outlined in [1]. In > particular in the standard (AAPCS) ABI, variadic arguments may be passed > in either registers or on the stack following the normal calling > convention. To handle this, va_list is a struct containing separate > pointers for arguments located in integer registers, floating point > registers, and on the stack. Apple's ABI simplifies this by passing all > variadic arguments on the stack and the va_list type becomes a simple > char* pointer. > > This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to > represent the new ABI variant on macOS. StackVaList is based on > WinVaList lightly modified to handle the different TypeClasses on > AArch64. The original AArch64Linker is renamed to AapcsLinker and is > currently used for all non-Mac platforms. I think we also need to add a > WinAArch64 CABI but I haven't yet been able to test on a Windows system > so will do that later. > > The macOS ABI also uses a different method of spilling arguments to the > stack (the standard ABI pads each argument to a multiple of 8 byte stack > slots, but the Mac ABI packs arguments according to their natural > alignment). None of the existing tests exercise this so I'll open a new > JBS issue and work on that separately. > > Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64. > > [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms This pull request has now been integrated. Changeset: 76b54a19 Author: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/76b54a19955cd93f071cf1fb45c6d01bb57b84eb Stats: 778 lines in 15 files changed: 571 ins; 115 del; 92 mod 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native Reviewed-by: jvernee ------------- PR: https://git.openjdk.java.net/jdk/pull/3617 From dlsmith at openjdk.java.net Sat Jun 5 00:15:25 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Sat, 5 Jun 2021 00:15:25 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v3] In-Reply-To: References: <-6zG1vORDQmf7hiaJuDnx3QO0Vv9IqVobSYdpd3QBlg=.3369e391-1478-4176-935a-4e0472415c16@github.com> Message-ID: On Fri, 4 Jun 2021 22:09:39 GMT, Mandy Chung wrote: > Can you also rename the parameter names in `java.lang.invoke.LambdaProxyClassArchive` methods to match the new ones? Hmm, that expands the reach of the patch a bit?into native HotSpot code?but I've given it a try. Let me know if it looks like I've broken something. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From dlsmith at openjdk.java.net Sat Jun 5 00:15:25 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Sat, 5 Jun 2021 00:15:25 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v4] In-Reply-To: References: Message-ID: > Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. > > Does some renaming of core parameters/fields to better reflect their purpose. > > In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). Dan Smith has updated the pull request incrementally with two additional commits since the last revision: - Fix stray renaming - Apply renamings to LambdaProxyClassArchive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4346/files - new: https://git.openjdk.java.net/jdk/pull/4346/files/b8b4ac14..9d722edf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4346&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4346&range=02-03 Stats: 94 lines in 4 files changed: 0 ins; 0 del; 94 mod Patch: https://git.openjdk.java.net/jdk/pull/4346.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4346/head:pull/4346 PR: https://git.openjdk.java.net/jdk/pull/4346 From henryjen at openjdk.java.net Sat Jun 5 00:19:25 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Sat, 5 Jun 2021 00:19:25 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v3] In-Reply-To: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: > ?d on macOS > > This patch simply round up the specified stack size to multiple of the system page size. > > Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. > > ```code:java > public class StackLeak { > public int depth = 0; > public void stackLeak() { > depth++; > stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge - Only try to round-up when current value failed - Avoid overflow on page size - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4256/files - new: https://git.openjdk.java.net/jdk/pull/4256/files/39b041d7..1e96be94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=01-02 Stats: 485003 lines in 2409 files changed: 450413 ins; 28438 del; 6152 mod Patch: https://git.openjdk.java.net/jdk/pull/4256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4256/head:pull/4256 PR: https://git.openjdk.java.net/jdk/pull/4256 From mchung at openjdk.java.net Sat Jun 5 00:45:01 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 5 Jun 2021 00:45:01 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v3] In-Reply-To: References: <-6zG1vORDQmf7hiaJuDnx3QO0Vv9IqVobSYdpd3QBlg=.3369e391-1478-4176-935a-4e0472415c16@github.com> Message-ID: On Fri, 4 Jun 2021 23:41:06 GMT, Dan Smith wrote: >> src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 312: >> >>> 310: * @return a CallSite whose target can be used to perform capture, generating >>> 311: * instances of the interface named by {@code factoryType} >>> 312: * @throws LambdaConversionException If {@code caller} does not have full privilege >> >> Suggestion: >> >> * @throws LambdaConversionException If {@code caller} does not have {@linkplain Lookup#hasFullPrivilegeAccess full privilege} > > It's hard to see in the diff, but this link just appeared in the javadoc a few lines above. Stylistically, doesn't seem like it should be linked again. I didn't realize it's already linked, thanks. So what you have is fine then. ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From mchung at openjdk.java.net Sat Jun 5 01:01:59 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 5 Jun 2021 01:01:59 GMT Subject: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation [v4] In-Reply-To: References: Message-ID: On Sat, 5 Jun 2021 00:15:25 GMT, Dan Smith wrote: >> Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. >> >> Does some renaming of core parameters/fields to better reflect their purpose. >> >> In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). > > Dan Smith has updated the pull request incrementally with two additional commits since the last revision: > > - Fix stray renaming > - Apply renamings to LambdaProxyClassArchive Thanks for going beyond the java code. Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4346 From henryjen at openjdk.java.net Sat Jun 5 01:48:21 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Sat, 5 Jun 2021 01:48:21 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v4] In-Reply-To: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: > ?d on macOS > > This patch simply round up the specified stack size to multiple of the system page size. > > Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. > > ```code:java > public class StackLeak { > public int depth = 0; > public void stackLeak() { > depth++; > stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Change java -X output for -Xss ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4256/files - new: https://git.openjdk.java.net/jdk/pull/4256/files/1e96be94..764a1f93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4256/head:pull/4256 PR: https://git.openjdk.java.net/jdk/pull/4256 From clanger at openjdk.java.net Sat Jun 5 05:52:07 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Sat, 5 Jun 2021 05:52:07 GMT Subject: RFR: JDK-8266918: merge_stack in check_code.c add NULL check [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 14:10:20 GMT, Matthias Baesken wrote: >> Hello, please review this small Sonar finding. >> Sonar reports a potential NULL pointer dereference here : >> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&types=BUG >> "Access to field 'item' results in a dereference of a null pointer (loaded from variable 'new')" >> It would be better to add a check . > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Replace check by assertion Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3979 From godin at openjdk.java.net Sat Jun 5 08:13:01 2021 From: godin at openjdk.java.net (Evgeny Mandrikov) Date: Sat, 5 Jun 2021 08:13:01 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12] In-Reply-To: <3V_zMXiJp7WrQ3RTA9T5XdwDYsHCPluTNVva7q5BLWA=.69ff5e7e-b2b8-4588-aa09-eedf19b1ba9b@github.com> References: <3V_zMXiJp7WrQ3RTA9T5XdwDYsHCPluTNVva7q5BLWA=.69ff5e7e-b2b8-4588-aa09-eedf19b1ba9b@github.com> Message-ID: On Fri, 4 Jun 2021 20:17:43 GMT, Jan Lahoda wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing typo. > > Thanks a lot for all the feedback. I've tried to do the requested changes in the recent commits. @lahodaj I also noticed that https://bugs.openjdk.java.net/browse/JDK-8213076 as well as https://openjdk.java.net/jeps/406 state > The implementation will likely make use of dynamic constants (JEP 309). and wondering if this should be changed on > The implementation will likely make use of invokedynamic. or maybe even removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at openjdk.java.net Sat Jun 5 09:46:06 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 5 Jun 2021 09:46:06 GMT Subject: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v13] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 20:20:26 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >> http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html >> >> A summary of notable parts of the patch: >> -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. >> -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. >> -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. >> -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. >> -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. >> -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. >> >> The specdiff for the change is here (to be updated): >> http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html > > Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: > > - Applying review feedback. > - Tweaking javadoc. Dynamic constants are needed when de-structuring classes that are not record at top-level, to make the type that will carry the bindings, from invokedynamic to where they are accessed, opaque. So dynamic constants are not needed yet ! ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From scolebourne at openjdk.java.net Sat Jun 5 13:30:08 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Sat, 5 Jun 2021 13:30:08 GMT Subject: Integrated: 8266846: Add java.time.InstantSource In-Reply-To: References: Message-ID: On Thu, 13 May 2021 20:52:33 GMT, Stephen Colebourne wrote: > 8266846: Add java.time.InstantSource This pull request has now been integrated. Changeset: 6c838c56 Author: Stephen Colebourne Committer: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/6c838c568c2c99145fd0ae8059de2b2865b65863 Stats: 623 lines in 6 files changed: 536 ins; 64 del; 23 mod 8266846: Add java.time.InstantSource Reviewed-by: rriggs, naoto, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/4016 From dcubed at openjdk.java.net Sat Jun 5 13:47:01 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 5 Jun 2021 13:47:01 GMT Subject: RFR: 8268227: java/foreign/TestUpcall.java still times out In-Reply-To: References: Message-ID: <2htTeXgTYFD5YoryvMFomelBcLzKril9F65Xl3CnNeA=.f98a25ca-ddca-4fd6-9950-ab877660b2d9@github.com> On Fri, 4 Jun 2021 10:53:42 GMT, Maurizio Cimadamore wrote: > Turns out that adding more timeout is a lost cause here. The root cause of the slowdown when running the test in debug build is: > > https://bugs.openjdk.java.net/browse/JDK-8266074 > > Which has also caused related test issues: > > https://bugs.openjdk.java.net/browse/JDK-8268095 > > So, the fix (at least temporarily) is to run method handle-heavy tests with the -XX:-VerifyDependency options. > > On my machine, execution time of these tests on debug goes from 10 minutes down to less than 1. > > Since `-XX:-VerifyDependencies` cannot be specified on non-debug build, the `-XX:+IgnoreUnrecognizedVMOptions` is also passed (thanks Vlad for the tip!). Thumbs up! -XX:-VerifyDependencies is useful for getting around the non-release bits slowness added by the new CHA based stuff added by: JDK-8266074 Vtable-based CHA implementation ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4355 From github.com+6704669+asgibbons at openjdk.java.net Sat Jun 5 14:12:11 2021 From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons) Date: Sat, 5 Jun 2021 14:12:11 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 Message-ID: Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. Benchmark Name | Base Score | Optimized Score | Gain -- | -- | -- | -- testBase64Decode size 1 | 15.36 | 15.32 | 1.00 testBase64Decode size 3 | 17.00 | 16.72 | 1.02 testBase64Decode size 7 | 20.60 | 18.82 | 1.09 testBase64Decode size 32 | 34.21 | 26.77 | 1.28 testBase64Decode size 64 | 54.43 | 38.35 | 1.42 testBase64Decode size 80 | 66.40 | 48.34 | 1.37 testBase64Decode size 96 | 73.16 | 52.90 | 1.38 testBase64Decode size 112 | 84.93 | 51.82 | 1.64 testBase64Decode size 512 | 288.81 | 32.04 | 9.01 testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 ------------- Commit messages: - Merge remote-tracking branch 'origin/base64_length_restrict' into base64_decode - Condition decode intrinsic within generator instead of outside to allow non-AVX acceleration - Adding MIME to signature. - Adding MIME to signature. - Adding MIME to signature. - Initialize vector before loop - Initialize vector before loop - Wrong register lengths. - Wrong register lengths. - writing in wrong order - ... and 418 more: https://git.openjdk.java.net/jdk/compare/48dc72b7...e527557a Changes: https://git.openjdk.java.net/jdk/pull/4368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268276 Stats: 743 lines in 10 files changed: 736 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368 From darcy at openjdk.java.net Sat Jun 5 18:42:37 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 5 Jun 2021 18:42:37 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v4] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - Update symbols for JDK 17 b25. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/5aafa154...f926c1bc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/fc4d8725..f926c1bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=02-03 Stats: 2678 lines in 127 files changed: 1537 ins; 898 del; 243 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From cushon at openjdk.java.net Sun Jun 6 20:18:18 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Sun, 6 Jun 2021 20:18:18 GMT Subject: RFR: 8268296: ScopedMemoryAccess build error with readonly filesystems Message-ID: This change fixes a build error during the generation of `ScopedMemoryAccess.java` when the sources are readonly, by using `cat a > b` instead of `cp a b` to avoid propagating the permissions to the generated source. ------------- Commit messages: - 8268296: ScopedMemoryAccess build error with readonly filesystems Changes: https://git.openjdk.java.net/jdk/pull/4380/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4380&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268296 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4380/head:pull/4380 PR: https://git.openjdk.java.net/jdk/pull/4380 From winterhalter at openjdk.java.net Sun Jun 6 21:19:03 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Sun, 6 Jun 2021 21:19:03 GMT Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions In-Reply-To: References: Message-ID: On Fri, 7 May 2021 18:58:02 GMT, Rafael Winterhalter wrote: > If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. Reopening PR as it is still under review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3925 From winterhalter at openjdk.java.net Sun Jun 6 21:20:04 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Sun, 6 Jun 2021 21:20:04 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v3] In-Reply-To: References: Message-ID: <6PLOE14WuQeoBCj82wjltnbIJhNSp2zoW_YtCGrNH8E=.d5e1e104-e954-46ef-8c83-2880476a5738@github.com> On Sat, 8 May 2021 09:51:46 GMT, Rafael Winterhalter wrote: >> This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. > > Rafael Winterhalter 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. Commenting on PR to avoid closing it, as it is still under review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3892 From dholmes at openjdk.java.net Sun Jun 6 22:29:02 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 6 Jun 2021 22:29:02 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> Message-ID: <-V3-GuFQLcbKVotN0nKemAI3s3mkmbtHW0WgpYL6cvc=.e4eb2552-ff8f-459f-afa5-4a312508228e@github.com> On Fri, 4 Jun 2021 14:00:25 GMT, Maxim Kartashev wrote: >> Not an expert by my understanding is that the VM only deals with modified UTF-8, as does JNI. So the incoming string should be modified-UTF8 IMO and then converted to UTF16. >> >> That said, this is shared code being modified on the JDK side so you can't just change the type of string being passed in without updating all the implementations of os::dll_load to support that! > > I think we need to establish some common ground before proceeding further with this fix. It's a bit of a long read; please, bear with me. > > The path name starts its life as a `jstring` in `Java_jdk_internal_loader_NativeLibraries_load()`, its encoding is irrelevant at this point. > > Next, the name has to be passed down to `JVM_LoadLibrary()` that takes `char*`. So we need to convert form `jstring` to `char*` (point (a)). Following that, `os::dll_load()` that actually performs loading in a platform-specific manner also receives `char*`. All platform implementations of `os::dll_load()` pass the path name down to their respective platform's APIs unmodified, but I think that's just incidental and here we have another possible point of conversion (point (b)). Other consumers of the path name are exception(c) and logging(d) messages; they also take `char*`, but potentially of a different encoding. > > Let me try to enumerate all conceivably valid conversions for `JVM_LoadLibrary()` consumption (point (a)): > 1. jstring -> platform-specific encoding (status quo meaning possibly lossy encoding on Windows and UTF-8 elsewhere AFAICT), > 2. jstring -> modified UTF-8, > 3. jstring -> UTF-8. > > This bug [8195129](https://bugs.openjdk.java.net/browse/JDK-8195129) occurs because conversion (1) may loose information on Windows if the platform encoding happens to be NOT UTF-8 (which it often - or even always - is). So that's a no-go and we are left with either (2) or (3). > > On MacOS and Linux, "platform" encoding already is UTF-8 and since all the platform APIs happily consume UTF-8, no further conversion is necessary (neither for actual library loading, nor for log or exception messages; the latter have to convert to UTF-16, but do that under the hood). > > On Windows, we require at least these variants of the path name: > 1. UTF16 for library loading (Unicode Windows API), > 2. "platform" encoding for logging (yes, loosing information here, but that's tolerable), > 3. "platform" (lossy) or UTF8 (lossless) encoding for exception messages (prefer lossless). > > This is what's behind my choice of UTF-8 for the path name encoding as it gets passed down to `JVM_LoadLibrary()`. We can go with modified UTF-8, of course, in which case all platforms - not just Windows - will have to do the conversion on their own, loosing the benefit of the knowledge about the original string encoding (the String.coder field of jstring). @mkartashev thank you for the detailed explanation. It is not clear to me that the JDK's conformance to being a Unicode application has significantly changed since the evaluation of JDK-8017274 - @naotoj can you comment on that and related discussion from the CCC for JDK-4958170 ? In particular I'm not sure that using the platform encoding is wrong, nor how we can have a path that cannot be represented by the platform encoding? Not being an expert in this area I cannot evaluate the affects of these shared code changes on other platforms, and so am reluctant to introduce any change that affects any non-Windows platforms. Also the JVM and JNI work with modified-UTF8 so I do not think we should diverge from that. I would hate to see windows specific code introduced into the JDK or JVM's shared code for these APIs, but that may be the only choice to avoid potential disruption to other platforms. Though perhaps we could push the initial conversion down into the JVM? ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From darcy at openjdk.java.net Mon Jun 7 00:15:09 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Jun 2021 00:15:09 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Message-ID: Make explicit illegal argument cases of Class.arrayType. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8268300 ------------- Commit messages: - Add test file. - Merge branch 'master' into 8268250 - 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException Changes: https://git.openjdk.java.net/jdk/pull/4382/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268250 Stats: 55 lines in 2 files changed: 55 ins; 0 del; 0 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 Mon Jun 7 00:22:41 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Jun 2021 00:22:41 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v2] 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 incrementally with one additional commit since the last revision: Add missing ending newline. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4382/files - new: https://git.openjdk.java.net/jdk/pull/4382/files/d26fe1e4..088e025f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4382&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 dholmes at openjdk.java.net Mon Jun 7 02:25:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Jun 2021 02:25:58 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v4] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: <2jMU1wmNZx1tB3pWkEYrCQwmGP_YzXvsyWaaciB1vIo=.e75685cf-097a-4b43-9c0d-dc38a2ce1078@github.com> On Sat, 5 Jun 2021 01:48:21 GMT, Henry Jen wrote: >> ?d on macOS >> >> This patch simply round up the specified stack size to multiple of the system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >> >> ```code:java >> public class StackLeak { >> public int depth = 0; >> public void stackLeak() { >> depth++; >> stackLeak(); >> } >> >> public static void main(String[] args) { >> var test = new StackLeak(); >> try { >> test.stackLeak(); >> } catch (Throwable e) { >> System.out.println(test.depth); >> } >> } >> } > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Change java -X output for -Xss I'm a bit confused about the state of this PR. It was closed/withdrawn but then reopened but with changes applied to platforms other than macOS - why? Also the code does not compile on Linux in current form. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From henryjen at openjdk.java.net Mon Jun 7 03:18:32 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Mon, 7 Jun 2021 03:18:32 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: > ?d on macOS > > This patch simply round up the specified stack size to multiple of the system page size. > > Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. > > ```code:java > public class StackLeak { > public int depth = 0; > public void stackLeak() { > depth++; > stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Cast type - Merge - Change java -X output for -Xss - Merge - Only try to round-up when current value failed - Avoid overflow on page size - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4256/files - new: https://git.openjdk.java.net/jdk/pull/4256/files/764a1f93..5a8d4a10 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=03-04 Stats: 1679 lines in 41 files changed: 1388 ins; 168 del; 123 mod Patch: https://git.openjdk.java.net/jdk/pull/4256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4256/head:pull/4256 PR: https://git.openjdk.java.net/jdk/pull/4256 From henryjen at openjdk.java.net Mon Jun 7 03:25:03 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Mon, 7 Jun 2021 03:25:03 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote: >> ?d on macOS >> >> This patch simply round up the specified stack size to multiple of the system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >> >> ```code:java >> public class StackLeak { >> public int depth = 0; >> public void stackLeak() { >> depth++; >> stackLeak(); >> } >> >> public static void main(String[] args) { >> var test = new StackLeak(); >> try { >> test.stackLeak(); >> } catch (Throwable e) { >> System.out.println(test.depth); >> } >> } >> } > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Cast type > - Merge > - Change java -X output for -Xss > - Merge > - Only try to round-up when current value failed > - Avoid overflow on page size > - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS Planned to close JDK-8236569 as 'Won't Fix', as the issue was re-opened, we give it another shot. As explained in the CSR review, we will only round-up the stack size as required by the operating system. Test on Ubuntu shows that there is no need to round-up, while some other Posix system might as explained in the man page. We round-up for MacOS as the document explicitly said that the size need to be multiple of system page size. I also changed to use getpagesize() as you suggested, although that's not needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From dholmes at openjdk.java.net Mon Jun 7 05:13:59 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Jun 2021 05:13:59 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Mon, 7 Jun 2021 03:22:18 GMT, Henry Jen wrote: > while some other Posix system might as explained in the man page What manpage? The POSIX specification for this does not allow for EINVAL being returned due to alignment issues. That is an extra constraint imposed by macOS and which makes it non-conforming to the POSIX spec IMO. While the changes in src/java.base/unix/native/libjli/java_md.c seem perfectly fine, are we actually ever going to execute it? ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From alanb at openjdk.java.net Mon Jun 7 06:01:00 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 7 Jun 2021 06:01:00 GMT Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v2] In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 00:22:41 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: > > Add missing ending newline. src/java.base/share/classes/java/lang/Class.java line 4440: > 4438: * @throws IllegalArgumentException if this component type is {@linkplain > 4439: * Void#TYPE void} or if the number of dimensions of the resulting array > 4440: * type would exceed 255. This is a no-arg method so I'm not sure that IAE is the right exception. The method was added in Java 12 so there probably isn't a huge body of code that expects it to throw IAE, meaning it may be possible to change it with little/no impact. ------------- PR: https://git.openjdk.java.net/jdk/pull/4382 From jlahoda at openjdk.java.net Mon Jun 7 07:05:12 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Jun 2021 07:05:12 GMT Subject: Integrated: 8262891: Compiler implementation for Pattern Matching for switch (Preview) In-Reply-To: References: Message-ID: On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote: > This is a preview of a patch implementing JEP 406: Pattern Matching for switch (Preview): > https://bugs.openjdk.java.net/browse/JDK-8213076 > > The current draft of the specification is here: > http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210430/specs/patterns-switch-jls.html > > A summary of notable parts of the patch: > -to support cases expressions and patterns in cases, there is a new common superinterface for expressions and patterns, `CaseLabelTree`, which expressions and patterns implement, and a list of case labels is returned from `CaseTree.getLabels()`. > -to support `case default`, there is an implementation of `CaseLabelTree` that represents it (`DefaultCaseLabelTree`). It is used also to represent the conventional `default` internally and in the newly added methods. > -in the parser, parenthesized patterns and expressions need to be disambiguated when parsing case labels. > -Lower has been enhanced to handle `case null` for ordinary (boxed-primitive, String, enum) switches. This is a bit tricky for boxed primitives, as there is no value that is not part of the input domain so that could be used to represent `case null`. Requires a bit shuffling with values. > -TransPatterns has been enhanced to handle the pattern matching switch. It produces code that delegates to a new bootstrap method, that will classify the input value to the switch and return the case number, to which the switch then jumps. To support guards, the switches (and the bootstrap method) are restartable. The bootstrap method as such is written very simply so far, but could be much more optimized later. > -nullable type patterns are `case String s, null`/`case null, String s`/`case null: case String s:`/`case String s: case null:`, handling of these required a few tricks in `Attr`, `Flow` and `TransPatterns`. > > The specdiff for the change is here (to be updated): > http://cr.openjdk.java.net/~jlahoda/8265981/specdiff.preview.01/overview-summary.html This pull request has now been integrated. Changeset: 908aca29 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/908aca29ca60f5f251df8c6a31b2543929be12fc Stats: 4940 lines in 79 files changed: 4621 ins; 118 del; 201 mod 8262891: Compiler implementation for Pattern Matching for switch (Preview) Co-authored-by: Brian Goetz Co-authored-by: Mandy Chung Co-authored-by: Jan Lahoda Reviewed-by: mcimadamore, forax, godin, psandoz, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/3863 From forax at univ-mlv.fr Mon Jun 7 08:51:49 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 7 Jun 2021 10:51:49 +0200 (CEST) Subject: Pattern matching - exhaustiveness is botched Message-ID: <1411790732.278468.1623055909583.JavaMail.zimbra@u-pem.fr> I don't know if you know but using the latest version of the source, this code does not compile. sealed interface Vehicle {} record Car(String owner, String color) implements Vehicle {} record Bus(String owner) implements Vehicle {} public static void example2() { var vehicles = List.of( new Car("Bob", "red"), new Bus("Ana") ); for(var vehicle: vehicles) { switch(vehicle) { case Car car -> System.out.println("car !"); case Bus bus -> System.out.println("bus !"); //default -> throw new AssertionError(); } } } PatternMatching101.java:25: error: the switch statement does not cover all possible input values switch(vehicle) { ^ same issue with a switch expression. regards, R?mi From forax at univ-mlv.fr Mon Jun 7 09:03:02 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 7 Jun 2021 11:03:02 +0200 (CEST) Subject: Pattern matching, not informative error message when the binding name is missing Message-ID: <1925651484.288197.1623056582206.JavaMail.zimbra@u-pem.fr> Hi all, with this code sealed interface Vehicle {} record Car(String owner, String color) implements Vehicle {} record Bus(String owner) implements Vehicle {} public static void example3() { var vehicles = List.of( new Car("Bob", "red"), new Bus("Ana") ); var tax = vehicles.stream() .mapToInt(v -> switch(v) { case Car -> 100; case Bus -> 200; default -> throw new AssertionError(); }).sum(); System.out.println("tax " + tax); } If there is no binding name in the case, case Car instead of case Car car the error message is not very explicit PatternMatching101.java:40: error: cannot find symbol case Car -> 100; ^ symbol: variable Car location: class PatternMatching101 I believe that in this case, it's possible to know that this is a switch on types, so provide a better error message. regards, R?mi From forax at univ-mlv.fr Mon Jun 7 09:51:29 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 7 Jun 2021 11:51:29 +0200 (CEST) Subject: case null vs case dominance Message-ID: <524498219.340928.1623059489798.JavaMail.zimbra@u-pem.fr> Hi all, the first part of the message is about javac error message that could be improved, the second part is about the current spec being not very logical. With this code Object o = null; var value = switch(o) { //case null -> 0; case Object __ -> 0; case null -> 0; }; System.out.println(value); The error message is PatternMatching101.java:70: error: this case label is dominated by a preceding case label case null -> 0; ^ The error message is wrong here, because it's 'case null' and you can put a case null where you want but below a total pattern, so the error mesage should reflect that. Here is an example that compiles showing that case null can be below a case String, which it dominates Object o = null; var value = switch(o) { case String s -> 0; case null -> 0; default -> 0; }; Also with default, the spec says that the code below should compile (and it works with javac), because default and case null are disjoint in term of type, but it feels wrong to me. Object o = null; var value = switch(o) { default -> 0; case null -> 0; }; System.out.println(value); The problem is that sometimes 'default' acts as a total pattern sometimes it does not, if there is a case null. I wonder if it's not better to ask users to put the case null on top. R?mi From forax at univ-mlv.fr Mon Jun 7 09:54:38 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 7 Jun 2021 11:54:38 +0200 (CEST) Subject: javac throws an AssertionError while compiling a switch on types Message-ID: <1328401025.342802.1623059678373.JavaMail.zimbra@u-pem.fr> Hi all, javac does like this code, there is a check missing because javac should not reach Gen with a code like this. Object o = null; var value = switch(o) { default -> 0; case String s -> 0; }; System.out.println(value); An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. java.lang.AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) at jdk.compiler/com.sun.tools.javac.jvm.Gen.handleSwitch(Gen.java:1310) at jdk.compiler/com.sun.tools.javac.jvm.Gen.doHandleSwitchExpression(Gen.java:1238) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitSwitchExpression(Gen.java:1202) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitchExpression.accept(JCTree.java:1381) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitLetExpr(Gen.java:2376) at jdk.compiler/com.sun.tools.javac.tree.JCTree$LetExpr.accept(JCTree.java:3288) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitVarDef(Gen.java:1081) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1028) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1092) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967) at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:922) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2415) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) regards, R?mi From github.com+28651297+mkartashev at openjdk.java.net Mon Jun 7 11:03:04 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Mon, 7 Jun 2021 11:03:04 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: <-V3-GuFQLcbKVotN0nKemAI3s3mkmbtHW0WgpYL6cvc=.e4eb2552-ff8f-459f-afa5-4a312508228e@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> <-V3-GuFQLcbKVotN0nKemAI3s3mkmbtHW0WgpYL6cvc=.e4eb2552-ff8f-459f-afa5-4a312508228e@github.com> Message-ID: On Sun, 6 Jun 2021 22:25:44 GMT, David Holmes wrote: >> I think we need to establish some common ground before proceeding further with this fix. It's a bit of a long read; please, bear with me. >> >> The path name starts its life as a `jstring` in `Java_jdk_internal_loader_NativeLibraries_load()`, its encoding is irrelevant at this point. >> >> Next, the name has to be passed down to `JVM_LoadLibrary()` that takes `char*`. So we need to convert form `jstring` to `char*` (point (a)). Following that, `os::dll_load()` that actually performs loading in a platform-specific manner also receives `char*`. All platform implementations of `os::dll_load()` pass the path name down to their respective platform's APIs unmodified, but I think that's just incidental and here we have another possible point of conversion (point (b)). Other consumers of the path name are exception(c) and logging(d) messages; they also take `char*`, but potentially of a different encoding. >> >> Let me try to enumerate all conceivably valid conversions for `JVM_LoadLibrary()` consumption (point (a)): >> 1. jstring -> platform-specific encoding (status quo meaning possibly lossy encoding on Windows and UTF-8 elsewhere AFAICT), >> 2. jstring -> modified UTF-8, >> 3. jstring -> UTF-8. >> >> This bug [8195129](https://bugs.openjdk.java.net/browse/JDK-8195129) occurs because conversion (1) may loose information on Windows if the platform encoding happens to be NOT UTF-8 (which it often - or even always - is). So that's a no-go and we are left with either (2) or (3). >> >> On MacOS and Linux, "platform" encoding already is UTF-8 and since all the platform APIs happily consume UTF-8, no further conversion is necessary (neither for actual library loading, nor for log or exception messages; the latter have to convert to UTF-16, but do that under the hood). >> >> On Windows, we require at least these variants of the path name: >> 1. UTF16 for library loading (Unicode Windows API), >> 2. "platform" encoding for logging (yes, loosing information here, but that's tolerable), >> 3. "platform" (lossy) or UTF8 (lossless) encoding for exception messages (prefer lossless). >> >> This is what's behind my choice of UTF-8 for the path name encoding as it gets passed down to `JVM_LoadLibrary()`. We can go with modified UTF-8, of course, in which case all platforms - not just Windows - will have to do the conversion on their own, loosing the benefit of the knowledge about the original string encoding (the String.coder field of jstring). > > @mkartashev thank you for the detailed explanation. > > It is not clear to me that the JDK's conformance to being a Unicode application has significantly changed since the evaluation of JDK-8017274 - @naotoj can you comment on that and related discussion from the CCC for JDK-4958170 ? In particular I'm not sure that using the platform encoding is wrong, nor how we can have a path that cannot be represented by the platform encoding? > > Not being an expert in this area I cannot evaluate the affects of these shared code changes on other platforms, and so am reluctant to introduce any change that affects any non-Windows platforms. Also the JVM and JNI work with modified-UTF8 so I do not think we should diverge from that. > I would hate to see windows specific code introduced into the JDK or JVM's shared code for these APIs, but that may be the only choice to avoid potential disruption to other platforms. Though perhaps we could push the initial conversion down into the JVM? > I think I am hesitant to change the JVM interface from modified UTF-8 to standard UTF-8, AFAICT all platforms except Windows already use standard UTF-8 on that path (from `Java_jdk_internal_loader_NativeLibraries_load()` to `JVM_LoadLibrary()`) because the "platform" encoding for those happens to be "UTF-8". So at the current stage this patch actually maintains status quo for all platforms except Windows, the only platform where the bug exists. But I am not against changing the encoding to modified UTF-8 and updating os::dll_load() for all platforms. Just wanted to have some consensus before proceeding with that change. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From sundar at openjdk.java.net Mon Jun 7 11:07:13 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 7 Jun 2021 11:07:13 GMT Subject: RFR: 8240349: jlink --vm with not present VM does not fail fast Message-ID: jlink should clean up output directory on any failure. should not leave partially filled output. ------------- Commit messages: - 8240349: jlink --vm with not present VM does not fail fast Changes: https://git.openjdk.java.net/jdk/pull/4386/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4386&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240349 Stats: 56 lines in 2 files changed: 56 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4386.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4386/head:pull/4386 PR: https://git.openjdk.java.net/jdk/pull/4386 From jlaskey at openjdk.java.net Mon Jun 7 11:49:02 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Jun 2021 11:49:02 GMT Subject: RFR: 8240349: jlink --vm with not present VM does not fail fast In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 11:00:00 GMT, Athijegannathan Sundararajan wrote: > jlink should clean up output directory on any failure. should not leave partially filled output. Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4386 From erikj at openjdk.java.net Mon Jun 7 12:37:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 12:37:03 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 20:55:51 GMT, Scott Gibbons wrote: > Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. > > A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. > > The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. > > Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. > > **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. > > > Benchmark Name | Base Score | Optimized Score | Gain > -- | -- | -- | -- > testBase64Decode size 1 | 15.36 | 15.32 | 1.00 > testBase64Decode size 3 | 17.00 | 16.72 | 1.02 > testBase64Decode size 7 | 20.60 | 18.82 | 1.09 > testBase64Decode size 32 | 34.21 | 26.77 | 1.28 > testBase64Decode size 64 | 54.43 | 38.35 | 1.42 > testBase64Decode size 80 | 66.40 | 48.34 | 1.37 > testBase64Decode size 96 | 73.16 | 52.90 | 1.38 > testBase64Decode size 112 | 84.93 | 51.82 | 1.64 > testBase64Decode size 512 | 288.81 | 32.04 | 9.01 > testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 > testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 > testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 > testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 > testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 > testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 > testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 > testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 > testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 > testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 > testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 > testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 > testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 > testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 > testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 > testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 > testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 > testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 > testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 > testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 > testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 > testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 > testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 > testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 > testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 > testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 > testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 The gitignore change looks ok, but should maybe be a separate change. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4368 From erikj at openjdk.java.net Mon Jun 7 12:38:02 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 12:38:02 GMT Subject: RFR: 8268296: ScopedMemoryAccess build error with readonly filesystems In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 20:09:32 GMT, Liam Miller-Cushon wrote: > This change fixes a build error during the generation of `ScopedMemoryAccess.java` when the sources are readonly, by using `cat a > b` instead of `cp a b` to avoid propagating the permissions to the generated source. Looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4380 From github.com+6704669+asgibbons at openjdk.java.net Mon Jun 7 13:20:20 2021 From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons) Date: Mon, 7 Jun 2021 13:20:20 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v2] In-Reply-To: References: Message-ID: > Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. > > A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. > > The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. > > Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. > > **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. > > > Benchmark Name | Base Score | Optimized Score | Gain > -- | -- | -- | -- > testBase64Decode size 1 | 15.36 | 15.32 | 1.00 > testBase64Decode size 3 | 17.00 | 16.72 | 1.02 > testBase64Decode size 7 | 20.60 | 18.82 | 1.09 > testBase64Decode size 32 | 34.21 | 26.77 | 1.28 > testBase64Decode size 64 | 54.43 | 38.35 | 1.42 > testBase64Decode size 80 | 66.40 | 48.34 | 1.37 > testBase64Decode size 96 | 73.16 | 52.90 | 1.38 > testBase64Decode size 112 | 84.93 | 51.82 | 1.64 > testBase64Decode size 512 | 288.81 | 32.04 | 9.01 > testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 > testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 > testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 > testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 > testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 > testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 > testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 > testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 > testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 > testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 > testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 > testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 > testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 > testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 > testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 > testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 > testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 > testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 > testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 > testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 > testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 > testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 > testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 > testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 > testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 > testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 > testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update full name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4368/files - new: https://git.openjdk.java.net/jdk/pull/4368/files/e527557a..00fd5621 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368 From jvernee at openjdk.java.net Mon Jun 7 13:39:52 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Jun 2021 13:39:52 GMT Subject: RFR: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Message-ID: Hi, The documentation of `CLinker::systemLookup` [1] says this: * Obtains a system lookup which is suitable to find symbols in the standard C libraries. However, currently it is not possible to look up common stdio.h symbols, such as `printf`, using the system lookup on Windows 10. This is because the backing library that is loaded, namely `ucrtbase.dll`, does not contain these symbols, as they are implemented in the standard library as inline functions. This patch changes the system lookup implementation on Windows 10 to make these symbols findable as well, by using a fallback library that forces the generation of the code for the inline functions, and exposes the missing symbols as a table of function pointers. See also the prior review of this patch for the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/547 Since the exact set of symbols findable by the system lookup is unspecified, and since the API in question (`CLinker::systemLookup`) was added only last week [2], I've elected to not create a CSR for this patch, but please let me know if one is needed). Thanks, Jorn [1] : https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java#L134-L151 [2] : https://github.com/openjdk/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab ------------- Commit messages: - Upstream 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Changes: https://git.openjdk.java.net/jdk/pull/4390/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4390&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268327 Stats: 273 lines in 5 files changed: 203 ins; 58 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/4390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4390/head:pull/4390 PR: https://git.openjdk.java.net/jdk/pull/4390 From erikj at openjdk.java.net Mon Jun 7 13:51:38 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 13:51:38 GMT Subject: RFR: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 13:23:46 GMT, Jorn Vernee wrote: > Hi, > > The documentation of `CLinker::systemLookup` [1] says this: > > > * Obtains a system lookup which is suitable to find symbols in the standard C libraries. > > > However, currently it is not possible to look up common stdio.h symbols, such as `printf`, using the system lookup on Windows 10. This is because the backing library that is loaded, namely `ucrtbase.dll`, does not contain these symbols, as they are implemented in the standard library as inline functions. > > This patch changes the system lookup implementation on Windows 10 to make these symbols findable as well, by using a fallback library that forces the generation of the code for the inline functions, and exposes the missing symbols as a table of function pointers. > > See also the prior review of this patch for the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/547 > > Since the exact set of symbols findable by the system lookup is unspecified, and since the API in question (`CLinker::systemLookup`) was added only last week [2], I've elected to not create a CSR for this patch, but please let me know if one is needed). > > Thanks, > Jorn > > [1] : https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java#L134-L151 > [2] : https://github.com/openjdk/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4390 From brian.goetz at oracle.com Mon Jun 7 15:06:20 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 7 Jun 2021 11:06:20 -0400 Subject: case null vs case dominance In-Reply-To: <524498219.340928.1623059489798.JavaMail.zimbra@u-pem.fr> References: <524498219.340928.1623059489798.JavaMail.zimbra@u-pem.fr> Message-ID: <0a29c5a8-14f2-4c15-913a-72f887e14242@oracle.com> On 6/7/2021 5:51 AM, Remi Forax wrote: > Hi all, > the first part of the message is about javac error message that could be improved, > the second part is about the current spec being not very logical. > > With this code > > Object o = null; > var value = switch(o) { > //case null -> 0; > case Object __ -> 0; > case null -> 0; > }; > System.out.println(value); > > The error message is > PatternMatching101.java:70: error: this case label is dominated by a preceding case label > case null -> 0; > ^ > > The error message is wrong here, because it's 'case null' and you can put a case null where you want but below a total pattern, so the error mesage should reflect that. But the case null *is* dominated by the total pattern, and therefore dead. > Here is an example that compiles showing that case null can be below a case String, which it dominates > > Object o = null; > var value = switch(o) { > case String s -> 0; > case null -> 0; > default -> 0; > }; In this case, the String pattern is not total, so it does not dominate null. From forax at univ-mlv.fr Mon Jun 7 15:21:12 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 7 Jun 2021 17:21:12 +0200 (CEST) Subject: case null vs case dominance In-Reply-To: <0a29c5a8-14f2-4c15-913a-72f887e14242@oracle.com> References: <524498219.340928.1623059489798.JavaMail.zimbra@u-pem.fr> <0a29c5a8-14f2-4c15-913a-72f887e14242@oracle.com> Message-ID: <1703672815.671169.1623079272302.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "Remi Forax" , "core-libs-dev" > Cc: "amber-spec-experts" > Envoy?: Lundi 7 Juin 2021 17:06:20 > Objet: Re: case null vs case dominance > On 6/7/2021 5:51 AM, Remi Forax wrote: >> Hi all, >> the first part of the message is about javac error message that could be >> improved, >> the second part is about the current spec being not very logical. >> >> With this code >> >> Object o = null; >> var value = switch(o) { >> //case null -> 0; >> case Object __ -> 0; >> case null -> 0; >> }; >> System.out.println(value); >> >> The error message is >> PatternMatching101.java:70: error: this case label is dominated by a preceding >> case label >> case null -> 0; >> ^ >> >> The error message is wrong here, because it's 'case null' and you can put a case >> null where you want but below a total pattern, so the error mesage should >> reflect that. > > But the case null *is* dominated by the total pattern, and therefore dead. it depends on the order you applies the rules you can also says that because there is a case null, Object does not accept null so it's not a total pattern so it doesn't not dominate null. I think it's an error but i think there should be a special rule for it. > >> Here is an example that compiles showing that case null can be below a case >> String, which it dominates >> >> Object o = null; >> var value = switch(o) { >> case String s -> 0; >> case null -> 0; >> default -> 0; >> }; > > In this case, the String pattern is not total, so it does not dominate null. That's my point, cf above. R?mi From henryjen at openjdk.java.net Mon Jun 7 15:21:20 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Mon, 7 Jun 2021 15:21:20 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote: >> ?d on macOS >> >> This patch simply round up the specified stack size to multiple of the system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >> >> ```code:java >> public class StackLeak { >> public int depth = 0; >> public void stackLeak() { >> depth++; >> stackLeak(); >> } >> >> public static void main(String[] args) { >> var test = new StackLeak(); >> try { >> test.stackLeak(); >> } catch (Throwable e) { >> System.out.println(test.depth); >> } >> } >> } > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Cast type > - Merge > - Change java -X output for -Xss > - Merge > - Only try to round-up when current value failed > - Avoid overflow on page size > - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS Linux man page for pthread_attr_setstacksize() states that, On some systems, pthread_attr_setstacksize() can fail with the error EINVAL if stacksize is not a multiple of the system page size. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From sundar at openjdk.java.net Mon Jun 7 15:26:27 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 7 Jun 2021 15:26:27 GMT Subject: RFR: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 13:23:46 GMT, Jorn Vernee wrote: > Hi, > > The documentation of `CLinker::systemLookup` [1] says this: > > > * Obtains a system lookup which is suitable to find symbols in the standard C libraries. > > > However, currently it is not possible to look up common stdio.h symbols, such as `printf`, using the system lookup on Windows 10. This is because the backing library that is loaded, namely `ucrtbase.dll`, does not contain these symbols, as they are implemented in the standard library as inline functions. > > This patch changes the system lookup implementation on Windows 10 to make these symbols findable as well, by using a fallback library that forces the generation of the code for the inline functions, and exposes the missing symbols as a table of function pointers. > > See also the prior review of this patch for the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/547 > > Since the exact set of symbols findable by the system lookup is unspecified, and since the API in question (`CLinker::systemLookup`) was added only last week [2], I've elected to not create a CSR for this patch, but please let me know if one is needed). > > Thanks, > Jorn > > [1] : https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java#L134-L151 > [2] : https://github.com/openjdk/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4390 From jvernee at openjdk.java.net Mon Jun 7 16:04:30 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Jun 2021 16:04:30 GMT Subject: RFR: 8268328: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 1) Message-ID: Hi, This is part 1 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. This patch changes the handling of method handles that might throw checked exceptions, by the var handle combinators found in `jdk.incubator.foreign.MemoryHandles`. Particularly, it makes the check more lenient towards `BoundMethodHandle`s that have fields that are method handles that might themselves throw exceptions, since it is not known whether the enclosing method handle catches such exceptions. For instance, if a target method handle is wrapped using the `catchException` combinator, which handles all exceptions thrown by that target, the current code will still reject such method handles, even though no checked exceptions can be thrown. The patch fixes this by instead wrapping method handles for which it is not possible to eagerly determine whether they throw exception using the `catchException` combinator, with an exception handler that catches checked exceptions and instead throws an `IllegalStateException` with the original exception as the cause. (See also the CSR). The main motivation for doing this is having the ability to share the implementation with the `CLinker::upcallStub` API, which also wants to eagerly reject method handles that are determined to throw exceptions. Thanks, Jorn Testing: `jdk_foreign` test suite. ------------- Commit messages: - Pt1 Changes: https://git.openjdk.java.net/jdk/pull/4395/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4395&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268328 Stats: 100 lines in 4 files changed: 49 ins; 18 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/4395.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4395/head:pull/4395 PR: https://git.openjdk.java.net/jdk/pull/4395 From jan.lahoda at oracle.com Mon Jun 7 11:31:28 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 7 Jun 2021 13:31:28 +0200 Subject: Pattern matching, not informative error message when the binding name is missing In-Reply-To: <1925651484.288197.1623056582206.JavaMail.zimbra@u-pem.fr> References: <1925651484.288197.1623056582206.JavaMail.zimbra@u-pem.fr> Message-ID: <4a8c5d4d-8079-4ed4-d4d8-325956e55855@oracle.com> Hi Remi, Thanks. I've filled: https://bugs.openjdk.java.net/browse/JDK-8268320 FWIW, I think compiler-dev is a better place for reports like this. Jan On 07. 06. 21 11:03, Remi Forax wrote: > Hi all, > with this code > > sealed interface Vehicle {} > record Car(String owner, String color) implements Vehicle {} > record Bus(String owner) implements Vehicle {} > > public static void example3() { > var vehicles = List.of( > new Car("Bob", "red"), > new Bus("Ana") > ); > var tax = vehicles.stream() > .mapToInt(v -> switch(v) { > case Car -> 100; > case Bus -> 200; > default -> throw new AssertionError(); > }).sum(); > System.out.println("tax " + tax); > } > > If there is no binding name in the case, > case Car > instead of > case Car car > the error message is not very explicit > > PatternMatching101.java:40: error: cannot find symbol > case Car -> 100; > ^ > symbol: variable Car > location: class PatternMatching101 > > I believe that in this case, it's possible to know that this is a switch on types, so provide a better error message. > > regards, > R?mi From jan.lahoda at oracle.com Mon Jun 7 14:17:21 2021 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 7 Jun 2021 16:17:21 +0200 Subject: javac throws an AssertionError while compiling a switch on types In-Reply-To: <1328401025.342802.1623059678373.JavaMail.zimbra@u-pem.fr> References: <1328401025.342802.1623059678373.JavaMail.zimbra@u-pem.fr> Message-ID: <267de959-1b1b-2f09-c045-85b3d9526829@oracle.com> Thanks for the report, Remi. I believe the specification currently allows this (default does not have to be last, and does not dominate anything), so javac should be able to handle this code. I've filled: https://bugs.openjdk.java.net/browse/JDK-8268333 Jan On 07. 06. 21 11:54, Remi Forax wrote: > Hi all, > javac does like this code, there is a check missing because javac should not reach Gen with a code like this. > > Object o = null; > var value = switch(o) { > default -> 0; > case String s -> 0; > }; > System.out.println(value); > > An exception has occurred in the compiler (17-internal). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you. > java.lang.AssertionError > at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) > at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.handleSwitch(Gen.java:1310) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.doHandleSwitchExpression(Gen.java:1238) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitSwitchExpression(Gen.java:1202) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitchExpression.accept(JCTree.java:1381) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitLetExpr(Gen.java:2376) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$LetExpr.accept(JCTree.java:3288) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:877) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitVarDef(Gen.java:1081) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1028) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:631) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:682) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1097) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1092) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:645) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:967) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:930) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:922) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:610) > at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2415) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:737) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1617) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1585) > at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317) > at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176) > at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64) > at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50) > > regards, > R?mi From joe.darcy at oracle.com Mon Jun 7 16:24:37 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 7 Jun 2021 09:24:37 -0700 Subject: RFR: 8268250: Class.arrayType() for a 255-d array throws undocumented IllegalArgumentException [v2] In-Reply-To: References: Message-ID: <39614f2c-19cf-ee07-e44b-e976a495cc07@oracle.com> Hi Alan, On 6/6/2021 11:01 PM, Alan Bateman wrote: > On Mon, 7 Jun 2021 00:22:41 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: >> >> Add missing ending newline. > src/java.base/share/classes/java/lang/Class.java line 4440: > >> 4438: * @throws IllegalArgumentException if this component type is {@linkplain >> 4439: * Void#TYPE void} or if the number of dimensions of the resulting array >> 4440: * type would exceed 255. > This is a no-arg method so I'm not sure that IAE is the right exception. The method was added in Java 12 so there probably isn't a huge body of code that expects it to throw IAE, meaning it may be possible to change it with little/no impact. Pedantically, "this" is an argument of sorts, but admittedly that line of reasoning doesn't usually yield a very satisfying user-experience? for a method. I wanted to avoid introducing any exception adaptation code to the one-line call to Array.newInstance. A less direct way to address the lack of exception specification there would be "@implSpec Code equivalent to return Array.newInstance(this, 0).getClass();", which would pull in the throws clauses from that method. I'll also note I only proposed changing the spec for Class.arrayType rather than the arrayType method in the superinterface or other implementations. The Class.arrayType method has the strongest ties to the particular 255 limit. Thanks, -Joe From github.com+28651297+mkartashev at openjdk.java.net Mon Jun 7 16:25:24 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Mon, 7 Jun 2021 16:25:24 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v5] In-Reply-To: References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Fri, 4 Jun 2021 13:36:27 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". >> >> This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. >> >> Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). >> >> The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. >> >> Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. >> >> Results from Linux: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 >> ============================== >> TEST SUCCESS >> >> >> Building target 'run-test-only' in configuration 'linux-x86_64-server-release' >> Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 >> >> >> Results from Windows 10: >> >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/runtime 746 746 0 0 >> ============================== >> TEST SUCCESS >> Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> >> >> Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' >> Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: >> * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode >> >> Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' >> Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java >> Test results: passed: 1 > > Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision: > > Updated the test to run on Windows only and to use a character from the > supplementary plane in the path name. I came to realize that changing `os::dll_load()` to accept UTF-8 (standard or modified) will break all the users of that function except `JVM_LoadLibrary()`. Consider `os::native_java_library()` that still operates with the platform encoding on Windows and works correctly if CWD contains Latin-1 characters (assuming 1252 code page). With this change, `java` will fail to start if its path name contains, say, ? because `os::dll_load()` will expect it to be encoded as `c3 86` (UTF-8), but will get `c6` (Latin-1) instead. One possible solution is to update all the call sites of `os::dll_load()` (quite laborous), another is to introduce `os::dll_load_utf8()` and change only `JVM_LoadLibrary()` at this point in time. Advice is welcome. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From duke at openjdk.java.net Mon Jun 7 17:03:22 2021 From: duke at openjdk.java.net (duke) Date: Mon, 7 Jun 2021 17:03:22 GMT Subject: Withdrawn: 8265039: Adjust javadoc for ByteArray*Stream and InputStream In-Reply-To: <4gCHtNBg4xI0Sfz81z5-iViKyF1z7BEVPpTGsWmuRek=.270a9f3e-c52e-404c-8290-5a2f0bab3855@github.com> References: <4gCHtNBg4xI0Sfz81z5-iViKyF1z7BEVPpTGsWmuRek=.270a9f3e-c52e-404c-8290-5a2f0bab3855@github.com> Message-ID: On Mon, 5 Apr 2021 08:37:15 GMT, ?????? ??????? wrote: > Hello, > > to avoid cases detected in [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pull/2992) I propose to modify JavaDoc of `ByteArray*Stream` to explicitly mention redundancy of wrapping with `BufferedInputStream`. > > As of `InputStream` I think in notation `It is never correct to use the return value of this method to allocate a buffer intended to hold all data in this stream.` the word 'never' should be replaced with 'usually': apart from `ByteArrayInputStream` e.g. `FileInputStream.available()` often returns the count of remaining bytes (the only exclusion I'm aware of is the files located under `/proc/`) and indeed this count can be used to allocate a buffer to read all the bytes in one call. > > Consider benchmark > > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class ByteArrayInputStreamBenchmark { > > @Benchmark > public void read(Data data, Blackhole bh) { > int value; > var in = data.bais; > while ((value = in.read()) != -1) { > bh.consume(value); > } > } > > @Benchmark > public void readBuffered(Data data, Blackhole bh) throws IOException { > int value; > var in = new BufferedInputStream(data.bais); > while ((value = in.read()) != -1) { > bh.consume(value); > } > } > > @Benchmark > public Object readAllBytes(Data data) { > var in = data.bais; > return in.readAllBytes(); > } > > @Benchmark > public Object readAllBytesBuffered(Data data) throws IOException { > var in = data.bais; > return new BufferedInputStream(in).readAllBytes(); > } > > @State(Scope.Thread) > public static class Data { > > @Param({"8", "128", "512", "1024"}) > private int length; > > private byte[] bytes; > private ByteArrayInputStream bais; > > @Setup(Level.Iteration) > public void setUp() { > bytes = new byte[length]; > ThreadLocalRandom.current().nextBytes(bytes); > } > > @Setup(Level.Invocation) > public void setUpBais() { > bais = new ByteArrayInputStream(bytes); > } > } > } > > > giving > > > (length) Score Error Units > read 8 55.737 ? 0.431 ns/op > read 128 533.172 ? 1.613 ns/op > read 512 2066.238 ? 23.989 ns/op > read 1024 4335.570 ? 20.137 ns/op > > readBuffered 8 521.936 ? 2.454 ns/op > readBuffered 128 971.617 ? 100.469 ns/op > readBuffered 512 2284.472 ? 251.390 ns/op > readBuffered 1024 4168.598 ? 77.980 ns/op > > readAllBytes 8 34.850 ? 0.072 ns/op > readAllBytes 128 36.751 ? 0.133 ns/op > readAllBytes 512 45.304 ? 0.699 ns/op > readAllBytes 1024 61.790 ? 0.386 ns/op > > readAllBytesBuffered 8 870.454 ? 4.406 ns/op > readAllBytesBuffered 128 910.176 ? 32.258 ns/op > readAllBytesBuffered 512 896.155 ? 6.005 ns/op > readAllBytesBuffered 1024 965.596 ? 29.225 ns/op > > read:?gc.alloc.rate.norm 8 32.006 ? 0.001 B/op > read:?gc.alloc.rate.norm 128 32.007 ? 0.004 B/op > read:?gc.alloc.rate.norm 512 32.010 ? 0.010 B/op > read:?gc.alloc.rate.norm 1024 32.011 ? 0.008 B/op > > readBuffered:?gc.alloc.rate.norm 8 8280.354 ? 0.016 B/op > readBuffered:?gc.alloc.rate.norm 128 8240.484 ? 0.015 B/op > readBuffered:?gc.alloc.rate.norm 512 8240.599 ? 0.056 B/op > readBuffered:?gc.alloc.rate.norm 1024 8280.978 ? 0.024 B/op > > readAllBytes:?gc.alloc.rate.norm 8 56.008 ? 0.001 B/op > readAllBytes:?gc.alloc.rate.norm 128 176.017 ? 0.001 B/op > readAllBytes:?gc.alloc.rate.norm 512 560.035 ? 0.002 B/op > readAllBytes:?gc.alloc.rate.norm 1024 1072.057 ? 0.002 B/op > > readAllBytesBuffered:?gc.alloc.rate.norm 8 16512.660 ? 0.026 B/op > readAllBytesBuffered:?gc.alloc.rate.norm 128 16632.684 ? 0.008 B/op > readAllBytesBuffered:?gc.alloc.rate.norm 512 17016.694 ? 0.017 B/op > readAllBytesBuffered:?gc.alloc.rate.norm 1024 17528.748 ? 0.012 B/op This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3341 From jvernee at openjdk.java.net Mon Jun 7 17:08:37 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Jun 2021 17:08:37 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) Message-ID: Hi, This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395 This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 Thanks, Jorn Testing: `jdk_foreign` test suite. Thanks, Jorn ------------- Depends on: https://git.openjdk.java.net/jdk/pull/4395 Commit messages: - Remove trailing whitespace - Pt2 Changes: https://git.openjdk.java.net/jdk/pull/4396/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4396&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268339 Stats: 282 lines in 14 files changed: 275 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4396/head:pull/4396 PR: https://git.openjdk.java.net/jdk/pull/4396 From jvernee at openjdk.java.net Mon Jun 7 17:08:37 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 7 Jun 2021 17:08:37 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 16:38:01 GMT, Jorn Vernee wrote: > Hi, > > This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395 > > This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. > > Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. > > This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. > > Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. > > See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. > > Thanks, > Jorn src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java line 43: > 41: static { > 42: String arch = privilegedGetProperty("os.arch"); > 43: String os = privilegedGetProperty("os.name"); These calls were causing problems for the test with a `SecurityManager`. They should have been using `priviledgedGetProperty` in the first place, so I've changed them here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4396 From rriggs at openjdk.java.net Mon Jun 7 17:44:26 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Jun 2021 17:44:26 GMT Subject: Integrated: 8191441: (Process) add Readers and Writer access to java.lang.Process streams In-Reply-To: References: Message-ID: On Thu, 20 May 2021 19:57:22 GMT, Roger Riggs wrote: > Methods are added to java.lang.Process to read and write characters and lines from and to a spawned Process. > The Charset used to encode and decode characters to bytes can be specified or use the > operating system native encoding as is available from the "native.encoding" system property. This pull request has now been integrated. Changeset: 81600dce Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/81600dce24903cbd3476830e302c9f182c85efb3 Stats: 676 lines in 2 files changed: 668 ins; 0 del; 8 mod 8191441: (Process) add Readers and Writer access to java.lang.Process streams Reviewed-by: naoto, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/4134 From erikj at openjdk.java.net Mon Jun 7 17:50:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 17:50:21 GMT Subject: RFR: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov wrote: > I got rid of `realpath` usage as discussed in https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro instead, however there were quite a few problems with this macro, here's the example: > > $(call RelativePath,/foo/bar,/foo/bar/baz) -> " ..//foo/bar" > $(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT > $(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> " ./baz/banan" > $(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> " ../baz" > > As you can see, 1st case is just plain wrong, 2nd crashes make because of infinite loop, 3rd can be simplified and all of them have leading whitespaces > First commit in this PR fixes all these issues and adds corresponding test cases and second commit replaces usage of `realpath` in idea.sh with `RelativePath` macro in idea.gmk and fixes problems, when paths are incorrectly treated by IDEA All builds passed, approved. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4369 From cushon at openjdk.java.net Mon Jun 7 18:02:22 2021 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Mon, 7 Jun 2021 18:02:22 GMT Subject: Integrated: 8268296: ScopedMemoryAccess build error with readonly filesystems In-Reply-To: References: Message-ID: On Sun, 6 Jun 2021 20:09:32 GMT, Liam Miller-Cushon wrote: > This change fixes a build error during the generation of `ScopedMemoryAccess.java` when the sources are readonly, by using `cat a > b` instead of `cp a b` to avoid propagating the permissions to the generated source. This pull request has now been integrated. Changeset: e546ae27 Author: Liam Miller-Cushon URL: https://git.openjdk.java.net/jdk/commit/e546ae27ffc6c19ae078a41ab6e1741a104958c1 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8268296: ScopedMemoryAccess build error with readonly filesystems Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4380 From naoto at openjdk.java.net Mon Jun 7 18:49:20 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Jun 2021 18:49:20 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: <-V3-GuFQLcbKVotN0nKemAI3s3mkmbtHW0WgpYL6cvc=.e4eb2552-ff8f-459f-afa5-4a312508228e@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> <-V3-GuFQLcbKVotN0nKemAI3s3mkmbtHW0WgpYL6cvc=.e4eb2552-ff8f-459f-afa5-4a312508228e@github.com> Message-ID: <5RuG3bGJjtM6zQu5tXdSlNwCg89bNOKqwsaz98t1iHQ=.eb527caf-5bde-4282-abfd-e8a745f5e4e6@github.com> On Sun, 6 Jun 2021 22:25:44 GMT, David Holmes wrote: >> I think we need to establish some common ground before proceeding further with this fix. It's a bit of a long read; please, bear with me. >> >> The path name starts its life as a `jstring` in `Java_jdk_internal_loader_NativeLibraries_load()`, its encoding is irrelevant at this point. >> >> Next, the name has to be passed down to `JVM_LoadLibrary()` that takes `char*`. So we need to convert form `jstring` to `char*` (point (a)). Following that, `os::dll_load()` that actually performs loading in a platform-specific manner also receives `char*`. All platform implementations of `os::dll_load()` pass the path name down to their respective platform's APIs unmodified, but I think that's just incidental and here we have another possible point of conversion (point (b)). Other consumers of the path name are exception(c) and logging(d) messages; they also take `char*`, but potentially of a different encoding. >> >> Let me try to enumerate all conceivably valid conversions for `JVM_LoadLibrary()` consumption (point (a)): >> 1. jstring -> platform-specific encoding (status quo meaning possibly lossy encoding on Windows and UTF-8 elsewhere AFAICT), >> 2. jstring -> modified UTF-8, >> 3. jstring -> UTF-8. >> >> This bug [8195129](https://bugs.openjdk.java.net/browse/JDK-8195129) occurs because conversion (1) may loose information on Windows if the platform encoding happens to be NOT UTF-8 (which it often - or even always - is). So that's a no-go and we are left with either (2) or (3). >> >> On MacOS and Linux, "platform" encoding already is UTF-8 and since all the platform APIs happily consume UTF-8, no further conversion is necessary (neither for actual library loading, nor for log or exception messages; the latter have to convert to UTF-16, but do that under the hood). >> >> On Windows, we require at least these variants of the path name: >> 1. UTF16 for library loading (Unicode Windows API), >> 2. "platform" encoding for logging (yes, loosing information here, but that's tolerable), >> 3. "platform" (lossy) or UTF8 (lossless) encoding for exception messages (prefer lossless). >> >> This is what's behind my choice of UTF-8 for the path name encoding as it gets passed down to `JVM_LoadLibrary()`. We can go with modified UTF-8, of course, in which case all platforms - not just Windows - will have to do the conversion on their own, loosing the benefit of the knowledge about the original string encoding (the String.coder field of jstring). > > @mkartashev thank you for the detailed explanation. > > It is not clear to me that the JDK's conformance to being a Unicode application has significantly changed since the evaluation of JDK-8017274 - @naotoj can you comment on that and related discussion from the CCC for JDK-4958170 ? In particular I'm not sure that using the platform encoding is wrong, nor how we can have a path that cannot be represented by the platform encoding? > > Not being an expert in this area I cannot evaluate the affects of these shared code changes on other platforms, and so am reluctant to introduce any change that affects any non-Windows platforms. Also the JVM and JNI work with modified-UTF8 so I do not think we should diverge from that. > I would hate to see windows specific code introduced into the JDK or JVM's shared code for these APIs, but that may be the only choice to avoid potential disruption to other platforms. Though perhaps we could push the initial conversion down into the JVM? @dholmes-ora Sorry, I don't think anything has changed as to the encoding as of JDK-8017274. For some reason, I had the impression that JVM_LoadLibrary() accepts UTF-8 (either modified or standard), but that was not correct. It is using the platform encoded string for the pathname. @mkartashev As you mentioned in another comment, the only way to fix this issue is to pass UTF-8 down to JVM_LoadLibray, but I don't think it is feasible. One reason is the effort is too great, and the other is that all VM implementations would need to be modified. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From joehw at openjdk.java.net Mon Jun 7 18:57:37 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Jun 2021 18:57:37 GMT Subject: RFR: 8264766: ClassCastException during template compilation (Variable can not be cast to Param) Message-ID: Fixes the addVariable/addParam methods in the SymbolTable to check types before casting. ------------- Commit messages: - 8264766: ClassCastException during template compilation (Variable cannot be cast to Param) Changes: https://git.openjdk.java.net/jdk/pull/4398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4398&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264766 Stats: 70 lines in 2 files changed: 64 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4398/head:pull/4398 PR: https://git.openjdk.java.net/jdk/pull/4398 From dcubed at openjdk.java.net Mon Jun 7 19:23:19 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 7 Jun 2021 19:23:19 GMT Subject: RFR: 8268227: java/foreign/TestUpcall.java still times out In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 10:53:42 GMT, Maurizio Cimadamore wrote: > Turns out that adding more timeout is a lost cause here. The root cause of the slowdown when running the test in debug build is: > > https://bugs.openjdk.java.net/browse/JDK-8266074 > > Which has also caused related test issues: > > https://bugs.openjdk.java.net/browse/JDK-8268095 > > So, the fix (at least temporarily) is to run method handle-heavy tests with the -XX:-VerifyDependency options. > > On my machine, execution time of these tests on debug goes from 10 minutes down to less than 1. > > Since `-XX:-VerifyDependencies` cannot be specified on non-debug build, the `-XX:+IgnoreUnrecognizedVMOptions` is also passed (thanks Vlad for the tip!). @mcimadamore - Can you please integrate this fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/4355 From darcy at openjdk.java.net Mon Jun 7 19:38:58 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Jun 2021 19:38:58 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v5] In-Reply-To: References: Message-ID: <4iK7aNo0h9tnnDn_doTG5Fv3BPYyQkRGIzbiiM3D9BU=.f4efa3b8-6ac6-4906-8de9-7fb2c5e9feef@github.com> > 8267630: Start of release updates for JDK 18 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 17 additional commits since the last revision: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Update symbols for JDK 17 b25. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/947ea6f5...34480e50 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/f926c1bc..34480e50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=03-04 Stats: 24229 lines in 300 files changed: 22483 ins; 936 del; 810 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From iris at openjdk.java.net Mon Jun 7 20:42:19 2021 From: iris at openjdk.java.net (Iris Clark) Date: Mon, 7 Jun 2021 20:42:19 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v5] In-Reply-To: <4iK7aNo0h9tnnDn_doTG5Fv3BPYyQkRGIzbiiM3D9BU=.f4efa3b8-6ac6-4906-8de9-7fb2c5e9feef@github.com> References: <4iK7aNo0h9tnnDn_doTG5Fv3BPYyQkRGIzbiiM3D9BU=.f4efa3b8-6ac6-4906-8de9-7fb2c5e9feef@github.com> Message-ID: On Mon, 7 Jun 2021 19:38:58 GMT, Joe Darcy wrote: >> 8267630: Start of release updates for JDK 18 > > 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 17 additional commits since the last revision: > > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Update symbols for JDK 17 b25. > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/41bce524...34480e50 Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4175 From weijun at openjdk.java.net Mon Jun 7 20:48:27 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 7 Jun 2021 20:48:27 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages Message-ID: More loudly and precise warning messages when either a security manager is enabled at startup or installed at runtime. ------------- Commit messages: - 8268349: Provide more detail in JEP 411 warning messages Changes: https://git.openjdk.java.net/jdk/pull/4400/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4400&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268349 Stats: 115 lines in 5 files changed: 73 ins; 21 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/4400.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4400/head:pull/4400 PR: https://git.openjdk.java.net/jdk/pull/4400 From naoto at openjdk.java.net Mon Jun 7 22:37:14 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Jun 2021 22:37:14 GMT Subject: RFR: 8264766: ClassCastException during template compilation (Variable can not be cast to Param) In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 18:49:19 GMT, Joe Wang wrote: > Fixes the addVariable/addParam methods in the SymbolTable to check types before casting. Looks good. I'd be tempted to write `v instanceof Param p ? p : null;`, but then it could not be backported. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4398 From cashford at openjdk.java.net Mon Jun 7 22:55:13 2021 From: cashford at openjdk.java.net (Corey Ashford) Date: Mon, 7 Jun 2021 22:55:13 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v2] In-Reply-To: References: Message-ID: <2R-VOwcHuj-BCU7K5DyfNTyS4sGc_BcGtaPH321wm2w=.76034c06-b609-4035-8986-e285c2748d59@github.com> On Mon, 7 Jun 2021 13:20:20 GMT, Scott Gibbons wrote: >> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. >> >> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. >> >> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. >> >> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. >> >> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. >> >> >> Benchmark Name | Base Score | Optimized Score | Gain >> -- | -- | -- | -- >> testBase64Decode size 1 | 15.36 | 15.32 | 1.00 >> testBase64Decode size 3 | 17.00 | 16.72 | 1.02 >> testBase64Decode size 7 | 20.60 | 18.82 | 1.09 >> testBase64Decode size 32 | 34.21 | 26.77 | 1.28 >> testBase64Decode size 64 | 54.43 | 38.35 | 1.42 >> testBase64Decode size 80 | 66.40 | 48.34 | 1.37 >> testBase64Decode size 96 | 73.16 | 52.90 | 1.38 >> testBase64Decode size 112 | 84.93 | 51.82 | 1.64 >> testBase64Decode size 512 | 288.81 | 32.04 | 9.01 >> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 >> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 >> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 >> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 >> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 >> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 >> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 >> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 >> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 >> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 >> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 >> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 >> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 >> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 >> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 >> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 >> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 >> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 >> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 >> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 >> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 >> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 >> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 >> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 >> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 >> testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 >> testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Update full name Thanks for making this interesting update, which improves the flexibility of intrinsics to make use of isMIME. src/java.base/share/classes/java/util/Base64.java line 813: > 811: while (sp < sl) { > 812: if (shiftto == 18 && sp < sl - 4) { // fast path > 813: int dl = decodeBlock(src, sp, sl, dst, dp, isURL, isMIME); This new param is passed all the way down to the intrinsic. I think existing intrinsics can safely ignore this parameter if it doesn't help the implementation (for example PPC64-LE has 16-byte vector registers, so isn't quite as seriously impacted by MIME). However, in the code for the PPC64-LE intrinsic, this new parameter isn't mentioned. I think if you're going to add a new parameter, it should be mentioned in the existing intrinsics as being present, but unused. src/java.base/share/classes/java/util/Base64.java line 818: > 816: * bytes of data were returned. > 817: */ > 818: int chars_decoded = ((dl + 2) / 3) * 4; In the PR comments, you say, "A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.", however there's still a comment in the code above that says: * If the intrinsic function does not process all of the bytes in * src, it must process a multiple of four of them, making the * returned destination length a multiple of three. So this comment needs to be changed or removed to reflect your commit. ------------- Changes requested by cashford (Author). PR: https://git.openjdk.java.net/jdk/pull/4368 From dlsmith at openjdk.java.net Mon Jun 7 23:25:24 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Mon, 7 Jun 2021 23:25:24 GMT Subject: Integrated: 8174222: LambdaMetafactory: validate inputs and improve documentation In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 20:03:53 GMT, Dan Smith wrote: > Standardizes and better specifies the errors thrown by LambdaMetafactory, including for inputs that would not be generated by javac. > > Does some renaming of core parameters/fields to better reflect their purpose. > > In the implementation, stops using ACC_BRIDGE for any methods, which is not a good fit for what these methods do (they don't delegate to each other, but all invoke the same implementation method). This pull request has now been integrated. Changeset: fc08af58 Author: Dan Smith URL: https://git.openjdk.java.net/jdk/commit/fc08af58cb0571ed375a7937aac7a951ba224644 Stats: 834 lines in 8 files changed: 397 ins; 33 del; 404 mod 8174222: LambdaMetafactory: validate inputs and improve documentation Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/4346 From joehw at openjdk.java.net Mon Jun 7 23:58:15 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Jun 2021 23:58:15 GMT Subject: RFR: 8264766: ClassCastException during template compilation (Variable can not be cast to Param) In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 18:49:19 GMT, Joe Wang wrote: > Fixes the addVariable/addParam methods in the SymbolTable to check types before casting. Thanks Naoto! Yeah, we're trying to keep the code level at 8 at the moment unless necessary (e.g. the optional elements for Deprecated), pattern matching for instanceof is a bit new. ------------- PR: https://git.openjdk.java.net/jdk/pull/4398 From dlsmith at openjdk.java.net Tue Jun 8 00:06:37 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 8 Jun 2021 00:06:37 GMT Subject: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError Message-ID: Small bug fix. ------------- Commit messages: - Fix merge markup - Merge branch 'master' into 8268192 - Merge branch '8174222' into 8268192 - Fix stray renaming - Apply renamings to LambdaProxyClassArchive - Address reviewer comments - Turn back on test case that was failing - Merge branch '8174222' into 8268192 - Fix accidentally commented-out parts of test - Merge branch '8174222' into 8268192 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/fc08af58...74c346a1 Changes: https://git.openjdk.java.net/jdk/pull/4403/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4403&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268192 Stats: 19 lines in 2 files changed: 7 ins; 8 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4403/head:pull/4403 PR: https://git.openjdk.java.net/jdk/pull/4403 From github.com+6704669+asgibbons at openjdk.java.net Tue Jun 8 00:14:16 2021 From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons) Date: Tue, 8 Jun 2021 00:14:16 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v2] In-Reply-To: <2R-VOwcHuj-BCU7K5DyfNTyS4sGc_BcGtaPH321wm2w=.76034c06-b609-4035-8986-e285c2748d59@github.com> References: <2R-VOwcHuj-BCU7K5DyfNTyS4sGc_BcGtaPH321wm2w=.76034c06-b609-4035-8986-e285c2748d59@github.com> Message-ID: On Mon, 7 Jun 2021 22:34:33 GMT, Corey Ashford wrote: >> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Update full name > > src/java.base/share/classes/java/util/Base64.java line 813: > >> 811: while (sp < sl) { >> 812: if (shiftto == 18 && sp < sl - 4) { // fast path >> 813: int dl = decodeBlock(src, sp, sl, dst, dp, isURL, isMIME); > > This new param is passed all the way down to the intrinsic. I think existing intrinsics can safely ignore this parameter if it doesn't help the implementation (for example PPC64-LE has 16-byte vector registers, so isn't quite as seriously impacted by MIME). However, in the code for the PPC64-LE intrinsic, this new parameter isn't mentioned. I think if you're going to add a new parameter, it should be mentioned in the existing intrinsics as being present, but unused. Are you suggesting that I change *all* intrinsic implementations (aarch64, ppc, etc.)? I have no problem doing that - just checking if this is what's desired. > src/java.base/share/classes/java/util/Base64.java line 818: > >> 816: * bytes of data were returned. >> 817: */ >> 818: int chars_decoded = ((dl + 2) / 3) * 4; > > In the PR comments, you say, "A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.", however there's still a comment in the code above that says: > > * If the intrinsic function does not process all of the bytes in > * src, it must process a multiple of four of them, making the > * returned destination length a multiple of three. > > So this comment needs to be changed or removed to reflect your commit. I will change the comment, and add verbage regarding the new parameter. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/4368 From cashford at openjdk.java.net Tue Jun 8 00:20:17 2021 From: cashford at openjdk.java.net (Corey Ashford) Date: Tue, 8 Jun 2021 00:20:17 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v2] In-Reply-To: References: <2R-VOwcHuj-BCU7K5DyfNTyS4sGc_BcGtaPH321wm2w=.76034c06-b609-4035-8986-e285c2748d59@github.com> Message-ID: On Tue, 8 Jun 2021 00:11:42 GMT, Scott Gibbons wrote: >> src/java.base/share/classes/java/util/Base64.java line 813: >> >>> 811: while (sp < sl) { >>> 812: if (shiftto == 18 && sp < sl - 4) { // fast path >>> 813: int dl = decodeBlock(src, sp, sl, dst, dp, isURL, isMIME); >> >> This new param is passed all the way down to the intrinsic. I think existing intrinsics can safely ignore this parameter if it doesn't help the implementation (for example PPC64-LE has 16-byte vector registers, so isn't quite as seriously impacted by MIME). However, in the code for the PPC64-LE intrinsic, this new parameter isn't mentioned. I think if you're going to add a new parameter, it should be mentioned in the existing intrinsics as being present, but unused. > > Are you suggesting that I change *all* intrinsic implementations (aarch64, ppc, etc.)? I have no problem doing that - just checking if this is what's desired. Yes. I didn't realize that there's a decodeBlock intrinsic for aarch64 already, but yeah it should only be a couple of lines of comments for each. ------------- PR: https://git.openjdk.java.net/jdk/pull/4368 From github.com+6704669+asgibbons at openjdk.java.net Tue Jun 8 00:30:38 2021 From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons) Date: Tue, 8 Jun 2021 00:30:38 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3] In-Reply-To: References: Message-ID: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> > Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. > > A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. > > The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. > > Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. > > **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. > > > Benchmark Name | Base Score | Optimized Score | Gain > -- | -- | -- | -- > testBase64Decode size 1 | 15.36 | 15.32 | 1.00 > testBase64Decode size 3 | 17.00 | 16.72 | 1.02 > testBase64Decode size 7 | 20.60 | 18.82 | 1.09 > testBase64Decode size 32 | 34.21 | 26.77 | 1.28 > testBase64Decode size 64 | 54.43 | 38.35 | 1.42 > testBase64Decode size 80 | 66.40 | 48.34 | 1.37 > testBase64Decode size 96 | 73.16 | 52.90 | 1.38 > testBase64Decode size 112 | 84.93 | 51.82 | 1.64 > testBase64Decode size 512 | 288.81 | 32.04 | 9.01 > testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 > testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 > testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 > testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 > testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 > testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 > testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 > testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 > testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 > testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 > testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 > testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 > testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 > testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 > testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 > testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 > testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 > testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 > testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 > testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 > testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 > testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 > testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 > testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 > testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 > testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 > testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Fixing review comments. Adding notes about isMIME parameter for other architectures; clarifying decodeBlock comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4368/files - new: https://git.openjdk.java.net/jdk/pull/4368/files/00fd5621..d66e32e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=01-02 Stats: 19 lines in 3 files changed: 8 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368 From jbhateja at openjdk.java.net Tue Jun 8 02:02:19 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 8 Jun 2021 02:02:19 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3] In-Reply-To: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> References: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> Message-ID: On Tue, 8 Jun 2021 00:30:38 GMT, Scott Gibbons wrote: >> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. >> >> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. >> >> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. >> >> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. >> >> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. >> >> >> Benchmark Name | Base Score | Optimized Score | Gain >> -- | -- | -- | -- >> testBase64Decode size 1 | 15.36 | 15.32 | 1.00 >> testBase64Decode size 3 | 17.00 | 16.72 | 1.02 >> testBase64Decode size 7 | 20.60 | 18.82 | 1.09 >> testBase64Decode size 32 | 34.21 | 26.77 | 1.28 >> testBase64Decode size 64 | 54.43 | 38.35 | 1.42 >> testBase64Decode size 80 | 66.40 | 48.34 | 1.37 >> testBase64Decode size 96 | 73.16 | 52.90 | 1.38 >> testBase64Decode size 112 | 84.93 | 51.82 | 1.64 >> testBase64Decode size 512 | 288.81 | 32.04 | 9.01 >> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 >> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 >> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 >> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 >> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 >> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 >> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 >> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 >> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 >> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 >> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 >> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 >> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 >> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 >> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 >> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 >> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 >> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 >> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 >> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 >> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 >> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 >> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 >> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 >> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 >> testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 >> testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Fixing review comments. Adding notes about isMIME parameter for other architectures; clarifying decodeBlock comments. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6239: > 6237: > 6238: __ align(32); > 6239: __ BIND(L_bruteForce); Is this alignment needed ? Given that brute force loop is already aligned. ------------- PR: https://git.openjdk.java.net/jdk/pull/4368 From github.com+7806504+liach at openjdk.java.net Tue Jun 8 02:26:14 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Tue, 8 Jun 2021 02:26:14 GMT Subject: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 23:58:44 GMT, Dan Smith wrote: > Small bug fix. src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 191: > 189: useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) && > 190: !VerifyAccess.isSamePackage(implClass, implInfo.getDeclaringClass())) || > 191: implKind == H_INVOKESPECIAL; Won't this make regular private instance method calls use condy as well, as they are invokespecial? ------------- PR: https://git.openjdk.java.net/jdk/pull/4403 From github.com+19194678+scientificware at openjdk.java.net Tue Jun 8 02:34:13 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Tue, 8 Jun 2021 02:34:13 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home In-Reply-To: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> Message-ID: On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare wrote: > This concerns [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). > > In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. > > So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. > > The expected value is `"Must set property 'dtd_home'"` > > And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? > ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From dholmes at openjdk.java.net Tue Jun 8 03:01:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Jun 2021 03:01:23 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote: >> ?d on macOS >> >> This patch simply round up the specified stack size to multiple of the system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >> >> ```code:java >> public class StackLeak { >> public int depth = 0; >> public void stackLeak() { >> depth++; >> stackLeak(); >> } >> >> public static void main(String[] args) { >> var test = new StackLeak(); >> try { >> test.stackLeak(); >> } catch (Throwable e) { >> System.out.println(test.depth); >> } >> } >> } > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Cast type > - Merge > - Change java -X output for -Xss > - Merge > - Only try to round-up when current value failed > - Avoid overflow on page size > - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS Hi Henry, I'm okay with these changes in the current form. The help text needs tweaking - see CSR request. Thanks, David src/java.base/share/classes/sun/launcher/resources/launcher.properties line 175: > 173: \ configuration and continue\n\ > 174: \ -Xss set java thread stack size\n\ > 175: \ The actual size may be round up to multiple of system\n\ See updated help text in the CSR request. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4256 From alanb at openjdk.java.net Tue Jun 8 06:16:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 06:16:13 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. Changes requested by alanb (Reviewer). src/java.base/share/classes/java/lang/System.java line 331: > 329: > 330: // Remember original System.err. setSecurityManager() warning goes here > 331: private static PrintStream oldErrStream = null; I assume this should needs to be volatile and @Stable. I think we need a better name for it too. src/java.base/share/classes/java/lang/System.java line 336: > 334: // Remember callers of setSecurityManager() here so that warning > 335: // is only printed once for each different caller > 336: final static Map callersOfSSM = new WeakHashMap<>(); You can't use a WeakHashMap without synchronization but a big question here is whether a single caller frame is sufficient. If I were doing this then I think I would capture the hash of a number of stack frames to create a better filter. src/java.base/share/classes/java/lang/System.java line 2219: > 2217: WARNING: java.lang.SecurityManager is deprecated and will be removed in a future release > 2218: WARNING: -Djava.security.manager=%s will have no effect when java.lang.SecurityManager is removed > 2219: """, smProp); Raw strings may be useful here but means the lines length are inconsistent and makes it too hard to look at side by side diffs now. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From david.holmes at oracle.com Tue Jun 8 06:32:49 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Jun 2021 16:32:49 +1000 Subject: RFR: 8268227: java/foreign/TestUpcall.java still times out In-Reply-To: References: Message-ID: <2c68c427-a9ed-65eb-417a-8dce2829c5e3@oracle.com> On 8/06/2021 5:23 am, Daniel D.Daugherty wrote: > On Fri, 4 Jun 2021 10:53:42 GMT, Maurizio Cimadamore wrote: > >> Turns out that adding more timeout is a lost cause here. The root cause of the slowdown when running the test in debug build is: >> >> https://bugs.openjdk.java.net/browse/JDK-8266074 >> >> Which has also caused related test issues: >> >> https://bugs.openjdk.java.net/browse/JDK-8268095 >> >> So, the fix (at least temporarily) is to run method handle-heavy tests with the -XX:-VerifyDependency options. >> >> On my machine, execution time of these tests on debug goes from 10 minutes down to less than 1. >> >> Since `-XX:-VerifyDependencies` cannot be specified on non-debug build, the `-XX:+IgnoreUnrecognizedVMOptions` is also passed (thanks Vlad for the tip!). > > @mcimadamore - Can you please integrate this fix? I see this test failing on Windows in GHA for tier1. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4355 > From dholmes at openjdk.java.net Tue Jun 8 06:33:18 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Jun 2021 06:33:18 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. There are a number of hotspot tests that will trigger this warning, so please ensure they work correctly with the extra output. You might want to make your "WARNING" consistent with the VM's "Warning" so that OutputAnalyzer's logic to ignore warnings will automatically ignore these too. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From alanb at openjdk.java.net Tue Jun 8 06:44:19 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 06:44:19 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 06:30:00 GMT, David Holmes wrote: > You might want to make your "WARNING" consistent with the VM's "Warning" so that OutputAnalyzer's logic to ignore warnings will automatically ignore these too. The uppercase "WARNING" is intentional here, it was the same with illegal reflective access warnings. I'm sure Max has or will run all tests to see if there are any issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From github.com+10835776+stsypanov at openjdk.java.net Tue Jun 8 07:01:53 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 8 Jun 2021 07:01:53 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v5] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - 8268113: Inline local vars where reasonable - 8268113: Delegate to Double.hashCode() - 8268113: Re-use Long.hashCode() where possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/7dc5020e..76af35c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=03-04 Stats: 30371 lines in 444 files changed: 25591 ins; 2648 del; 2132 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From mbaesken at openjdk.java.net Tue Jun 8 07:25:20 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 8 Jun 2021 07:25:20 GMT Subject: Integrated: JDK-8266918: merge_stack in check_code.c add NULL check In-Reply-To: References: Message-ID: On Tue, 11 May 2021 14:49:42 GMT, Matthias Baesken wrote: > Hello, please review this small Sonar finding. > Sonar reports a potential NULL pointer dereference here : > https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8CPLBBG2CXpcnh_z&resolved=false&severities=MAJOR&types=BUG > "Access to field 'item' results in a dereference of a null pointer (loaded from variable 'new')" > It would be better to add a check . This pull request has now been integrated. Changeset: 00c88f79 Author: Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/00c88f79b30d7867be4a66317b90b9ba7e947f4f Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8266918: merge_stack in check_code.c add NULL check Reviewed-by: rschmelter, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/3979 From stuefe at openjdk.java.net Tue Jun 8 08:24:24 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 8 Jun 2021 08:24:24 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote: >> ?d on macOS >> >> This patch simply round up the specified stack size to multiple of the system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >> >> ```code:java >> public class StackLeak { >> public int depth = 0; >> public void stackLeak() { >> depth++; >> stackLeak(); >> } >> >> public static void main(String[] args) { >> var test = new StackLeak(); >> try { >> test.stackLeak(); >> } catch (Throwable e) { >> System.out.println(test.depth); >> } >> } >> } > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Cast type > - Merge > - Change java -X output for -Xss > - Merge > - Only try to round-up when current value failed > - Avoid overflow on page size > - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS Hi, proposed shorter form. Otherwise this looks fine. Cheers, Thomas src/java.base/unix/native/libjli/java_md.c line 666: > 664: return page_size * pages; > 665: } > 666: } Could probably be shortened to something like this: size_t pagesize = (size_t)sysconf(_SC_PAGESIZE); return (stack_size + (pagesize - 1)) & ~(pagesize - 1); or, if you insist on checking for SIZE_MAX: size_t pagesize = (size_t)sysconf(_SC_PAGESIZE); size_t max = SIZE_MAX - pagesize; return stack_size <= max ? (stack_size + (pagesize - 1)) & ~(pagesize - 1) : max; (I see David requested this, so this is fine, though passing SIZE_MAX to this function will quite likely fail anyway :) ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From winterhalter at openjdk.java.net Tue Jun 8 08:37:21 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Tue, 8 Jun 2021 08:37:21 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: On Sun, 9 May 2021 21:59:29 GMT, Rafael Winterhalter wrote: > During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. Commenting on the issue to avoid closing as it is still under review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3940 From github.com+28651297+mkartashev at openjdk.java.net Tue Jun 8 09:48:20 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Tue, 8 Jun 2021 09:48:20 GMT Subject: Withdrawn: 8195129: System.load() fails to load from unicode paths In-Reply-To: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> Message-ID: On Mon, 24 May 2021 16:43:09 GMT, Maxim Kartashev wrote: > Character strings within JVM are produced and consumed in several formats. Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() or dlopen()) consume strings also in UTF8. On Windows, however, the situation is far less simple: some new(er) APIs expect UTF16 (wide-character strings), some older APIs can only work with strings in a "platform" format, where not all UTF8 characters can be represented; which ones can depends on the current "code page". > > This commit switches the Windows version of native library loading code to using the new UTF16 API `LoadLibraryW()` and attempts to streamline the use of various string formats in the surrounding code. > > Namely, exception messages are made to consume strings explicitly in the UTF8 format, while logging functions (that end up using legacy Windows API) are made to consume "platform" strings in most cases. One exception is `JVM_LoadLibrary()` logging where the UTF8 name of the library is logged, which can, of course, be fixed, but was considered not worth the additional code (NB: this isn't a new bug). > > The test runs in a separate JVM in order to make NIO happy about non-ASCII characters in the file name; tests are executed with LC_ALL=C and that doesn't let NIO work with non-ASCII file names even on Linux or MacOS. > > Tested by running `test/hotspot/jtreg:tier1` on Linux and `jtreg:test/hotspot/jtreg/runtime` on Windows 10. The new test (` jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode`) was explicitly ran on those platforms as well. > > Results from Linux: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg:tier1 1784 1784 0 0 > ============================== > TEST SUCCESS > > > Building target 'run-test-only' in configuration 'linux-x86_64-server-release' > Test selection 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 > > > Results from Windows 10: > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/hotspot/jtreg/runtime 746 746 0 0 > ============================== > TEST SUCCESS > Finished building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' > > > Building target 'run-test-only' in configuration 'windows-x86_64-server-fastdebug' > Test selection 'test/hotspot/jtreg/runtime/jni/loadLibraryUnicode', will run: > * jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode > > Running test 'jtreg:test/hotspot/jtreg/runtime/jni/loadLibraryUnicode' > Passed: runtime/jni/loadLibraryUnicode/LoadLibraryUnicodeTest.java > Test results: passed: 1 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From github.com+28651297+mkartashev at openjdk.java.net Tue Jun 8 09:48:19 2021 From: github.com+28651297+mkartashev at openjdk.java.net (Maxim Kartashev) Date: Tue, 8 Jun 2021 09:48:19 GMT Subject: RFR: 8195129: System.load() fails to load from unicode paths [v3] In-Reply-To: <5RuG3bGJjtM6zQu5tXdSlNwCg89bNOKqwsaz98t1iHQ=.eb527caf-5bde-4282-abfd-e8a745f5e4e6@github.com> References: <6qzdQJy3fcfn-PjXHjGNRZH7ZTBt_Sehohf4zRkMWKc=.0e5fa6d7-0182-4242-bed6-bf4b602abafe@github.com> <3y0nPfUyTPbNksPn1y5pvopzN2AReOgIl2CafPKD4b4=.3b490e90-5098-4d9f-8d7e-2770f5548895@github.com> <923qsXnidgxLrhNUc8Bxw3zDCiw1ZNLC6OmIYqIeSOE=.783c385d-1d4c-4c87-b975-3ee27a71513d@github.com> <-V3-GuFQLcbKVotN0nKemAI3s3mkmbtHW0WgpYL6cvc=.e4eb2552-ff8f-459f-afa5-4a312508228e@github.com> <5RuG3bGJjtM6zQu5tXdSlNwCg89bNOKqwsaz98t1iHQ=.eb527caf-5bde-4282-abfd-e8a745f5e4e6@github.com> Message-ID: On Mon, 7 Jun 2021 18:46:11 GMT, Naoto Sato wrote: >> @mkartashev thank you for the detailed explanation. >> >> It is not clear to me that the JDK's conformance to being a Unicode application has significantly changed since the evaluation of JDK-8017274 - @naotoj can you comment on that and related discussion from the CCC for JDK-4958170 ? In particular I'm not sure that using the platform encoding is wrong, nor how we can have a path that cannot be represented by the platform encoding? >> >> Not being an expert in this area I cannot evaluate the affects of these shared code changes on other platforms, and so am reluctant to introduce any change that affects any non-Windows platforms. Also the JVM and JNI work with modified-UTF8 so I do not think we should diverge from that. >> I would hate to see windows specific code introduced into the JDK or JVM's shared code for these APIs, but that may be the only choice to avoid potential disruption to other platforms. Though perhaps we could push the initial conversion down into the JVM? > > @dholmes-ora Sorry, I don't think anything has changed as to the encoding as of JDK-8017274. For some reason, I had the impression that JVM_LoadLibrary() accepts UTF-8 (either modified or standard), but that was not correct. It is using the platform encoded string for the pathname. > > @mkartashev As you mentioned in another comment, the only way to fix this issue is to pass UTF-8 down to JVM_LoadLibray, but I don't think it is feasible. One reason is the effort is too great, and the other is that all VM implementations would need to be modified. @naotoj Then I guess this bug will have to wait until Windows evolves to the point when its platform encoding is UTF-8. In the mean time, I'm closing this PR. Thank you all so much for your time! ------------- PR: https://git.openjdk.java.net/jdk/pull/4169 From jbhateja at openjdk.java.net Tue Jun 8 10:29:44 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 8 Jun 2021 10:29:44 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v8] In-Reply-To: References: Message-ID: > Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- > > vec1 = lanewise(VectorOperators.LSHL, n) > vec2 = lanewise(VectorOperators.LSHR, n) > res = lanewise(VectorOperations.OR, vec1 , vec2) > > This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. > > AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. > > Please find below the performance data for included JMH benchmark. > Machine: Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz) > > > Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain % > -- | -- | -- | -- | -- | -- | -- | -- | -- > ? | ? | ? | ? | ? | ? | ? | ? | ? > RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82 > RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84 > RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90 > RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44 > RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30 > RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14 > RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58 > RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18 > RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02 > RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52 > RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40 > RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16 > RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98 > RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91 > RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60 > RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03 > RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80 > RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68 > RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83 > RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78 > RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96 > RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89 > RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79 > RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09 > RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05 > RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22 > RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98 > RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68 > RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27 > RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78 > RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57 > RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69 > RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53 > RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88 > RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59 > RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27 > RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77 > RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77 > RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24 > RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49 > RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60 > RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27 > RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16 > RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39 > RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87 > RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38 > RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49 > RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39 > RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80 > RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06 > RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64 > RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17 > RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56 > RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53 > RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05 > RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49 > RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85 > RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79 > RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95 > RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87 > RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13 > RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77 > RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37 > RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56 > RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93 > RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03 > RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64 > RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78 > RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08 > RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17 > RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11 > RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43 > RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06 > RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94 > RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31 > RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70 > RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29 > RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27 > RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01 > RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77 > RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29 > RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25 > RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22 > RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78 > RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68 > RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08 > RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64 > RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61 > RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08 > RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16 > RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92 > RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01 > RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29 > RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28 > RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60 > RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34 > RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89 > RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63 > RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16 > RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53 > RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18 > RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64 > RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26 > RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99 > RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54 > RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04 > RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71 > RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66 > RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66 > RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02 > RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34 > RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15 > RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13 > RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46 > RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18 > RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97 > RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68 > RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82 > RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61 > RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13 > RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85 > RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66 > RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58 > RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49 > RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35 > RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83 > RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21 > RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21 > RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39 > RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84 > RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67 > RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84 > RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35 > RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66 > RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97 > RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34 > RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08 > RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43 > RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06 > RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96 > RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32 > RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74 > RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13 > RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61 > RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20 > RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19 > RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71 > RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38 > RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72 > RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11 > RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28 > RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82 > RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11 > RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35 > RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58 > RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29 > RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12 > RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88 > RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05 > RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15 > RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56 > RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36 > RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37 > RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53 > RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42 > RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01 > RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76 > RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01 > RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22 > RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76 > RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95 > RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48 > RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41 > RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23 > RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52 > RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03 > RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70 > RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63 > RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74 > RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48 > RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92 > RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08 > RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90 > RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38 > RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24 > RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99 > RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95 > RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19 > RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37 > RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38 > RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38 > RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06 Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge http://github.com/openjdk/jdk into JDK-8266054 - Merge http://github.com/openjdk/jdk into JDK-8266054 - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054 - 8266054: Removing redundant teat templates. - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform. - 8266054: Removing redundant test templates. - 8266054: Review comments resolution. - 8266054: Review comments resolution. - 8266054: Review comments resolution. - Merge http://github.com/openjdk/jdk into JDK-8266054 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/61ab4b9d...debb09f2 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3720/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=07 Stats: 4393 lines in 52 files changed: 4172 ins; 60 del; 161 mod Patch: https://git.openjdk.java.net/jdk/pull/3720.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720 PR: https://git.openjdk.java.net/jdk/pull/3720 From rriggs at openjdk.java.net Tue Jun 8 10:32:49 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Jun 2021 10:32:49 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v14] In-Reply-To: References: Message-ID: > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Clarified javadoc for rejectUndecidedClass. Added javadoc to describe throwing of ExceptionInInitializerError if the class named by system property jdk.serialFilterFactory is not valid. Added description of jdk.serialFilterFactory to java.security file. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/6d07298f..755d8f20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=12-13 Stats: 19 lines in 2 files changed: 9 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From dfuchs at openjdk.java.net Tue Jun 8 11:16:15 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Jun 2021 11:16:15 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. Changes to LoggerFinderLoaderTest look reasonable to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From alanb at openjdk.java.net Tue Jun 8 11:37:16 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 11:37:16 GMT Subject: RFR: 8240349: jlink --vm with not present VM does not fail fast In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 11:00:00 GMT, Athijegannathan Sundararajan wrote: > jlink should clean up output directory on any failure. should not leave partially filled output. I think we need to rename the JBS issue as this is not specific to the -vm option. Instead, this is about cleanup when jlink fails with some intermediate files in the output directory. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 295: > 293: cleanupOutput(outputPath); > 294: return EXIT_ERROR; > 295: } catch (BadArgs e) { Can you confirm that this change is benign for the case that the output directory exists? I believe it's a BadArgs case so it won't attempt to delete a file or tree if it exists but I'd like confirmation. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 490: > 488: > 489: private static void deleteDirectory(Path dir) throws IOException { > 490: if (dir != null && Files.isDirectory(dir)) { I don't think this method should be checking dir, that should be up to the caller to ensure that it is not called when output is null. ------------- PR: https://git.openjdk.java.net/jdk/pull/4386 From dfuchs at openjdk.java.net Tue Jun 8 11:47:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Jun 2021 11:47:24 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v14] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 10:32:49 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarified javadoc for rejectUndecidedClass. > Added javadoc to describe throwing of ExceptionInInitializerError if the class > named by system property jdk.serialFilterFactory is not valid. > Added description of jdk.serialFilterFactory to java.security file. src/java.base/share/classes/java/io/ObjectInputFilter.java line 392: > 390: * Returns a filter that invokes a given filter and maps {@code UNDECIDED} to {@code REJECTED} > 391: * for classes, with some special cases, and otherwise returns the status. > 392: * If the class is not a primitive class and not an array, the status returned is REJECTED. {@code REJECTED} src/java.base/share/classes/java/io/ObjectInputFilter.java line 550: > 548: * be accessible via the {@linkplain ClassLoader#getSystemClassLoader() application class loader}. > 549: * If the filter factory constructor is not invoked successfully, an {@link ExceptionInInitializerError} > 550: * is thrown. Should you also say that later attempts to create an `ObjectInputStream` or to call `ObjectInputStream::setObjectInputFilter` will result in an `IllegalStateException`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From weijun at openjdk.java.net Tue Jun 8 12:22:15 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 8 Jun 2021 12:22:15 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: <8Con08J4o54RWaz5vK6omwhiLiLoPTkKooPHEqufJys=.40d6ea48-b98f-4376-aed1-76e3f44ed037@github.com> On Tue, 8 Jun 2021 06:41:11 GMT, Alan Bateman wrote: > > You might want to make your "WARNING" consistent with the VM's "Warning" so that OutputAnalyzer's logic to ignore warnings will automatically ignore these too. > > The uppercase "WARNING" is intentional here, it was the same with illegal reflective access warnings. I'm sure Max has or will run all tests to see if there are any issues. Will definitely run all from tier1-tier9. I ran them multiple times while implementing JEP 411. I've seen warnings with "VM" word in the prefix and test methods that filter them out, but feel the warnings here are not related to VM. The new warnings do have impacts on some tests and I'll be very carefully not break them. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From jvernee at openjdk.java.net Tue Jun 8 12:23:21 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 12:23:21 GMT Subject: RFR: 8240349: jlink --vm with not present VM does not fail fast In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 11:00:00 GMT, Athijegannathan Sundararajan wrote: > jlink should clean up output directory on any failure. should not leave partially filled output. WRT the test failure on Windows discussed offline: when the directory is deleted as a result of a `PluginException` being thrown, there is still an open file handle on the `lib/modules` file in the image directory, which prevents the directory from being deleted. Bisecting this, it seems that the file handle is being created in `ImageFileCreater::writeImage` with a call to `plugins.getJImageFileOutputStream` (https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java#L162). This creates an output stream that is never closed. Following patch fixes: diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java index 749025bea9d..8beddc5a037 100644 --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java @@ -158,8 +158,10 @@ public final class ImageFileCreator { BasicImageWriter writer = new BasicImageWriter(byteOrder); ResourcePoolManager allContent = createPoolManager(archives, entriesForModule, byteOrder, writer); - ResourcePool result = generateJImage(allContent, - writer, plugins, plugins.getJImageFileOutputStream()); + ResourcePool result; + try (DataOutputStream out = plugins.getJImageFileOutputStream()) { + result = generateJImage(allContent, writer, plugins, out); + } //Handle files. try { ------------- PR: https://git.openjdk.java.net/jdk/pull/4386 From weijun at openjdk.java.net Tue Jun 8 12:28:16 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 8 Jun 2021 12:28:16 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 06:11:17 GMT, Alan Bateman wrote: >> More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. > > src/java.base/share/classes/java/lang/System.java line 331: > >> 329: >> 330: // Remember original System.err. setSecurityManager() warning goes here >> 331: private static PrintStream oldErrStream = null; > > I assume this should needs to be volatile and @Stable. I think we need a better name for it too. Will add the modifiers. How about "originalErr"? > src/java.base/share/classes/java/lang/System.java line 336: > >> 334: // Remember callers of setSecurityManager() here so that warning >> 335: // is only printed once for each different caller >> 336: final static Map callersOfSSM = new WeakHashMap<>(); > > You can't use a WeakHashMap without synchronization but a big question here is whether a single caller frame is sufficient. If I were doing this then I think I would capture the hash of a number of stack frames to create a better filter. I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. > src/java.base/share/classes/java/lang/System.java line 2219: > >> 2217: WARNING: java.lang.SecurityManager is deprecated and will be removed in a future release >> 2218: WARNING: -Djava.security.manager=%s will have no effect when java.lang.SecurityManager is removed >> 2219: """, smProp); > > Raw strings may be useful here but means the lines length are inconsistent and makes it too hard to look at side by side diffs now. I understand what you mean when I switch to Split View. While I can extract the lines to a method, I somehow think it's not worth doing because for each type of warning the method is only called once. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From erikj at openjdk.java.net Tue Jun 8 12:40:18 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Jun 2021 12:40:18 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home In-Reply-To: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> Message-ID: On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare wrote: > This concerns [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). > > In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. > > So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. > > The expected value is `"Must set property 'dtd_home'"` > > And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java line 287: > 285: > 286: String dtd_home = System.getProperty("dtd_home") + File.separator; > 287: if (dtd_home.equals("null" + File.separator)) { dtd_home is only used in one location, so instead of changing this null check, maybe just move the "+ File.separator" to line 295? ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From sundar at openjdk.java.net Tue Jun 8 13:05:14 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 8 Jun 2021 13:05:14 GMT Subject: RFR: 8240349: jlink --vm with not present VM does not fail fast In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 12:20:32 GMT, Jorn Vernee wrote: > WRT the test failure on Windows discussed offline: when the directory is deleted as a result of a `PluginException` being thrown, there is still an open file handle on the `lib/modules` file in the image directory, which prevents the directory from being deleted. > > Bisecting this, it seems that the file handle is being created in `ImageFileCreater::writeImage` with a call to `plugins.getJImageFileOutputStream` (https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java#L162). This creates an output stream that is never closed. > > Following patch fixes: > > ``` > diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java > index 749025bea9d..8beddc5a037 100644 > --- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java > +++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java > @@ -158,8 +158,10 @@ public final class ImageFileCreator { > BasicImageWriter writer = new BasicImageWriter(byteOrder); > ResourcePoolManager allContent = createPoolManager(archives, > entriesForModule, byteOrder, writer); > - ResourcePool result = generateJImage(allContent, > - writer, plugins, plugins.getJImageFileOutputStream()); > + ResourcePool result; > + try (DataOutputStream out = plugins.getJImageFileOutputStream()) { > + result = generateJImage(allContent, writer, plugins, out); > + } > > //Handle files. > try { > ``` Thanks @JornVernee ------------- PR: https://git.openjdk.java.net/jdk/pull/4386 From sundar at openjdk.java.net Tue Jun 8 13:05:16 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 8 Jun 2021 13:05:16 GMT Subject: RFR: 8240349: jlink --vm with not present VM does not fail fast In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 11:32:29 GMT, Alan Bateman wrote: >> jlink should clean up output directory on any failure. should not leave partially filled output. > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 295: > >> 293: cleanupOutput(outputPath); >> 294: return EXIT_ERROR; >> 295: } catch (BadArgs e) { > > Can you confirm that this change is benign for the case that the output directory exists? I believe it's a BadArgs case so it won't attempt to delete a file or tree if it exists but I'd like confirmation. Will check that. > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 490: > >> 488: >> 489: private static void deleteDirectory(Path dir) throws IOException { >> 490: if (dir != null && Files.isDirectory(dir)) { > > I don't think this method should be checking dir, that should be up to the caller to ensure that it is not called when output is null. okay. will move that check to caller. ------------- PR: https://git.openjdk.java.net/jdk/pull/4386 From github.com+6704669+asgibbons at openjdk.java.net Tue Jun 8 13:28:17 2021 From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons) Date: Tue, 8 Jun 2021 13:28:17 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3] In-Reply-To: References: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> Message-ID: On Tue, 8 Jun 2021 01:56:42 GMT, Jatin Bhateja wrote: >> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing review comments. Adding notes about isMIME parameter for other architectures; clarifying decodeBlock comments. > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6239: > >> 6237: >> 6238: __ align(32); >> 6239: __ BIND(L_bruteForce); > > Is this alignment needed ? Given that brute force loop is already aligned. I must be missing something. How is the brute force loop aligned if not by this directive? I don't see an alignment anywhere else that could force it. After the entry(), there are pushes and length comparisons followed by the conditional on VBMI. The only thing I can guess would be that the jmp aligns, but I see no indication that that occurs. ------------- PR: https://git.openjdk.java.net/jdk/pull/4368 From stuefe at openjdk.java.net Tue Jun 8 13:40:17 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 8 Jun 2021 13:40:17 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote: >> ?d on macOS >> >> This patch simply round up the specified stack size to multiple of the system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >> >> ```code:java >> public class StackLeak { >> public int depth = 0; >> public void stackLeak() { >> depth++; >> stackLeak(); >> } >> >> public static void main(String[] args) { >> var test = new StackLeak(); >> try { >> test.stackLeak(); >> } catch (Throwable e) { >> System.out.println(test.depth); >> } >> } >> } > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Cast type > - Merge > - Change java -X output for -Xss > - Merge > - Only try to round-up when current value failed > - Avoid overflow on page size > - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS Please make sure the failing tests have nothing to do with your patch. `gc/shenandoah/compiler/TestLinkToNativeRBP.java` sounds at least suggestive. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From mcimadamore at openjdk.java.net Tue Jun 8 14:06:21 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 8 Jun 2021 14:06:21 GMT Subject: Integrated: 8268227: java/foreign/TestUpcall.java still times out In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 10:53:42 GMT, Maurizio Cimadamore wrote: > Turns out that adding more timeout is a lost cause here. The root cause of the slowdown when running the test in debug build is: > > https://bugs.openjdk.java.net/browse/JDK-8266074 > > Which has also caused related test issues: > > https://bugs.openjdk.java.net/browse/JDK-8268095 > > So, the fix (at least temporarily) is to run method handle-heavy tests with the -XX:-VerifyDependency options. > > On my machine, execution time of these tests on debug goes from 10 minutes down to less than 1. > > Since `-XX:-VerifyDependencies` cannot be specified on non-debug build, the `-XX:+IgnoreUnrecognizedVMOptions` is also passed (thanks Vlad for the tip!). This pull request has now been integrated. Changeset: 6843576c Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/6843576c95a70bffad95df278d5f5be29371bca4 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8268227: java/foreign/TestUpcall.java still times out Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4355 From herrick at openjdk.java.net Tue Jun 8 14:06:50 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 8 Jun 2021 14:06:50 GMT Subject: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR [v2] In-Reply-To: References: Message-ID: > JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Andy Herrick 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 122 additional commits since the last revision: - JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR - Merge branch 'master' into JDK-8267764 - Merge branch 'master' into JDK-8267764 - 8191441: (Process) add Readers and Writer access to java.lang.Process streams Reviewed-by: naoto, alanb - 8261549: Adjust memory size in MTLTexurePool.m Reviewed-by: prr - 8268299: jvms tag produces incorrect URL Reviewed-by: iris, erikj, jjg - 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests Co-authored-by: Christian Hagedorn Co-authored-by: Tobias Hartmann Reviewed-by: iignatyev - 8268331: Fix crash in humongous object eager reclaim logging Reviewed-by: sjohanss - 8267875: Shenandoah: Duplicated code in ShenandoahBarrierSetC2::ideal_node() Reviewed-by: rkennke, roland - 8268267: Remove -Djavatest.security.noSecurityManager=true from jtreg runs Reviewed-by: lancea, jjg, erikj - ... and 112 more: https://git.openjdk.java.net/jdk/compare/583e2df7...7ad71791 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4306/files - new: https://git.openjdk.java.net/jdk/pull/4306/files/cfd8ce4d..7ad71791 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4306&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4306&range=00-01 Stats: 484800 lines in 1905 files changed: 468469 ins; 10878 del; 5453 mod Patch: https://git.openjdk.java.net/jdk/pull/4306.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4306/head:pull/4306 PR: https://git.openjdk.java.net/jdk/pull/4306 From herrick at openjdk.java.net Tue Jun 8 14:06:52 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 8 Jun 2021 14:06:52 GMT Subject: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote: > JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR as suggested added a simple test to verify an app on windows can continue to run after ".exe" is renamed to any other extension ------------- PR: https://git.openjdk.java.net/jdk/pull/4306 From jbhateja at openjdk.java.net Tue Jun 8 14:17:18 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 8 Jun 2021 14:17:18 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3] In-Reply-To: References: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> Message-ID: On Tue, 8 Jun 2021 13:25:00 GMT, Scott Gibbons wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6239: >> >>> 6237: >>> 6238: __ align(32); >>> 6239: __ BIND(L_bruteForce); >> >> Is this alignment needed ? Given that brute force loop is already aligned. > > I must be missing something. How is the brute force loop aligned if not by this directive? I don't see an alignment anywhere else that could force it. After the entry(), there are pushes and length comparisons followed by the conditional on VBMI. The only thing I can guess would be that the jmp aligns, but I see no indication that that occurs. > > Perhaps what you missed was that L_forceLoop is aligned (line 6288). This is not the same label as L_bruteForce, which is a jump target from within the VBMI conditional (which should be aligned)? Otherwise, I don't see how L_bruteForce could possibly already be aligned. Yes, I meant force loop already has alignment so earlier one can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4368 From jvernee at openjdk.java.net Tue Jun 8 14:25:22 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 14:25:22 GMT Subject: Integrated: 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 13:23:46 GMT, Jorn Vernee wrote: > Hi, > > The documentation of `CLinker::systemLookup` [1] says this: > > > * Obtains a system lookup which is suitable to find symbols in the standard C libraries. > > > However, currently it is not possible to look up common stdio.h symbols, such as `printf`, using the system lookup on Windows 10. This is because the backing library that is loaded, namely `ucrtbase.dll`, does not contain these symbols, as they are implemented in the standard library as inline functions. > > This patch changes the system lookup implementation on Windows 10 to make these symbols findable as well, by using a fallback library that forces the generation of the code for the inline functions, and exposes the missing symbols as a table of function pointers. > > See also the prior review of this patch for the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/547 > > Since the exact set of symbols findable by the system lookup is unspecified, and since the API in question (`CLinker::systemLookup`) was added only last week [2], I've elected to not create a CSR for this patch, but please let me know if one is needed). > > Thanks, > Jorn > > [1] : https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java#L134-L151 > [2] : https://github.com/openjdk/jdk/commit/a223189b069a7cfe49511d49b5b09e7107cb3cab This pull request has now been integrated. Changeset: 8158b822 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/8158b82269513a60c13bb10a6edfa82f806e8efc Stats: 273 lines in 5 files changed: 203 ins; 58 del; 12 mod 8268327: Upstream: 8268169: The system lookup can not find stdio functions such as printf on Windows 10 Reviewed-by: erikj, sundar ------------- PR: https://git.openjdk.java.net/jdk/pull/4390 From rriggs at openjdk.java.net Tue Jun 8 14:26:43 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Jun 2021 14:26:43 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v15] In-Reply-To: References: Message-ID: > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Clarify exceptions that occur if initializing the filter factory from jdk.serialFilterFactory fails ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3996/files - new: https://git.openjdk.java.net/jdk/pull/3996/files/755d8f20..d96d4e3e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3996&range=13-14 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3996/head:pull/3996 PR: https://git.openjdk.java.net/jdk/pull/3996 From rriggs at openjdk.java.net Tue Jun 8 14:26:44 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Jun 2021 14:26:44 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v14] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 11:41:28 GMT, Daniel Fuchs wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarified javadoc for rejectUndecidedClass. >> Added javadoc to describe throwing of ExceptionInInitializerError if the class >> named by system property jdk.serialFilterFactory is not valid. >> Added description of jdk.serialFilterFactory to java.security file. > > src/java.base/share/classes/java/io/ObjectInputFilter.java line 550: > >> 548: * be accessible via the {@linkplain ClassLoader#getSystemClassLoader() application class loader}. >> 549: * If the filter factory constructor is not invoked successfully, an {@link ExceptionInInitializerError} >> 550: * is thrown. > > Should you also say that later attempts to create an `ObjectInputStream` or to call `ObjectInputStream::setObjectInputFilter` will result in an `IllegalStateException`? Yes, and setObjectInputFilter should throw ISE if the initialization from the system property has failed. ``` * If the filter factory constructor is not invoked successfully, an {@link ExceptionInInitializerError} * is thrown and subsequent use of the filter factory for deserialization fails with * {@link IllegalStateException}. ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From sundar at openjdk.java.net Tue Jun 8 14:29:38 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 8 Jun 2021 14:29:38 GMT Subject: RFR: 8240349: jlink should not leave partial image output directory on failure [v2] In-Reply-To: References: Message-ID: > jlink should clean up output directory on any failure. should not leave partially filled output. Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: Fixed resouce closing issue for lib/moduls file. Pre-existing output directory should not be deleted when exiting. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4386/files - new: https://git.openjdk.java.net/jdk/pull/4386/files/f12e6a29..df036a3a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4386&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4386&range=00-01 Stats: 48 lines in 5 files changed: 22 ins; 12 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/4386.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4386/head:pull/4386 PR: https://git.openjdk.java.net/jdk/pull/4386 From dfuchs at openjdk.java.net Tue Jun 8 14:31:24 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 8 Jun 2021 14:31:24 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v15] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 14:26:43 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify exceptions that occur if initializing the filter factory from jdk.serialFilterFactory fails Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From chegar at openjdk.java.net Tue Jun 8 14:37:24 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 8 Jun 2021 14:37:24 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v15] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 14:26:43 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify exceptions that occur if initializing the filter factory from jdk.serialFilterFactory fails Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From github.com+9004656+yaaz at openjdk.java.net Tue Jun 8 14:39:21 2021 From: github.com+9004656+yaaz at openjdk.java.net (Nikita Gubarkov) Date: Tue, 8 Jun 2021 14:39:21 GMT Subject: Integrated: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac In-Reply-To: References: Message-ID: <9QO9wAPeIwrFaGmBA1PCfyBR3CIG_vaVdBTPxgNoOf8=.f8cb58a4-dba6-4734-bf7d-3fe151a45582@github.com> On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov wrote: > I got rid of `realpath` usage as discussed in https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro instead, however there were quite a few problems with this macro, here's the example: > > $(call RelativePath,/foo/bar,/foo/bar/baz) -> " ..//foo/bar" > $(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT > $(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> " ./baz/banan" > $(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> " ../baz" > > As you can see, 1st case is just plain wrong, 2nd crashes make because of infinite loop, 3rd can be simplified and all of them have leading whitespaces > First commit in this PR fixes all these issues and adds corresponding test cases and second commit replaces usage of `realpath` in idea.sh with `RelativePath` macro in idea.gmk and fixes problems, when paths are incorrectly treated by IDEA This pull request has now been integrated. Changeset: 159cb6fa Author: Nikita Gubarkov Committer: Alexey Ushakov URL: https://git.openjdk.java.net/jdk/commit/159cb6facc668acc30552665e46b18edf58c3a91 Stats: 219 lines in 11 files changed: 107 ins; 47 del; 65 mod 8268083: JDK-8267706 breaks bin/idea.sh on a Mac Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4369 From jlaskey at openjdk.java.net Tue Jun 8 14:53:18 2021 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Jun 2021 14:53:18 GMT Subject: RFR: 8240349: jlink should not leave partial image output directory on failure [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 14:29:38 GMT, Athijegannathan Sundararajan wrote: >> jlink should clean up output directory on any failure. should not leave partially filled output. > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > Fixed resouce closing issue for lib/moduls file. Pre-existing output directory should not be deleted when exiting. Marked as reviewed by jlaskey (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4386 From dlsmith at openjdk.java.net Tue Jun 8 15:30:33 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 8 Jun 2021 15:30:33 GMT Subject: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2] In-Reply-To: References: Message-ID: > Small bug fix. Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Clean up validation of implKind REF_invokeSpecial ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4403/files - new: https://git.openjdk.java.net/jdk/pull/4403/files/74c346a1..149fb55b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4403&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4403&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4403.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4403/head:pull/4403 PR: https://git.openjdk.java.net/jdk/pull/4403 From dlsmith at openjdk.java.net Tue Jun 8 15:30:34 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 8 Jun 2021 15:30:34 GMT Subject: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2] In-Reply-To: References: Message-ID: <1wmHduinWU2-uu9HNWrAVb5FLENTvUZJt75jyCH9vi4=.936ac841-1fcf-4d78-aa42-99a5d803c456@github.com> On Tue, 8 Jun 2021 15:27:04 GMT, Dan Smith wrote: >> Small bug fix. > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Clean up validation of implKind REF_invokeSpecial src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java line 160: > 158: // method with REF_invokeSpecial. Newer classes use REF_invokeVirtual or > 159: // REF_invokeInterface, and we can use that instruction in the lambda class. > 160: if (targetClass == implClass) { The name `` can't appear here. It's only used by `newInvokeSpecial`. src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 189: > 187: // to invoke directly. (javac prefers to avoid this situation by > 188: // generating bridges in the target class) > 189: useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) && Switched from `!Modifier.isPublic` to `Modifier.isProtected`. Access errors from the caller Lookup should already be caught by validation when the `implementation` is cracked. Protected and `super` calls are the only cases where the access from the nestmate is not equivalent. ------------- PR: https://git.openjdk.java.net/jdk/pull/4403 From dlsmith at openjdk.java.net Tue Jun 8 15:30:36 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 8 Jun 2021 15:30:36 GMT Subject: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2] In-Reply-To: <8uxW_SlLKnCxGuwFefxpBvB3vHQ-2SoJM9hPh3GRgHY=.5918864a-7685-49fd-afbd-96a48fe02c95@github.com> References: <8uxW_SlLKnCxGuwFefxpBvB3vHQ-2SoJM9hPh3GRgHY=.5918864a-7685-49fd-afbd-96a48fe02c95@github.com> Message-ID: On Tue, 8 Jun 2021 15:17:44 GMT, Dan Smith wrote: >> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 191: >> >>> 189: useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) && >>> 190: !VerifyAccess.isSamePackage(implClass, implInfo.getDeclaringClass())) || >>> 191: implKind == H_INVOKESPECIAL; >> >> Won't this make regular private instance method calls use condy as well, as they are invokespecial? > > See this code from the `AbstractValidatingLambdaMetafactory` constructor: > > > case REF_invokeSpecial: > // JDK-8172817: should use referenced class here, but we don't know what it was > this.implClass = implInfo.getDeclaringClass(); > this.implIsInstanceMethod = true; > > // Classes compiled prior to dynamic nestmate support invokes a private instance > // method with REF_invokeSpecial. > // > // invokespecial should only be used to invoke private nestmate constructors. > // The lambda proxy class will be defined as a nestmate of targetClass. > // If the method to be invoked is an instance method of targetClass, then > // convert to use invokevirtual or invokeinterface. > if (targetClass == implClass && !implInfo.getName().equals("")) { > this.implKind = implClass.isInterface() ? REF_invokeInterface : REF_invokeVirtual; > } else { > this.implKind = REF_invokeSpecial; > } > break; > > > We turn all same-class invocations into `invokevirtual`. (And all `` invocations have kind `newInvokeSpecial`, mentioning them here is actually useless.) Actually, I think I'll fix up this code and the comment... ------------- PR: https://git.openjdk.java.net/jdk/pull/4403 From dlsmith at openjdk.java.net Tue Jun 8 15:30:35 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Tue, 8 Jun 2021 15:30:35 GMT Subject: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2] In-Reply-To: References: Message-ID: <8uxW_SlLKnCxGuwFefxpBvB3vHQ-2SoJM9hPh3GRgHY=.5918864a-7685-49fd-afbd-96a48fe02c95@github.com> On Tue, 8 Jun 2021 02:23:09 GMT, liach wrote: >> Dan Smith has updated the pull request incrementally with one additional commit since the last revision: >> >> Clean up validation of implKind REF_invokeSpecial > > src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 191: > >> 189: useImplMethodHandle = (Modifier.isProtected(implInfo.getModifiers()) && >> 190: !VerifyAccess.isSamePackage(implClass, implInfo.getDeclaringClass())) || >> 191: implKind == H_INVOKESPECIAL; > > Won't this make regular private instance method calls use condy as well, as they are invokespecial? See this code from the `AbstractValidatingLambdaMetafactory` constructor: case REF_invokeSpecial: // JDK-8172817: should use referenced class here, but we don't know what it was this.implClass = implInfo.getDeclaringClass(); this.implIsInstanceMethod = true; // Classes compiled prior to dynamic nestmate support invokes a private instance // method with REF_invokeSpecial. // // invokespecial should only be used to invoke private nestmate constructors. // The lambda proxy class will be defined as a nestmate of targetClass. // If the method to be invoked is an instance method of targetClass, then // convert to use invokevirtual or invokeinterface. if (targetClass == implClass && !implInfo.getName().equals("")) { this.implKind = implClass.isInterface() ? REF_invokeInterface : REF_invokeVirtual; } else { this.implKind = REF_invokeSpecial; } break; We turn all same-class invocations into `invokevirtual`. (And all `` invocations have kind `newInvokeSpecial`, mentioning them here is actually useless.) ------------- PR: https://git.openjdk.java.net/jdk/pull/4403 From asemenyuk at openjdk.java.net Tue Jun 8 15:57:21 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 8 Jun 2021 15:57:21 GMT Subject: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR [v2] In-Reply-To: References: Message-ID: <1H70pU_BlayNCjCp9eOHUwwm8q7PUXUZZLMydKzGRZM=.37a92020-fc35-4f5e-bbd4-5fb795eb0bf8@github.com> On Tue, 8 Jun 2021 14:06:50 GMT, Andy Herrick wrote: >> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR > > Andy Herrick 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 122 additional commits since the last revision: > > - JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR > - Merge branch 'master' into JDK-8267764 > - Merge branch 'master' into JDK-8267764 > - 8191441: (Process) add Readers and Writer access to java.lang.Process streams > > Reviewed-by: naoto, alanb > - 8261549: Adjust memory size in MTLTexurePool.m > > Reviewed-by: prr > - 8268299: jvms tag produces incorrect URL > > Reviewed-by: iris, erikj, jjg > - 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests > > Co-authored-by: Christian Hagedorn > Co-authored-by: Tobias Hartmann > Reviewed-by: iignatyev > - 8268331: Fix crash in humongous object eager reclaim logging > > Reviewed-by: sjohanss > - 8267875: Shenandoah: Duplicated code in ShenandoahBarrierSetC2::ideal_node() > > Reviewed-by: rkennke, roland > - 8268267: Remove -Djavatest.security.noSecurityManager=true from jtreg runs > > Reviewed-by: lancea, jjg, erikj > - ... and 112 more: https://git.openjdk.java.net/jdk/compare/95c2968d...7ad71791 Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4306 From jvernee at openjdk.java.net Tue Jun 8 16:12:18 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 16:12:18 GMT Subject: RFR: 8268328: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 1) In-Reply-To: References: Message-ID: <4nhUrkF8c4D49WNfZQfLqby_ukrKz1fbcN4PZ2808WI=.d861e05a-6a05-420e-b310-af1521b2eebd@github.com> On Mon, 7 Jun 2021 15:14:39 GMT, Jorn Vernee wrote: > Hi, > > This is part 1 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. > > This patch changes the handling of method handles that might throw checked exceptions, by the var handle combinators found in `jdk.incubator.foreign.MemoryHandles`. Particularly, it makes the check more lenient towards `BoundMethodHandle`s that have fields that are method handles that might themselves throw exceptions, since it is not known whether the enclosing method handle catches such exceptions. For instance, if a target method handle is wrapped using the `catchException` combinator, which handles all exceptions thrown by that target, the current code will still reject such method handles, even though no checked exceptions can be thrown. > > The patch fixes this by instead wrapping method handles for which it is not possible to eagerly determine whether they throw exception using the `catchException` combinator, with an exception handler that catches checked exceptions and instead throws an `IllegalStateException` with the original exception as the cause. (See also the CSR). > > The main motivation for doing this is having the ability to share the implementation with the `CLinker::upcallStub` API, which also wants to eagerly reject method handles that are determined to throw exceptions. > > See also the original review for the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. Deferred until a better solution is available. ------------- PR: https://git.openjdk.java.net/jdk/pull/4395 From jvernee at openjdk.java.net Tue Jun 8 16:12:18 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 16:12:18 GMT Subject: Withdrawn: 8268328: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 1) In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 15:14:39 GMT, Jorn Vernee wrote: > Hi, > > This is part 1 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. > > This patch changes the handling of method handles that might throw checked exceptions, by the var handle combinators found in `jdk.incubator.foreign.MemoryHandles`. Particularly, it makes the check more lenient towards `BoundMethodHandle`s that have fields that are method handles that might themselves throw exceptions, since it is not known whether the enclosing method handle catches such exceptions. For instance, if a target method handle is wrapped using the `catchException` combinator, which handles all exceptions thrown by that target, the current code will still reject such method handles, even though no checked exceptions can be thrown. > > The patch fixes this by instead wrapping method handles for which it is not possible to eagerly determine whether they throw exception using the `catchException` combinator, with an exception handler that catches checked exceptions and instead throws an `IllegalStateException` with the original exception as the cause. (See also the CSR). > > The main motivation for doing this is having the ability to share the implementation with the `CLinker::upcallStub` API, which also wants to eagerly reject method handles that are determined to throw exceptions. > > See also the original review for the panama-foreign repo: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4395 From github.com+6704669+asgibbons at openjdk.java.net Tue Jun 8 16:13:19 2021 From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons) Date: Tue, 8 Jun 2021 16:13:19 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3] In-Reply-To: References: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> Message-ID: On Tue, 8 Jun 2021 14:13:53 GMT, Jatin Bhateja wrote: >> I must be missing something. How is the brute force loop aligned if not by this directive? I don't see an alignment anywhere else that could force it. After the entry(), there are pushes and length comparisons followed by the conditional on VBMI. The only thing I can guess would be that the jmp aligns, but I see no indication that that occurs. >> >> Perhaps what you missed was that L_forceLoop is aligned (line 6288). This is not the same label as L_bruteForce, which is a jump target from within the VBMI conditional (which should be aligned)? Otherwise, I don't see how L_bruteForce could possibly already be aligned. > > Yes, I meant force loop already has alignment so earlier one can be removed. Sorry - still confused. These are two different labels, bound to two different locations. I believe the alignments for both are justified. ------------- PR: https://git.openjdk.java.net/jdk/pull/4368 From jvernee at openjdk.java.net Tue Jun 8 16:14:43 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 16:14:43 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) [v2] In-Reply-To: References: Message-ID: > Hi, > > This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395 > > This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. > > Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. > > This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. > > Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. > > See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. > > Thanks, > Jorn Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4396/files - new: https://git.openjdk.java.net/jdk/pull/4396/files/b495aae3..b495aae3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4396&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4396&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4396/head:pull/4396 PR: https://git.openjdk.java.net/jdk/pull/4396 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Tue Jun 8 16:14:44 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Tue, 8 Jun 2021 16:14:44 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 16:38:01 GMT, Jorn Vernee wrote: > Hi, > > This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395 > > This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. > > Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. > > This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. > > Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. > > See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. > > Thanks, > Jorn The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout Upstream_Excp_Hndl git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/4396 From henryjen at openjdk.java.net Tue Jun 8 16:34:18 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Tue, 8 Jun 2021 16:34:18 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: <2H0p0FTNfSLWWhPm4zU9czymsXst4mCM9D6K1X8L-mk=.ac3c6ec6-04ca-4899-862c-7e584558f89d@github.com> On Tue, 8 Jun 2021 02:36:26 GMT, David Holmes wrote: >> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Cast type >> - Merge >> - Change java -X output for -Xss >> - Merge >> - Only try to round-up when current value failed >> - Avoid overflow on page size >> - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS > > src/java.base/share/classes/sun/launcher/resources/launcher.properties line 175: > >> 173: \ configuration and continue\n\ >> 174: \ -Xss set java thread stack size\n\ >> 175: \ The actual size may be round up to multiple of system\n\ > > See updated help text in the CSR request. Updated, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From henryjen at openjdk.java.net Tue Jun 8 16:48:19 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Tue, 8 Jun 2021 16:48:19 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: On Tue, 8 Jun 2021 08:17:54 GMT, Thomas Stuefe wrote: >> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Cast type >> - Merge >> - Change java -X output for -Xss >> - Merge >> - Only try to round-up when current value failed >> - Avoid overflow on page size >> - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS > > src/java.base/unix/native/libjli/java_md.c line 666: > >> 664: return page_size * pages; >> 665: } >> 666: } > > Could probably be shortened to something like this: > > > size_t pagesize = (size_t)sysconf(_SC_PAGESIZE); > return (stack_size + (pagesize - 1)) & ~(pagesize - 1); > > > or, if you insist on checking for SIZE_MAX: > > > size_t pagesize = (size_t)sysconf(_SC_PAGESIZE); > size_t max = SIZE_MAX - pagesize; > return stack_size <= max ? (stack_size + (pagesize - 1)) & ~(pagesize - 1) : max; > > > (I see David requested this, so this is fine, though passing SIZE_MAX to this function will quite likely fail anyway :) While sysconf(_SC_PAGESIZE) is most likely(if not always) be power of 2, it's not a constant we know for sure here and this is not critical path for performance, thus I didn't take that approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From henryjen at openjdk.java.net Tue Jun 8 16:53:38 2021 From: henryjen at openjdk.java.net (Henry Jen) Date: Tue, 8 Jun 2021 16:53:38 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v6] In-Reply-To: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: > ?d on macOS > > This patch simply round up the specified stack size to multiple of the system page size. > > Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. > > ```code:java > public class StackLeak { > public int depth = 0; > public void stackLeak() { > depth++; > stackLeak(); > } > > public static void main(String[] args) { > var test = new StackLeak(); > try { > test.stackLeak(); > } catch (Throwable e) { > System.out.println(test.depth); > } > } > } Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Update help text ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4256/files - new: https://git.openjdk.java.net/jdk/pull/4256/files/5a8d4a10..a3966612 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4256&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4256/head:pull/4256 PR: https://git.openjdk.java.net/jdk/pull/4256 From vromero at openjdk.java.net Tue Jun 8 16:54:29 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 8 Jun 2021 16:54:29 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling Message-ID: Please review this PR which is just syncing the implementation of DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the method's spec is that if the value of the `refKind` parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of `true` for its second argument, currently it is invoked with `false` regardless of the value of the `refKind` parameter TIA ------------- Commit messages: - 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling Changes: https://git.openjdk.java.net/jdk/pull/4416/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4416&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267421 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4416/head:pull/4416 PR: https://git.openjdk.java.net/jdk/pull/4416 From asemenyuk at openjdk.java.net Tue Jun 8 16:54:37 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 8 Jun 2021 16:54:37 GMT Subject: RFR: 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages Message-ID: <1gp-hzi2Nf3kS_KBzd5rLHNpDTffoxfA1e9IaT-5zZI=.4d8c4875-6d5d-46a5-831c-0a91a673309b@github.com> ?ages ------------- Commit messages: - 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages Changes: https://git.openjdk.java.net/jdk/pull/4415/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4415&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264144 Stats: 115 lines in 5 files changed: 114 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4415/head:pull/4415 PR: https://git.openjdk.java.net/jdk/pull/4415 From jvernee at openjdk.java.net Tue Jun 8 17:07:43 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 17:07:43 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) [v3] In-Reply-To: References: Message-ID: > Hi, > > This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395 > > This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. > > Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. > > This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. > > Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. > > See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. > > Thanks, > Jorn Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Remove spurious import - Pt2 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4396/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4396&range=02 Stats: 227 lines in 8 files changed: 222 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4396/head:pull/4396 PR: https://git.openjdk.java.net/jdk/pull/4396 From jvernee at openjdk.java.net Tue Jun 8 17:15:16 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 17:15:16 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) [v3] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 17:07:43 GMT, Jorn Vernee wrote: >> Hi, >> >> This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395 >> >> This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. >> >> Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. >> >> This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. >> >> Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. >> >> See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 >> >> Thanks, >> Jorn >> >> Testing: `jdk_foreign` test suite. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Remove spurious import > - Pt2 During some offline discussion of the CSR for the first part of this upstreaming, it was decided to focus on the second part only, and address the first part later. I've rebased this PR onto the master branch, and this has the effect that the `CLinker::upcallStub` method no longer does an eager check for exceptions, and I've updated the javadoc to reflect this. I've also removed the security manager usage, which tries to block calls to System.exit, from the test, since the new version of the jtreg agent also tries to call System.exit it seems, and the test fails because of the SecurityManager it installs. While it's theoretically possible to inspect the stack to figure out if the jtreg agent is calling System.exit, and then give permission, with the complexity that this would introduce in the test, together with the fact that the SecurityManager is deprecated, and it being seemingly unlikely that a SecurityManager check would be added to the alternative API currently being used to shut down the VM, it seems that programmatically testing that we can exit the VM with a SecurityManager installed is not worth the effort. We already know that the current code works from earlier testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/4396 From alanb at openjdk.java.net Tue Jun 8 17:18:17 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 17:18:17 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 12:22:52 GMT, Weijun Wang wrote: > I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. > > As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. WeakHashMap access synchronization. Whether we need to cache to avoid excessive warnings isn't clear. If the SM is enabled once and never disabled/re-enabled then caching isn't interesting. On the other hand if there are programs that are enabling/disabling to execute subsets of code then maybe it is. Maybe we should just drop this and see if there is any feedback on the repeated warning? ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From jvernee at openjdk.java.net Tue Jun 8 17:21:45 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 17:21:45 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) [v4] In-Reply-To: References: Message-ID: <47snZM_hfgbIZBlQice2lhRXYwQdGm-KRck7CeYhJ-w=.03930671-42a1-4d37-95ab-b74caa704070@github.com> > Hi, > > ~This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395~ > > This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. > > Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. > > This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. > > Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. > > See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Remove another spurious import ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4396/files - new: https://git.openjdk.java.net/jdk/pull/4396/files/803427e7..a9e652e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4396&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4396&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4396/head:pull/4396 PR: https://git.openjdk.java.net/jdk/pull/4396 From asemenyuk at openjdk.java.net Tue Jun 8 17:25:46 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 8 Jun 2021 17:25:46 GMT Subject: RFR: 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages [v2] In-Reply-To: <1gp-hzi2Nf3kS_KBzd5rLHNpDTffoxfA1e9IaT-5zZI=.4d8c4875-6d5d-46a5-831c-0a91a673309b@github.com> References: <1gp-hzi2Nf3kS_KBzd5rLHNpDTffoxfA1e9IaT-5zZI=.4d8c4875-6d5d-46a5-831c-0a91a673309b@github.com> Message-ID: > ?ages Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8264144 - 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4415/files - new: https://git.openjdk.java.net/jdk/pull/4415/files/74ece7db..0aba3dd9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4415&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4415&range=00-01 Stats: 29705 lines in 426 files changed: 25434 ins; 2162 del; 2109 mod Patch: https://git.openjdk.java.net/jdk/pull/4415.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4415/head:pull/4415 PR: https://git.openjdk.java.net/jdk/pull/4415 From alanb at openjdk.java.net Tue Jun 8 17:31:16 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 17:31:16 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v2] In-Reply-To: References: Message-ID: On Wed, 19 May 2021 15:36:57 GMT, Jorn Vernee wrote: >> This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. >> >> The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. >> >> I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. >> >> Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. >> >> Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html >> >> Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Update error message This all looks reasonable, I just wonder if the --validate description in the help output should provide a brief summary on what it does check. We can add to it as some validation is added. Without it then people will make assumptions on what it does. ------------- PR: https://git.openjdk.java.net/jdk/pull/3971 From jvernee at openjdk.java.net Tue Jun 8 17:34:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 17:34:58 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) [v5] In-Reply-To: References: Message-ID: > Hi, > > ~This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395~ > > This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. > > Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. > > This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. > > Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. > > See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Suggest try/catch Throwable in upcallStub javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4396/files - new: https://git.openjdk.java.net/jdk/pull/4396/files/a9e652e7..fd691628 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4396&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4396&range=03-04 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4396/head:pull/4396 PR: https://git.openjdk.java.net/jdk/pull/4396 From darcy at openjdk.java.net Tue Jun 8 17:58:43 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Jun 2021 17:58:43 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v6] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 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 18 additional commits since the last revision: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Update symbols for JDK 17 b25. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/f12e9650...15479c92 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4175/files - new: https://git.openjdk.java.net/jdk/pull/4175/files/34480e50..15479c92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=04-05 Stats: 5201 lines in 96 files changed: 2786 ins; 1026 del; 1389 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From weijun at openjdk.java.net Tue Jun 8 18:26:13 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 8 Jun 2021 18:26:13 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: <6Cbsgd3M-d5WTqHG4ztUx3SEnsVrrGOT-Qk0CGQ1F9o=.5bbf554f-740e-47b1-abc2-0ee7d4171f2b@github.com> On Tue, 8 Jun 2021 17:15:29 GMT, Alan Bateman wrote: >> I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. >> >> As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. > >> I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. >> >> As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. > > WeakHashMap access needs synchronization. Whether we need to cache to avoid excessive warnings isn't clear. If the SM is enabled once and never disabled/re-enabled then caching isn't interesting. On the other hand if there are programs that are enabling/disabling to execute subsets of code then maybe it is. Maybe we should just drop this and see if there is any feedback on the repeated warning? Not sure what you meant by "WeakHashMap access synchronization", it's just a noun without any other parts. Do you think synchronization is necessary? For the cache, I'm OK to drop it at the moment. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From alanb at openjdk.java.net Tue Jun 8 18:31:18 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 8 Jun 2021 18:31:18 GMT Subject: RFR: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: <6Cbsgd3M-d5WTqHG4ztUx3SEnsVrrGOT-Qk0CGQ1F9o=.5bbf554f-740e-47b1-abc2-0ee7d4171f2b@github.com> References: <6Cbsgd3M-d5WTqHG4ztUx3SEnsVrrGOT-Qk0CGQ1F9o=.5bbf554f-740e-47b1-abc2-0ee7d4171f2b@github.com> Message-ID: On Tue, 8 Jun 2021 18:22:55 GMT, Weijun Wang wrote: >>> I thought about that but not sure of performance impact. Is the worst problem that more than one warnings will be printed for a single caller? It's not really harmless. >>> >>> As for the frame, if the warning message only contain the caller class name and its code source, why is it worth using a key of multiple frames? The message will look the same. >> >> WeakHashMap access needs synchronization. Whether we need to cache to avoid excessive warnings isn't clear. If the SM is enabled once and never disabled/re-enabled then caching isn't interesting. On the other hand if there are programs that are enabling/disabling to execute subsets of code then maybe it is. Maybe we should just drop this and see if there is any feedback on the repeated warning? > > Not sure what you meant by "WeakHashMap access synchronization", it's just a noun without any other parts. Do you think synchronization is necessary? > > For the cache, I'm OK to drop it at the moment. I think it would be simpler to start out without the caller cache. Sorry the sentence got garbled, I was trying to repeat what I said above that WeakHashMap is not synchronized so you would need to add synchronization to use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From jvernee at openjdk.java.net Tue Jun 8 18:32:36 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 18:32:36 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v3] In-Reply-To: References: Message-ID: > This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. > > The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. > > I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. > > Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. > > Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html > > Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Improve help message. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3971/files - new: https://git.openjdk.java.net/jdk/pull/3971/files/cbd6e81b..c4cfe847 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3971&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3971&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3971/head:pull/3971 PR: https://git.openjdk.java.net/jdk/pull/3971 From jvernee at openjdk.java.net Tue Jun 8 18:32:36 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 8 Jun 2021 18:32:36 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 17:28:21 GMT, Alan Bateman wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Update error message > > This all looks reasonable, I just wonder if the --validate description in the help output should provide a brief summary on what it does check. We can add to it as some validation is added. Without it then people will make assumptions on what it does. @AlanBateman Thanks for the suggestion. I think adding a description is good idea. I initially left the description vague, so that the behavior could be more easily amended. But, on second thought, such changes would seemingly require no less review, so I think it's better to include a description, as suggested. I've updated the description to say the following: \ --validate Validate a jar. This process will validate that the API\n\ \ exported by a multi-release jar is consistent across all\n\ \ different release versions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3971 From psandoz at openjdk.java.net Tue Jun 8 19:28:21 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 8 Jun 2021 19:28:21 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) [v5] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 17:34:58 GMT, Jorn Vernee wrote: >> Hi, >> >> ~This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395~ >> >> This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. >> >> Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. >> >> This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. >> >> Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. >> >> See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 >> >> Thanks, >> Jorn >> >> Testing: `jdk_foreign` test suite. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Suggest try/catch Throwable in upcallStub javadoc test/jdk/java/foreign/TestUpcallException.java line 70: > 68: Process process = new ProcessBuilder() > 69: .command( > 70: Paths.get(Utils.TEST_JDK) You might find `jdk.test.lib.JDKToolLauncher` useful. ------------- PR: https://git.openjdk.java.net/jdk/pull/4396 From psandoz at openjdk.java.net Tue Jun 8 19:40:11 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 8 Jun 2021 19:40:11 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled (Pt. 2) [v5] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 17:34:58 GMT, Jorn Vernee wrote: >> Hi, >> >> ~This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395~ >> >> This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. >> >> Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. >> >> This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. >> >> Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. >> >> See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 >> >> Thanks, >> Jorn >> >> Testing: `jdk_foreign` test suite. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Suggest try/catch Throwable in upcallStub javadoc I think this approach makes sense given the native code cannot react to the exception, possibly resulting in undefined behavior. We might be able to better check upcall handles if they declare they throw and reject them, but it's tricky to nail down the exact conditions, so better to defer and spend more time getting it right. (Perhaps one day we might be able to reflect over code and do more detailed analysis.) ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4396 From herrick at openjdk.java.net Tue Jun 8 19:50:22 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 8 Jun 2021 19:50:22 GMT Subject: RFR: 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages [v2] In-Reply-To: References: <1gp-hzi2Nf3kS_KBzd5rLHNpDTffoxfA1e9IaT-5zZI=.4d8c4875-6d5d-46a5-831c-0a91a673309b@github.com> Message-ID: On Tue, 8 Jun 2021 17:25:46 GMT, Alexey Semenyuk wrote: >> ?ages > > Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8264144 > - 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4415 From herrick at openjdk.java.net Tue Jun 8 19:50:28 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 8 Jun 2021 19:50:28 GMT Subject: Integrated: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote: > JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR This pull request has now been integrated. Changeset: 51e8201e Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/51e8201eb5a66a8fbbff21194fd35389343baee1 Stats: 69 lines in 2 files changed: 67 ins; 0 del; 2 mod 8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/4306 From bchristi at openjdk.java.net Tue Jun 8 21:11:22 2021 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 8 Jun 2021 21:11:22 GMT Subject: RFR: 8264859: Implement Context-Specific Deserialization Filters [v15] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 14:26:43 GMT, Roger Riggs wrote: >> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. >> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional >> configuration mechanisms and filter utilities. >> >> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: >> http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Clarify exceptions that occur if initializing the filter factory from jdk.serialFilterFactory fails Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From almatvee at openjdk.java.net Tue Jun 8 21:52:21 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 8 Jun 2021 21:52:21 GMT Subject: RFR: 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages [v2] In-Reply-To: References: <1gp-hzi2Nf3kS_KBzd5rLHNpDTffoxfA1e9IaT-5zZI=.4d8c4875-6d5d-46a5-831c-0a91a673309b@github.com> Message-ID: On Tue, 8 Jun 2021 17:25:46 GMT, Alexey Semenyuk wrote: >> ?ages > > Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8264144 > - 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4415 From asemenyuk at openjdk.java.net Tue Jun 8 22:24:20 2021 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Tue, 8 Jun 2021 22:24:20 GMT Subject: Integrated: 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages In-Reply-To: <1gp-hzi2Nf3kS_KBzd5rLHNpDTffoxfA1e9IaT-5zZI=.4d8c4875-6d5d-46a5-831c-0a91a673309b@github.com> References: <1gp-hzi2Nf3kS_KBzd5rLHNpDTffoxfA1e9IaT-5zZI=.4d8c4875-6d5d-46a5-831c-0a91a673309b@github.com> Message-ID: <4-nzKDqAlFd2L8RlW2rZ6Ezr6_Ed09SAasiFXmFeY_Y=.30417156-02fa-48b3-98fe-9410814a0700@github.com> On Tue, 8 Jun 2021 16:45:27 GMT, Alexey Semenyuk wrote: > ?ages This pull request has now been integrated. Changeset: bcaa2cb1 Author: Alexey Semenyuk URL: https://git.openjdk.java.net/jdk/commit/bcaa2cb154ae5d23a067f6e38a19a21eef8fe8e8 Stats: 115 lines in 5 files changed: 114 ins; 0 del; 1 mod 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages Reviewed-by: herrick, almatvee ------------- PR: https://git.openjdk.java.net/jdk/pull/4415 From lancea at openjdk.java.net Tue Jun 8 22:46:16 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Jun 2021 22:46:16 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v3] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 18:32:36 GMT, Jorn Vernee wrote: >> This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. >> >> The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. >> >> I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. >> >> Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. >> >> Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html >> >> Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Improve help message. The changes look good ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3971 From psandoz at openjdk.java.net Tue Jun 8 23:35:29 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 8 Jun 2021 23:35:29 GMT Subject: RFR: 8268353: Test libsvml.so is and is not present in jdk image Message-ID: Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. ------------- Commit messages: - Improve test. - Test for linux and windows - 8268353: Test libsvml.so is and is not present in jdk image Changes: https://git.openjdk.java.net/jdk/pull/4421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4421&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268353 Stats: 99 lines in 2 files changed: 96 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4421/head:pull/4421 PR: https://git.openjdk.java.net/jdk/pull/4421 From joehw at openjdk.java.net Wed Jun 9 00:37:20 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 9 Jun 2021 00:37:20 GMT Subject: Integrated: 8264766: ClassCastException during template compilation (Variable cannot be cast to Param) In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 18:49:19 GMT, Joe Wang wrote: > Fixes the addVariable/addParam methods in the SymbolTable to check types before casting. This pull request has now been integrated. Changeset: 1c3932f3 Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/1c3932f3d5ec47678f55769cb6a9f657ace411c6 Stats: 70 lines in 2 files changed: 64 ins; 0 del; 6 mod 8264766: ClassCastException during template compilation (Variable cannot be cast to Param) Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/4398 From github.com+19194678+scientificware at openjdk.java.net Wed Jun 9 00:42:35 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Wed, 9 Jun 2021 00:42:35 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home [v2] In-Reply-To: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> Message-ID: <9LCwJ9Y4oQbnZ452lIMOwF3TgmCaJ89Yb7yz4p-A2vU=.d31b14af-4c43-4806-879b-e2e2a1c3799c@github.com> > This concerns [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). > > In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. > > So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. > > The expected value is `"Must set property 'dtd_home'"` > > And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? ScientificWare has updated the pull request incrementally with one additional commit since the last revision: Changes to keep home_dtd null check. As suggested in conversation moving `+ File.separator` is more elegant than changing the `null` check. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3626/files - new: https://git.openjdk.java.net/jdk/pull/3626/files/94c97f14..d1a6727e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3626&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3626&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3626.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3626/head:pull/3626 PR: https://git.openjdk.java.net/jdk/pull/3626 From github.com+19194678+scientificware at openjdk.java.net Wed Jun 9 00:42:36 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Wed, 9 Jun 2021 00:42:36 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home [v2] In-Reply-To: References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> Message-ID: On Tue, 8 Jun 2021 12:37:27 GMT, Erik Joelsson wrote: >> ScientificWare has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes to keep home_dtd null check. >> >> As suggested in conversation moving `+ File.separator` is more elegant than changing the `null` check. > > make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java line 287: > >> 285: >> 286: String dtd_home = System.getProperty("dtd_home") + File.separator; >> 287: if (dtd_home.equals("null" + File.separator)) { > > dtd_home is only used in one location, so instead of changing this null check, maybe just move the "+ File.separator" to line 295? You are right. Thanks for this suggestion and reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From github.com+19194678+scientificware at openjdk.java.net Wed Jun 9 00:47:19 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Wed, 9 Jun 2021 00:47:19 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home [v2] In-Reply-To: <9LCwJ9Y4oQbnZ452lIMOwF3TgmCaJ89Yb7yz4p-A2vU=.d31b14af-4c43-4806-879b-e2e2a1c3799c@github.com> References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> <9LCwJ9Y4oQbnZ452lIMOwF3TgmCaJ89Yb7yz4p-A2vU=.d31b14af-4c43-4806-879b-e2e2a1c3799c@github.com> Message-ID: <6Ymvmr00c8Dd7eNaN6CdEETNj4L3FJVg6JVv6pOsBuc=.26891d38-a497-43c5-a33b-3a8353780461@github.com> On Wed, 9 Jun 2021 00:42:35 GMT, ScientificWare wrote: >> This concerns [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). >> >> In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. >> >> So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. >> >> The expected value is `"Must set property 'dtd_home'"` >> >> And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? > > ScientificWare has updated the pull request incrementally with one additional commit since the last revision: > > Changes to keep home_dtd null check. > > As suggested in conversation moving `+ File.separator` is more elegant than changing the `null` check. Submit suggested changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From sviswanathan at openjdk.java.net Wed Jun 9 00:59:19 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 9 Jun 2021 00:59:19 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3] In-Reply-To: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> References: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> Message-ID: On Tue, 8 Jun 2021 00:30:38 GMT, Scott Gibbons wrote: >> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. >> >> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. >> >> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. >> >> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. >> >> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. >> >> >> Benchmark Name | Base Score | Optimized Score | Gain >> -- | -- | -- | -- >> testBase64Decode size 1 | 15.36 | 15.32 | 1.00 >> testBase64Decode size 3 | 17.00 | 16.72 | 1.02 >> testBase64Decode size 7 | 20.60 | 18.82 | 1.09 >> testBase64Decode size 32 | 34.21 | 26.77 | 1.28 >> testBase64Decode size 64 | 54.43 | 38.35 | 1.42 >> testBase64Decode size 80 | 66.40 | 48.34 | 1.37 >> testBase64Decode size 96 | 73.16 | 52.90 | 1.38 >> testBase64Decode size 112 | 84.93 | 51.82 | 1.64 >> testBase64Decode size 512 | 288.81 | 32.04 | 9.01 >> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 >> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 >> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 >> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 >> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 >> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 >> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 >> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 >> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 >> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 >> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 >> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 >> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 >> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 >> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 >> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 >> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 >> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 >> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 >> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 >> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 >> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 >> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 >> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 >> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 >> testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 >> testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 > > Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Fixing review comments. Adding notes about isMIME parameter for other architectures; clarifying decodeBlock comments. @asgibbons Thanks a lot for contributing this. The performance gain is impressive. I have some minor comments. Please take a look. src/hotspot/cpu/x86/assembler_x86.cpp line 4555: > 4553: void Assembler::evpmaddubsw(XMMRegister dst, XMMRegister src1, XMMRegister src2, int vector_len) { > 4554: assert(VM_Version::supports_avx512bw(), ""); > 4555: InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true); This instruction is also supported on AVX platforms. The assert check could be as follows: assert(vector_len == AVX_128bit? VM_Version::supports_avx() : vector_len == AVX_256bit? VM_Version::supports_avx2() : vector_len == AVX_512bit? VM_Version::supports_avx512bw() : 0, ""); Accordingly the instruction could be named as vpmaddubsw. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5688: > 5686: address base64_vbmi_lookup_lo_addr() { > 5687: __ align(64, (unsigned long) __ pc()); > 5688: StubCodeMark mark(this, "StubRoutines", "lookup_lo"); It will be good to add base64 to the StubCodeMark name for this and all the tables. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5983: > 5981: // calculate length from offsets > 5982: __ movq(length, end_offset); > 5983: __ subq(length, start_offset); These are 32bit, so movl, subl instead of movq, subq. Similar for all length relates instructions below. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5987: > 5985: > 5986: // If AVX512 VBMI not supported, just compile non-AVX code > 5987: if(VM_Version::supports_avx512_vbmi()) { Need to also check for VM_Version::supports_avx512bw() support. Could you please check if VM_Version::supports_avx512dq is needed as well? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6134: > 6132: __ subq(length, 64); > 6133: __ addq(source, 64); > 6134: __ addq(dest, 48); All address related instructions here and below could use addptr, subptr etc. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6273: > 6271: > 6272: __ shrq(length, 2); // Multiple of 4 bytes only - length is # 4-byte chunks > 6273: __ cmpq(length, 0); Should these be shrl, cmpl? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6278: > 6276: // Set up src and dst pointers properly > 6277: __ addq(source, start_offset); // Initial offset > 6278: __ addq(dest, dp); The convention is to use addptr for pointers. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6284: > 6282: __ shll(isURL, 8); // index into decode table based on isURL > 6283: __ lea(decode_table, ExternalAddress(StubRoutines::x86::base64_decoding_table_addr())); > 6284: __ addq(decode_table, isURL); addptr here. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6297: > 6295: __ orl(byte1, byte4); > 6296: > 6297: __ incrementq(source, 4); addptr here. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6317: > 6315: __ load_signed_byte(byte4, Address(source, RegisterOrConstant(), Address::times_1, 3)); > 6316: __ load_signed_byte(byte3, Address(decode_table, byte3, Address::times_1, 0)); > 6317: __ load_signed_byte(byte4, Address(decode_table, byte4, Address::times_1, 0)); You could use Address(base, offset) form directly here and other places: e.g. Address (source, 1) instead of Address(source, RegisterOrConstant(), Address::times_1, 1). src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6329: > 6327: __ subq(dest, rax); // Number of bytes converted > 6328: __ movq(rax, dest); > 6329: __ pop(rbx); subptr, movptr here. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7627: > 7625: StubRoutines::x86::_right_shift_mask = base64_right_shift_mask_addr(); > 7626: StubRoutines::_base64_encodeBlock = generate_base64_encodeBlock(); > 7627: if (VM_Version::supports_avx512_vbmi()) { Need to add avx512bw check here also. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7628: > 7626: StubRoutines::_base64_encodeBlock = generate_base64_encodeBlock(); > 7627: if (VM_Version::supports_avx512_vbmi()) { > 7628: StubRoutines::x86::_lookup_lo = base64_vbmi_lookup_lo_addr(); It would be good to add base64 to these names. ------------- PR: https://git.openjdk.java.net/jdk/pull/4368 From david.holmes at oracle.com Wed Jun 9 01:10:24 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Jun 2021 11:10:24 +1000 Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: <745faa5c-e2e6-19c8-308a-9e3f9041905e@oracle.com> On 8/06/2021 11:40 pm, Thomas Stuefe wrote: > On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote: > >>> ?d on macOS >>> >>> This patch simply round up the specified stack size to multiple of the system page size. >>> >>> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >>> >>> ```code:java >>> public class StackLeak { >>> public int depth = 0; >>> public void stackLeak() { >>> depth++; >>> stackLeak(); >>> } >>> >>> public static void main(String[] args) { >>> var test = new StackLeak(); >>> try { >>> test.stackLeak(); >>> } catch (Throwable e) { >>> System.out.println(test.depth); >>> } >>> } >>> } >> >> Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Cast type >> - Merge >> - Change java -X output for -Xss >> - Merge >> - Only try to round-up when current value failed >> - Avoid overflow on page size >> - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS > > Please make sure the failing tests have nothing to do with your patch. `gc/shenandoah/compiler/TestLinkToNativeRBP.java` > sounds at least suggestive. warning: using incubating module(s): jdk.incubator.foreign /home/runner/work/jdk/jdk/test/hotspot/jtreg/gc/shenandoah/compiler/TestLinkToNativeRBP.java:42: error: cannot find symbol import jdk.incubator.foreign.LibraryLookup; Looks like shenandoah test was not updated for latest Foreign changes. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4256 > From dholmes at openjdk.java.net Wed Jun 9 01:10:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Jun 2021 01:10:12 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v6] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: <4QNBKIaeKr7dRQAmhoSeKnkjEgShi345K7KFDprAbBs=.13be4e82-6ff3-4554-9f82-a8eb9b0cb890@github.com> On Tue, 8 Jun 2021 16:53:38 GMT, Henry Jen wrote: >> ?d on macOS >> >> This patch simply round up the specified stack size to multiple of the system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output. >> >> ```code:java >> public class StackLeak { >> public int depth = 0; >> public void stackLeak() { >> depth++; >> stackLeak(); >> } >> >> public static void main(String[] args) { >> var test = new StackLeak(); >> try { >> test.stackLeak(); >> } catch (Throwable e) { >> System.out.println(test.depth); >> } >> } >> } > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Update help text Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From dholmes at openjdk.java.net Wed Jun 9 02:10:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Jun 2021 02:10:23 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v6] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 17:58:43 GMT, Joe Darcy wrote: >> 8267630: Start of release updates for JDK 18 > > 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 18 additional commits since the last revision: > > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Update symbols for JDK 17 b25. > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/edba5b0d...15479c92 Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4175 From darcy at openjdk.java.net Wed Jun 9 03:26:33 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 9 Jun 2021 03:26:33 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v7] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Update symbols for JDK 17 b25. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/51e8201e...ee6bd4de ------------- Changes: https://git.openjdk.java.net/jdk/pull/4175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=06 Stats: 5334 lines in 63 files changed: 5292 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From stuefe at openjdk.java.net Wed Jun 9 04:04:16 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Jun 2021 04:04:16 GMT Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5] In-Reply-To: References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com> Message-ID: <4W-aQGRI_4GBu_tU-VUp5OK9XQsh5awazx6Qlo2gbJw=.28b0fed0-00e4-4bf9-8ce9-d4da22ae3683@github.com> On Tue, 8 Jun 2021 16:45:12 GMT, Henry Jen wrote: >> src/java.base/unix/native/libjli/java_md.c line 666: >> >>> 664: return page_size * pages; >>> 665: } >>> 666: } >> >> Could probably be shortened to something like this: >> >> >> size_t pagesize = (size_t)sysconf(_SC_PAGESIZE); >> return (stack_size + (pagesize - 1)) & ~(pagesize - 1); >> >> >> or, if you insist on checking for SIZE_MAX: >> >> >> size_t pagesize = (size_t)sysconf(_SC_PAGESIZE); >> size_t max = SIZE_MAX - pagesize; >> return stack_size <= max ? (stack_size + (pagesize - 1)) & ~(pagesize - 1) : max; >> >> >> (I see David requested this, so this is fine, though passing SIZE_MAX to this function will quite likely fail anyway :) > > While sysconf(_SC_PAGESIZE) is most likely(if not always) be power of 2, it's not a constant we know for sure here and this is not critical path for performance, thus I didn't take that approach. My concern was not performance but brevity, especially since you add the same function twice. And about using the same logic for aligning up as we do within hotspot (see align.hpp). You also mix up size_t and long (signed vs unsigned, and potentially different sizes) - there is nothing obvious wrong with that but I would at least consistently use size_t here. ------------- PR: https://git.openjdk.java.net/jdk/pull/4256 From alanb at openjdk.java.net Wed Jun 9 06:18:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 9 Jun 2021 06:18:13 GMT Subject: RFR: 8240349: jlink should not leave partial image output directory on failure [v2] In-Reply-To: References: Message-ID: <97QZOAyG5wBJcqNIIDA0qCgzXiuLbn_B8bCkUP4IPvY=.b55a4bff-b042-41e5-9013-b440ab23aba8@github.com> On Tue, 8 Jun 2021 14:29:38 GMT, Athijegannathan Sundararajan wrote: >> jlink should clean up output directory on any failure. should not leave partially filled output. > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > Fixed resouce closing issue for lib/moduls file. Pre-existing output directory should not be deleted when exiting. New version looks good. Good spot by Jorn that ImageFileCreator wasn't closing. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4386 From sundar at openjdk.java.net Wed Jun 9 06:38:21 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Wed, 9 Jun 2021 06:38:21 GMT Subject: Integrated: 8240349: jlink should not leave partial image output directory on failure In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 11:00:00 GMT, Athijegannathan Sundararajan wrote: > jlink should clean up output directory on any failure. should not leave partially filled output. This pull request has now been integrated. Changeset: 4d1cf51b Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/jdk/commit/4d1cf51b1d4a5e812c9f78b0104e40fbc4883a6c Stats: 71 lines in 5 files changed: 66 ins; 0 del; 5 mod 8240349: jlink should not leave partial image output directory on failure Reviewed-by: jlaskey, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/4386 From yyang at openjdk.java.net Wed Jun 9 08:17:40 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 9 Jun 2021 08:17:40 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v12] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with two additional commits since the last revision: - c1 can not handle 0 constant value when using cmp - fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/289d752c..63f1c30d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=10-11 Stats: 51 lines in 1 file changed: 23 ins; 17 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From iignatyev at openjdk.java.net Wed Jun 9 08:50:24 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 9 Jun 2021 08:50:24 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 01:00:53 GMT, Leonid Mesnik wrote: >> EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > spaces updated. Changes requested by iignatyev (Reviewer). test/failure_handler/src/share/classes/jdk/test/failurehandler/GathererFactory.java line 32: > 30: import java.io.FileWriter; > 31: import java.io.PrintWriter; > 32: import java.nio.file.Files; I don't see why we need these 3 new imports. test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java line 28: > 26: import jdk.test.failurehandler.action.ActionSet; > 27: import jdk.test.failurehandler.action.ActionHelper; > 28: import jdk.test.failurehandler.action.PatternAction; redundant import test/failure_handler/src/share/conf/linux.properties line 62: > 60: cores=native.gdb > 61: native.gdb.app=gdb > 62: native.gdb.args=%java\0-c\0%p\0-batch\0-ex\0thread apply all backtrace could you please add a comment similar to the one in `common.properties` file? test/failure_handler/src/share/conf/mac.properties line 71: > 69: native.lldb.app=lldb > 70: native.lldb.delimiter=\0 > 71: native.lldb.args=--core\0%p\0%java\0-o\0thread backtrace all\0-o\0quit could you please add a comment similar to the one in common.properties file? test/failure_handler/src/share/conf/mac.properties line 72: > 70: native.lldb.delimiter=\0 > 71: native.lldb.args=--core\0%p\0%java\0-o\0thread backtrace all\0-o\0quit > 72: native.lldb.params.timeout=3600000 why does `lldb` require an increases timeout, but `gdb` and `jhsdb` do not? ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From jfranck at openjdk.java.net Wed Jun 9 08:52:17 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 9 Jun 2021 08:52:17 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v3] In-Reply-To: References: Message-ID: On Sat, 8 May 2021 09:51:46 GMT, Rafael Winterhalter wrote: >> This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. > > Rafael Winterhalter 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. Link to CSR: https://bugs.openjdk.java.net/browse/JDK-8266768 ------------- PR: https://git.openjdk.java.net/jdk/pull/3892 From yyang at openjdk.java.net Wed Jun 9 08:53:40 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 9 Jun 2021 08:53:40 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: more comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/63f1c30d..87d8b399 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=11-12 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From jfranck at openjdk.java.net Wed Jun 9 08:59:15 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 9 Jun 2021 08:59:15 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v3] In-Reply-To: References: Message-ID: On Sat, 8 May 2021 09:51:46 GMT, Rafael Winterhalter wrote: >> This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. > > Rafael Winterhalter 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. Changes requested by jfranck (Reviewer). test/jdk/java/lang/annotation/AnnotationTypeMismatchException/AnnotationTypeMismatchTest.java line 27: > 25: * @test > 26: * @bug 8228988 > 27: * @bug 8266598 @bug numbers are usually on the same line: "* @bug 8228988 8266598" test/jdk/java/lang/annotation/AnnotationTypeMismatchException/EnumTypeMismatchTest.java line 27: > 25: * @test > 26: * @bug 8228988 > 27: * @bug 8266598 Same, here, single line ------------- PR: https://git.openjdk.java.net/jdk/pull/3892 From winterhalter at openjdk.java.net Wed Jun 9 10:02:35 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 10:02:35 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v4] In-Reply-To: References: Message-ID: > This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. Rafael Winterhalter 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: 8266598: Exception values for AnnotationTypeMismatchException are not always informative ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3892/files - new: https://git.openjdk.java.net/jdk/pull/3892/files/9acdb5d0..064334c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3892&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3892&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3892.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3892/head:pull/3892 PR: https://git.openjdk.java.net/jdk/pull/3892 From winterhalter at openjdk.java.net Wed Jun 9 10:02:36 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 10:02:36 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v3] In-Reply-To: References: Message-ID: <6MvRSVQbfX-YXqA5-eY9QAkwHKcx9deD_kCjdeisqTo=.e7b47384-8199-4a63-986f-fc8d973476b9@github.com> On Sat, 8 May 2021 09:51:46 GMT, Rafael Winterhalter wrote: >> This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. > > Rafael Winterhalter 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. Moved the bug number to the same line on both tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/3892 From pconcannon at openjdk.java.net Wed Jun 9 10:19:53 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 9 Jun 2021 10:19:53 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v4] In-Reply-To: <618GzC0qITXnu_SQ0E-V5FjpoW5nNj1ov7w1vjlemD8=.35c01194-1e74-4172-806e-d85d4aff02df@github.com> References: <618GzC0qITXnu_SQ0E-V5FjpoW5nNj1ov7w1vjlemD8=.35c01194-1e74-4172-806e-d85d4aff02df@github.com> Message-ID: On Wed, 2 Jun 2021 16:10:19 GMT, R?mi Forax wrote: >> Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8268124 >> - 8268124: small refactoring; fixed misplaced comment and added missing lambda operator >> - Merge remote-tracking branch 'origin/master' into JDK-8268124 >> - 8268124: Update java.lang to use switch expressions > > src/java.base/share/classes/java/lang/invoke/MemberName.java line 331: > >> 329: assert(false) : this+" != "+MethodHandleNatives.refKindName((byte)originalRefKind); >> 330: yield true; >> 331: } > > this code always yield true, better to check if the assert are enabled, do the switch in that case and always return true Thanks for your suggestion. I've incorporated it into commit a8706b0 ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From pconcannon at openjdk.java.net Wed Jun 9 10:19:47 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 9 Jun 2021 10:19:47 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v4] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: small refactoring; fixed misplaced comment and added missing lambda operator - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: Update java.lang to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4312/files - new: https://git.openjdk.java.net/jdk/pull/4312/files/a8706b02..7907f3eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=02-03 Stats: 463928 lines in 821 files changed: 455007 ins; 5063 del; 3858 mod Patch: https://git.openjdk.java.net/jdk/pull/4312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4312/head:pull/4312 PR: https://git.openjdk.java.net/jdk/pull/4312 From pconcannon at openjdk.java.net Wed Jun 9 10:25:35 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 9 Jun 2021 10:25:35 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v5] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request incrementally with two additional commits since the last revision: - 8268124: moved cases into separate lines in DirectMethodHandleDescImpl part II - 8268124: moved cases onto separate lines in DirectMethodHandleDescImpl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4312/files - new: https://git.openjdk.java.net/jdk/pull/4312/files/7907f3eb..df5b34e5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=03-04 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/4312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4312/head:pull/4312 PR: https://git.openjdk.java.net/jdk/pull/4312 From pconcannon at openjdk.java.net Wed Jun 9 10:25:36 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 9 Jun 2021 10:25:36 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 17:04:58 GMT, Mandy Chung wrote: >> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8268124: small refactoring; fixed misplaced comment and added missing lambda operator > > src/java.base/share/classes/java/lang/constant/DirectMethodHandleDescImpl.java line 138: > >> 136: public String lookupDescriptor() { >> 137: return switch (kind) { >> 138: case VIRTUAL, SPECIAL, > > Nit: I prefer to have each case in a separate line (in this switch and also the switch in `resolveConstantDesc`. Hi Mandy. Thanks for your suggestion. I've now moved each case onto its own line. Please see ccc9db7 / df5b34e ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From lancea at openjdk.java.net Wed Jun 9 10:30:16 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 9 Jun 2021 10:30:16 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v5] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 10:25:35 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with two additional commits since the last revision: > > - 8268124: moved cases into separate lines in DirectMethodHandleDescImpl part II > - 8268124: moved cases onto separate lines in DirectMethodHandleDescImpl Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 9 10:32:38 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 9 Jun 2021 10:32:38 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v6] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: <5DP52RlB_Dtcy30JuehAzoGtvEXryh10kqEYoYZvN9k=.1229b4f2-f7f5-4f0b-9d40-947cbe3672f1@github.com> > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? 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: - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - 8268113: Inline local vars where reasonable - 8268113: Delegate to Double.hashCode() - 8268113: Re-use Long.hashCode() where possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/76af35c6..3a7b5515 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=04-05 Stats: 5577 lines in 149 files changed: 3466 ins; 1405 del; 706 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From mcimadamore at openjdk.java.net Wed Jun 9 10:41:31 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 9 Jun 2021 10:41:31 GMT Subject: RFR: 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] Message-ID: This tests fails intermittently but very rarely, on Windows it seems. The subtest in question is `testLockSharedMultiThread`. This test is spawning a number of threads, each of which: * increments a counter atomically * acquire scope * waits some time * release scope * decrement counter (in finally block) The main test thread tries (while the counter value is > 0) to repeatedly close the scope, and asserts that if the scope closes successfully, then the counter value should be exactly zero. Looking at the test closely, I realized there's an issue: the order in which counter is incremented and scope is acquired is wrong. As such it is possible for counter to be increased, but then for subsequent acquire to fail (e.g. if segment is already closed). This would lead to the main test thread to fail, as it would appear as if the segment has been closed successfully, but the counter value is not zero. The fix is to only increment the counter after a successful acquire. I have also tweaked the test so that it keeps trying closing the scope, even if the counter value reaches zero permanently (e.g. all other threads have completed). ------------- Commit messages: - Fix TestResourceScope locking test Changes: https://git.openjdk.java.net/jdk/pull/4427/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4427&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268428 Stats: 14 lines in 1 file changed: 6 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4427/head:pull/4427 PR: https://git.openjdk.java.net/jdk/pull/4427 From winterhalter at openjdk.java.net Wed Jun 9 10:52:49 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 10:52:49 GMT Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v2] In-Reply-To: References: Message-ID: > If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. Rafael Winterhalter 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: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3925/files - new: https://git.openjdk.java.net/jdk/pull/3925/files/55284e94..3e3eb032 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3925/head:pull/3925 PR: https://git.openjdk.java.net/jdk/pull/3925 From winterhalter at openjdk.java.net Wed Jun 9 10:52:51 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 10:52:51 GMT Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions In-Reply-To: References: Message-ID: On Fri, 7 May 2021 18:58:02 GMT, Rafael Winterhalter wrote: > If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. Link to CSR: https://bugs.openjdk.java.net/browse/JDK-8268447 ------------- PR: https://git.openjdk.java.net/jdk/pull/3925 From dfuchs at openjdk.java.net Wed Jun 9 10:57:15 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 9 Jun 2021 10:57:15 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v5] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 10:25:35 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with two additional commits since the last revision: > > - 8268124: moved cases into separate lines in DirectMethodHandleDescImpl part II > - 8268124: moved cases onto separate lines in DirectMethodHandleDescImpl Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From dfuchs at openjdk.java.net Wed Jun 9 11:03:12 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 9 Jun 2021 11:03:12 GMT Subject: RFR: 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] In-Reply-To: References: Message-ID: <0GtZdXFs3oVbC3QXMSiO58wcsJ5Q3z3FPyFhQZfFmY4=.207bcd95-11ac-471d-98b0-5c2c0daba95a@github.com> On Wed, 9 Jun 2021 10:33:34 GMT, Maurizio Cimadamore wrote: > This tests fails intermittently but very rarely, on Windows it seems. The subtest in question is `testLockSharedMultiThread`. This test is spawning a number of threads, each of which: > > * increments a counter atomically > * acquire scope > * waits some time > * release scope > * decrement counter (in finally block) > > The main test thread tries (while the counter value is > 0) to repeatedly close the scope, and asserts that if the scope closes successfully, then the counter value should be exactly zero. > > Looking at the test closely, I realized there's an issue: the order in which counter is incremented and scope is acquired is wrong. As such it is possible for counter to be increased, but then for subsequent acquire to fail (e.g. if segment is already closed). This would lead to the main test thread to fail, as it would appear as if the segment has been closed successfully, but the counter value is not zero. > > The fix is to only increment the counter after a successful acquire. I have also tweaked the test so that it keeps trying closing the scope, even if the counter value reaches zero permanently (e.g. all other threads have completed). I agree with the analysis and test code changes. Trivially you should also update the copyright years on this file. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4427 From winterhalter at openjdk.java.net Wed Jun 9 11:04:12 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 11:04:12 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: <89bBPA_oQYXFK4JL2qpIlRA7uuaBzSdvFZGuMxsM7eU=.1156b72f-499f-4fd2-a279-00e379fa5992@github.com> On Sun, 9 May 2021 21:59:29 GMT, Rafael Winterhalter wrote: > During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. Link to CSR: https://bugs.openjdk.java.net/browse/JDK-8268452 ------------- PR: https://git.openjdk.java.net/jdk/pull/3940 From mcimadamore at openjdk.java.net Wed Jun 9 11:34:33 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 9 Jun 2021 11:34:33 GMT Subject: RFR: 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] [v2] In-Reply-To: References: Message-ID: <6xptfMn1KOcQIg7K2yc4rksU-b_XlxiIPxzn-yQTVK0=.4b712a4e-a144-47be-8561-0d666fac483b@github.com> > This tests fails intermittently but very rarely, on Windows it seems. The subtest in question is `testLockSharedMultiThread`. This test is spawning a number of threads, each of which: > > * increments a counter atomically > * acquire scope > * waits some time > * release scope > * decrement counter (in finally block) > > The main test thread tries (while the counter value is > 0) to repeatedly close the scope, and asserts that if the scope closes successfully, then the counter value should be exactly zero. > > Looking at the test closely, I realized there's an issue: the order in which counter is incremented and scope is acquired is wrong. As such it is possible for counter to be increased, but then for subsequent acquire to fail (e.g. if segment is already closed). This would lead to the main test thread to fail, as it would appear as if the segment has been closed successfully, but the counter value is not zero. > > The fix is to only increment the counter after a successful acquire. I have also tweaked the test so that it keeps trying closing the scope, even if the counter value reaches zero permanently (e.g. all other threads have completed). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update wrong copyright date ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4427/files - new: https://git.openjdk.java.net/jdk/pull/4427/files/eb0c5d50..13f87671 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4427&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4427&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4427.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4427/head:pull/4427 PR: https://git.openjdk.java.net/jdk/pull/4427 From dfuchs at openjdk.java.net Wed Jun 9 11:34:33 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 9 Jun 2021 11:34:33 GMT Subject: RFR: 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] [v2] In-Reply-To: <6xptfMn1KOcQIg7K2yc4rksU-b_XlxiIPxzn-yQTVK0=.4b712a4e-a144-47be-8561-0d666fac483b@github.com> References: <6xptfMn1KOcQIg7K2yc4rksU-b_XlxiIPxzn-yQTVK0=.4b712a4e-a144-47be-8561-0d666fac483b@github.com> Message-ID: On Wed, 9 Jun 2021 11:31:52 GMT, Maurizio Cimadamore wrote: >> This tests fails intermittently but very rarely, on Windows it seems. The subtest in question is `testLockSharedMultiThread`. This test is spawning a number of threads, each of which: >> >> * increments a counter atomically >> * acquire scope >> * waits some time >> * release scope >> * decrement counter (in finally block) >> >> The main test thread tries (while the counter value is > 0) to repeatedly close the scope, and asserts that if the scope closes successfully, then the counter value should be exactly zero. >> >> Looking at the test closely, I realized there's an issue: the order in which counter is incremented and scope is acquired is wrong. As such it is possible for counter to be increased, but then for subsequent acquire to fail (e.g. if segment is already closed). This would lead to the main test thread to fail, as it would appear as if the segment has been closed successfully, but the counter value is not zero. >> >> The fix is to only increment the counter after a successful acquire. I have also tweaked the test so that it keeps trying closing the scope, even if the counter value reaches zero permanently (e.g. all other threads have completed). > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Update wrong copyright date Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4427 From jvernee at openjdk.java.net Wed Jun 9 11:41:14 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 9 Jun 2021 11:41:14 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 16:46:36 GMT, Vicente Romero wrote: > Please review this PR which is just syncing the implementation of DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the method's spec is that if the value of the `refKind` parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of `true` for its second argument, currently it is invoked with `false` regardless of the value of the `refKind` parameter > > TIA Looks good to me. ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4416 From rriggs at openjdk.java.net Wed Jun 9 12:33:28 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 9 Jun 2021 12:33:28 GMT Subject: Integrated: 8264859: Implement Context-Specific Deserialization Filters In-Reply-To: References: Message-ID: On Wed, 12 May 2021 13:58:44 GMT, Roger Riggs wrote: > JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415. > The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional > configuration mechanisms and filter utilities. > > javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`: > http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html This pull request has now been integrated. Changeset: 13d61804 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/13d618042112aa761ef256aa35ec0a8b808cd78b Stats: 2594 lines in 9 files changed: 2409 ins; 40 del; 145 mod 8264859: Implement Context-Specific Deserialization Filters Reviewed-by: bchristi, dfuchs, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/3996 From jvernee at openjdk.java.net Wed Jun 9 12:55:14 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 9 Jun 2021 12:55:14 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v3] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 18:32:36 GMT, Jorn Vernee wrote: >> This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. >> >> The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. >> >> I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. >> >> Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. >> >> Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html >> >> Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Improve help message. If the changes look good like this, please review the accompanying CSR for the command line option changes: https://bugs.openjdk.java.net/browse/JDK-8267402 Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/3971 From jfranck at openjdk.java.net Wed Jun 9 12:57:13 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Wed, 9 Jun 2021 12:57:13 GMT Subject: RFR: 8266598: Exception values for AnnotationTypeMismatchException are not always informative [v4] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 10:02:35 GMT, Rafael Winterhalter wrote: >> This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. > > Rafael Winterhalter 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: > > 8266598: Exception values for AnnotationTypeMismatchException are not always informative LGTM ------------- Marked as reviewed by jfranck (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3892 From alanb at openjdk.java.net Wed Jun 9 13:06:14 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 9 Jun 2021 13:06:14 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v3] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 18:32:36 GMT, Jorn Vernee wrote: >> This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. >> >> The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. >> >> I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. >> >> Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. >> >> Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html >> >> Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Improve help message. src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 241: > 239: \ --validate Validate a jar. This process will validate that the API\n\ > 240: \ exported by a multi-release jar is consistent across all\n\ > 241: \ different release versions. Thanks for the update. I see that that "jar archive" is used in some of the existing options so maybe tweak it to: Validate the contents of the jar archive. This option will validate that the API exported by ... ------------- PR: https://git.openjdk.java.net/jdk/pull/3971 From winterhalter at openjdk.java.net Wed Jun 9 13:24:16 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 13:24:16 GMT Subject: Integrated: 8266598: Exception values for AnnotationTypeMismatchException are not always informative In-Reply-To: References: Message-ID: On Wed, 5 May 2021 21:36:45 GMT, Rafael Winterhalter wrote: > This improves the messages that are provided by `AnnotationTypeMismatchException`s. The message provided by AnnotationTypeMismatchExceptions is deliberately undefined such that this should not break any contract. This pull request has now been integrated. Changeset: 7b1e4024 Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck URL: https://git.openjdk.java.net/jdk/commit/7b1e4024c02e6e831502e20cdbf54efb6240d12b Stats: 28 lines in 3 files changed: 15 ins; 3 del; 10 mod 8266598: Exception values for AnnotationTypeMismatchException are not always informative Reviewed-by: jfranck ------------- PR: https://git.openjdk.java.net/jdk/pull/3892 From jvernee at openjdk.java.net Wed Jun 9 13:43:40 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 9 Jun 2021 13:43:40 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v4] In-Reply-To: References: Message-ID: > This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. > > The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. > > I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. > > Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. > > Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html > > Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Update help message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3971/files - new: https://git.openjdk.java.net/jdk/pull/3971/files/c4cfe847..6efd89de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3971&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3971&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3971/head:pull/3971 PR: https://git.openjdk.java.net/jdk/pull/3971 From jvernee at openjdk.java.net Wed Jun 9 13:43:41 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 9 Jun 2021 13:43:41 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v3] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 13:02:50 GMT, Alan Bateman wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve help message. > > src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 241: > >> 239: \ --validate Validate a jar. This process will validate that the API\n\ >> 240: \ exported by a multi-release jar is consistent across all\n\ >> 241: \ different release versions. > > Thanks for the update. I see that that "jar archive" is used in some of the existing options so maybe tweak it to: > > Validate the contents of the jar archive. > This option will validate that the API exported by ... Done. FWIW, I also thought about using "jar file", but the jar tool can also take input from stdin, so that didn't seem appropriate. ------------- PR: https://git.openjdk.java.net/jdk/pull/3971 From alanb at openjdk.java.net Wed Jun 9 13:43:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 9 Jun 2021 13:43:41 GMT Subject: RFR: 8266835: Add a --validate option to the jar tool [v3] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 13:37:02 GMT, Jorn Vernee wrote: >> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 241: >> >>> 239: \ --validate Validate a jar. This process will validate that the API\n\ >>> 240: \ exported by a multi-release jar is consistent across all\n\ >>> 241: \ different release versions. >> >> Thanks for the update. I see that that "jar archive" is used in some of the existing options so maybe tweak it to: >> >> Validate the contents of the jar archive. >> This option will validate that the API exported by ... > > Done. > > FWIW, I also thought about using "jar file", but the jar tool can also take input from stdin, so that didn't seem appropriate. Yeah, there are inconsistencies. In other contexts we say "JAR file". In the usage output it has historically used "jar archive". ------------- PR: https://git.openjdk.java.net/jdk/pull/3971 From winterhalter at openjdk.java.net Wed Jun 9 13:46:04 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 13:46:04 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v2] In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: > During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3940/files - new: https://git.openjdk.java.net/jdk/pull/3940/files/aeae89ac..f126bc2d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=00-01 Stats: 607815 lines in 5193 files changed: 511783 ins; 75812 del; 20220 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940 From winterhalter at openjdk.java.net Wed Jun 9 13:46:28 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 13:46:28 GMT Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v3] In-Reply-To: References: Message-ID: > If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions ------------- Changes: https://git.openjdk.java.net/jdk/pull/3925/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=02 Stats: 130 lines in 2 files changed: 128 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3925/head:pull/3925 PR: https://git.openjdk.java.net/jdk/pull/3925 From mcimadamore at openjdk.java.net Wed Jun 9 13:56:13 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 9 Jun 2021 13:56:13 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled [v5] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 17:34:58 GMT, Jorn Vernee wrote: >> Hi, >> >> ~This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395~ >> >> This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. >> >> Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. >> >> This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. >> >> Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. >> >> See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 >> >> Thanks, >> Jorn >> >> Testing: `jdk_foreign` test suite. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Suggest try/catch Throwable in upcallStub javadoc Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4396 From winterhalter at openjdk.java.net Wed Jun 9 13:56:40 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Wed, 9 Jun 2021 13:56:40 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3] In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: > During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. Rafael Winterhalter 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 two new commits since the last revision: - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3940/files - new: https://git.openjdk.java.net/jdk/pull/3940/files/f126bc2d..4e14cbb9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940 From erikj at openjdk.java.net Wed Jun 9 14:16:15 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Jun 2021 14:16:15 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home [v2] In-Reply-To: <9LCwJ9Y4oQbnZ452lIMOwF3TgmCaJ89Yb7yz4p-A2vU=.d31b14af-4c43-4806-879b-e2e2a1c3799c@github.com> References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> <9LCwJ9Y4oQbnZ452lIMOwF3TgmCaJ89Yb7yz4p-A2vU=.d31b14af-4c43-4806-879b-e2e2a1c3799c@github.com> Message-ID: On Wed, 9 Jun 2021 00:42:35 GMT, ScientificWare wrote: >> This concerns [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). >> >> In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. >> >> So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. >> >> The expected value is `"Must set property 'dtd_home'"` >> >> And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? > > ScientificWare has updated the pull request incrementally with one additional commit since the last revision: > > Changes to keep home_dtd null check. > > As suggested in conversation moving `+ File.separator` is more elegant than changing the `null` check. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From pconcannon at openjdk.java.net Wed Jun 9 15:49:25 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 9 Jun 2021 15:49:25 GMT Subject: RFR: 8268469: Update java.time to use switch expressions Message-ID: Hi, Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? Kind regards, Patrick ------------- Commit messages: - 8268469: Update java.time to use switch expressions Changes: https://git.openjdk.java.net/jdk/pull/4433/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268469 Stats: 388 lines in 23 files changed: 15 ins; 97 del; 276 mod Patch: https://git.openjdk.java.net/jdk/pull/4433.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4433/head:pull/4433 PR: https://git.openjdk.java.net/jdk/pull/4433 From lancea at openjdk.java.net Wed Jun 9 16:17:12 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 9 Jun 2021 16:17:12 GMT Subject: RFR: 8268469: Update java.time to use switch expressions In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 15:41:59 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? > > Kind regards, > Patrick Updates look good Patrick ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4433 From naoto at openjdk.java.net Wed Jun 9 16:57:14 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 9 Jun 2021 16:57:14 GMT Subject: RFR: 8268469: Update java.time to use switch expressions In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 15:41:59 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? > > Kind regards, > Patrick Looks good overall. Some misplaced comments. Also, copyright years should be updated. src/java.base/share/classes/java/time/LocalDateTime.java line 1188: > 1186: case HOURS -> plusHours(amountToAdd); > 1187: case HALF_DAYS -> plusDays(amountToAdd / 256).plusHours((amountToAdd % 256) * 12); > 1188: default -> with(date.plus(amountToAdd, unit), time); // no overflow (256 is multiple of 2) The comment is misplaced. src/java.base/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java line 310: > 308: case HOURS -> plusHours(amountToAdd); > 309: case HALF_DAYS -> plusDays(amountToAdd / 256).plusHours((amountToAdd % 256) * 12); > 310: default -> with(date.plus(amountToAdd, unit), time); // no overflow (256 is multiple of 2) Misplaced comment here too. src/java.base/share/classes/java/time/format/SignStyle.java line 127: > 125: boolean parse(boolean positive, boolean strict, boolean fixedWidth) { > 126: return switch (ordinal()) { > 127: // valid if negative or (positive and lenient) The comment should apply only to the `case 0`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From dfuchs at openjdk.java.net Wed Jun 9 17:05:16 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 9 Jun 2021 17:05:16 GMT Subject: RFR: 8268469: Update java.time to use switch expressions In-Reply-To: References: Message-ID: <77duiMdW0OcTvKM8GHE9QSzauQK2JVPIRj2myEdqYKk=.467f310d-5c10-4f85-b222-a54b560aa9df@github.com> On Wed, 9 Jun 2021 15:41:59 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? > > Kind regards, > Patrick src/java.base/share/classes/java/time/Month.java line 491: > 489: case OCTOBER -> 274 + leap; > 490: case NOVEMBER -> 305 + leap; > 491: default -> 335 + leap; It would be better to keep `DECEMBER` here for clarity - even if only in a comment - e.g: case NOVEMBER -> 305 + leap; // otherwise (DECEMBER) default -> 335 + leap; src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java line 334: > 332: > 333: default -> with(isoDate.with(field, newValue)); > 334: }; My preference would be to keep the imbricated switch structure: it is not obvious whether this change is correct. Have you verified that `getChronology().range(chronoField).checkValidIntValue(newValue, chronoField);` is a no op when chronoField == ERA? src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 4992: > 4990: } > 4991: default -> throw new IllegalStateException("unreachable"); > 4992: }; Not sure I like the new version more than the old, as it seems to lead to more duplication. Maybe the 'Y' case should be tested before entering the switch - then the switch could be used to assign `var field = switch (chr) {...};` ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From mchung at openjdk.java.net Wed Jun 9 17:25:15 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Jun 2021 17:25:15 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 16:46:36 GMT, Vicente Romero wrote: > Please review this PR which is just syncing the implementation of DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the method's spec is that if the value of the `refKind` parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of `true` for its second argument, currently it is invoked with `false` regardless of the value of the `refKind` parameter > > TIA test/jdk/java/lang/constant/MethodHandleDescTest.java line 362: > 360: public void testKind() { > 361: for (Kind k : Kind.values()) { > 362: assertEquals(Kind.valueOf(k.refKind), Kind.valueOf(k.refKind, k.refKind == MethodHandleInfo.REF_invokeInterface)); Looks like the test does not verify the cases specified by `valueOf(int refKind, boolean isInterface)`. i.e. For most values of refKind, there is an exact match regardless of the value of isInterface except `REF_invokeStatic` and `REF_invokeSpecial`. Do you mind adding those cases? ------------- PR: https://git.openjdk.java.net/jdk/pull/4416 From jvernee at openjdk.java.net Wed Jun 9 18:18:20 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 9 Jun 2021 18:18:20 GMT Subject: Integrated: 8266835: Add a --validate option to the jar tool In-Reply-To: References: Message-ID: On Tue, 11 May 2021 10:51:18 GMT, Jorn Vernee wrote: > This patch adds a `--validate` option to the jar tool which can be used to validate a jar file that might be malformed. For instance, if a jar is a multi-release jar, it is malformed if different versions expose different APIs. > > The implementation is straight forward since there already exists validation logic that is run when creating or updating a jar. This patch just exposes that logic directly under a new command line flag. > > I've enhanced the existing ApiValidatorTest to also create malformed jars using the zip file APIs (the jar tool does not output malformed jars) and run them through `jar --validate`. > > Note that while the jdk's jar tool does not output malformed jars, third-party archiving tools might, or the jar could have been manually edited. > > Some prior discussion here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077420.html > > Testing: running jdk/tools/jar test suite locally, tier 1-3 (in progress), manual testing. This pull request has now been integrated. Changeset: 79010f22 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/79010f2254aee8459523800d6049f396b055f123 Stats: 150 lines in 4 files changed: 117 ins; 4 del; 29 mod 8266835: Add a --validate option to the jar tool Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/3971 From lmesnik at openjdk.java.net Wed Jun 9 18:55:15 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 9 Jun 2021 18:55:15 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 08:42:13 GMT, Igor Ignatyev wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> spaces updated. > > test/failure_handler/src/share/classes/jdk/test/failurehandler/GathererFactory.java line 32: > >> 30: import java.io.FileWriter; >> 31: import java.io.PrintWriter; >> 32: import java.nio.file.Files; > > I don't see why we need these 3 new imports. fixed > test/failure_handler/src/share/classes/jdk/test/failurehandler/ToolKit.java line 28: > >> 26: import jdk.test.failurehandler.action.ActionSet; >> 27: import jdk.test.failurehandler.action.ActionHelper; >> 28: import jdk.test.failurehandler.action.PatternAction; > > redundant import fixed > test/failure_handler/src/share/conf/mac.properties line 71: > >> 69: native.lldb.app=lldb >> 70: native.lldb.delimiter=\0 >> 71: native.lldb.args=--core\0%p\0%java\0-o\0thread backtrace all\0-o\0quit > > could you please add a comment similar to the one in common.properties file? fixed > test/failure_handler/src/share/conf/mac.properties line 72: > >> 70: native.lldb.delimiter=\0 >> 71: native.lldb.args=--core\0%p\0%java\0-o\0thread backtrace all\0-o\0quit >> 72: native.lldb.params.timeout=3600000 > > why does `lldb` require an increases timeout, but `gdb` and `jhsdb` do not? Not sure I remember if there is any reason. I remove it. Let increase it later if it actually needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From lmesnik at openjdk.java.net Wed Jun 9 18:55:12 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 9 Jun 2021 18:55:12 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v5] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 01:00:53 GMT, Leonid Mesnik wrote: >> EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > spaces updated. updated diff ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From lmesnik at openjdk.java.net Wed Jun 9 19:00:39 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 9 Jun 2021 19:00:39 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v6] In-Reply-To: References: Message-ID: <6SZF9RWatyvXJXVRqFCre9XU9T7eX8Cp_Q5mABj68YQ=.ef3a10d8-000f-4436-86ca-a5b4b1bff6fb@github.com> > EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fxies ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4234/files - new: https://git.openjdk.java.net/jdk/pull/4234/files/e70518bc..67b61d01 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4234&range=04-05 Stats: 7 lines in 4 files changed: 2 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4234.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4234/head:pull/4234 PR: https://git.openjdk.java.net/jdk/pull/4234 From iris at openjdk.java.net Wed Jun 9 19:35:15 2021 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 9 Jun 2021 19:35:15 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v5] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 10:25:35 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with two additional commits since the last revision: > > - 8268124: moved cases into separate lines in DirectMethodHandleDescImpl part II > - 8268124: moved cases onto separate lines in DirectMethodHandleDescImpl Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From mchung at openjdk.java.net Wed Jun 9 20:37:17 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Jun 2021 20:37:17 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v5] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 10:25:35 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with two additional commits since the last revision: > > - 8268124: moved cases into separate lines in DirectMethodHandleDescImpl part II > - 8268124: moved cases onto separate lines in DirectMethodHandleDescImpl Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From scolebourne at openjdk.java.net Wed Jun 9 22:20:13 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 9 Jun 2021 22:20:13 GMT Subject: RFR: 8268469: Update java.time to use switch expressions In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 15:41:59 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? > > Kind regards, > Patrick My biggest comment is the spaces used to align, which I strongly object to. I agree with @dfuch comments too. src/java.base/share/classes/java/time/LocalDate.java line 608: > 606: if (chronoField.isDateBased()) { > 607: return switch (chronoField) { > 608: case DAY_OF_MONTH -> ValueRange.of(1, lengthOfMonth()); For the record, I hate code that is aligned like this. It makes refactoring much more noisy, as the author has to readjust all the associated lines. I also don't believe it is within the spirit of Java's traditional coding guidelines. src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java line 331: > 329: yield with(isoDate.withYear(nvalue - YEARS_DIFFERENCE)); > 330: } > 331: case ERA -> with(isoDate.withYear((1 - getProlepticYear()) - YEARS_DIFFERENCE)); `checkValidIntValue` performs validation, so removing it has changed the behavoiur src/java.base/share/classes/java/time/format/SignStyle.java line 129: > 127: // valid if negative or (positive and lenient) > 128: case 0 -> !positive || !strict;// NORMAL > 129: case 1, 4 -> true; // ALWAYS, EXCEEDS_PAD Extra space before `4` ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From psandoz at openjdk.java.net Wed Jun 9 22:48:16 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 9 Jun 2021 22:48:16 GMT Subject: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 15:30:33 GMT, Dan Smith wrote: >> Small bug fix. > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Clean up validation of implKind REF_invokeSpecial Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4403 From mchung at openjdk.java.net Wed Jun 9 23:50:18 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Jun 2021 23:50:18 GMT Subject: RFR: 8268192: LambdaMetafactory with invokespecial causes VerificationError [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 15:30:33 GMT, Dan Smith wrote: >> Small bug fix. > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Clean up validation of implKind REF_invokeSpecial Looks good to me. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4403 From dlsmith at openjdk.java.net Thu Jun 10 00:01:24 2021 From: dlsmith at openjdk.java.net (Dan Smith) Date: Thu, 10 Jun 2021 00:01:24 GMT Subject: Integrated: 8268192: LambdaMetafactory with invokespecial causes VerificationError In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 23:58:44 GMT, Dan Smith wrote: > Small bug fix. This pull request has now been integrated. Changeset: 58ba48b7 Author: Dan Smith URL: https://git.openjdk.java.net/jdk/commit/58ba48b7b88eff359683aa3271c48b18f1973282 Stats: 27 lines in 3 files changed: 7 ins; 12 del; 8 mod 8268192: LambdaMetafactory with invokespecial causes VerificationError Reviewed-by: psandoz, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/4403 From darcy at openjdk.java.net Thu Jun 10 00:02:14 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Jun 2021 00:02:14 GMT Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v3] In-Reply-To: References: Message-ID: <3vqUX4uQvJq-qYyolxi8ZKRZgaiHgZfsTR5eyrTD4tA=.0c4628ba-3155-42d5-a0f0-2a16830f8ec2@github.com> On Wed, 9 Jun 2021 13:46:28 GMT, Rafael Winterhalter wrote: >> If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. > > Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8266766: Arrays of types that cannot be an annotation member do not yield exceptions To aid future maintainers, please add a short summary comment with an outline of what the test is doing before integrating. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3925 From darcy at openjdk.java.net Thu Jun 10 00:18:15 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Jun 2021 00:18:15 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3] In-Reply-To: References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: On Wed, 9 Jun 2021 13:56:40 GMT, Rafael Winterhalter wrote: >> During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. > > Rafael Winterhalter 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. Please add an overview to test before integrating; thanks. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3940 From darcy at openjdk.java.net Thu Jun 10 00:47:35 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Jun 2021 00:47:35 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v8] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Update symbols for JDK 17 b25. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/b41f3f8e...ae4d6cce ------------- Changes: https://git.openjdk.java.net/jdk/pull/4175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=07 Stats: 5334 lines in 63 files changed: 5292 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From iignatyev at openjdk.java.net Thu Jun 10 03:42:20 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 10 Jun 2021 03:42:20 GMT Subject: RFR: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes [v6] In-Reply-To: <6SZF9RWatyvXJXVRqFCre9XU9T7eX8Cp_Q5mABj68YQ=.ef3a10d8-000f-4436-86ca-a5b4b1bff6fb@github.com> References: <6SZF9RWatyvXJXVRqFCre9XU9T7eX8Cp_Q5mABj68YQ=.ef3a10d8-000f-4436-86ca-a5b4b1bff6fb@github.com> Message-ID: On Wed, 9 Jun 2021 19:00:39 GMT, Leonid Mesnik wrote: >> EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fxies Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From dholmes at openjdk.java.net Thu Jun 10 04:20:14 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Jun 2021 04:20:14 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3] In-Reply-To: References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: On Wed, 9 Jun 2021 13:56:40 GMT, Rafael Winterhalter wrote: >> During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. > > Rafael Winterhalter 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. test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArityTypeMismatchTest.java line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. Copyright year is wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/3940 From darcy at openjdk.java.net Thu Jun 10 05:16:36 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Jun 2021 05:16:36 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v9] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Update symbols for JDK 17 b25. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/2623b0bf...794f3173 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=08 Stats: 5334 lines in 63 files changed: 5292 ins; 0 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From jbhateja at openjdk.java.net Thu Jun 10 05:59:24 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 10 Jun 2021 05:59:24 GMT Subject: RFR: 8266054: VectorAPI rotate operation optimization [v8] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 10:29:44 GMT, Jatin Bhateja wrote: >> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:- >> >> vec1 = lanewise(VectorOperators.LSHL, n) >> vec2 = lanewise(VectorOperators.LSHR, n) >> res = lanewise(VectorOperations.OR, vec1 , vec2) >> >> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction. >> >> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations ) instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted. >> >> Please find below the performance data for included JMH benchmark. >> Machine: Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz) >> >> >> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain % >> -- | -- | -- | -- | -- | -- | -- | -- | -- >> ? | ? | ? | ? | ? | ? | ? | ? | ? >> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82 >> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84 >> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90 >> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44 >> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30 >> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14 >> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58 >> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18 >> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02 >> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52 >> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40 >> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16 >> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98 >> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91 >> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80 >> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78 >> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79 >> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22 >> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27 >> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69 >> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59 >> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77 >> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60 >> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39 >> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49 >> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06 >> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56 >> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49 >> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95 >> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77 >> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93 >> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78 >> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11 >> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94 >> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29 >> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77 >> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22 >> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08 >> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08 >> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01 >> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60 >> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34 >> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89 >> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63 >> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16 >> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53 >> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18 >> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64 >> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26 >> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99 >> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54 >> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04 >> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71 >> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66 >> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66 >> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02 >> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13 >> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97 >> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61 >> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66 >> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35 >> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21 >> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67 >> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66 >> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08 >> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96 >> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13 >> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19 >> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72 >> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82 >> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58 >> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88 >> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56 >> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53 >> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76 >> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76 >> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41 >> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03 >> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74 >> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08 >> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24 >> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19 >> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38 >> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06 > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge http://github.com/openjdk/jdk into JDK-8266054 > - Merge http://github.com/openjdk/jdk into JDK-8266054 > - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054 > - 8266054: Removing redundant teat templates. > - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform. > - 8266054: Removing redundant test templates. > - 8266054: Review comments resolution. > - 8266054: Review comments resolution. > - 8266054: Review comments resolution. > - Merge http://github.com/openjdk/jdk into JDK-8266054 > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/61ab4b9d...debb09f2 Hi @iwanowww, @neliasso , kindly review compiler side changes and share your feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/3720 From darcy at openjdk.java.net Thu Jun 10 06:53:34 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Jun 2021 06:53:34 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v10] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Update copyright year. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Update symbols for JDK 17 b25. - ... and 14 more: https://git.openjdk.java.net/jdk/compare/dd1cbadc...aaf47c1f ------------- Changes: https://git.openjdk.java.net/jdk/pull/4175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=09 Stats: 5352 lines in 63 files changed: 5292 ins; 0 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From winterhalter at openjdk.java.net Thu Jun 10 08:08:47 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 10 Jun 2021 08:08:47 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v4] In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: > During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. Rafael Winterhalter 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: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3940/files - new: https://git.openjdk.java.net/jdk/pull/3940/files/4e14cbb9..e804eb38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940 From winterhalter at openjdk.java.net Thu Jun 10 08:08:52 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 10 Jun 2021 08:08:52 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3] In-Reply-To: References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: On Thu, 10 Jun 2021 04:17:37 GMT, David Holmes wrote: >> Rafael Winterhalter 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. > > test/jdk/java/lang/annotation/AnnotationTypeMismatchException/ArityTypeMismatchTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > > Copyright year is wrong. Thanks, I corrected the year. ------------- PR: https://git.openjdk.java.net/jdk/pull/3940 From winterhalter at openjdk.java.net Thu Jun 10 08:14:12 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 10 Jun 2021 08:14:12 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3] In-Reply-To: References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: <2lgcdp-z69xhUm96qY-jZqCz7bkEffF6OOClH8UF73U=.00a5d018-d4eb-44d5-b4b7-9f963b984289@github.com> On Thu, 10 Jun 2021 00:15:24 GMT, Joe Darcy wrote: > Please add an overview to test before integrating; thanks. Sorry, I missed that one. Not sure what you mean by *overview*? ------------- PR: https://git.openjdk.java.net/jdk/pull/3940 From winterhalter at openjdk.java.net Thu Jun 10 08:29:46 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 10 Jun 2021 08:29:46 GMT Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v4] In-Reply-To: References: Message-ID: > If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. Rafael Winterhalter 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 one additional commit since the last revision: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3925/files - new: https://git.openjdk.java.net/jdk/pull/3925/files/c812a4c4..b51dafbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3925&range=02-03 Stats: 1236 lines in 63 files changed: 823 ins; 166 del; 247 mod Patch: https://git.openjdk.java.net/jdk/pull/3925.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3925/head:pull/3925 PR: https://git.openjdk.java.net/jdk/pull/3925 From github.com+10835776+stsypanov at openjdk.java.net Thu Jun 10 08:30:43 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 10 Jun 2021 08:30:43 GMT Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v7] In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com> Message-ID: > There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode(). ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - Merge branch 'master' into 8268113 - 8268113: Inline local vars where reasonable - 8268113: Delegate to Double.hashCode() - 8268113: Re-use Long.hashCode() where possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4309/files - new: https://git.openjdk.java.net/jdk/pull/4309/files/3a7b5515..f1c8cc7b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=05-06 Stats: 4631 lines in 103 files changed: 3649 ins; 401 del; 581 mod Patch: https://git.openjdk.java.net/jdk/pull/4309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309 PR: https://git.openjdk.java.net/jdk/pull/4309 From iignatyev at openjdk.java.net Thu Jun 10 08:35:25 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 10 Jun 2021 08:35:25 GMT Subject: RFR: 8267448: Add "ulimit -a" to environment.html Message-ID: <4UGs3avpcoXZtLgyl_8Hj8lapTPwVGk3FIP61i-dIXM=.4827f8f7-778b-439f-966c-c139ab3abd46@github.com> Hi all, could you please review this small patch that does $subj? Thanks, -- Igor attn: @plummercj ------------- Commit messages: - 8267448 Changes: https://git.openjdk.java.net/jdk/pull/4451/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4451&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267448 Stats: 15 lines in 3 files changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4451.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4451/head:pull/4451 PR: https://git.openjdk.java.net/jdk/pull/4451 From winterhalter at openjdk.java.net Thu Jun 10 08:36:22 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 10 Jun 2021 08:36:22 GMT Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v3] In-Reply-To: <3vqUX4uQvJq-qYyolxi8ZKRZgaiHgZfsTR5eyrTD4tA=.0c4628ba-3155-42d5-a0f0-2a16830f8ec2@github.com> References: <3vqUX4uQvJq-qYyolxi8ZKRZgaiHgZfsTR5eyrTD4tA=.0c4628ba-3155-42d5-a0f0-2a16830f8ec2@github.com> Message-ID: <-kW1vUyCEHQiAfFeZtBB--9Bl-GdTJSwp-_mCV78ilM=.49096ac4-38f1-461f-9a0a-b8c29a4e62c5@github.com> On Wed, 9 Jun 2021 23:59:45 GMT, Joe Darcy wrote: > To aid future maintainers, please add a short summary comment with an outline of what the test is doing before integrating. I added a comment to the test to explain what is done in it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3925 From winterhalter at openjdk.java.net Thu Jun 10 08:36:42 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 10 Jun 2021 08:36:42 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v5] In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: > During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions ------------- Changes: https://git.openjdk.java.net/jdk/pull/3940/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=04 Stats: 242 lines in 3 files changed: 240 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940 From pconcannon at openjdk.java.net Thu Jun 10 08:43:44 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 10 Jun 2021 08:43:44 GMT Subject: RFR: 8268124: Update java.lang to use switch expressions [v6] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: moved cases into separate lines in DirectMethodHandleDescImpl part II - 8268124: moved cases onto separate lines in DirectMethodHandleDescImpl - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: small refactoring; fixed misplaced comment and added missing lambda operator - Merge remote-tracking branch 'origin/master' into JDK-8268124 - 8268124: Update java.lang to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4312/files - new: https://git.openjdk.java.net/jdk/pull/4312/files/df5b34e5..c7c11939 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4312&range=04-05 Stats: 4673 lines in 106 files changed: 3649 ins; 412 del; 612 mod Patch: https://git.openjdk.java.net/jdk/pull/4312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4312/head:pull/4312 PR: https://git.openjdk.java.net/jdk/pull/4312 From jvernee at openjdk.java.net Thu Jun 10 08:48:25 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Jun 2021 08:48:25 GMT Subject: Integrated: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 16:38:01 GMT, Jorn Vernee wrote: > Hi, > > ~This is part 2 of a two part upstreaming process of the patch mentioned in the subject line. The patch was split into 2 in order to document 2 separate specification changes that arose from a change in the implementation, with 2 separate CSRs. The first patch can be found here: https://github.com/openjdk/jdk/pull/4395~ > > This patch adds uniform exception handling for exceptions thrown during FLA upcalls. Currently, these exceptions are either handled similarly to the VMs `CATCH` macro, or ignored after which control returns to unsuspecting native code, until control returns to Java, which will then handle the exception. The handling depends on the invocation mode. > > Both of these are bad. The former because a stack trace is not printed and instead the VM exits with a fatal error. The latter is bad because an upcall completing abruptly and returning to native code which has no idea an exception occurred is unsafe, in the sense that invariants about the state of the program that the native code depends on might no longer hold. > > This patch adds uniform exception handling that replaces both of these cases (see `SharedUtils::handleUncaughtException`), which prints the exception stack trace, and then unconditionally exits the VM, which is the only safe course of action at that point. > > Exceptions thrown by upcalls should instead be handled during the upcall itself, for instance by translating the exception into an error code that is then returned to the native caller, which can deal with it appropriately. > > See also the original review for panama-foreign: https://github.com/openjdk/panama-foreign/pull/543 > > Thanks, > Jorn > > Testing: `jdk_foreign` test suite. > > Thanks, > Jorn This pull request has now been integrated. Changeset: ab01cb54 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/ab01cb547dd87f76017e9b079ab68495c38ffc90 Stats: 229 lines in 8 files changed: 224 ins; 0 del; 5 mod 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled Reviewed-by: psandoz, mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/4396 From pconcannon at openjdk.java.net Thu Jun 10 08:50:43 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 10 Jun 2021 08:50:43 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v2] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8268469 - 8268469: Update java.time to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4433/files - new: https://git.openjdk.java.net/jdk/pull/4433/files/e6d76af2..2abbea11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=00-01 Stats: 1167 lines in 61 files changed: 779 ins; 153 del; 235 mod Patch: https://git.openjdk.java.net/jdk/pull/4433.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4433/head:pull/4433 PR: https://git.openjdk.java.net/jdk/pull/4433 From jvernee at openjdk.java.net Thu Jun 10 08:53:22 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Jun 2021 08:53:22 GMT Subject: RFR: 8268339: Upstream: 8267989: Exceptions thrown during upcalls should be handled [v5] In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 19:25:36 GMT, Paul Sandoz wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Suggest try/catch Throwable in upcallStub javadoc > > test/jdk/java/foreign/TestUpcallException.java line 70: > >> 68: Process process = new ProcessBuilder() >> 69: .command( >> 70: Paths.get(Utils.TEST_JDK) > > You might find `jdk.test.lib.JDKToolLauncher` useful. Thanks for the suggestion (forgot to reply earlier). I think I copied the current way to find `java` from another test. I'll look at using JDKToolLauncher next time. ------------- PR: https://git.openjdk.java.net/jdk/pull/4396 From jfranck at openjdk.java.net Thu Jun 10 09:07:14 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Thu, 10 Jun 2021 09:07:14 GMT Subject: RFR: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions [v4] In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 08:29:46 GMT, Rafael Winterhalter wrote: >> If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. > > Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8266766: Arrays of types that cannot be an annotation member do not yield exceptions Marked as reviewed by jfranck (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3925 From github.com+10835776+stsypanov at openjdk.java.net Thu Jun 10 10:06:38 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 10 Jun 2021 10:06:38 GMT Subject: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 14:07:20 GMT, ?????? ??????? wrote: > Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues. > > However the code like > > private String getSimpleName0() { > if (isArray()) { > return getComponentType().getSimpleName() + "[]"; > } > //... > } > > can be improved via replacement of `+` with `String.concat()` call. > > I've used this benchmark to measure impact: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ClassMethodsBenchmark { > private final Class arrayClass = Object[].class; > private Method descriptorString; > > @Setup > public void setUp() throws NoSuchMethodException { > //fore some reason compiler doesn't allow me to call Class.descriptorString() directly > descriptorString = Class.class.getDeclaredMethod("descriptorString"); > } > > @Benchmark > public Object descriptorString() throws Exception { > return descriptorString.invoke(arrayClass); > } > > @Benchmark > public Object typeName() { > return arrayClass.getTypeName(); > } > } > > and got those results > > Mode Cnt Score Error Units > descriptorString avgt 60 91.480 ? 1.839 ns/op > descriptorString:?gc.alloc.rate.norm avgt 60 404.008 ? 4.033 B/op > descriptorString:?gc.churn.G1_Eden_Space avgt 60 2791.866 ? 181.589 MB/sec > descriptorString:?gc.churn.G1_Eden_Space.norm avgt 60 401.702 ? 26.047 B/op > descriptorString:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > descriptorString:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > descriptorString:?gc.count avgt 60 205.000 counts > descriptorString:?gc.time avgt 60 216.000 ms > > patched > Mode Cnt Score Error Units > descriptorString avgt 60 65.016 ? 3.446 ns/op > descriptorString:?gc.alloc.rate avgt 60 2844.240 ? 115.719 MB/sec > descriptorString:?gc.alloc.rate.norm avgt 60 288.006 ? 0.001 B/op > descriptorString:?gc.churn.G1_Eden_Space avgt 60 2832.996 ? 206.939 MB/sec > descriptorString:?gc.churn.G1_Eden_Space.norm avgt 60 286.955 ? 17.853 B/op > descriptorString:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > descriptorString:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > descriptorString:?gc.count avgt 60 208.000 counts > descriptorString:?gc.time avgt 60 228.000 ms > ----------------- > typeName avgt 60 34.273 ? 0.480 ns/op > typeName:?gc.alloc.rate avgt 60 3265.356 ? 45.113 MB/sec > typeName:?gc.alloc.rate.norm avgt 60 176.004 ? 0.001 B/op > typeName:?gc.churn.G1_Eden_Space avgt 60 3268.454 ? 134.458 MB/sec > typeName:?gc.churn.G1_Eden_Space.norm avgt 60 176.109 ? 6.595 B/op > typeName:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > typeName:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > typeName:?gc.count avgt 60 240.000 counts > typeName:?gc.time avgt 60 255.000 ms > > patched > > typeName avgt 60 15.787 ? 0.214 ns/op > typeName:?gc.alloc.rate avgt 60 2577.554 ? 32.339 MB/sec > typeName:?gc.alloc.rate.norm avgt 60 64.001 ? 0.001 B/op > typeName:?gc.churn.G1_Eden_Space avgt 60 2574.039 ? 147.774 MB/sec > typeName:?gc.churn.G1_Eden_Space.norm avgt 60 63.895 ? 3.511 B/op > typeName:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > typeName:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > typeName:?gc.count avgt 60 189.000 counts > typeName:?gc.time avgt 60 199.000 ms > > I think this patch is likely to improve reflection operations related to arrays. > > If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible. > > Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here. Spotted one more method to be improved: @State(Scope.Benchmark) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class ClassToStringBenchmark { private final Class clazzWithShortName = Object.class; private final Class interfaceWithShortName = Serializable.class; private final Class primitive = int.class; @Benchmark public String classToString() { return clazzWithShortName.toString(); } @Benchmark public String interfaceToString() { return interfaceWithShortName.toString(); } @Benchmark public String primitiveToString() { return primitive.toString(); } } giving before Mode Cnt Score Error Units classToString avgt 50 30,769 ? 0,352 ns/op classToString:?gc.alloc.rate avgt 50 3769,212 ? 42,959 MB/sec classToString:?gc.alloc.rate.norm avgt 50 152,003 ? 0,001 B/op classToString:?gc.churn.G1_Eden_Space avgt 50 3776,990 ? 112,309 MB/sec classToString:?gc.churn.G1_Eden_Space.norm avgt 50 152,328 ? 4,317 B/op classToString:?gc.churn.G1_Survivor_Space avgt 50 0,004 ? 0,001 MB/sec classToString:?gc.churn.G1_Survivor_Space.norm avgt 50 ? 10?? B/op classToString:?gc.count avgt 50 385,000 counts classToString:?gc.time avgt 50 378,000 ms interfaceToString avgt 50 35,571 ? 0,583 ns/op interfaceToString:?gc.alloc.rate avgt 50 3433,504 ? 52,056 MB/sec interfaceToString:?gc.alloc.rate.norm avgt 50 160,003 ? 0,001 B/op interfaceToString:?gc.churn.G1_Eden_Space avgt 50 3443,384 ? 91,647 MB/sec interfaceToString:?gc.churn.G1_Eden_Space.norm avgt 50 160,456 ? 3,454 B/op interfaceToString:?gc.churn.G1_Survivor_Space avgt 50 0,004 ? 0,001 MB/sec interfaceToString:?gc.churn.G1_Survivor_Space.norm avgt 50 ? 10?? B/op interfaceToString:?gc.count avgt 50 351,000 counts interfaceToString:?gc.time avgt 50 351,000 ms primitiveToString avgt 50 20,193 ? 0,369 ns/op primitiveToString:?gc.alloc.rate avgt 50 3932,425 ? 68,453 MB/sec primitiveToString:?gc.alloc.rate.norm avgt 50 104,002 ? 0,001 B/op primitiveToString:?gc.churn.G1_Eden_Space avgt 50 3943,662 ? 119,781 MB/sec primitiveToString:?gc.churn.G1_Eden_Space.norm avgt 50 104,305 ? 2,678 B/op primitiveToString:?gc.churn.G1_Survivor_Space avgt 50 0,005 ? 0,001 MB/sec primitiveToString:?gc.churn.G1_Survivor_Space.norm avgt 50 ? 10?? B/op primitiveToString:?gc.count avgt 50 402,000 counts primitiveToString:?gc.time avgt 50 387,000 ms after Mode Cnt Score Error Units classToString avgt 50 13,552 ? 0,114 ns/op classToString:?gc.alloc.rate avgt 50 3602,305 ? 27,881 MB/sec classToString:?gc.alloc.rate.norm avgt 50 64,001 ? 0,001 B/op classToString:?gc.churn.G1_Eden_Space avgt 50 3619,864 ? 119,002 MB/sec classToString:?gc.churn.G1_Eden_Space.norm avgt 50 64,318 ? 2,081 B/op classToString:?gc.churn.G1_Survivor_Space avgt 50 0,004 ? 0,001 MB/sec classToString:?gc.churn.G1_Survivor_Space.norm avgt 50 ? 10?? B/op classToString:?gc.count avgt 50 369,000 counts classToString:?gc.time avgt 50 366,000 ms interfaceToString avgt 50 16,480 ? 0,113 ns/op interfaceToString:?gc.alloc.rate avgt 50 3332,045 ? 21,628 MB/sec interfaceToString:?gc.alloc.rate.norm avgt 50 72,001 ? 0,001 B/op interfaceToString:?gc.churn.G1_Eden_Space avgt 50 3335,296 ? 98,091 MB/sec interfaceToString:?gc.churn.G1_Eden_Space.norm avgt 50 72,086 ? 2,187 B/op interfaceToString:?gc.churn.G1_Survivor_Space avgt 50 0,004 ? 0,001 MB/sec interfaceToString:?gc.churn.G1_Survivor_Space.norm avgt 50 ? 10?? B/op interfaceToString:?gc.count avgt 50 340,000 counts interfaceToString:?gc.time avgt 50 337,000 ms primitiveToString avgt 50 5,992 ? 0,079 ns/op primitiveToString:?gc.alloc.rate avgt 50 3056,666 ? 39,390 MB/sec primitiveToString:?gc.alloc.rate.norm avgt 50 24,000 ? 0,001 B/op primitiveToString:?gc.churn.G1_Eden_Space avgt 50 3070,543 ? 107,567 MB/sec primitiveToString:?gc.churn.G1_Eden_Space.norm avgt 50 24,114 ? 0,814 B/op primitiveToString:?gc.churn.G1_Survivor_Space avgt 50 0,004 ? 0,001 MB/sec primitiveToString:?gc.churn.G1_Survivor_Space.norm avgt 50 ? 10?? B/op primitiveToString:?gc.count avgt 50 313,000 counts primitiveToString:?gc.time avgt 50 310,000 ms ------------- PR: https://git.openjdk.java.net/jdk/pull/3627 From github.com+10835776+stsypanov at openjdk.java.net Thu Jun 10 10:06:38 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 10 Jun 2021 10:06:38 GMT Subject: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available [v2] In-Reply-To: References: Message-ID: > Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues. > > However the code like > > private String getSimpleName0() { > if (isArray()) { > return getComponentType().getSimpleName() + "[]"; > } > //... > } > > can be improved via replacement of `+` with `String.concat()` call. > > I've used this benchmark to measure impact: > > @State(Scope.Thread) > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) > public class ClassMethodsBenchmark { > private final Class arrayClass = Object[].class; > private Method descriptorString; > > @Setup > public void setUp() throws NoSuchMethodException { > //fore some reason compiler doesn't allow me to call Class.descriptorString() directly > descriptorString = Class.class.getDeclaredMethod("descriptorString"); > } > > @Benchmark > public Object descriptorString() throws Exception { > return descriptorString.invoke(arrayClass); > } > > @Benchmark > public Object typeName() { > return arrayClass.getTypeName(); > } > } > > and got those results > > Mode Cnt Score Error Units > descriptorString avgt 60 91.480 ? 1.839 ns/op > descriptorString:?gc.alloc.rate.norm avgt 60 404.008 ? 4.033 B/op > descriptorString:?gc.churn.G1_Eden_Space avgt 60 2791.866 ? 181.589 MB/sec > descriptorString:?gc.churn.G1_Eden_Space.norm avgt 60 401.702 ? 26.047 B/op > descriptorString:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > descriptorString:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > descriptorString:?gc.count avgt 60 205.000 counts > descriptorString:?gc.time avgt 60 216.000 ms > > patched > Mode Cnt Score Error Units > descriptorString avgt 60 65.016 ? 3.446 ns/op > descriptorString:?gc.alloc.rate avgt 60 2844.240 ? 115.719 MB/sec > descriptorString:?gc.alloc.rate.norm avgt 60 288.006 ? 0.001 B/op > descriptorString:?gc.churn.G1_Eden_Space avgt 60 2832.996 ? 206.939 MB/sec > descriptorString:?gc.churn.G1_Eden_Space.norm avgt 60 286.955 ? 17.853 B/op > descriptorString:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > descriptorString:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > descriptorString:?gc.count avgt 60 208.000 counts > descriptorString:?gc.time avgt 60 228.000 ms > ----------------- > typeName avgt 60 34.273 ? 0.480 ns/op > typeName:?gc.alloc.rate avgt 60 3265.356 ? 45.113 MB/sec > typeName:?gc.alloc.rate.norm avgt 60 176.004 ? 0.001 B/op > typeName:?gc.churn.G1_Eden_Space avgt 60 3268.454 ? 134.458 MB/sec > typeName:?gc.churn.G1_Eden_Space.norm avgt 60 176.109 ? 6.595 B/op > typeName:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > typeName:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > typeName:?gc.count avgt 60 240.000 counts > typeName:?gc.time avgt 60 255.000 ms > > patched > > typeName avgt 60 15.787 ? 0.214 ns/op > typeName:?gc.alloc.rate avgt 60 2577.554 ? 32.339 MB/sec > typeName:?gc.alloc.rate.norm avgt 60 64.001 ? 0.001 B/op > typeName:?gc.churn.G1_Eden_Space avgt 60 2574.039 ? 147.774 MB/sec > typeName:?gc.churn.G1_Eden_Space.norm avgt 60 63.895 ? 3.511 B/op > typeName:?gc.churn.G1_Survivor_Space avgt 60 0.003 ? 0.001 MB/sec > typeName:?gc.churn.G1_Survivor_Space.norm avgt 60 ? 10?? B/op > typeName:?gc.count avgt 60 189.000 counts > typeName:?gc.time avgt 60 199.000 ms > > I think this patch is likely to improve reflection operations related to arrays. > > If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible. > > Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here. ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8266972: Use String.concat() in j.l.Class.toSting() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3627/files - new: https://git.openjdk.java.net/jdk/pull/3627/files/b38f4fe2..81568116 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3627.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627 PR: https://git.openjdk.java.net/jdk/pull/3627 From sergei.tsypanov at yandex.ru Thu Jun 10 10:58:02 2021 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 10 Jun 2021 12:58:02 +0200 Subject: Windows aarch64 (build debug) constantly fails Message-ID: <5243221623322682@vla5-3610e71ecd90.qloud-c.yandex.net> Hello, in the pipeline of my JDK fork the mentioned build step constantly fails even providing I modify only Java code I see this message in the log Compiling 2 files for BUILD_JVMTI_TOOLS LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' make[3]: *** [gensrc/GensrcAdlc.gmk:63: /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/hotspot/variant-server/tools/adlc/adlc.exe] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [make/Main.gmk:248: hotspot-server-gensrc] Error 2 ERROR: Build failed for target 'default (hotspot)' in configuration 'windows-aarch64' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-server_tools_adlc_objs_BUILD_ADLC_link: LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' * All command lines available in /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/make-support/failure-logs. === End of repeated output === No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:315: main] Error 2 make: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:186: default] Error 2 Error: Process completed with exit code 1. Here's the link to particular run https://github.com/stsypanov/jdk/runs/2792324849 What can I do with this? Regards, Sergey Tsypanov From pconcannon at openjdk.java.net Thu Jun 10 11:16:18 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 10 Jun 2021 11:16:18 GMT Subject: Integrated: 8268124: Update java.lang to use switch expressions In-Reply-To: References: Message-ID: <4YuYeMAtj3VSjiEb6c2QGr3p5v4PZ4GQvWuAbv5ghNo=.af44662a-6895-4626-897f-0bcdc1b48e3c@github.com> On Wed, 2 Jun 2021 15:25:16 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.lang` packages to make use of the switch expressions? > > Kind regards, > Patrick This pull request has now been integrated. Changeset: d43c8a74 Author: Patrick Concannon URL: https://git.openjdk.java.net/jdk/commit/d43c8a74b33692b3628c3c9c6c472ab1cf1fdeac Stats: 558 lines in 22 files changed: 6 ins; 136 del; 416 mod 8268124: Update java.lang to use switch expressions Reviewed-by: naoto, darcy, mchung, iris, lancea, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/4312 From winterhalter at openjdk.java.net Thu Jun 10 12:06:23 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 10 Jun 2021 12:06:23 GMT Subject: Integrated: 8266766: Arrays of types that cannot be an annotation member do not yield exceptions In-Reply-To: References: Message-ID: On Fri, 7 May 2021 18:58:02 GMT, Rafael Winterhalter wrote: > If a type is changed from a type that can be a member of an annotation which is used in an array, changing it to a type that cannot be an array member will be treated as if the type is an annotation type. As a result, no exception proxy is created and the type is returned as if it was correctly defined. This pull request has now been integrated. Changeset: 09243822 Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck URL: https://git.openjdk.java.net/jdk/commit/09243822ebcca611b04f94ece5afba183723cf74 Stats: 143 lines in 2 files changed: 141 ins; 1 del; 1 mod 8266766: Arrays of types that cannot be an annotation member do not yield exceptions Reviewed-by: darcy, jfranck ------------- PR: https://git.openjdk.java.net/jdk/pull/3925 From jfranck at openjdk.java.net Thu Jun 10 12:23:19 2021 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Thu, 10 Jun 2021 12:23:19 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v5] In-Reply-To: References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: On Thu, 10 Jun 2021 08:36:42 GMT, Rafael Winterhalter wrote: >> During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. > > Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException > - 8266766: Arrays of types that cannot be an annotation member do not yield exceptions Marked as reviewed by jfranck (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3940 From mcimadamore at openjdk.java.net Thu Jun 10 12:55:17 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 10 Jun 2021 12:55:17 GMT Subject: Integrated: 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 10:33:34 GMT, Maurizio Cimadamore wrote: > This tests fails intermittently but very rarely, on Windows it seems. The subtest in question is `testLockSharedMultiThread`. This test is spawning a number of threads, each of which: > > * increments a counter atomically > * acquire scope > * waits some time > * release scope > * decrement counter (in finally block) > > The main test thread tries (while the counter value is > 0) to repeatedly close the scope, and asserts that if the scope closes successfully, then the counter value should be exactly zero. > > Looking at the test closely, I realized there's an issue: the order in which counter is incremented and scope is acquired is wrong. As such it is possible for counter to be increased, but then for subsequent acquire to fail (e.g. if segment is already closed). This would lead to the main test thread to fail, as it would appear as if the segment has been closed successfully, but the counter value is not zero. > > The fix is to only increment the counter after a successful acquire. I have also tweaked the test so that it keeps trying closing the scope, even if the counter value reaches zero permanently (e.g. all other threads have completed). This pull request has now been integrated. Changeset: f4b31701 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/f4b3170197ca517b4816f863af053f019ce0f181 Stats: 15 lines in 1 file changed: 6 ins; 3 del; 6 mod 8268428: Test java/foreign/TestResourceScope.java fails: expected [M] but found [N] Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/4427 From winterhalter at openjdk.java.net Thu Jun 10 14:00:28 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Thu, 10 Jun 2021 14:00:28 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v6] In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: > During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException ------------- Changes: https://git.openjdk.java.net/jdk/pull/3940/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3940&range=05 Stats: 99 lines in 2 files changed: 99 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3940.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3940/head:pull/3940 PR: https://git.openjdk.java.net/jdk/pull/3940 From kcr at openjdk.java.net Thu Jun 10 14:14:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Jun 2021 14:14:59 GMT Subject: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3] In-Reply-To: <2lgcdp-z69xhUm96qY-jZqCz7bkEffF6OOClH8UF73U=.00a5d018-d4eb-44d5-b4b7-9f963b984289@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> <2lgcdp-z69xhUm96qY-jZqCz7bkEffF6OOClH8UF73U=.00a5d018-d4eb-44d5-b4b7-9f963b984289@github.com> Message-ID: On Thu, 10 Jun 2021 08:11:42 GMT, Rafael Winterhalter wrote: >> Please add an overview to test before integrating; thanks. > >> Please add an overview to test before integrating; thanks. > > Sorry, I missed that one. Not sure what you mean by *overview*? I was not sure if there's an official tag for something like this but added a description as a comment. @raphw Please do not force push to your branch after a PR is under review. It makes it difficult for reviewers to see incremental diffs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3940 From darcy at openjdk.java.net Thu Jun 10 14:42:24 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Jun 2021 14:42:24 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v11] In-Reply-To: References: Message-ID: > 8267630: Start of release updates for JDK 18 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into 8267630 - Update copyright year. - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - Merge branch 'master' into 8267630 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/a95e64cc...51f51814 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4175&range=10 Stats: 5352 lines in 63 files changed: 5292 ins; 0 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/4175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4175/head:pull/4175 PR: https://git.openjdk.java.net/jdk/pull/4175 From iris at openjdk.java.net Thu Jun 10 14:49:59 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 10 Jun 2021 14:49:59 GMT Subject: RFR: 8267630: Start of release updates for JDK 18 [v11] In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 14:42:24 GMT, Joe Darcy wrote: >> 8267630: Start of release updates for JDK 18 > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into 8267630 > - Update copyright year. > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - Merge branch 'master' into 8267630 > - ... and 15 more: https://git.openjdk.java.net/jdk/compare/a95e64cc...51f51814 Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4175 From github.com+6704669+asgibbons at openjdk.java.net Thu Jun 10 16:16:32 2021 From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons) Date: Thu, 10 Jun 2021 16:16:32 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v3] In-Reply-To: References: <_jzUJqPGgV255ofevS6BguJqQddvfdMdr0gGwwn3DA4=.03e8dc6d-ff6b-46de-8dc5-69ed36481615@github.com> Message-ID: On Tue, 8 Jun 2021 23:42:13 GMT, Sandhya Viswanathan wrote: >> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixing review comments. Adding notes about isMIME parameter for other architectures; clarifying decodeBlock comments. > > src/hotspot/cpu/x86/assembler_x86.cpp line 4555: > >> 4553: void Assembler::evpmaddubsw(XMMRegister dst, XMMRegister src1, XMMRegister src2, int vector_len) { >> 4554: assert(VM_Version::supports_avx512bw(), ""); >> 4555: InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true); > > This instruction is also supported on AVX platforms. The assert check could be as follows: > assert(vector_len == AVX_128bit? VM_Version::supports_avx() : > vector_len == AVX_256bit? VM_Version::supports_avx2() : > vector_len == AVX_512bit? VM_Version::supports_avx512bw() : 0, ""); > Accordingly the instruction could be named as vpmaddubsw. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5688: > >> 5686: address base64_vbmi_lookup_lo_addr() { >> 5687: __ align(64, (unsigned long) __ pc()); >> 5688: StubCodeMark mark(this, "StubRoutines", "lookup_lo"); > > It will be good to add base64 to the StubCodeMark name for this and all the tables. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5983: > >> 5981: // calculate length from offsets >> 5982: __ movq(length, end_offset); >> 5983: __ subq(length, start_offset); > > These are 32bit, so movl, subl instead of movq, subq. Similar for all length relates instructions below. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5987: > >> 5985: >> 5986: // If AVX512 VBMI not supported, just compile non-AVX code >> 5987: if(VM_Version::supports_avx512_vbmi()) { > > Need to also check for VM_Version::supports_avx512bw() support. > Could you please check if VM_Version::supports_avx512dq is needed as well? Done. No need for avx512dq. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6134: > >> 6132: __ subq(length, 64); >> 6133: __ addq(source, 64); >> 6134: __ addq(dest, 48); > > All address related instructions here and below could use addptr, subptr etc. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6273: > >> 6271: >> 6272: __ shrq(length, 2); // Multiple of 4 bytes only - length is # 4-byte chunks >> 6273: __ cmpq(length, 0); > > Should these be shrl, cmpl? Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6278: > >> 6276: // Set up src and dst pointers properly >> 6277: __ addq(source, start_offset); // Initial offset >> 6278: __ addq(dest, dp); > > The convention is to use addptr for pointers. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6284: > >> 6282: __ shll(isURL, 8); // index into decode table based on isURL >> 6283: __ lea(decode_table, ExternalAddress(StubRoutines::x86::base64_decoding_table_addr())); >> 6284: __ addq(decode_table, isURL); > > addptr here. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6297: > >> 6295: __ orl(byte1, byte4); >> 6296: >> 6297: __ incrementq(source, 4); > > addptr here. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6317: > >> 6315: __ load_signed_byte(byte4, Address(source, RegisterOrConstant(), Address::times_1, 3)); >> 6316: __ load_signed_byte(byte3, Address(decode_table, byte3, Address::times_1, 0)); >> 6317: __ load_signed_byte(byte4, Address(decode_table, byte4, Address::times_1, 0)); > > You could use Address(base, offset) form directly here and other places: e.g. Address (source, 1) instead of Address(source, RegisterOrConstant(), Address::times_1, 1). Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6329: > >> 6327: __ subq(dest, rax); // Number of bytes converted >> 6328: __ movq(rax, dest); >> 6329: __ pop(rbx); > > subptr, movptr here. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7627: > >> 7625: StubRoutines::x86::_right_shift_mask = base64_right_shift_mask_addr(); >> 7626: StubRoutines::_base64_encodeBlock = generate_base64_encodeBlock(); >> 7627: if (VM_Version::supports_avx512_vbmi()) { > > Need to add avx512bw check here also. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7628: > >> 7626: StubRoutines::_base64_encodeBlock = generate_base64_encodeBlock(); >> 7627: if (VM_Version::supports_avx512_vbmi()) { >> 7628: StubRoutines::x86::_lookup_lo = base64_vbmi_lookup_lo_addr(); > > It would be good to add base64 to these names. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/4368 From github.com+6704669+asgibbons at openjdk.java.net Thu Jun 10 16:16:08 2021 From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons) Date: Thu, 10 Jun 2021 16:16:08 GMT Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v4] In-Reply-To: References: Message-ID: <0Qj7oQT5xTnuyhwykScVOvEgS0__4xiGdNM0RhawDoU=.dcd3bf74-9042-4dde-9058-e210da195f1b@github.com> > Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding. > > A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done. This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so. A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded. This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded. > > The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding. The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically. > > Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k. The numbers are given in the table below. > > **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**. > > > Benchmark Name | Base Score | Optimized Score | Gain > -- | -- | -- | -- > testBase64Decode size 1 | 15.36 | 15.32 | 1.00 > testBase64Decode size 3 | 17.00 | 16.72 | 1.02 > testBase64Decode size 7 | 20.60 | 18.82 | 1.09 > testBase64Decode size 32 | 34.21 | 26.77 | 1.28 > testBase64Decode size 64 | 54.43 | 38.35 | 1.42 > testBase64Decode size 80 | 66.40 | 48.34 | 1.37 > testBase64Decode size 96 | 73.16 | 52.90 | 1.38 > testBase64Decode size 112 | 84.93 | 51.82 | 1.64 > testBase64Decode size 512 | 288.81 | 32.04 | 9.01 > testBase64Decode size 1000 | 560.48 | 40.79 | 13.74 > testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72 > testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15 > testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07 > testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10 > testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02 > testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10 > testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05 > testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00 > testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05 > testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20 > testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09 > testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12 > testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09 > testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21 > testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29 > testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12 > testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05 > testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18 > testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02 > testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24 > testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23 > testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24 > testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14 > testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19 > testBase64WithErrorInputsDecode size 20000 | 1398.44 | 1138.17 | 1.23 > testBase64WithErrorInputsDecode size 50000 | 1409.41 | 1114.16 | 1.26 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Addressing review comments. 1. Modified evpmaddubsw. Assert for avx512bw, renamed to vpmaddubsw. 2. Added base64 to StubCodeMark names and associated variables. 3. Added avx512bw check at top of vbmi loop. No need for avx512dq. 4. Fixed all length references (addq=>addl, addq=>addptr, etc.). 5. Converted to Address(base, offset) where appropriate. Compiles, and smoke-tested. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4368/files - new: https://git.openjdk.java.net/jdk/pull/4368/files/d66e32e3..247f2245 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=02-03 Stats: 104 lines in 5 files changed: 4 ins; 0 del; 100 mod Patch: https://git.openjdk.java.net/jdk/pull/4368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368 PR: https://git.openjdk.java.net/jdk/pull/4368 From darcy at openjdk.java.net Thu Jun 10 16:28:01 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Jun 2021 16:28:01 GMT Subject: Integrated: 8267630: Start of release updates for JDK 18 In-Reply-To: References: Message-ID: On Mon, 24 May 2021 22:35:04 GMT, Joe Darcy wrote: > 8267630: Start of release updates for JDK 18 This pull request has now been integrated. Changeset: b018c450 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/b018c450e5e4737ccd08ed505fd06cee16c42648 Stats: 5352 lines in 63 files changed: 5292 ins; 0 del; 60 mod 8267630: Start of release updates for JDK 18 8267632: Add source 18 and target 18 to javac 8267631: Add SourceVersion.RELEASE_18 Reviewed-by: iris, erikj, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4175 From iignatyev at openjdk.java.net Thu Jun 10 16:54:52 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 10 Jun 2021 16:54:52 GMT Subject: Withdrawn: 8267448: Add "ulimit -a" to environment.html In-Reply-To: <4UGs3avpcoXZtLgyl_8Hj8lapTPwVGk3FIP61i-dIXM=.4827f8f7-778b-439f-966c-c139ab3abd46@github.com> References: <4UGs3avpcoXZtLgyl_8Hj8lapTPwVGk3FIP61i-dIXM=.4827f8f7-778b-439f-966c-c139ab3abd46@github.com> Message-ID: On Thu, 10 Jun 2021 06:26:53 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that does $subj? > > Thanks, > -- Igor > > attn: @plummercj This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4451 From iignatyev at openjdk.java.net Thu Jun 10 16:54:52 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 10 Jun 2021 16:54:52 GMT Subject: RFR: 8267448: Add "ulimit -a" to environment.html In-Reply-To: <4UGs3avpcoXZtLgyl_8Hj8lapTPwVGk3FIP61i-dIXM=.4827f8f7-778b-439f-966c-c139ab3abd46@github.com> References: <4UGs3avpcoXZtLgyl_8Hj8lapTPwVGk3FIP61i-dIXM=.4827f8f7-778b-439f-966c-c139ab3abd46@github.com> Message-ID: On Thu, 10 Jun 2021 06:26:53 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that does $subj? > > Thanks, > -- Igor > > attn: @plummercj closing in favor of openjdk/jdk17#2 ------------- PR: https://git.openjdk.java.net/jdk/pull/4451 From vromero at openjdk.java.net Thu Jun 10 17:16:50 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 10 Jun 2021 17:16:50 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote: > Looks like the test does not verify the cases specified by `valueOf(int refKind, boolean isInterface)`. > i.e. For most values of refKind, there is an exact match regardless of the value of isInterface except `REF_invokeStatic` and `REF_invokeSpecial`. > > Do you mind adding those cases? hum, the spec for `valueOf(int refKind, boolean isInterface)` is incorrect, the behavior does depends on the value of `isInterface` for example: `Kind.valueOf(1, false)` returns GETTER while `Kind.valueOf(1, true)` fails with `java.lang.IllegalArgumentException` will fix the implementation of `valueOf(int refKind, boolean isInterface)` for it to match its spec ------------- PR: https://git.openjdk.java.net/jdk/pull/4416 From lmesnik at openjdk.java.net Thu Jun 10 17:49:09 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 10 Jun 2021 17:49:09 GMT Subject: Integrated: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes In-Reply-To: References: Message-ID: On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik wrote: > EFH is improved to process cores and get mixed stack traces with jhsdb and native stack traces with gdb/lldb. It might be useful because hs_err doesn't contain info about all threads, sometimes it is even not generated. This pull request has now been integrated. Changeset: 8c8422e0 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/8c8422e0f8886d9bbfca29fd228368f88bf46f2c Stats: 159 lines in 12 files changed: 130 ins; 7 del; 22 mod 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes Reviewed-by: iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/4234 From vromero at openjdk.java.net Thu Jun 10 23:26:21 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 10 Jun 2021 23:26:21 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2] In-Reply-To: References: Message-ID: > Please review this PR which is just syncing the implementation of DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the method's spec is that if the value of the `refKind` parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of `true` for its second argument, currently it is invoked with `false` regardless of the value of the `refKind` parameter > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4416/files - new: https://git.openjdk.java.net/jdk/pull/4416/files/ea47769d..a5e1c8e5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4416&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4416&range=00-01 Stats: 19 lines in 2 files changed: 16 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4416/head:pull/4416 PR: https://git.openjdk.java.net/jdk/pull/4416 From vromero at openjdk.java.net Thu Jun 10 23:26:22 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 10 Jun 2021 23:26:22 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> addressing review changes > > test/jdk/java/lang/constant/MethodHandleDescTest.java line 362: > >> 360: public void testKind() { >> 361: for (Kind k : Kind.values()) { >> 362: assertEquals(Kind.valueOf(k.refKind), Kind.valueOf(k.refKind, k.refKind == MethodHandleInfo.REF_invokeInterface)); > > Looks like the test does not verify the cases specified by `valueOf(int refKind, boolean isInterface)`. > i.e. For most values of refKind, there is an exact match regardless of the value of isInterface except `REF_invokeStatic` and `REF_invokeSpecial`. > > Do you mind adding those cases? @mlchung I have updated the PR with another commit, thanks for your comments ------------- PR: https://git.openjdk.java.net/jdk/pull/4416 From weijun at openjdk.java.net Fri Jun 11 01:56:55 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Jun 2021 01:56:55 GMT Subject: Withdrawn: 8268349: Provide more detail in JEP 411 warning messages In-Reply-To: References: Message-ID: On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4400 From mchung at openjdk.java.net Fri Jun 11 02:52:50 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Jun 2021 02:52:50 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2] In-Reply-To: References: Message-ID: <34z0TelXSIxu_M1tm6L2y5Vzhv5nA85tutV_WwAtOoI=.2e8cd20e-7327-484b-8163-c99ffddfc758@github.com> On Thu, 10 Jun 2021 23:26:21 GMT, Vicente Romero wrote: >> Please review this PR which is just syncing the implementation of DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the method's spec is that if the value of the `refKind` parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of `true` for its second argument, currently it is invoked with `false` regardless of the value of the `refKind` parameter >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review changes src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java line 143: > 141: } > 142: if (kind.refKind == refKind && > 143: (refKind != REF_invokeStatic || refKind != REF_invokeSpecial || kind.isInterface == isInterface)){ It reads to me that the static initializer tries to set up the table such that `valueOf(refKind, isInterface)` should find the proper kind to return except this: // There is not a specific Kind for interfaces if (kind == VIRTUAL) kind = INTERFACE_VIRTUAL; This changes the entry for `REF_invokeVirtual` to kind `INTERFACE_VIRTUAL`. Do you know why? If this entry is set to VIRTUAL, then each refKind has two entries in the table corresponding to the correct result for `valueOf`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4416 From mchung at openjdk.java.net Fri Jun 11 02:52:50 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Jun 2021 02:52:50 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 23:23:23 GMT, Vicente Romero wrote: >> test/jdk/java/lang/constant/MethodHandleDescTest.java line 362: >> >>> 360: public void testKind() { >>> 361: for (Kind k : Kind.values()) { >>> 362: assertEquals(Kind.valueOf(k.refKind), Kind.valueOf(k.refKind, k.refKind == MethodHandleInfo.REF_invokeInterface)); >> >> Looks like the test does not verify the cases specified by `valueOf(int refKind, boolean isInterface)`. >> i.e. For most values of refKind, there is an exact match regardless of the value of isInterface except `REF_invokeStatic` and `REF_invokeSpecial`. >> >> Do you mind adding those cases? > > @mlchung I have updated the PR with another commit, thanks for your comments It may be better to create a new JBS issue to fix this bug as it may take more time to investigate. ------------- PR: https://git.openjdk.java.net/jdk/pull/4416 From david.holmes at oracle.com Fri Jun 11 06:11:40 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jun 2021 16:11:40 +1000 Subject: Windows aarch64 (build debug) constantly fails In-Reply-To: <5243221623322682@vla5-3610e71ecd90.qloud-c.yandex.net> References: <5243221623322682@vla5-3610e71ecd90.qloud-c.yandex.net> Message-ID: <870dded6-faea-3828-b070-5a64c82baf8f@oracle.com> Hi, On 10/06/2021 8:58 pm, ?????? ??????? wrote: > Hello, in the pipeline of my JDK fork the mentioned build step constantly fails even providing I modify only Java code > > I see this message in the log > > Compiling 2 files for BUILD_JVMTI_TOOLS > LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' Yes this has been failing in Github actions for some time now. It appears to be a misconfigured Visual Studio installation. However there seems to be no way to report a problem in this regard so we seem to be stuck unless someone knows how to bring such issues to the attention of the Github support team ? Cheers, David ----- > make[3]: *** [gensrc/GensrcAdlc.gmk:63: /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/hotspot/variant-server/tools/adlc/adlc.exe] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [make/Main.gmk:248: hotspot-server-gensrc] Error 2 > > ERROR: Build failed for target 'default (hotspot)' in configuration 'windows-aarch64' (exit code 2) > > === Output from failing command(s) repeated here === > * For target hotspot_variant-server_tools_adlc_objs_BUILD_ADLC_link: > LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' > > * All command lines available in /cygdrive/d/a/jdk/jdk/jdk/build/windows-aarch64/make-support/failure-logs. > === End of repeated output === > > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:315: main] Error 2 > make: *** [/cygdrive/d/a/jdk/jdk/jdk/make/Init.gmk:186: default] Error 2 > Error: Process completed with exit code 1. > > Here's the link to particular run > > https://github.com/stsypanov/jdk/runs/2792324849 > > What can I do with this? > > Regards, > Sergey Tsypanov > From jai.forums2013 at gmail.com Fri Jun 11 06:27:34 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 11 Jun 2021 11:57:34 +0530 Subject: Windows aarch64 (build debug) constantly fails In-Reply-To: <870dded6-faea-3828-b070-5a64c82baf8f@oracle.com> References: <5243221623322682@vla5-3610e71ecd90.qloud-c.yandex.net> <870dded6-faea-3828-b070-5a64c82baf8f@oracle.com> Message-ID: <13d4c018-6d89-242b-ca22-a38dfad26ca3@gmail.com> Hello David, On 11/06/21 11:41 am, David Holmes wrote: > Hi, > > On 10/06/2021 8:58 pm, ?????? ??????? wrote: >> Hello, in the pipeline of my JDK fork the mentioned build step >> constantly fails even providing I modify only Java code >> >> I see this message in the log >> >> Compiling 2 files for BUILD_JVMTI_TOOLS >> LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' > > Yes this has been failing in Github actions for some time now. It > appears to be a misconfigured Visual Studio installation. However > there seems to be no way to report a problem in this regard so we seem > to be stuck unless someone knows how to bring such issues to the > attention of the Github support team ? > Unrelated to JDK project, last time when I had run into a Github actions issue, I had reported it as a issue at https://github.com/actions/virtual-environments and they were pretty responsive and helpful about it. -Jaikiran From david.holmes at oracle.com Fri Jun 11 06:36:48 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jun 2021 16:36:48 +1000 Subject: Windows aarch64 (build debug) constantly fails In-Reply-To: <13d4c018-6d89-242b-ca22-a38dfad26ca3@gmail.com> References: <5243221623322682@vla5-3610e71ecd90.qloud-c.yandex.net> <870dded6-faea-3828-b070-5a64c82baf8f@oracle.com> <13d4c018-6d89-242b-ca22-a38dfad26ca3@gmail.com> Message-ID: On 11/06/2021 4:27 pm, Jaikiran Pai wrote: > Hello David, > > On 11/06/21 11:41 am, David Holmes wrote: >> Hi, >> >> On 10/06/2021 8:58 pm, ?????? ??????? wrote: >>> Hello, in the pipeline of my JDK fork the mentioned build step >>> constantly fails even providing I modify only Java code >>> >>> I see this message in the log >>> >>> Compiling 2 files for BUILD_JVMTI_TOOLS >>> LINK : fatal error LNK1104: cannot open file 'libcpmt.lib' >> >> Yes this has been failing in Github actions for some time now. It >> appears to be a misconfigured Visual Studio installation. However >> there seems to be no way to report a problem in this regard so we seem >> to be stuck unless someone knows how to bring such issues to the >> attention of the Github support team ? >> > Unrelated to JDK project, last time when I had run into a Github actions > issue, I had reported it as a issue at > https://github.com/actions/virtual-environments and they were pretty > responsive and helpful about it. Thanks Jaikiran I'll give that a go. David > -Jaikiran > > From github.com+19194678+scientificware at openjdk.java.net Fri Jun 11 09:46:52 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Fri, 11 Jun 2021 09:46:52 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home [v2] In-Reply-To: References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> <9LCwJ9Y4oQbnZ452lIMOwF3TgmCaJ89Yb7yz4p-A2vU=.d31b14af-4c43-4806-879b-e2e2a1c3799c@github.com> Message-ID: On Wed, 9 Jun 2021 14:13:06 GMT, Erik Joelsson wrote: >> ScientificWare has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes to keep home_dtd null check. >> >> As suggested in conversation moving `+ File.separator` is more elegant than changing the `null` check. > > Marked as reviewed by erikj (Reviewer). Hi @erikj79 , Could you sponsor this change ? Best regards. ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From avoitylov at openjdk.java.net Fri Jun 11 10:03:44 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 11 Jun 2021 10:03:44 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v7] In-Reply-To: References: Message-ID: > Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. > > Problem being fixed: > > The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. > > Proposed fix: > > The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. > > The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. > > Testing: jtreg and jck testing with no regressions. A new regression test was developed. Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3976/files - new: https://git.openjdk.java.net/jdk/pull/3976/files/85005d57..f8423b97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=05-06 Stats: 47 lines in 5 files changed: 19 ins; 6 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/3976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976 PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Fri Jun 11 10:03:50 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 11 Jun 2021 10:03:50 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v6] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 20:56:14 GMT, Mandy Chung wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 207: > >> 205: * >> 206: * We use a static stack to hold the list of libraries we are >> 207: * loading, so that each thread maintains its own stack. > > line 206: no longer a static stack. line 206-207 can be replaced with: > > > * Each thread maintains its own stack to hold the list of libraries it is loading. Done. > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 213: > >> 211: * a different class loader, we raise UnsatisfiedLinkError. >> 212: */ >> 213: for (NativeLibraryImpl lib : NativeLibraryContext.get()) { > > I suggest to rename the `get` method of `NativeLibraryContext` to `current` that returns the current thread's context. Done. > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/LoadLibraryDeadlock.java line 49: > >> 47: InstantiationException | >> 48: IllegalAccessException ignore) { >> 49: System.out.println("Class Class1 not found."); > > In general a test should let the exception to propagate. In this case, the threads (both t1 and t2) can warp the exception and throw `RuntimeException` as it's an error. Fixed. > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/LoadLibraryDeadlock.java line 60: > >> 58: System.out.println("Signed jar loaded."); >> 59: } catch (ClassNotFoundException ignore) { >> 60: System.out.println("Class Class2 not found."); > > Same as above Fixed. > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 69: > >> 67: >> 68: private static OutputAnalyzer genKey() throws Throwable { >> 69: runCommandInTestClassPath("rm", "-f", KEYSTORE); > > Can you use `jdk.test.lib.util.FileUtils` instead of exec `rm -f`. Done. > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 84: > >> 82: >> 83: private static OutputAnalyzer createJar(String outputJar, String... classes) throws Throwable { >> 84: String jar = JDKToolFinder.getJDKTool("jar"); > > You can consider using `jdk.test.lib.util.JarUtils` to reduce the test execution time so that it can create the jar without exec'ing another process. I tried, but this doesn't work that well unfortunately with JarUtils.createJar() as it only produces a valid jar-file capable of triggering the issue when the compiled class files (jtreg @build output) are in the same directory as the current directory of the process calling JarUtils.createJar(). Jtreg @build outputs the compiled classes to a separate directory. Creation of a new jar process allows to change the current directory so that the relative paths to the class files are such that it would form the valid output jar-file. Alternatively we could copy the class files to the current directory prior to creating the jar-file, but that would introduce an extra step. Would you mind me keeping the createJar() in the test? > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 141: > >> 139: try { >> 140: return future.get(1000, TimeUnit.MILLISECONDS); >> 141: } catch (Exception ignoreAll) { > > if this is an unexpected error case, it should throw an exception. If this threw an exception, it wouldn't be possible to collect all available data from the process which is not yet completed. Throwing an exception would defeat the purpose of readAvailable() method. > test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 31: > >> 29: * @test >> 30: * @bug 8266310 >> 31: * @summary deadlock while loading the JNI code > > please update `@summary` with a description of the test (rather than the synposis of the bug). Updated. > test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java line 32: > >> 30: * @test >> 31: * @bug 8266310 >> 32: * @summary deadlock while loading the JNI code > > Please update `@summary` with a description of the test (rather than the synposis of the bug) Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Fri Jun 11 11:13:55 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 11 Jun 2021 11:13:55 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v7] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 10:03:44 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Mandy, thank you for review! I used all of your suggestions except for two places. Please see a responses in the conversation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Fri Jun 11 11:13:57 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 11 Jun 2021 11:13:57 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v6] In-Reply-To: References: Message-ID: On Mon, 31 May 2021 23:57:09 GMT, Mandy Chung wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 165: > >> 163: >> 164: runCommandInTestClassPath("rm", "-f", "*.jar") >> 165: .shouldHaveExitValue(0); > > You can use `jdk.test.lib.util.FileUtils` to delete a directory or a given path. Fixed. > test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 83: > >> 81: this.object = fromClass.newInstance(); >> 82: this.method = fromClass.getDeclaredMethod("loadLibrary"); >> 83: } catch (Exception error) { > > Nit: `s/Exception/ReflectiveOperationException/` as ROE is the specific checked exception you want to catch here. Fixed. > test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 84: > >> 82: this.method = fromClass.getDeclaredMethod("loadLibrary"); >> 83: } catch (Exception error) { >> 84: throw new Error(error); > > Error is fine. Most tests throw `RuntimeException` that can be another choice. Yes, used RuntimeException. > test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 92: > >> 90: try { >> 91: method.invoke(object); >> 92: } catch (Exception error) { > > Same here to catch the `ReflectiveOperationException`. Same here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From github.com+19194678+scientificware at openjdk.java.net Fri Jun 11 12:28:53 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Fri, 11 Jun 2021 12:28:53 GMT Subject: Integrated: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home In-Reply-To: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> Message-ID: On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare wrote: > This concerns [dtdbuilder tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). > > In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. > > So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home` string value is not `null`, causing an exception with the present test. > > The expected value is `"Must set property 'dtd_home'"` > > And in this case, should'nt we have a `System.exit(1)` too rather than a simple `return` ? This pull request has now been integrated. Changeset: 49112fa5 Author: ScientificWare Committer: Erik Joelsson URL: https://git.openjdk.java.net/jdk/commit/49112fa5752174a77fb5cd276fdd4240bf76bf82 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8265909: build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From github.com+19194678+scientificware at openjdk.java.net Fri Jun 11 12:36:15 2021 From: github.com+19194678+scientificware at openjdk.java.net (ScientificWare) Date: Fri, 11 Jun 2021 12:36:15 GMT Subject: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home [v2] In-Reply-To: References: <_w5ZE_R0t_GeIFXIJaRhbqf00DRk4VFDuWU3h-lsVcY=.dfd54449-9e96-49f6-93ff-7c5c52242763@github.com> <9LCwJ9Y4oQbnZ452lIMOwF3TgmCaJ89Yb7yz4p-A2vU=.d31b14af-4c43-4806-879b-e2e2a1c3799c@github.com> Message-ID: On Wed, 9 Jun 2021 14:13:06 GMT, Erik Joelsson wrote: >> ScientificWare has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes to keep home_dtd null check. >> >> As suggested in conversation moving `+ File.separator` is more elegant than changing the `null` check. > > Marked as reviewed by erikj (Reviewer). @erikj79 Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3626 From myano at openjdk.java.net Fri Jun 11 13:52:10 2021 From: myano at openjdk.java.net (Masanori Yano) Date: Fri, 11 Jun 2021 13:52:10 GMT Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML Message-ID: Hi all, Could you please review the 8268457 bug fixes? The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair. This fix changes the processing for non-surrogate pairs to the else condition. ------------- Commit messages: - clean up whitespace - 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML Changes: https://git.openjdk.java.net/jdk/pull/4474/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4474&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268457 Stats: 235 lines in 7 files changed: 223 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4474/head:pull/4474 PR: https://git.openjdk.java.net/jdk/pull/4474 From vromero at openjdk.java.net Fri Jun 11 15:08:02 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Jun 2021 15:08:02 GMT Subject: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling Message-ID: This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk. Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter TIA ------------- Commit messages: - 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling Changes: https://git.openjdk.java.net/jdk17/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267421 Stats: 21 lines in 2 files changed: 17 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk17/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk17/pull/29 From vromero at openjdk.java.net Fri Jun 11 15:15:59 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Jun 2021 15:15:59 GMT Subject: Withdrawn: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 16:46:36 GMT, Vicente Romero wrote: > Please review this PR which is just syncing the implementation of DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the method's spec is that if the value of the `refKind` parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of `true` for its second argument, currently it is invoked with `false` regardless of the value of the `refKind` parameter > > TIA This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4416 From vromero at openjdk.java.net Fri Jun 11 15:15:58 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Jun 2021 15:15:58 GMT Subject: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jun 2021 23:26:21 GMT, Vicente Romero wrote: >> Please review this PR which is just syncing the implementation of DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the method's spec is that if the value of the `refKind` parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of `true` for its second argument, currently it is invoked with `false` regardless of the value of the `refKind` parameter >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > addressing review changes I will be withdrawing this one to open a new [PR-29](https://github.com/openjdk/jdk17/pull/29) intended to jdk17, please let's follow the discussion there ------------- PR: https://git.openjdk.java.net/jdk/pull/4416 From vromero at openjdk.java.net Fri Jun 11 15:22:03 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Jun 2021 15:22:03 GMT Subject: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 15:01:20 GMT, Vicente Romero wrote: > This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk. > > Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter > > TIA src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java line 143: > 141: } > 142: if (kind.refKind == refKind && > 143: (refKind != REF_invokeStatic || refKind != REF_invokeSpecial || kind.isInterface == isInterface)){ @mlchung 13 hours ago Member It reads to me that the static initializer tries to set up the table such that valueOf(refKind, isInterface) should find the proper kind to return except this: // There is not a specific Kind for interfaces if (kind == VIRTUAL) kind = INTERFACE_VIRTUAL; This changes the entry for REF_invokeVirtual to kind INTERFACE_VIRTUAL. Do you know why? If this entry is set to VIRTUAL, then each refKind has two entries in the table corresponding to the correct result for valueOf. test/jdk/java/lang/constant/MethodHandleDescTest.java line 364: > 362: public void testKind() { > 363: for (Kind k : Kind.values()) { > 364: assertEquals(Kind.valueOf(k.refKind), Kind.valueOf(k.refKind, k.refKind == MethodHandleInfo.REF_invokeInterface)); @mlchung mlchung 2 days ago Member Looks like the test does not verify the cases specified by valueOf(int refKind, boolean isInterface). i.e. For most values of refKind, there is an exact match regardless of the value of isInterface except REF_invokeStatic and REF_invokeSpecial. Do you mind adding those cases? @vicente-romero-oracle vicente-romero-oracle 22 hours ago ? hum, the implementation for valueOf(int refKind, boolean isInterface) is incorrect, the behavior does depends on the value of isInterface for example: Kind.valueOf(1, false) returns GETTER while Kind.valueOf(1, true) fails with java.lang.IllegalArgumentException will fix the implementation of valueOf(int refKind, boolean isInterface) for it to match its spec ------------- PR: https://git.openjdk.java.net/jdk17/pull/29 From chegar at openjdk.java.net Fri Jun 11 15:33:12 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 11 Jun 2021 15:33:12 GMT Subject: [jdk17] RFR: 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" Message-ID: <21tZNep8vfy50l1QvAEpBBNhaZMgfl8wK7iH908XB_Q=.6e3e51b7-3910-480f-9a86-08858c6e38d4@github.com> There is the possibility for a race in the test, where the outbound socket buffer is still being filled, after 5 seconds, when the main test thread tries to close the resource scope. The test has been updated to set the send/receive buffer sizes in an attempt/hint to limit the accepted/connected socket buffer sizes. Actual buffer sizes in use will likely be larger due to TCP auto-tuning, but the hint typically reduces the overall scaled sizes. This is primarily to stabilize outstanding write operations. Additionally, to ameliorate the wait-for-writebuf-to-fill situation, the dumb sleep 5secs has been replaced with a heuristic that checks that the number of bytes written quiesces. With these changes, the test successfully passes several thousands of runs. ------------- Commit messages: - initial changes Changes: https://git.openjdk.java.net/jdk17/pull/30/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=30&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268342 Stats: 52 lines in 1 file changed: 46 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/30/head:pull/30 PR: https://git.openjdk.java.net/jdk17/pull/30 From dfuchs at openjdk.java.net Fri Jun 11 16:31:49 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 11 Jun 2021 16:31:49 GMT Subject: [jdk17] RFR: 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" In-Reply-To: <21tZNep8vfy50l1QvAEpBBNhaZMgfl8wK7iH908XB_Q=.6e3e51b7-3910-480f-9a86-08858c6e38d4@github.com> References: <21tZNep8vfy50l1QvAEpBBNhaZMgfl8wK7iH908XB_Q=.6e3e51b7-3910-480f-9a86-08858c6e38d4@github.com> Message-ID: On Fri, 11 Jun 2021 15:26:50 GMT, Chris Hegarty wrote: > There is the possibility for a race in the test, where the outbound socket buffer is still being filled, after 5 seconds, when the main test thread tries to close the resource scope. > > The test has been updated to set the send/receive buffer sizes in an attempt/hint to limit the accepted/connected socket buffer sizes. Actual buffer sizes in use will likely be larger due to TCP auto-tuning, but the hint typically reduces the overall scaled sizes. This is primarily to stabilize outstanding write operations. Additionally, to ameliorate the wait-for-writebuf-to-fill situation, the dumb sleep 5secs has been replaced with a heuristic that checks that the number of bytes written quiesces. With these changes, the test successfully passes several thousands of runs. Looks good but you could make the logic simpler by calling latch.countDown() in the last call to completed(), instead of doing it in the first one. test/jdk/java/foreign/channels/TestAsyncSocketChannels.java line 283: > 281: readNBytes(asc2, bytesWritten.get()); > 282: assertTrue(scope.isAlive()); > 283: awaitOutstandingWrites(outstandingWriteOps); An alternative would be to delegate the call to latch.countDown() to the TestHandler subclass, and call it at the end of completed() only when outstandingWriteOps.decrementAndGet() == 0; As it stands the latch is released with the first call to `completed` (instead of being released with the last one) - and that's what makes this method necessary. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/30 From vromero at openjdk.java.net Fri Jun 11 16:37:53 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Jun 2021 16:37:53 GMT Subject: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 15:15:12 GMT, Vicente Romero wrote: >> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk. >> >> Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter >> >> TIA > > src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java line 143: > >> 141: } >> 142: if (kind.refKind == refKind && >> 143: (refKind != REF_invokeStatic || refKind != REF_invokeSpecial || kind.isInterface == isInterface)){ > > @mlchung 13 hours ago Member > > It reads to me that the static initializer tries to set up the table such that valueOf(refKind, isInterface) should find the proper kind to return except this: > > // There is not a specific Kind for interfaces > if (kind == VIRTUAL) kind = INTERFACE_VIRTUAL; > > This changes the entry for REF_invokeVirtual to kind INTERFACE_VIRTUAL. Do you know why? If this entry is set to VIRTUAL, then each refKind has two entries in the table corresponding to the correct result for valueOf. this is the table that is being generated right now: Table has 20 entries 0: null 1: null 2: Kind: [name: GETTER, refKind: 1, isInterface: false] 3: Kind: [name: GETTER, refKind: 1, isInterface: false] 4: Kind: [name: STATIC_GETTER, refKind: 2, isInterface: false] 5: Kind: [name: STATIC_GETTER, refKind: 2, isInterface: false] 6: Kind: [name: SETTER, refKind: 3, isInterface: false] 7: Kind: [name: SETTER, refKind: 3, isInterface: false] 8: Kind: [name: STATIC_SETTER, refKind: 4, isInterface: false] 9: Kind: [name: STATIC_SETTER, refKind: 4, isInterface: false] 10: Kind: [name: VIRTUAL, refKind: 5, isInterface: false] 11: Kind: [name: INTERFACE_VIRTUAL, refKind: 9, isInterface: true] 12: Kind: [name: STATIC, refKind: 6, isInterface: false] 13: Kind: [name: INTERFACE_STATIC, refKind: 6, isInterface: true] 14: Kind: [name: SPECIAL, refKind: 7, isInterface: false] 15: Kind: [name: INTERFACE_SPECIAL, refKind: 7, isInterface: true] 16: Kind: [name: CONSTRUCTOR, refKind: 8, isInterface: false] 17: Kind: [name: CONSTRUCTOR, refKind: 8, isInterface: false] 18: Kind: [name: INTERFACE_VIRTUAL, refKind: 9, isInterface: true] 19: Kind: [name: INTERFACE_VIRTUAL, refKind: 9, isInterface: true] ------------- PR: https://git.openjdk.java.net/jdk17/pull/29 From chegar at openjdk.java.net Fri Jun 11 16:50:51 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Fri, 11 Jun 2021 16:50:51 GMT Subject: [jdk17] RFR: 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" In-Reply-To: References: <21tZNep8vfy50l1QvAEpBBNhaZMgfl8wK7iH908XB_Q=.6e3e51b7-3910-480f-9a86-08858c6e38d4@github.com> Message-ID: On Fri, 11 Jun 2021 16:27:07 GMT, Daniel Fuchs wrote: >> There is the possibility for a race in the test, where the outbound socket buffer is still being filled, after 5 seconds, when the main test thread tries to close the resource scope. >> >> The test has been updated to set the send/receive buffer sizes in an attempt/hint to limit the accepted/connected socket buffer sizes. Actual buffer sizes in use will likely be larger due to TCP auto-tuning, but the hint typically reduces the overall scaled sizes. This is primarily to stabilize outstanding write operations. Additionally, to ameliorate the wait-for-writebuf-to-fill situation, the dumb sleep 5secs has been replaced with a heuristic that checks that the number of bytes written quiesces. With these changes, the test successfully passes several thousands of runs. > > test/jdk/java/foreign/channels/TestAsyncSocketChannels.java line 283: > >> 281: readNBytes(asc2, bytesWritten.get()); >> 282: assertTrue(scope.isAlive()); >> 283: awaitOutstandingWrites(outstandingWriteOps); > > An alternative would be to delegate the call to latch.countDown() to the TestHandler subclass, and call it at the end of completed() only when outstandingWriteOps.decrementAndGet() == 0; As it stands the latch is released with the first call to `completed` (instead of being released with the last one) - and that's what makes this method necessary. Strictly speaking it wasn't necessary to touch this area of code to resolve the failures that we're seeing - I decided to refactor this into a separate method to improve readability of the test logic. Here again, awaiting for completion is not strictly necessary, just good practice to ensure that all threads and operations associated with the test scenario complete before the next scenario. I'll see if this can be simplified as you suggest. ------------- PR: https://git.openjdk.java.net/jdk17/pull/30 From iveresov at openjdk.java.net Fri Jun 11 17:59:54 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 11 Jun 2021 17:59:54 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > more comment Alright, tests pass now. I think we're good to go. ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From iveresov at openjdk.java.net Fri Jun 11 18:08:49 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 11 Jun 2021 18:08:49 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > more comment I guess you need to do the "integrate" command again. ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From vromero at openjdk.java.net Fri Jun 11 18:17:10 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Jun 2021 18:17:10 GMT Subject: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2] In-Reply-To: References: Message-ID: <-AWxe73HwY-dRtFmCot7-gB5T3QciRfYScrEls-Ezeo=.fe6e88c2-db17-4b38-9729-8a923c04efec@github.com> > This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk. > > Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: updating after review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/29/files - new: https://git.openjdk.java.net/jdk17/pull/29/files/b6b3f87c..8ed4cdb3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=29&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=29&range=00-01 Stats: 12 lines in 1 file changed: 0 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk17/pull/29 From vromero at openjdk.java.net Fri Jun 11 18:40:55 2021 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Jun 2021 18:40:55 GMT Subject: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2] In-Reply-To: <-AWxe73HwY-dRtFmCot7-gB5T3QciRfYScrEls-Ezeo=.fe6e88c2-db17-4b38-9729-8a923c04efec@github.com> References: <-AWxe73HwY-dRtFmCot7-gB5T3QciRfYScrEls-Ezeo=.fe6e88c2-db17-4b38-9729-8a923c04efec@github.com> Message-ID: On Fri, 11 Jun 2021 18:17:10 GMT, Vicente Romero wrote: >> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk. >> >> Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > updating after review comments @mlchung I have uploaded a new commit, thanks for your comments ------------- PR: https://git.openjdk.java.net/jdk17/pull/29 From lmesnik at openjdk.java.net Fri Jun 11 18:52:07 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 11 Jun 2021 18:52:07 GMT Subject: RFR: 8268626: Remove native pre-jdk9 support for jtreg failure handler Message-ID: jtreg failure handler uses native lib to implement getPid for preJDK9. Currently. it is not needed and might be removed. ------------- Commit messages: - native lib support removed. Changes: https://git.openjdk.java.net/jdk/pull/4476/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4476&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268626 Stats: 100 lines in 4 files changed: 0 ins; 96 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4476/head:pull/4476 PR: https://git.openjdk.java.net/jdk/pull/4476 From erikj at openjdk.java.net Fri Jun 11 20:05:54 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 11 Jun 2021 20:05:54 GMT Subject: RFR: 8268626: Remove native pre-jdk9 support for jtreg failure handler In-Reply-To: References: Message-ID: <2UtBNyAOeyjdMpsYHqp4McwXAdhbg9l9bED75w6SKG8=.3fec402a-7826-47ad-937d-b0ea79d63e11@github.com> On Fri, 11 Jun 2021 18:44:38 GMT, Leonid Mesnik wrote: > jtreg failure handler uses native lib to implement getPid for preJDK9. Currently. it is not needed and might be removed. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4476 From yyang at openjdk.java.net Sat Jun 12 01:06:58 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Sat, 12 Jun 2021 01:06:58 GMT Subject: Integrated: 8265518: C1: Intrinsic support for Preconditions.checkIndex In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 06:55:41 GMT, Yi Yang wrote: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk This pull request has now been integrated. Changeset: 5cee23a9 Author: Yi Yang URL: https://git.openjdk.java.net/jdk/commit/5cee23a9ed0b7fe2657be7492d9c1f78fcd02ebf Stats: 347 lines in 11 files changed: 250 ins; 78 del; 19 mod 8265518: C1: Intrinsic support for Preconditions.checkIndex Reviewed-by: dfuchs, iveresov ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Sat Jun 12 01:06:56 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Sat, 12 Jun 2021 01:06:56 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: <-kHu9fSLdqH287-Ud0MjAss-Jg8WBZZqRkL8PwKr-Yw=.77104be0-952d-44da-9390-22aca4ed21f0@github.com> On Fri, 11 Jun 2021 18:05:45 GMT, Igor Veresov wrote: > I guess you need to do the "integrate" command again. Okay?thank you all for taking time to look at this ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From simonis at openjdk.java.net Sat Jun 12 06:32:55 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Sat, 12 Jun 2021 06:32:55 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > more comment This change removed a product flag so I wonder how it could be integrated without a CSR? ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From stuefe at openjdk.java.net Sat Jun 12 06:53:57 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 12 Jun 2021 06:53:57 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: On Sat, 12 Jun 2021 06:29:50 GMT, Volker Simonis wrote: > This change removed a product flag so I wonder how it could be integrated without a CSR? And if the intention was to remove it, should it not have been marked as obsolete first? ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Sat Jun 12 06:56:57 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Sat, 12 Jun 2021 06:56:57 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: On Sat, 12 Jun 2021 06:50:48 GMT, Thomas Stuefe wrote: > This change removed a product flag so I wonder how it could be integrated without a CSR? It's a diagnostic product flag, so it? okay to remove it without issuing CSR. But I am not 100% sure. @dholmes-ora, do you have any comment about this? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From simonis at openjdk.java.net Sat Jun 12 07:04:53 2021 From: simonis at openjdk.java.net (Volker Simonis) Date: Sat, 12 Jun 2021 07:04:53 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > more comment Looks like you are right Yi: https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process Seems like for diagnostic flags the creation of a CSR is up to the developer. Sorry for the confusion. Yi Yang ***@***.***> schrieb am Sa., 12. Juni 2021, 08:54: > This change removed a product flag so I wonder how it could be integrated > without a CSR? > > It's a diagnostic product flag, so it? okay to remove it without issuing > CSR. But I am not 100% sure. > > @dholmes-ora , do you have any comment > about this? Thanks! > > ? > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From stuefe at openjdk.java.net Sat Jun 12 08:25:52 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 12 Jun 2021 08:25:52 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: <9ixWD6Ea4OUcXAzU5s2Y68URPHJvq8RO5g-go6k1aMw=.e52e0571-e07d-4c5f-8afb-6b2408efd4a0@github.com> On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > more comment Hi Yi, you may need to add the option to the obsolete-flags-table though as described in arguments.cpp: https://github.com/openjdk/jdk/blob/5cee23a9ed0b7fe2657be7492d9c1f78fcd02ebf/src/hotspot/share/runtime/arguments.cpp#L489-L490 I think the point is to give a customer a grace period where the option is still accepted on the command line. I am not sure if that step is optional though, if one is reasonably sure that the option is unused. Maybe @dholmes-ora can chime in. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From rafael.wth at gmail.com Sun Jun 13 20:28:33 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Sun, 13 Jun 2021 22:28:33 +0200 Subject: JEP 411: Deprecation with removal would break most existing Java libraries Message-ID: I am currently looking into how I should address JEP 411 in my library Byte Buddy and I find it rather challenging. The problem I am facing is that I know of several users who rely on the security manager in their Java 8/11 applications. I would like to continue to support those users' use cases as long as I support Java versions that contain the security manager, which will be for many years to come. At the same time, I would like to address the announced removal of the API and make sure that Byte Buddy can work without it prior to the deadline when the library in its current state would no longer link. >From my understanding of the intention of JEP 411, the API was supposed to be stubbed ? similar to Android?s stubbing of the API - rather than being removed. However, with the announced deprecation for removal of AccessController and SecurityManager, I understand that I would need to fully remove the dispatching to work with future Java versions. Furthermore, it is difficult to create a working facade for dispatching to the security manager only if it is available. Methods like AccessController.doPrivileged are caller sensitive and by adding a utility to a library, this utility would leak to any potential user. It would therefore require package-private dispatchers for any relevant package, which would lead to a lot of copy-paste to retain backwards compatibility (given that a library cannot assume to be run as a module). Finally, removing the API would mean that Byte Buddy versions of the last ten years would no longer link in future JDKs. For Byte Buddy where new Java versions often require an update, that might not be a big issue but many other libraries do support the API, I don?t feel it would be a rather severe restriction and cause unnecessary breakage if API is removed, rather than stubbed. I am thinking of libraries like Netty here which are rather omnipresent and would suddenly no longer link, a concept that is unlikely intuitive to a lot of developers. Therefore, my question is: should SecurityManager, AccessController and the Policy APIs really be deprecated for removal? Rather, I think that the APIs should be deprecated, but be retained with stubbed implementations. System.getSecurityMananger would then always return null. System.setSecurityManager on the other hand could be deprecated for removal. This way, existing code could continue to work as if the security manager is not active, which already is the common scenario and would not cause any disruption at the small price of keeping a handful of some stubbed classes. Thanks for advice on how this is intended to be handled by library developers like me. Best regards, Rafael From forax at univ-mlv.fr Sun Jun 13 21:21:12 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 13 Jun 2021 23:21:12 +0200 (CEST) Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: Message-ID: <2097586730.118227.1623619272151.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Rafael Winterhalter" > ?: "core-libs-dev" > Envoy?: Dimanche 13 Juin 2021 22:28:33 > Objet: JEP 411: Deprecation with removal would break most existing Java libraries > I am currently looking into how I should address JEP 411 in my library Byte > Buddy and I find it rather challenging. The problem I am facing is that I > know of several users who rely on the security manager in their Java 8/11 > applications. I would like to continue to support those users' use cases as > long as I support Java versions that contain the security manager, which > will be for many years to come. At the same time, I would like to address > the announced removal of the API and make sure that Byte Buddy can work > without it prior to the deadline when the library in its current state > would no longer link. Can you tell us about more about the scenarii where people are relying on the uses of doPrivileged() by ByteBuddy ? > > From my understanding of the intention of JEP 411, the API was supposed to > be stubbed ? similar to Android?s stubbing of the API - rather than being > removed. However, with the announced deprecation for removal of > AccessController and SecurityManager, I understand that I would need to > fully remove the dispatching to work with future Java versions. > > Furthermore, it is difficult to create a working facade for dispatching to > the security manager only if it is available. Methods like > AccessController.doPrivileged are caller sensitive and by adding a utility > to a library, this utility would leak to any potential user. It would > therefore require package-private dispatchers for any relevant package, > which would lead to a lot of copy-paste to retain backwards compatibility > (given that a library cannot assume to be run as a module). > > Finally, removing the API would mean that Byte Buddy versions of the last > ten years would no longer link in future JDKs. For Byte Buddy where new > Java versions often require an update, that might not be a big issue but > many other libraries do support the API, I don?t feel it would be a rather > severe restriction and cause unnecessary breakage if API is removed, rather > than stubbed. I am thinking of libraries like Netty here which are rather > omnipresent and would suddenly no longer link, a concept that is unlikely > intuitive to a lot of developers. In my opinion, the best way to deal with that is to have two codes one which is compatible with an AccessController.doPrivileged and one without it, using a multi release jar. I can see a Maven/Gradle plugin that takes a code that uses an AccessController and generate a new code with a higher Java version that remove the calls to AccessController, as a kind of forward port. But we are not yet there, AccessController has to be removed first. > > Therefore, my question is: should SecurityManager, AccessController and the > Policy APIs really be deprecated for removal? Rather, I think that the APIs > should be deprecated, but be retained with stubbed implementations. > System.getSecurityMananger would then always return null. > System.setSecurityManager on the other hand could be deprecated for > removal. This way, existing code could continue to work as if the security > manager is not active, which already is the common scenario and would not > cause any disruption at the small price of keeping a handful of some > stubbed classes. I guess the real question is when those classes will be removed. If it's after several LTS releases, nobody will care. If it's tomorrow, that's another story. > > Thanks for advice on how this is intended to be handled by library > developers like me. > Best regards, Rafael regards, R?mi From donraab at gmail.com Mon Jun 14 04:01:39 2021 From: donraab at gmail.com (Donald Raab) Date: Mon, 14 Jun 2021 00:01:39 -0400 Subject: New convenience methods on Stream In-Reply-To: References: Message-ID: Thank you for the response Tagir! The intent of all three of these proposals to was to explore better ways of providing improved interop between Streams and 3rd party collection libraries. I agree with you on option 1. This is my least favorite option, but seemed the most obvious shortcut and should be relatively straightforward to implement. It primarily saves characters, and can save creating additional Collectors that then have to be discovered and learned by developers. We named our static utility class in Eclipse Collections Collectors2 to try and help with discovery as it should show up near Collectors in IDE lookups. Option 3 is also straightforward to implement, and has the additional utility you identified for existing collections. As you point out it can also be optimized for JDK types like ArrayList. Unfortunately, there is no general interface for ensureCapacity, although maybe there could be if this method is deemed worthwhile. Option 2 was interesting to me because there are quite a few existing methods in 3rd party collection libraries that take var args as an argument to create collection types. I found and listed 24 factory methods below in different frameworks where I found this could be used today, and there are likely many more. It did bother me having a '(T[])? cast but I couldn?t see another alternative that would allow for all these existing var arg methods to be useful. I had thought of something similar to the Stream transform idea you shared, and this works with Eclipse Collections today as we have factory methods which take Streams, but I didn?t initially see this option working anywhere else today as I couldn?t find any other library providing factory methods that take Streams. That doesn?t mean they couldn't be added eventually of course, but I was looking at what was available to leverage today. The transform idea you linked to would work as follows with Eclipse Collections: MutableList list = stream.transform(Lists.mutable::fromStream) MutableSet set = stream.transform(Sets.mutable::fromStream) // compared to collect with Collectors2 today MutableList list = stream.collect(Collectors2.toList()) MutableSet set = stream.collect(Collectors2.toSet()) ImmutableList list = stream.transform(Lists.immutable::fromStream) ImmutableSet set = stream.transform(Sets.immutable::fromStream) // compared to collect with Collectors2 today MutableList list = stream.collect(Collectors2.toImmutableList()) MutableSet set = stream.collect(Collectors2.toImmutableSet()) In terms of character savings, this is less helpful that calling the method ?to?, but this was never about just character savings. I think I could live with transform(Function, U> function). Having read your email a few times now and the link to the Bug in the Bug System you provided, I agree with the usefulness of the transform approach. Thank you for taking the time to describe this. I would upvote the bug if I could. Thanks, Don > On Apr 30, 2021, at 9:25 PM, Tagir Valeev wrote: > > Hello! > > 1. toCollection looks too specific to be added to JDK. Essentially, > it's a shortcut for toCollection constructor and unlike toList, it > cannot add many optimizations there. So we basically save several > characters and nothing more. And toCollection collector is orders of > magnitude less used than toList. I think that it's even less used than > joining or groupingBy, so why not providing these shortcuts first? > It's always about where to draw a line. > > 2. to() sounds quite specific, as it expects that the target object is > ready to accept an array. But why? Probably its API more suitable to > accept a collection as an input? It's essentially 'toArrayAndThen' > (similar to 'collectingAndThen' collector). There's a suggestion [1] > to add transform() method to stream which is much more general, and > can be used like `stream.transform(s -> Arrays.asList(s.toArray()))`. > Note that collection libraries may provide ready methods that supply > the lambdas specific to this library, and this allows to encapsulate > the exact implementation detail, like whether we need an array or > something else as an intermediate step, like: > > class MyCustomCollection { > ... > static Function, MyCustomCollection> toMyCustomCollection() { > return s -> createMyCustomCollectionFromStream((T[])s.toArray()); > // in the next version we may change to for-each version if we > find that it's more performant > // or s -> {var c = new MyCustomCollection(); > s.forEach(c::add); return c;} > } > } > > And use `stream.transform(MyCustomCollection.toMyCustomCollection())` > without caring whether it's array or something else in-between. > > Finally, adding a `(T[])` cast to the standard library sounds a bad > idea. Imagine if the custom collection has a fixed element type: > > class MyStringCollection implements Collection { > public MyStringCollection(String[] array) {...} > } > > It looks like stream.to(MyStringCollection::new) should work but in > fact, it will throw a ClassCastException > > 3. into() sounds more interesting as it's indeed useful to dump the > stream into an existing collection. It's mostly useful if the > collection is non-empty, as you can append into single collection from > existing sources. Essentially, into(c) == forEach(c::add), but it's > also possible to add optimizations for specific collections (like `if > (isSizedStream() && c instanceof ArrayList al) { > al.ensureCapacity(...); }`), so it could be faster. > > With best regards, > Tagir Valeev > > [1] https://bugs.openjdk.java.net/browse/JDK-8140283 > > On Thu, Apr 29, 2021 at 5:58 AM Donald Raab wrote: >> >> I looked through a few libraries and found some methods where the option #2 proposal for Steam might be useful. If the JDK had constructors for ArrayList, HashSet and other collection types that take arrays this method would work there as well. >> >>> default > R to(Function function) >>> { >>> return function.apply((T[]) this.toArray()); >>> } >> >> >> // JDK >> Set set = stream.to(Set::of); >> List list = stream.to(List::of); >> List arraysAsList = stream.to(Arrays::asList); >> >> // Guava >> ArrayList arrayList = stream.to(Lists::newArrayList); >> HashSet hashSet = stream.to(Sets::newHashSet); >> Multiset multiset = stream.to(ImmutableMultiset::copyOf); >> List guavaList = stream.to(ImmutableList::copyOf); >> Set guavaSet = stream.to(ImmutableSet::copyOf); >> >> // Apache Commons Collections >> FluentIterable fluentIterable = stream.to(FluentIterable::of); >> >> // Eclipse Collections >> MutableList adapter = stream.to(ArrayAdapter::adapt); >> >> MutableList mutableList = stream.to(Lists.mutable::with); >> MutableSet mutableSet = stream.to(Sets.mutable::with); >> MutableBag mutableBag = stream.to(Bags.mutable::with); >> >> // Eclipse Collections - ListIterable, SetIterable and Bag all extend Iterable, not Collection >> ListIterable listIterable = stream.to(Lists.mutable::with); >> SetIterable setIterable = stream.to(Sets.mutable::with); >> Bag bag = stream.to(Bags.mutable::with); >> >> // Eclipse Collections - Immutable Collections do not extend Collection >> ImmutableList immutableList = stream.to(Lists.immutable::with); >> ImmutableSet immutableSet = stream.to(Sets.immutable::with); >> ImmutableBag immutableBag = stream.to(Bags.immutable::with); >> >> // Eclipse Collections - Stack does not extend Collection >> StackIterable stackIterable = stream.to(Stacks.mutable::with); >> MutableStack mutableStack = stream.to(Stacks.mutable::with); >> ImmutableStack immutableStack = stream.to(Stacks.immutable::with); >> >> // Eclipse Collections - Mutable Map and MutableBiMap are both Iterable so they are valid returns >> MutableMap map = >> stream.to(array -> ArrayAdapter.adapt(array) >> .toMap(String::toLowerCase, String::toUpperCase)); >> >> MutableBiMap biMap = >> stream.to(array -> ArrayAdapter.adapt(array) >> .toBiMap(String::toLowerCase, String::toUpperCase)); >> >> Thanks, >> Don >> >>> On Apr 27, 2021, at 1:35 AM, Donald Raab wrote: >>> >>> I realized after sending that option 2 can be made more abstract: >>> >>> default > R to(Function function) >>> { >>> return function.apply((T[]) this.toArray()); >>> } >>> >>>> >>>> 2. Pass the result of toArray directly into a function that can then return a Collection. This should work with Set.of, List.of and any 3rd party collections which take arrays. >>>> >>>> default > R to(Function function) >>>> { >>>> return function.apply((T[]) this.toArray()); >>>> } >>>> >>>> Usage Examples: >>>> >>>> Set set = stream.to(Set::of); >>>> List list = stream.to(List::of); >>>> List arrayList = stream.to(Arrays::asList); >>>> >>> >> From Alan.Bateman at oracle.com Mon Jun 14 05:54:51 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jun 2021 06:54:51 +0100 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: Message-ID: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> cc'ing security-dev as that is the mailing list to use for this JEP. This JEP is the first of several in a multi-release/multi-year effort. It's way too early to give any guess as to when the APIs will be removed. As the JEP says, future releases may degrade the SM APIs so that System.getSM returns always returns null or AccessController::doPriv just runs the action. This should mean that libraries that are compiling to older releases should continue to compile and run on those releases. When they run on some future release that degrades the implementation then it will be as if there is no SM.? So I would say the impact is little to none for libraries for the foreseeable future. -Alan On 13/06/2021 21:28, Rafael Winterhalter wrote: > I am currently looking into how I should address JEP 411 in my library Byte > Buddy and I find it rather challenging. The problem I am facing is that I > know of several users who rely on the security manager in their Java 8/11 > applications. I would like to continue to support those users' use cases as > long as I support Java versions that contain the security manager, which > will be for many years to come. At the same time, I would like to address > the announced removal of the API and make sure that Byte Buddy can work > without it prior to the deadline when the library in its current state > would no longer link. > > From my understanding of the intention of JEP 411, the API was supposed to > be stubbed ? similar to Android?s stubbing of the API - rather than being > removed. However, with the announced deprecation for removal of > AccessController and SecurityManager, I understand that I would need to > fully remove the dispatching to work with future Java versions. > > Furthermore, it is difficult to create a working facade for dispatching to > the security manager only if it is available. Methods like > AccessController.doPrivileged are caller sensitive and by adding a utility > to a library, this utility would leak to any potential user. It would > therefore require package-private dispatchers for any relevant package, > which would lead to a lot of copy-paste to retain backwards compatibility > (given that a library cannot assume to be run as a module). > > Finally, removing the API would mean that Byte Buddy versions of the last > ten years would no longer link in future JDKs. For Byte Buddy where new > Java versions often require an update, that might not be a big issue but > many other libraries do support the API, I don?t feel it would be a rather > severe restriction and cause unnecessary breakage if API is removed, rather > than stubbed. I am thinking of libraries like Netty here which are rather > omnipresent and would suddenly no longer link, a concept that is unlikely > intuitive to a lot of developers. > > Therefore, my question is: should SecurityManager, AccessController and the > Policy APIs really be deprecated for removal? Rather, I think that the APIs > should be deprecated, but be retained with stubbed implementations. > System.getSecurityMananger would then always return null. > System.setSecurityManager on the other hand could be deprecated for > removal. This way, existing code could continue to work as if the security > manager is not active, which already is the common scenario and would not > cause any disruption at the small price of keeping a handful of some > stubbed classes. > > Thanks for advice on how this is intended to be handled by library > developers like me. > Best regards, Rafael From peter.firmstone at zeus.net.au Mon Jun 14 07:35:19 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 17:35:19 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> Message-ID: <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> My thoughts on how to proceed with this is: 1. Develop authorization layer security provider services in OpenJDK, back port it to Java 8 and Java 11 (these provide most of the utilised functionality of SecurityManager, allowing developers to only implement those which they need, without enabling SecurityManager and editing policy files). 2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19. 3. Leave AccessController and AccessControlContext in place, provide a security property that allows the stack walk to be disabled (One ProtectionDomain to represent all code in JVM, without any permissions, later making it the default, while allowing it to be enabled) and continue to inject user Subject principles using SubjectDomainCombiner for JAAS compatibility. Developers can implement just the authorization they feel necessary for users and develop their own configuration, or adapt existing. 4. At some point, preferably when StackWalker has equivalent performance, replace the internals of AccessController. Gut feel is that removal of AccessController, AccessControlContext and DomainCombiner causes carnage with JAAS, it's a lot to deal with, SecurityManager and Policy, I don't need them if I've got authorization layer hooks in the JVM. I wouldn't want to see SecurityManager and Policy be neutralized, it's better to remove it and fail early so people update their software, there's a risk they may update without realizing it's no longer fully functional.?? Get rid of the baggage so people can start fresh with better practices. Note that I'll be implementing a full authorization layer based on least privilege principles, that still utilizes a stack walk. I won't use the standard Java Permission implementations, as I'd like to do things a little differently, for usability reasons, this will do everything I need at least.? If the authorization layer is back ported, then I can support all current versions. My policy files are generated, so I don't need permission implementations to remain compatible. Whatever happens with JAAS will need to be backported, so we can support all versions. Regards, Peter. On 14/06/2021 3:54 pm, Alan Bateman wrote: > cc'ing security-dev as that is the mailing list to use for this JEP. > > This JEP is the first of several in a multi-release/multi-year effort. > It's way too early to give any guess as to when the APIs will be > removed. As the JEP says, future releases may degrade the SM APIs so > that System.getSM returns always returns null or > AccessController::doPriv just runs the action. This should mean that > libraries that are compiling to older releases should continue to > compile and run on those releases. When they run on some future > release that degrades the implementation then it will be as if there > is no SM.? So I would say the impact is little to none for libraries > for the foreseeable future. > > -Alan > > > On 13/06/2021 21:28, Rafael Winterhalter wrote: >> I am currently looking into how I should address JEP 411 in my >> library Byte >> Buddy and I find it rather challenging. The problem I am facing is >> that I >> know of several users who rely on the security manager in their Java >> 8/11 >> applications. I would like to continue to support those users' use >> cases as >> long as I support Java versions that contain the security manager, which >> will be for many years to come. At the same time, I would like to >> address >> the announced removal of the API and make sure that Byte Buddy can work >> without it prior to the deadline when the library in its current state >> would no longer link. >> >> ?From my understanding of the intention of JEP 411, the API was >> supposed to >> be stubbed ? similar to Android?s stubbing of the API - rather than >> being >> removed. However, with the announced deprecation for removal of >> AccessController and SecurityManager, I understand that I would need to >> fully remove the dispatching to work with future Java versions. >> >> Furthermore, it is difficult to create a working facade for >> dispatching to >> the security manager only if it is available. Methods like >> AccessController.doPrivileged are caller sensitive and by adding a >> utility >> to a library, this utility would leak to any potential user. It would >> therefore require package-private dispatchers for any relevant package, >> which would lead to a lot of copy-paste to retain backwards >> compatibility >> (given that a library cannot assume to be run as a module). >> >> Finally, removing the API would mean that Byte Buddy versions of the >> last >> ten years would no longer link in future JDKs. For Byte Buddy where new >> Java versions often require an update, that might not be a big issue but >> many other libraries do support the API, I don?t feel it would be a >> rather >> severe restriction and cause unnecessary breakage if API is removed, >> rather >> than stubbed. I am thinking of libraries like Netty here which are >> rather >> omnipresent and would suddenly no longer link, a concept that is >> unlikely >> intuitive to a lot of developers. >> >> Therefore, my question is: should SecurityManager, AccessController >> and the >> Policy APIs really be deprecated for removal? Rather, I think that >> the APIs >> should be deprecated, but be retained with stubbed implementations. >> System.getSecurityMananger would then always return null. >> System.setSecurityManager on the other hand could be deprecated for >> removal. This way, existing code could continue to work as if the >> security >> manager is not active, which already is the common scenario and would >> not >> cause any disruption at the small price of keeping a handful of some >> stubbed classes. >> >> Thanks for advice on how this is intended to be handled by library >> developers like me. >> Best regards, Rafael > -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Mon Jun 14 07:52:20 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 17:52:20 +1000 Subject: Low level hooks in JDK for permission checks. Message-ID: <3ebd4dba-84f4-d69c-c455-9c09fe37cc7d@zeus.net.au> Making things clearer if I can: Some thoughts on hooks: * Utilize java.security.Provider, so as not to expose jdk implementation code.? Eg: a module declaration or META-INF/services/java.security.Provider to obtain relevant instances of java.security.Guard, where Permission implementation types are currently used. * Allow existing Permission classes to remain backward compatible, declare them as services, so that SecurityManager can be degraded as planned and Permission implementations can be gradually removed as planned. (Removes dependencies on Permission instance types). * Guard implementation's are typically required to have a constructor with two String arguments, (String name, String actions), can be passed as new String[]{ name, actions} constructor parameter to java.security.Provider.Service::newInstance. * Service must implement Guard interface, with Guard::check method (current Permission implementations implement this method and call System.getSecurityManager). * Doesn't depend on Permission or any existing implementation classes, completely customizable by the service implementation. * Application developers can also implement hooks using this service. * Using security provider avoids deadlock during Provider initialization, it must be listed as a provider in the java.security file or if security.overridePropertiesFile=true and -Djava.security.properties=file://path/additional.security defines providers, which would be useful for testing. Break up guard service providers into current Permission types (independent instances to avoid circular deadlocks), developers only need implement those relevant to them and may only use checks for users if they wish: "AWT" "FILE" "SERIALIZABLE" "MANAGEMENT" "REFLECT" "RUNTIME" "NET" "SOCKET" "URL" "FILE-LINK" "SECURITY" "SQL" "LOGGING" "PROPERTY" "MBEAN" "MBEAN-SERVER" "MBEAN-TRUST" "SUBJECT-DELEGATION" "TLS" "AUTH" "KERBEROS-DELEGATION" "KERBEROS-SERVICE" "PRIVATE-CREDENTIAL" "AUDIO" "JAXB" "WEB-SERVICE" I would like to suggest adding a new provider type: "PARSE-DATA" - To be called by any code about to parse data, eg deserialization, XML, JSON, SQL, etc.? Granted to users, so that it can only be performed after authentication. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From winterhalter at openjdk.java.net Mon Jun 14 08:27:00 2021 From: winterhalter at openjdk.java.net (Rafael Winterhalter) Date: Mon, 14 Jun 2021 08:27:00 GMT Subject: Integrated: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException In-Reply-To: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> References: <_4ws26uD2ePVzTrKLLiOzo37SyzZr7azothOOSNV0tw=.3547bc53-e515-4059-a020-967d4e8482b2@github.com> Message-ID: On Sun, 9 May 2021 21:59:29 GMT, Rafael Winterhalter wrote: > During annotation parsing, the parser assumes that a declared property is of an array type if the parsed annotation property is defined as an array. In this case, the component type is `null`, and a `NullPointerException` is thrown. This change discovers the mismatch and throws an `AnnotationTypeMismatchException`. This pull request has now been integrated. Changeset: 51f3427e Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck URL: https://git.openjdk.java.net/jdk/commit/51f3427e9bb4a3924a8178338316b9ea30304182 Stats: 99 lines in 2 files changed: 99 ins; 0 del; 0 mod 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException Reviewed-by: darcy, jfranck ------------- PR: https://git.openjdk.java.net/jdk/pull/3940 From chegar at openjdk.java.net Mon Jun 14 08:32:52 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Mon, 14 Jun 2021 08:32:52 GMT Subject: [jdk17] Integrated: 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" In-Reply-To: <21tZNep8vfy50l1QvAEpBBNhaZMgfl8wK7iH908XB_Q=.6e3e51b7-3910-480f-9a86-08858c6e38d4@github.com> References: <21tZNep8vfy50l1QvAEpBBNhaZMgfl8wK7iH908XB_Q=.6e3e51b7-3910-480f-9a86-08858c6e38d4@github.com> Message-ID: On Fri, 11 Jun 2021 15:26:50 GMT, Chris Hegarty wrote: > There is the possibility for a race in the test, where the outbound socket buffer is still being filled, after 5 seconds, when the main test thread tries to close the resource scope. > > The test has been updated to set the send/receive buffer sizes in an attempt/hint to limit the accepted/connected socket buffer sizes. Actual buffer sizes in use will likely be larger due to TCP auto-tuning, but the hint typically reduces the overall scaled sizes. This is primarily to stabilize outstanding write operations. Additionally, to ameliorate the wait-for-writebuf-to-fill situation, the dumb sleep 5secs has been replaced with a heuristic that checks that the number of bytes written quiesces. With these changes, the test successfully passes several thousands of runs. This pull request has now been integrated. Changeset: fe48ea9d Author: Chris Hegarty URL: https://git.openjdk.java.net/jdk17/commit/fe48ea9d7975188853bc165ce29789753f4758f2 Stats: 52 lines in 1 file changed: 46 ins; 4 del; 2 mod 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk17/pull/30 From Alan.Bateman at oracle.com Mon Jun 14 08:37:10 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Jun 2021 09:37:10 +0100 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> Message-ID: <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> On 14/06/2021 08:35, Peter Firmstone wrote: > > I wouldn't want to see SecurityManager and Policy be neutralized, it's > better to remove it and fail early so people update their software, > there's a risk they may update without realizing it's no longer fully > functional.?? Get rid of the baggage so people can start fresh with > better practices. > I think the context for the question is libraries that want to be able to compile to an older JDK release and work with a very wide range of JDK releases. Many libraries do not play well with a SM. They don't execute actions that require permission checks in privileged blocks and will often need to be granted AllPermission. This may have knock on impact to the components that call into these libraries, maybe they end up needing to be? granted AllPermission too. Add callbacks or hand-off between threads to the picture and it can become farcical. If the library code isn't calling System.getSM or invoking AccessController.doPrivileged then it probably won't care if these APIs are degraded or removed. There are some libraries where the maintainers have put effort into working with a SM. Code in the library may use System.getSM, or doPriv or limited-doPriv. It may document the permissions that it requires and be helpful to someone assembling an application and creating its policy file. This JEP is mildly disruptive in that there will be warnings at compile-time or testing JDK 17+. If some future JDK releases degrades some of these APIs then it may be a bit more disruptive, maybe tests that try to set a SM will fail or need to be skipped. It might be that a library uses an exotic API that doesn't degrade in a sensible way and maybe that will be a bit more disruptive. Further out again, if the APIs are actually removed then it will be disruptive for libraries that want to support the possibility of being deployed with a SM on an older release. That may require some refactoring and the use of a MR-JAR as Remi mentioned. -Alan From rafael.wth at gmail.com Mon Jun 14 08:38:05 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 14 Jun 2021 10:38:05 +0200 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> Message-ID: One example for a currently necessary "doPrivileged" are Java agents where a class loading triggers agent code where the agent shares the stack with any code that loads a class for the first time. Otherwise, Byte Buddy wraps anything that might require privileges as privileged action to allow setting a policy that gives Byte Buddy for example access to class loaders, system properties or other things that the security manager currently checks. There's many uses of the security manager throughout the library, in the spirit of the API's invention. I could, of course, rip this code out of the library. But this would make it impossible for users that choose to use the functionality for now to update their dependency. This would certainly hinder a smooth transition as library maintainers will always have people drag at both ends of the JDK version range. After all, Java 8 is supported for another decade. Multi-release jars are neither a feasible option. They are not globally supported by all class loaders, and would require me to add a copy of an adjusted class file for any Java version prior to the removal version or upwards from there. I don't think that this should be addressed by tooling if keeping deprecated skeletons of the API can so easily avoid this entire problem for all libraries without the need to chase down maintainers. Therefore, I really think that the SecurityManager and AccessController APIs should remain as skeletons and be deprecated, but not be marked forRemoval, especially without a clear roadmap for the actual removal forward. And while I appreciate the clean up effort - I do think the SecurityManager deprecation and feature removal is a right decision - I find the attempt to remove this API will cause unnecessary breakage and cause thousands of libraries to become unlinkable on future VM, without a clear need for it. Discovering this breakage would also require manually scanning the content of each library and affect all the big names in the industry. This would require big waves of dependency updates, where such updates sometimes will be impossible if only a single (transitive) dependency has not catched up, including major names such as Spring, Hibernate or Mockito. From experience, such major updating waves are often complex and therefore avoided, which will hinder adoption of future JVM versions. This seems like a very high price to pay which could be easily avoided by only keeping a handful of skeleton classes. Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < Alan.Bateman at oracle.com>: > cc'ing security-dev as that is the mailing list to use for this JEP. > > This JEP is the first of several in a multi-release/multi-year effort. > It's way too early to give any guess as to when the APIs will be > removed. As the JEP says, future releases may degrade the SM APIs so > that System.getSM returns always returns null or > AccessController::doPriv just runs the action. This should mean that > libraries that are compiling to older releases should continue to > compile and run on those releases. When they run on some future release > that degrades the implementation then it will be as if there is no SM. > So I would say the impact is little to none for libraries for the > foreseeable future. > > -Alan > > > On 13/06/2021 21:28, Rafael Winterhalter wrote: > > I am currently looking into how I should address JEP 411 in my library > Byte > > Buddy and I find it rather challenging. The problem I am facing is that I > > know of several users who rely on the security manager in their Java 8/11 > > applications. I would like to continue to support those users' use cases > as > > long as I support Java versions that contain the security manager, which > > will be for many years to come. At the same time, I would like to address > > the announced removal of the API and make sure that Byte Buddy can work > > without it prior to the deadline when the library in its current state > > would no longer link. > > > > From my understanding of the intention of JEP 411, the API was supposed > to > > be stubbed ? similar to Android?s stubbing of the API - rather than being > > removed. However, with the announced deprecation for removal of > > AccessController and SecurityManager, I understand that I would need to > > fully remove the dispatching to work with future Java versions. > > > > Furthermore, it is difficult to create a working facade for dispatching > to > > the security manager only if it is available. Methods like > > AccessController.doPrivileged are caller sensitive and by adding a > utility > > to a library, this utility would leak to any potential user. It would > > therefore require package-private dispatchers for any relevant package, > > which would lead to a lot of copy-paste to retain backwards compatibility > > (given that a library cannot assume to be run as a module). > > > > Finally, removing the API would mean that Byte Buddy versions of the last > > ten years would no longer link in future JDKs. For Byte Buddy where new > > Java versions often require an update, that might not be a big issue but > > many other libraries do support the API, I don?t feel it would be a > rather > > severe restriction and cause unnecessary breakage if API is removed, > rather > > than stubbed. I am thinking of libraries like Netty here which are rather > > omnipresent and would suddenly no longer link, a concept that is unlikely > > intuitive to a lot of developers. > > > > Therefore, my question is: should SecurityManager, AccessController and > the > > Policy APIs really be deprecated for removal? Rather, I think that the > APIs > > should be deprecated, but be retained with stubbed implementations. > > System.getSecurityMananger would then always return null. > > System.setSecurityManager on the other hand could be deprecated for > > removal. This way, existing code could continue to work as if the > security > > manager is not active, which already is the common scenario and would not > > cause any disruption at the small price of keeping a handful of some > > stubbed classes. > > > > Thanks for advice on how this is intended to be handled by library > > developers like me. > > Best regards, Rafael > > From peter.firmstone at zeus.net.au Mon Jun 14 09:23:39 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 19:23:39 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> Message-ID: Binary compatibility only? Security.getSecurityManager() always returns null. Security.setSecurityManager() always throws a SecurityException (compatible because existing SecurityManager is allowed to prevent the call from succeeding). SecurityManager constructor always throws a SecurityException (compatible because existing SecurityManager is allowed to prevent the call from succeeding). Remove all methods from SecurityManager, no instances will be created, so methods will not be resolved, still binary compatible. For Policy, retain methods and constructor, throwing appropriate exceptions, eg SecurityException or NoSuchAlgorithmException. Note that constructor will throw no exception, the exception will be thrown when? attempting to set Policy. Remove PolicyFile implementation. Leave PolicySPI as is, but don't load them. The first step would be to provide low level JDK hooks that allow for equivalent functionality to be implemented, back-porting to all long term releases, while leaving SecurityManager unchanged. Then change SecurityManager prior to next LTS version (Java 23) to binary compatible only.? Then prior to the next LTS version (Java 29), remove it. Maintained software will have had plenty of time to update and be compatible across all supported Java releases, provided appropriate JDK hooks are provided, only unmaintained software will still require it and unmaintained software will still run on unmaintained Java releases in VM's with unmaintained OS's. Peter. On 14/06/2021 6:37 pm, Alan Bateman wrote: > On 14/06/2021 08:35, Peter Firmstone wrote: >> >> I wouldn't want to see SecurityManager and Policy be neutralized, >> it's better to remove it and fail early so people update their >> software, there's a risk they may update without realizing it's no >> longer fully functional.?? Get rid of the baggage so people can start >> fresh with better practices. >> > I think the context for the question is libraries that want to be able > to compile to an older JDK release and work with a very wide range of > JDK releases. > > Many libraries do not play well with a SM. They don't execute actions > that require permission checks in privileged blocks and will often > need to be granted AllPermission. This may have knock on impact to the > components that call into these libraries, maybe they end up needing > to be? granted AllPermission too. Add callbacks or hand-off between > threads to the picture and it can become farcical. If the library code > isn't calling System.getSM or invoking AccessController.doPrivileged > then it probably won't care if these APIs are degraded or removed. > > There are some libraries where the maintainers have put effort into > working with a SM. Code in the library may use System.getSM, or doPriv > or limited-doPriv. It may document the permissions that it requires > and be helpful to someone assembling an application and creating its > policy file. This JEP is mildly disruptive in that there will be > warnings at compile-time or testing JDK 17+. If some future JDK > releases degrades some of these APIs then it may be a bit more > disruptive, maybe tests that try to set a SM will fail or need to be > skipped. It might be that a library uses an exotic API that doesn't > degrade in a sensible way and maybe that will be a bit more > disruptive. Further out again, if the APIs are actually removed then > it will be disruptive for libraries that want to support the > possibility of being deployed with a SM on an older release. That may > require some refactoring and the use of a MR-JAR as Remi mentioned. > > -Alan From ron.pressler at oracle.com Mon Jun 14 09:26:12 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 14 Jun 2021 09:26:12 +0000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> Message-ID: <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> The JEP addresses this: > In future JDK releases, we will degrade the Security Manager APIs so that they remain in place but have limited or no functionality. ... This will allow libraries that support the Security Manager and were compiled against previous Java releases to continue to work without change or even recompilation. We expect to remove the APIs once the compatibility risk of doing so declines to an acceptable level. If your question is, when only few codebases will refer to the API and the compatibility impact is low enough for it to be removed, what if some of those few libraries still want to support versions prior to the removal, the answer is the same as with all removals (MR-JARs, or multiple artefacts). By definition, the impact of complete removal when the impact is low, would be low. ? Ron > On 14 Jun 2021, at 09:38, Rafael Winterhalter wrote: > > One example for a currently necessary "doPrivileged" are Java agents where > a class loading triggers agent code where the agent shares the stack with > any code that loads a class for the first time. Otherwise, Byte Buddy wraps > anything that might require privileges as privileged action to allow > setting a policy that gives Byte Buddy for example access to class loaders, > system properties or other things that the security manager currently > checks. There's many uses of the security manager throughout the library, > in the spirit of the API's invention. > > I could, of course, rip this code out of the library. But this would make > it impossible for users that choose to use the functionality for now to > update their dependency. This would certainly hinder a smooth transition as > library maintainers will always have people drag at both ends of the JDK > version range. After all, Java 8 is supported for another decade. > Multi-release jars are neither a feasible option. They are not globally > supported by all class loaders, and would require me to add a copy of an > adjusted class file for any Java version prior to the removal version or > upwards from there. I don't think that this should be addressed by tooling > if keeping deprecated skeletons of the API can so easily avoid this entire > problem for all libraries without the need to chase down maintainers. > > Therefore, I really think that the SecurityManager and AccessController > APIs should remain as skeletons and be deprecated, but not be marked > forRemoval, especially without a clear roadmap for the actual removal > forward. And while I appreciate the clean up effort - I do think the > SecurityManager deprecation and feature removal is a right decision - I > find the attempt to remove this API will cause unnecessary breakage and > cause thousands of libraries to become unlinkable on future VM, without a > clear need for it. Discovering this breakage would also require manually > scanning the content of each library and affect all the big names in the > industry. This would require big waves of dependency updates, where such > updates sometimes will be impossible if only a single (transitive) > dependency has not catched up, including major names such as Spring, > Hibernate or Mockito. From experience, such major updating waves are often > complex and therefore avoided, which will hinder adoption of future JVM > versions. This seems like a very high price to pay which could be easily > avoided by only keeping a handful of skeleton classes. > > Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < > Alan.Bateman at oracle.com>: > >> cc'ing security-dev as that is the mailing list to use for this JEP. >> >> This JEP is the first of several in a multi-release/multi-year effort. >> It's way too early to give any guess as to when the APIs will be >> removed. As the JEP says, future releases may degrade the SM APIs so >> that System.getSM returns always returns null or >> AccessController::doPriv just runs the action. This should mean that >> libraries that are compiling to older releases should continue to >> compile and run on those releases. When they run on some future release >> that degrades the implementation then it will be as if there is no SM. >> So I would say the impact is little to none for libraries for the >> foreseeable future. >> >> -Alan >> >> >> On 13/06/2021 21:28, Rafael Winterhalter wrote: >>> I am currently looking into how I should address JEP 411 in my library >> Byte >>> Buddy and I find it rather challenging. The problem I am facing is that I >>> know of several users who rely on the security manager in their Java 8/11 >>> applications. I would like to continue to support those users' use cases >> as >>> long as I support Java versions that contain the security manager, which >>> will be for many years to come. At the same time, I would like to address >>> the announced removal of the API and make sure that Byte Buddy can work >>> without it prior to the deadline when the library in its current state >>> would no longer link. >>> >>> From my understanding of the intention of JEP 411, the API was supposed >> to >>> be stubbed ? similar to Android?s stubbing of the API - rather than being >>> removed. However, with the announced deprecation for removal of >>> AccessController and SecurityManager, I understand that I would need to >>> fully remove the dispatching to work with future Java versions. >>> >>> Furthermore, it is difficult to create a working facade for dispatching >> to >>> the security manager only if it is available. Methods like >>> AccessController.doPrivileged are caller sensitive and by adding a >> utility >>> to a library, this utility would leak to any potential user. It would >>> therefore require package-private dispatchers for any relevant package, >>> which would lead to a lot of copy-paste to retain backwards compatibility >>> (given that a library cannot assume to be run as a module). >>> >>> Finally, removing the API would mean that Byte Buddy versions of the last >>> ten years would no longer link in future JDKs. For Byte Buddy where new >>> Java versions often require an update, that might not be a big issue but >>> many other libraries do support the API, I don?t feel it would be a >> rather >>> severe restriction and cause unnecessary breakage if API is removed, >> rather >>> than stubbed. I am thinking of libraries like Netty here which are rather >>> omnipresent and would suddenly no longer link, a concept that is unlikely >>> intuitive to a lot of developers. >>> >>> Therefore, my question is: should SecurityManager, AccessController and >> the >>> Policy APIs really be deprecated for removal? Rather, I think that the >> APIs >>> should be deprecated, but be retained with stubbed implementations. >>> System.getSecurityMananger would then always return null. >>> System.setSecurityManager on the other hand could be deprecated for >>> removal. This way, existing code could continue to work as if the >> security >>> manager is not active, which already is the common scenario and would not >>> cause any disruption at the small price of keeping a handful of some >>> stubbed classes. >>> >>> Thanks for advice on how this is intended to be handled by library >>> developers like me. >>> Best regards, Rafael >> >> From peter.firmstone at zeus.net.au Mon Jun 14 09:33:33 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 14 Jun 2021 19:33:33 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> <8b1e05b2-8b19-75c1-3743-32358ef247de@oracle.com> Message-ID: On 14/06/2021 6:37 pm, Alan Bateman wrote: > > There are some libraries where the maintainers have put effort into > working with a SM. Yes, I am one of them, very much so. At first it's a shock, but the show must go on, it could be an opportunity to address some long standing issues also. If Permission implementations are unmaintained, we are better off without them too and re implementing our own.?? It doesn't matter what they change to, I can generate my policy files. AccessController, AccessControlContext and DomainController are bigger fish, which will take longer, personally I wouldn't remove these classes, but it's not my choice. -- Regards, Peter. From martin.doerr at sap.com Mon Jun 14 10:16:56 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Jun 2021 10:16:56 +0000 Subject: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64 Message-ID: Hi, we observe crashes in jdk 11.0.12 on Windows: https://bugs.openjdk.java.net/browse/JDK-8267440 I haven?t found any backport which looks like obviously causing it. We had different theories which include: * Antivirus tool which keeps the test file open. * Error in handling of OVERLAPPED structures. I was hoping that JDK-8184157 would fix it, but it doesn?t. Maybe it is incomplete? Did anybody else notice such crashes? Any idea? Best regards, Martin From rafael.wth at gmail.com Mon Jun 14 11:34:26 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 14 Jun 2021 13:34:26 +0200 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> Message-ID: Why not add the property once this is the case, though? As it is now, I read the 'forRemoval' property to indicate a problem that should be instantly addressed. With Java 8 being a common baseline for libraries and the version being supported until (at least) 2030, I don't see how this removal would have a low impact within the next decade, if ever. Shouldn't the property be set if the removal is within reach? To some degree, I would expect that any deprecated API could be removed once it is no longer used. As it is now, library maintainers face the choice of breaking their support for current users that are on Java 8/11 and rely on the security manager, or to remove their support to accommodate a Java release that might be many years in the future. For my part, supporting the security manager seems to be the right choice as things stand today. Over the years, I would expect that fewer and fewer people rely on the security manager, where this balance might shift. I would hope that the 'forRemoval' property would serve as an indicator at that time to tell library maintainers that usage of the security manager has decreased so much that it is time to remove the library support, too. I see the reason for a strong signal, deprecation already is such a signal, but if you give the full blow today, it is no longer available in the future where it might be more relevant to give. Am Mo., 14. Juni 2021 um 11:26 Uhr schrieb Ron Pressler < ron.pressler at oracle.com>: > The JEP addresses this: > > > In future JDK releases, we will degrade the Security Manager APIs so > that they > remain in place but have limited or no functionality. ... This will allow > libraries > that support the Security Manager and were compiled against previous Java > releases > to continue to work without change or even recompilation. We expect to > remove the > APIs once the compatibility risk of doing so declines to an acceptable > level. > > If your question is, when only few codebases will refer to the API and the > compatibility impact is low enough for it to be removed, what if some of > those > few libraries still want to support versions prior to the removal, the > answer is > the same as with all removals (MR-JARs, or multiple artefacts). By > definition, > the impact of complete removal when the impact is low, would be low. > > ? Ron > > > On 14 Jun 2021, at 09:38, Rafael Winterhalter > wrote: > > > > One example for a currently necessary "doPrivileged" are Java agents > where > > a class loading triggers agent code where the agent shares the stack with > > any code that loads a class for the first time. Otherwise, Byte Buddy > wraps > > anything that might require privileges as privileged action to allow > > setting a policy that gives Byte Buddy for example access to class > loaders, > > system properties or other things that the security manager currently > > checks. There's many uses of the security manager throughout the library, > > in the spirit of the API's invention. > > > > I could, of course, rip this code out of the library. But this would make > > it impossible for users that choose to use the functionality for now to > > update their dependency. This would certainly hinder a smooth transition > as > > library maintainers will always have people drag at both ends of the JDK > > version range. After all, Java 8 is supported for another decade. > > Multi-release jars are neither a feasible option. They are not globally > > supported by all class loaders, and would require me to add a copy of an > > adjusted class file for any Java version prior to the removal version or > > upwards from there. I don't think that this should be addressed by > tooling > > if keeping deprecated skeletons of the API can so easily avoid this > entire > > problem for all libraries without the need to chase down maintainers. > > > > Therefore, I really think that the SecurityManager and AccessController > > APIs should remain as skeletons and be deprecated, but not be marked > > forRemoval, especially without a clear roadmap for the actual removal > > forward. And while I appreciate the clean up effort - I do think the > > SecurityManager deprecation and feature removal is a right decision - I > > find the attempt to remove this API will cause unnecessary breakage and > > cause thousands of libraries to become unlinkable on future VM, without a > > clear need for it. Discovering this breakage would also require manually > > scanning the content of each library and affect all the big names in the > > industry. This would require big waves of dependency updates, where such > > updates sometimes will be impossible if only a single (transitive) > > dependency has not catched up, including major names such as Spring, > > Hibernate or Mockito. From experience, such major updating waves are > often > > complex and therefore avoided, which will hinder adoption of future JVM > > versions. This seems like a very high price to pay which could be easily > > avoided by only keeping a handful of skeleton classes. > > > > Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < > > Alan.Bateman at oracle.com>: > > > >> cc'ing security-dev as that is the mailing list to use for this JEP. > >> > >> This JEP is the first of several in a multi-release/multi-year effort. > >> It's way too early to give any guess as to when the APIs will be > >> removed. As the JEP says, future releases may degrade the SM APIs so > >> that System.getSM returns always returns null or > >> AccessController::doPriv just runs the action. This should mean that > >> libraries that are compiling to older releases should continue to > >> compile and run on those releases. When they run on some future release > >> that degrades the implementation then it will be as if there is no SM. > >> So I would say the impact is little to none for libraries for the > >> foreseeable future. > >> > >> -Alan > >> > >> > >> On 13/06/2021 21:28, Rafael Winterhalter wrote: > >>> I am currently looking into how I should address JEP 411 in my library > >> Byte > >>> Buddy and I find it rather challenging. The problem I am facing is > that I > >>> know of several users who rely on the security manager in their Java > 8/11 > >>> applications. I would like to continue to support those users' use > cases > >> as > >>> long as I support Java versions that contain the security manager, > which > >>> will be for many years to come. At the same time, I would like to > address > >>> the announced removal of the API and make sure that Byte Buddy can work > >>> without it prior to the deadline when the library in its current state > >>> would no longer link. > >>> > >>> From my understanding of the intention of JEP 411, the API was supposed > >> to > >>> be stubbed ? similar to Android?s stubbing of the API - rather than > being > >>> removed. However, with the announced deprecation for removal of > >>> AccessController and SecurityManager, I understand that I would need to > >>> fully remove the dispatching to work with future Java versions. > >>> > >>> Furthermore, it is difficult to create a working facade for dispatching > >> to > >>> the security manager only if it is available. Methods like > >>> AccessController.doPrivileged are caller sensitive and by adding a > >> utility > >>> to a library, this utility would leak to any potential user. It would > >>> therefore require package-private dispatchers for any relevant package, > >>> which would lead to a lot of copy-paste to retain backwards > compatibility > >>> (given that a library cannot assume to be run as a module). > >>> > >>> Finally, removing the API would mean that Byte Buddy versions of the > last > >>> ten years would no longer link in future JDKs. For Byte Buddy where new > >>> Java versions often require an update, that might not be a big issue > but > >>> many other libraries do support the API, I don?t feel it would be a > >> rather > >>> severe restriction and cause unnecessary breakage if API is removed, > >> rather > >>> than stubbed. I am thinking of libraries like Netty here which are > rather > >>> omnipresent and would suddenly no longer link, a concept that is > unlikely > >>> intuitive to a lot of developers. > >>> > >>> Therefore, my question is: should SecurityManager, AccessController and > >> the > >>> Policy APIs really be deprecated for removal? Rather, I think that the > >> APIs > >>> should be deprecated, but be retained with stubbed implementations. > >>> System.getSecurityMananger would then always return null. > >>> System.setSecurityManager on the other hand could be deprecated for > >>> removal. This way, existing code could continue to work as if the > >> security > >>> manager is not active, which already is the common scenario and would > not > >>> cause any disruption at the small price of keeping a handful of some > >>> stubbed classes. > >>> > >>> Thanks for advice on how this is intended to be handled by library > >>> developers like me. > >>> Best regards, Rafael > >> > >> > > From jwilhelm at openjdk.java.net Mon Jun 14 14:36:59 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 14 Jun 2021 14:36:59 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow - 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" - 8268630: ProblemList serviceability/jvmti/CompiledMethodLoad/Zombie.java on linux-aarch64 - 8268470: CDS dynamic dump asserts with JFR RecordingStream - 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE - 8268602: a couple runtime/os tests don't check exit code - 8268555: Update HttpClient tests that use ITestContext to jtreg 6+1 - 8268580: runtime/memory/LargePages/TestLargePagesFlags.java should be run in driver mode - 8268565: runtime/records/RedefineRecord.java should be run in driver mode - 8268576: jdk/jfr/event/gc/collection/TestSystemGc.java fails - ... and 3 more: https://git.openjdk.java.net/jdk/compare/74007890...b3185354 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jdk/pull/4484/files Stats: 786 lines in 57 files changed: 593 ins; 73 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/4484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4484/head:pull/4484 PR: https://git.openjdk.java.net/jdk/pull/4484 From github.com+741251+turbanoff at openjdk.java.net Mon Jun 14 14:37:56 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 14 Jun 2021 14:37:56 GMT Subject: RFR: 8265474: Dubious 'null' assignment in CompactByteArray.expand In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 16:06:30 GMT, Andrey Turbanov wrote: > I propose to remove 'null' assignment of field CompactByteArray.values in `expand` method. In the next statement this field is overridden with another value - `tempArray`. > This code was there from initial load of OpenJDK sources. I believe it was just leftovers from development phase of this class. There is no practical reason to assign `null` to non-volatile field and then overwrite it with another value. > Also I've removed unused method `getArray`. I hope it's ok to cleanup such unused stuff in the same PR. Let's keep open this PR with cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/1880 From sean.mullan at oracle.com Mon Jun 14 15:43:27 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Jun 2021 11:43:27 -0400 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <8E213231-239F-48A4-A359-BEFA3F81C790@oracle.com> Message-ID: <0bc2acc3-2086-ffc4-c5e6-53bdbbaeaef0@oracle.com> On 6/14/21 7:34 AM, Rafael Winterhalter wrote: > Why not add the property once this is the case, though? As it is now, I > read the 'forRemoval' property to indicate a problem that should be > instantly addressed. With Java 8 being a common baseline for libraries and > the version being supported until (at least) 2030, I don't see how this > removal would have a low impact within the next decade, if ever. Shouldn't > the property be set if the removal is within reach? To some degree, I would > expect that any deprecated API could be removed once it is no longer used. > > As it is now, library maintainers face the choice of breaking their support > for current users that are on Java 8/11 and rely on the security manager, > or to remove their support to accommodate a Java release that might be many > years in the future. For my part, supporting the security manager seems to > be the right choice as things stand today. Over the years, I would expect > that fewer and fewer people rely on the security manager, where this > balance might shift. I would hope that the 'forRemoval' property would > serve as an indicator at that time to tell library maintainers that usage > of the security manager has decreased so much that it is time to remove the > library support, too. I see the reason for a strong signal, deprecation > already is such a signal, but if you give the full blow today, it is no > longer available in the future where it might be more relevant to give. As Alan and others have mentioned, there is no immediate plan to remove the APIs that SM-enabled libraries are typically dependent on, i.e., AccessController.doPrivileged and System.getSecurityManager. The APIs, when degraded will behave as if the Security Manager was not enabled. It isn't clear to me why that plan would have a high compatibility impact for libraries. And in JDK 17, the Security Manager will still be fully supported. The 'forRemoval' property means that the API is earmarked for removal in a future release. This is important, as it provides a clear warning bell to those that are dependent on it that it will eventually be going away. On the other hand, if an API is only deprecated, there is no intention to remove it. Users usually can still expect the API to continue to work as specified. It isn't as strong enough of a signal that it should not be used and in my opinion would only delay the removal of the Security Manager for many more years. I also think it would be more confusing, and possibly wrong to degrade or "stub" a deprecated API (one that is not marked forRemoval) such that it is a no-op or basically no longer works as expected. --Sean > > Am Mo., 14. Juni 2021 um 11:26 Uhr schrieb Ron Pressler < > ron.pressler at oracle.com>: > >> The JEP addresses this: >> >>> In future JDK releases, we will degrade the Security Manager APIs so >> that they >> remain in place but have limited or no functionality. ... This will allow >> libraries >> that support the Security Manager and were compiled against previous Java >> releases >> to continue to work without change or even recompilation. We expect to >> remove the >> APIs once the compatibility risk of doing so declines to an acceptable >> level. >> >> If your question is, when only few codebases will refer to the API and the >> compatibility impact is low enough for it to be removed, what if some of >> those >> few libraries still want to support versions prior to the removal, the >> answer is >> the same as with all removals (MR-JARs, or multiple artefacts). By >> definition, >> the impact of complete removal when the impact is low, would be low. >> >> ? Ron >> >>> On 14 Jun 2021, at 09:38, Rafael Winterhalter >> wrote: >>> >>> One example for a currently necessary "doPrivileged" are Java agents >> where >>> a class loading triggers agent code where the agent shares the stack with >>> any code that loads a class for the first time. Otherwise, Byte Buddy >> wraps >>> anything that might require privileges as privileged action to allow >>> setting a policy that gives Byte Buddy for example access to class >> loaders, >>> system properties or other things that the security manager currently >>> checks. There's many uses of the security manager throughout the library, >>> in the spirit of the API's invention. >>> >>> I could, of course, rip this code out of the library. But this would make >>> it impossible for users that choose to use the functionality for now to >>> update their dependency. This would certainly hinder a smooth transition >> as >>> library maintainers will always have people drag at both ends of the JDK >>> version range. After all, Java 8 is supported for another decade. >>> Multi-release jars are neither a feasible option. They are not globally >>> supported by all class loaders, and would require me to add a copy of an >>> adjusted class file for any Java version prior to the removal version or >>> upwards from there. I don't think that this should be addressed by >> tooling >>> if keeping deprecated skeletons of the API can so easily avoid this >> entire >>> problem for all libraries without the need to chase down maintainers. >>> >>> Therefore, I really think that the SecurityManager and AccessController >>> APIs should remain as skeletons and be deprecated, but not be marked >>> forRemoval, especially without a clear roadmap for the actual removal >>> forward. And while I appreciate the clean up effort - I do think the >>> SecurityManager deprecation and feature removal is a right decision - I >>> find the attempt to remove this API will cause unnecessary breakage and >>> cause thousands of libraries to become unlinkable on future VM, without a >>> clear need for it. Discovering this breakage would also require manually >>> scanning the content of each library and affect all the big names in the >>> industry. This would require big waves of dependency updates, where such >>> updates sometimes will be impossible if only a single (transitive) >>> dependency has not catched up, including major names such as Spring, >>> Hibernate or Mockito. From experience, such major updating waves are >> often >>> complex and therefore avoided, which will hinder adoption of future JVM >>> versions. This seems like a very high price to pay which could be easily >>> avoided by only keeping a handful of skeleton classes. >>> >>> Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman < >>> Alan.Bateman at oracle.com>: >>> >>>> cc'ing security-dev as that is the mailing list to use for this JEP. >>>> >>>> This JEP is the first of several in a multi-release/multi-year effort. >>>> It's way too early to give any guess as to when the APIs will be >>>> removed. As the JEP says, future releases may degrade the SM APIs so >>>> that System.getSM returns always returns null or >>>> AccessController::doPriv just runs the action. This should mean that >>>> libraries that are compiling to older releases should continue to >>>> compile and run on those releases. When they run on some future release >>>> that degrades the implementation then it will be as if there is no SM. >>>> So I would say the impact is little to none for libraries for the >>>> foreseeable future. >>>> >>>> -Alan >>>> >>>> >>>> On 13/06/2021 21:28, Rafael Winterhalter wrote: >>>>> I am currently looking into how I should address JEP 411 in my library >>>> Byte >>>>> Buddy and I find it rather challenging. The problem I am facing is >> that I >>>>> know of several users who rely on the security manager in their Java >> 8/11 >>>>> applications. I would like to continue to support those users' use >> cases >>>> as >>>>> long as I support Java versions that contain the security manager, >> which >>>>> will be for many years to come. At the same time, I would like to >> address >>>>> the announced removal of the API and make sure that Byte Buddy can work >>>>> without it prior to the deadline when the library in its current state >>>>> would no longer link. >>>>> >>>>> From my understanding of the intention of JEP 411, the API was supposed >>>> to >>>>> be stubbed ? similar to Android?s stubbing of the API - rather than >> being >>>>> removed. However, with the announced deprecation for removal of >>>>> AccessController and SecurityManager, I understand that I would need to >>>>> fully remove the dispatching to work with future Java versions. >>>>> >>>>> Furthermore, it is difficult to create a working facade for dispatching >>>> to >>>>> the security manager only if it is available. Methods like >>>>> AccessController.doPrivileged are caller sensitive and by adding a >>>> utility >>>>> to a library, this utility would leak to any potential user. It would >>>>> therefore require package-private dispatchers for any relevant package, >>>>> which would lead to a lot of copy-paste to retain backwards >> compatibility >>>>> (given that a library cannot assume to be run as a module). >>>>> >>>>> Finally, removing the API would mean that Byte Buddy versions of the >> last >>>>> ten years would no longer link in future JDKs. For Byte Buddy where new >>>>> Java versions often require an update, that might not be a big issue >> but >>>>> many other libraries do support the API, I don?t feel it would be a >>>> rather >>>>> severe restriction and cause unnecessary breakage if API is removed, >>>> rather >>>>> than stubbed. I am thinking of libraries like Netty here which are >> rather >>>>> omnipresent and would suddenly no longer link, a concept that is >> unlikely >>>>> intuitive to a lot of developers. >>>>> >>>>> Therefore, my question is: should SecurityManager, AccessController and >>>> the >>>>> Policy APIs really be deprecated for removal? Rather, I think that the >>>> APIs >>>>> should be deprecated, but be retained with stubbed implementations. >>>>> System.getSecurityMananger would then always return null. >>>>> System.setSecurityManager on the other hand could be deprecated for >>>>> removal. This way, existing code could continue to work as if the >>>> security >>>>> manager is not active, which already is the common scenario and would >> not >>>>> cause any disruption at the small price of keeping a handful of some >>>>> stubbed classes. >>>>> >>>>> Thanks for advice on how this is intended to be handled by library >>>>> developers like me. >>>>> Best regards, Rafael >>>> >>>> >> >> From mcimadamore at openjdk.java.net Mon Jun 14 15:50:13 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 14 Jun 2021 15:50:13 GMT Subject: [jdk17] RFR: 8268566: java/foreign/TestResourceScope.java timed out Message-ID: This patch contains another minor tweak to TestResourceScope as we have seen this test timing out at least once (on arm64). I realized that some of the logic recently introduced in the test could lead to the test waiting forever: for instance, if all threads are executed right away before the main thread gets a chance to do anything, we'd be in a state where the lock count is zero, and no other thread will update it. I've removed the while loop - as that's not essential to make sure that the test works (what we want is to trigger a close operation that is concurrent with respect some acquire/release). I've also lowered the number of threads - which was using 10K - that was good for stress testing, but it's not a good number in more realistic conditions. ------------- Commit messages: - * Remove wait from test Changes: https://git.openjdk.java.net/jdk17/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268566 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk17/pull/45 From dcubed at openjdk.java.net Mon Jun 14 15:49:59 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 14 Jun 2021 15:49:59 GMT Subject: RFR: Merge jdk17 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 Thumbs up! Thanks for doing this sync forward. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4484 From psandoz at openjdk.java.net Mon Jun 14 15:56:55 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 14 Jun 2021 15:56:55 GMT Subject: Withdrawn: 8268353: Test libsvml.so is and is not present in jdk image In-Reply-To: References: Message-ID: On Tue, 8 Jun 2021 23:27:52 GMT, Paul Sandoz wrote: > Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4421 From dfuchs at openjdk.java.net Mon Jun 14 16:02:28 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 14 Jun 2021 16:02:28 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: <2daAOoP8hnt5nqsZJasI5g1_QUovwyTwY3JutixTGik=.0bf9118f-8348-4f28-ba59-220c51a8732e@github.com> On Mon, 14 Jun 2021 15:58:15 GMT, Jesper Wilhelmsson wrote: >> Forwardport JDK 17 -> JDK 18 > > Jesper Wilhelmsson 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. Looked at this two changesets and they were fine. - 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already - 8268555: Update HttpClient tests that use ITestContext to jtreg 6+1 ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4484 From jwilhelm at openjdk.java.net Mon Jun 14 16:02:24 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 14 Jun 2021 16:02:24 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4484/files - new: https://git.openjdk.java.net/jdk/pull/4484/files/b3185354..b3185354 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4484&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4484&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4484/head:pull/4484 PR: https://git.openjdk.java.net/jdk/pull/4484 From jwilhelm at openjdk.java.net Mon Jun 14 16:02:33 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Mon, 14 Jun 2021 16:02:33 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 17295b1b Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/17295b1bb02b2121978f1459b2e75c5e1031e7ea Stats: 721 lines in 30 files changed: 573 ins; 73 del; 75 mod Merge Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/4484 From psandoz at openjdk.java.net Mon Jun 14 16:14:25 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 14 Jun 2021 16:14:25 GMT Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image Message-ID: Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. ------------- Commit messages: - 8268353: Test libsvml.so is and is not present in jdk image Changes: https://git.openjdk.java.net/jdk17/pull/47/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=47&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268353 Stats: 99 lines in 2 files changed: 96 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/47/head:pull/47 PR: https://git.openjdk.java.net/jdk17/pull/47 From david.lloyd at redhat.com Mon Jun 14 16:23:13 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 14 Jun 2021 11:23:13 -0500 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> Message-ID: On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone wrote: > 1. Develop authorization layer security provider services in OpenJDK, > back port it to Java 8 and Java 11 (these provide most of the > utilised functionality of SecurityManager, allowing developers to > only implement those which they need, without enabling > SecurityManager and editing policy files). > 2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19. The SecurityManager class itself already is *exactly* an authorization provider. I don't think it makes sense to consider removing the security manager class to replace it with something that has basically exactly the same API (specifically, a single method for each general authorization check that can be called without constructing any new objects, if and only if the authorization provider is installed). See my other proposal where, post-"removal", SecurityManager (the class) is retained but made abstract (and sans a few methods). All of the existing code which performs authorization checks would be retained and the problem solved in essentially the way you're describing, just using existing APIs. The security manager implementation itself can implement any kind of authorization behavior whatsoever, based mainly on the Permission types (which work just fine for this purpose, and anyway are already retained by the current JEP). Policy and its supporting classes are completely unnecessary for implementing a security policy. In fact, this is the case today already. On Mon, Jun 14, 2021 at 12:57 AM Alan Bateman wrote: > AccessController::doPriv just runs the action. TBH this should have always been the case. Implementation-wise, if one were constructing an access control context based on stack walking, one would stop at points where `AccessController` is on the stack (which is easily determinable) to do special work on assembling the access control context based on the method called at that frame. -- - DML ? he/him From psandoz at openjdk.java.net Mon Jun 14 16:55:25 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 14 Jun 2021 16:55:25 GMT Subject: [jdk17] RFR: 8266518: Refactor and expand scatter/gather tests Message-ID: Refactor scatter/gather tests to be included in the load/store test classes and expand to support access between `ShortVector` and and `char[]`, and access between `ByteVector` and `boolean[]`. Vector tests pass on linux-x64 linux-aarch64 macosx-x64, and windows-x64. ------------- Commit messages: - 8266518: Refactor and expand scatter/gather tests Changes: https://git.openjdk.java.net/jdk17/pull/48/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=48&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266518 Stats: 11793 lines in 72 files changed: 6487 ins; 5271 del; 35 mod Patch: https://git.openjdk.java.net/jdk17/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/48/head:pull/48 PR: https://git.openjdk.java.net/jdk17/pull/48 From mchung at openjdk.java.net Mon Jun 14 18:42:58 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Jun 2021 18:42:58 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v7] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 10:03:44 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thanks for making the change. I have a few minor comments and looking good. I think the synopsis of the JBS issue should be updated to reflect this problem. What about "deadlock between System::loadLibrary and JNI FindClass loading another class"? test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/LoadLibraryDeadlock.java line 44: > 42: try { > 43: // an instance of unsigned class that loads a native library > 44: Class c1 = Class.forName("Class1"); nit: `s/Class/Class/ ` avoid raw type (same in line 58) test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 67: > 65: public Class loadClass(String name) throws ClassNotFoundException { > 66: synchronized (getClassLoadingLock(name)) { > 67: Class clazz = findLoadedClass(name); nit: `s/Class/Class/` test/jdk/java/lang/ClassLoader/loadLibraryUnload/p/Class1.java line 40: > 38: System.loadLibrary("loadLibraryUnload"); > 39: System.out.println("Native library loaded from Class1."); > 40: } catch (Exception ignore) { should this exception just be thrown? ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From mchung at openjdk.java.net Mon Jun 14 18:42:59 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 14 Jun 2021 18:42:59 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v6] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 10:00:14 GMT, Aleksei Voitylov wrote: >> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 84: >> >>> 82: >>> 83: private static OutputAnalyzer createJar(String outputJar, String... classes) throws Throwable { >>> 84: String jar = JDKToolFinder.getJDKTool("jar"); >> >> You can consider using `jdk.test.lib.util.JarUtils` to reduce the test execution time so that it can create the jar without exec'ing another process. > > I tried, but this doesn't work that well unfortunately with JarUtils.createJar() as it only produces a valid jar-file capable of triggering the issue when the compiled class files (jtreg @build output) are in the same directory as the current directory of the process calling JarUtils.createJar(). Jtreg @build outputs the compiled classes to a separate directory. Creation of a new jar process allows to change the current directory so that the relative paths to the class files are such that it would form the valid output jar-file. Alternatively we could copy the class files to the current directory prior to creating the jar-file, but that would introduce an extra step. Would you mind me keeping the createJar() in the test? Is `jar -C

    ` option what you want? FYI. `jar` tool is a tool provider which is a simple way to run `jar` tool in process (lookup the tool provider by calling `ToolProvider.findFirst("jar")`). Yes I am fine with what you have if this does not work. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From lmesnik at openjdk.java.net Mon Jun 14 19:38:54 2021 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 14 Jun 2021 19:38:54 GMT Subject: Integrated: 8268626: Remove native pre-jdk9 support for jtreg failure handler In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 18:44:38 GMT, Leonid Mesnik wrote: > jtreg failure handler uses native lib to implement getPid for preJDK9. Currently. it is not needed and might be removed. This pull request has now been integrated. Changeset: 2e70bc35 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/2e70bc35dffce47e85f5ca4eaa4c9bdba5afb95b Stats: 100 lines in 4 files changed: 0 ins; 96 del; 4 mod 8268626: Remove native pre-jdk9 support for jtreg failure handler Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4476 From peter.firmstone at zeus.net.au Mon Jun 14 23:47:38 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 15 Jun 2021 09:47:38 +1000 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> Message-ID: On 15/06/2021 2:23 am, David Lloyd wrote: > On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone > wrote: >> 1. Develop authorization layer security provider services in OpenJDK, >> back port it to Java 8 and Java 11 (these provide most of the >> utilised functionality of SecurityManager, allowing developers to >> only implement those which they need, without enabling >> SecurityManager and editing policy files). >> 2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19. > The SecurityManager class itself already is *exactly* an authorization > provider. I don't think it makes sense to consider removing the > security manager class to replace it with something that has basically > exactly the same API Logic behind this choice: SecurityManager depends on Permission, currently there are Permission checks throughout the JVM, however Permission implementation classes will be removed, although the Permission class itself won't be. Permission references can be replaced with Guard references (which Permissions are instances of). The Permission implementations of Guard::check call SecurityManager, so checks will continue working as expected, but it allows us to intercept them and do something different. By replacing Permission references with Guard, it allows us to implement our own checks in these locations, and OpenJDK doesn't need to maintain Permission instances, and or, we don't need to make use of unmaintained Permission implementations. There are already issues with Permission implementations, take for example SocketPermission, it consults DNS and it isn't possible to enter a range of IP addresses (such as the local subnet, and a list of public IP addresses), for now, every single IP address must be entered and this isn't practical.?? The proposed API would allow us to re-implement SocketPermission functionality, as well as other Permission implementations. This proposal also allows every existing component of the SM architecture to be removed, while retaining the most important component, the checks themselves, such that you or I or anyone else for that matter can re-implement the functionality of SM. SM and friends will be removed eventually, so now is our opportunity to get something in place that has minimal impact on OpenJDK maintenance, that will remain. > (specifically, a single method for each general > authorization check that can be called without constructing any new > objects, if and only if the authorization provider is installed). See > my other proposal where, post-"removal", SecurityManager (the class) > is retained but made abstract (and sans a few methods). All of the > existing code which performs authorization checks would be retained > and the problem solved in essentially the way you're describing, just > using existing APIs. > > The security manager implementation itself can implement any kind of > authorization behavior whatsoever, based mainly on the Permission > types (which work just fine for this purpose, and anyway are already > retained by the current JEP). Policy and its supporting classes are > completely unnecessary for implementing a security policy. In fact, > this is the case today already. > > On Mon, Jun 14, 2021 at 12:57 AM Alan Bateman wrote: >> AccessController::doPriv just runs the action. > TBH this should have always been the case. Implementation-wise, if > one were constructing an access control context based on stack > walking, one would stop at points where `AccessController` is on the > stack (which is easily determinable) to do special work on assembling > the access control context based on the method called at that frame. Yes, one can do that, but these classes will also eventually be removed. -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From yyang at openjdk.java.net Tue Jun 15 02:39:47 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 15 Jun 2021 02:39:47 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: <9ixWD6Ea4OUcXAzU5s2Y68URPHJvq8RO5g-go6k1aMw=.e52e0571-e07d-4c5f-8afb-6b2408efd4a0@github.com> References: <9ixWD6Ea4OUcXAzU5s2Y68URPHJvq8RO5g-go6k1aMw=.e52e0571-e07d-4c5f-8afb-6b2408efd4a0@github.com> Message-ID: On Sat, 12 Jun 2021 08:22:32 GMT, Thomas Stuefe wrote: > Hi Yi, > > you may need to add the option to the obsolete-flags-table though as described in arguments.cpp: > > https://github.com/openjdk/jdk/blob/5cee23a9ed0b7fe2657be7492d9c1f78fcd02ebf/src/hotspot/share/runtime/arguments.cpp#L489-L490 > > I think the point is to give a customer a grace period where the option is still accepted on the command line. I am not sure if that step is optional though, if one is reasonably sure that the option is unused. Maybe @dholmes-ora can chime in. > > Cheers, Thomas Hi Thomas, I think what you said is right. It does not take too much time to do this but it can give users a smooth transition for unavailable options! I will create a new PR to do this stuff if there are no objections. Thanks, Yang ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From iveresov at openjdk.java.net Tue Jun 15 04:12:46 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 15 Jun 2021 04:12:46 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > more comment It's up to you, we can of course print a warning that the flag has been removed. In my opinion, we shouldn't waste time on this, that was an obscure non-product flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From peter.levart at gmail.com Tue Jun 15 07:20:37 2021 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Jun 2021 09:20:37 +0200 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: Message-ID: <101ce005-c5e7-1d56-9f08-87cd89246bd0@gmail.com> Hi Rafael, On 13/06/2021 22:28, Rafael Winterhalter wrote: > Furthermore, it is difficult to create a working facade for dispatching to > the security manager only if it is available. Methods like > AccessController.doPrivileged are caller sensitive and by adding a utility > to a library, this utility would leak to any potential user. It would > therefore require package-private dispatchers for any relevant package, > which would lead to a lot of copy-paste to retain backwards compatibility > (given that a library cannot assume to be run as a module). Here's my attempt / idea for such a utility which uses MethodHandles.Lookup as an additional argument in order to dispatch to a caller-sensitive AccessControler.doPrivileged: https://gist.github.com/plevart/ec333cb2c3a0306793961e8fb223bc98 I don't know whether this helps much in your situation because apps currently using AccessControler.doPrivileged would have to 1st migrate to using such utility wrapper so you would have to provide an independent module containing it. But it is a possible solution in the long run when AccessControler API is removed from JDK. Regards, Peter From martin.doerr at sap.com Tue Jun 15 08:26:44 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 15 Jun 2021 08:26:44 +0000 Subject: AW: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64 In-Reply-To: References: , Message-ID: Hi Brian, thanks a lot! It may be difficult to reproduce. Maybe a slow file system helps (like NFS). Just let us know if you have questions. Best regards, Martin Von: Brian Stafford Datum: Dienstag, 15. Juni 2021 um 01:20 An: jdk-updates-dev at openjdk.java.net , core-libs-dev at openjdk.java.net , Doerr, Martin Cc: Reka Kovacs , Aditya Mandaleeka , Monica Beckwith Betreff: RE: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64 Hi Martin, We haven?t encountered this yet, to my knowledge, but we?ll see if we can reproduce it during our next sprint. Thanks, Brian Stafford From: Doerr, Martin > Sent: Monday, June 14, 2021 3:17 AM To: jdk-updates-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Reka Kovacs >; Aditya Mandaleeka >; Monica Beckwith > Subject: [11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64 Hi, we observe crashes in jdk 11.0.12 on Windows: https://bugs.openjdk.java.net/browse/JDK-8267440 I haven?t found any backport which looks like obviously causing it. We had different theories which include: * Antivirus tool which keeps the test file open. * Error in handling of OVERLAPPED structures. I was hoping that JDK-8184157 would fix it, but it doesn?t. Maybe it is incomplete? Did anybody else notice such crashes? Any idea? Best regards, Martin From rafael.wth at gmail.com Tue Jun 15 08:35:19 2021 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 15 Jun 2021 10:35:19 +0200 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: <101ce005-c5e7-1d56-9f08-87cd89246bd0@gmail.com> References: <101ce005-c5e7-1d56-9f08-87cd89246bd0@gmail.com> Message-ID: Hi Peter, thanks for the suggestion. Byte Buddy still baselines to Java 5, unfortunately method handles are not an option at this point. I am looking into writing a Byte Buddy build plugin that discovers calls to PrivilegedAction.run and wraps those in a reflection-based AccessController invocation. This does however not cover all corner cases. I have tabled the problem for now and will see how and if other libraries adapt. Best regards, Rafael Am Di., 15. Juni 2021 um 09:20 Uhr schrieb Peter Levart < peter.levart at gmail.com>: > Hi Rafael, > > On 13/06/2021 22:28, Rafael Winterhalter wrote: > > Furthermore, it is difficult to create a working facade for dispatching > to > > the security manager only if it is available. Methods like > > AccessController.doPrivileged are caller sensitive and by adding a > utility > > to a library, this utility would leak to any potential user. It would > > therefore require package-private dispatchers for any relevant package, > > which would lead to a lot of copy-paste to retain backwards compatibility > > (given that a library cannot assume to be run as a module). > > > Here's my attempt / idea for such a utility which uses > MethodHandles.Lookup as an additional argument in order to dispatch to a > caller-sensitive AccessControler.doPrivileged: > > https://gist.github.com/plevart/ec333cb2c3a0306793961e8fb223bc98 > > > I don't know whether this helps much in your situation because apps > currently using AccessControler.doPrivileged would have to 1st migrate > to using such utility wrapper so you would have to provide an > independent module containing it. But it is a possible solution in the > long run when AccessControler API is removed from JDK. > > > Regards, Peter > > From peter.levart at gmail.com Tue Jun 15 12:02:51 2021 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 15 Jun 2021 14:02:51 +0200 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <101ce005-c5e7-1d56-9f08-87cd89246bd0@gmail.com> Message-ID: <32073603-e55c-f46f-a656-5c12804d694e@gmail.com> On 15/06/2021 10:35, Rafael Winterhalter wrote: > Hi Peter, > thanks for the suggestion. Byte Buddy still baselines to Java 5, > unfortunately method handles are not an option at this point. I am > looking into writing a Byte Buddy build plugin that discovers calls to > PrivilegedAction.run and wraps those in a reflection-based > AccessController invocation. This does however not cover all corner > cases. I have tabled the problem for now and will see how and if other > libraries adapt. > Best regards, Rafael Maybe the problem would be clearer if you described what Byte Buddy normally does with code that uses AccessController.doPrivileged. Does Byte Buddy also use AccessController.doPrivileged internally? What I mean is AccessControllerWrapper could be an independent library, compiled for at least JDK 7 target. Apps or libraries that want to be deployable across JDK 7 ... JDK X (where X is the release which removes AccessController API) could use this library instead of directly invoking AccessController API to achieve that. Apps that still want to run on JDK 5 or 6 probably are not also targeting JDK X at the same time right? Such apps can keep using AccessController API. Now how does ByteBuddy come into this picture? What does it do with code that either uses AccessController API and what would it have to do with code that uses AccessControllerWrapper instead? Regards, Peter > > Am Di., 15. Juni 2021 um 09:20?Uhr schrieb Peter Levart > >: > > Hi Rafael, > > On 13/06/2021 22:28, Rafael Winterhalter wrote: > > Furthermore, it is difficult to create a working facade for > dispatching to > > the security manager only if it is available. Methods like > > AccessController.doPrivileged are caller sensitive and by adding > a utility > > to a library, this utility would leak to any potential user. It > would > > therefore require package-private dispatchers for any relevant > package, > > which would lead to a lot of copy-paste to retain backwards > compatibility > > (given that a library cannot assume to be run as a module). > > > Here's my attempt / idea for such a utility which uses > MethodHandles.Lookup as an additional argument in order to > dispatch to a > caller-sensitive AccessControler.doPrivileged: > > https://gist.github.com/plevart/ec333cb2c3a0306793961e8fb223bc98 > > > > I don't know whether this helps much in your situation because apps > currently using AccessControler.doPrivileged would have to 1st > migrate > to using such utility wrapper so you would have to provide an > independent module containing it. But it is a possible solution in > the > long run when AccessControler API is removed from JDK. > > > Regards, Peter > From github.com+10835776+stsypanov at openjdk.java.net Tue Jun 15 12:22:50 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 15 Jun 2021 12:22:50 GMT Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable Message-ID: In some JDK classes there's still the following hashCode() implementation: long objNum; public int hashCode() { return (int) objNum; } This outdated expression should be replaced with Long.hashCode(long) as it - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite). - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation. See https://stackoverflow.com/a/4045083 This is related to https://github.com/openjdk/jdk/pull/4309 ------------- Commit messages: - 8268764: Use Long.hashCode() instead of int-cast where applicable Changes: https://git.openjdk.java.net/jdk/pull/4491/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268764 Stats: 15 lines in 9 files changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4491.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491 PR: https://git.openjdk.java.net/jdk/pull/4491 From maurizio.cimadamore at oracle.com Tue Jun 15 13:26:18 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 14:26:18 +0100 Subject: Integrated: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac In-Reply-To: <9QO9wAPeIwrFaGmBA1PCfyBR3CIG_vaVdBTPxgNoOf8=.f8cb58a4-dba6-4734-bf7d-3fe151a45582@github.com> References: <9QO9wAPeIwrFaGmBA1PCfyBR3CIG_vaVdBTPxgNoOf8=.f8cb58a4-dba6-4734-bf7d-3fe151a45582@github.com> Message-ID: This PR removes support for the Ant support file. Without that, many of the IDE actions are no longer working. Jtreg plugin support seems broken as well, as you can no longer select which build target has to be executed before the tests are run. I think I'm a bit concerned by these changes, in the sense that they tweak quite a lot of the functionality of the IDE project, in ways which makes them no longer working, and, more generally, this PR does a lot more than just replacing realpath, it seems. I think we should back this out, and have a wider discussion (possibly using ide-support mailing list) as to whether some of the features in this PR are worth pursuing. As things stand, I can no longer use the IDE in a way which works. Maurizio On 08/06/2021 15:39, Nikita Gubarkov wrote: > On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov wrote: > >> I got rid of `realpath` usage as discussed in https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro instead, however there were quite a few problems with this macro, here's the example: >> >> $(call RelativePath,/foo/bar,/foo/bar/baz) -> " ..//foo/bar" >> $(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT >> $(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> " ./baz/banan" >> $(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> " ../baz" >> >> As you can see, 1st case is just plain wrong, 2nd crashes make because of infinite loop, 3rd can be simplified and all of them have leading whitespaces >> First commit in this PR fixes all these issues and adds corresponding test cases and second commit replaces usage of `realpath` in idea.sh with `RelativePath` macro in idea.gmk and fixes problems, when paths are incorrectly treated by IDEA > This pull request has now been integrated. > > Changeset: 159cb6fa > Author: Nikita Gubarkov > Committer: Alexey Ushakov > URL: https://git.openjdk.java.net/jdk/commit/159cb6facc668acc30552665e46b18edf58c3a91 > Stats: 219 lines in 11 files changed: 107 ins; 47 del; 65 mod > > 8268083: JDK-8267706 breaks bin/idea.sh on a Mac > > Reviewed-by: erikj > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4369 From maurizio.cimadamore at oracle.com Tue Jun 15 13:33:44 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 14:33:44 +0100 Subject: Integrated: 8268083: JDK-8267706 breaks bin/idea.sh on a Mac In-Reply-To: References: <9QO9wAPeIwrFaGmBA1PCfyBR3CIG_vaVdBTPxgNoOf8=.f8cb58a4-dba6-4734-bf7d-3fe151a45582@github.com> Message-ID: Seems like another big change is that we try to create an IDE module per imported JDK module. Again, whether this is feasible or not is something which deserves more discussion. At the moment it just doesn't work. Maurizio On 15/06/2021 14:26, Maurizio Cimadamore wrote: > This PR removes support for the Ant support file. Without that, many > of the IDE actions are no longer working. Jtreg plugin support seems > broken as well, as you can no longer select which build target has to > be executed before the tests are run. > > I think I'm a bit concerned by these changes, in the sense that they > tweak quite a lot of the functionality of the IDE project, in ways > which makes them no longer working, and, more generally, this PR does > a lot more than just replacing realpath, it seems. > > I think we should back this out, and have a wider discussion (possibly > using ide-support mailing list) as to whether some of the features in > this PR are worth pursuing. > > As things stand, I can no longer use the IDE in a way which works. > > Maurizio > > On 08/06/2021 15:39, Nikita Gubarkov wrote: >> On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov >> wrote: >> >>> I got rid of `realpath` usage as discussed in >>> https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` >>> macro instead, however there were quite a few problems with this >>> macro, here's the example: >>> >>> $(call RelativePath,/foo/bar,/foo/bar/baz) -> " ..//foo/bar" >>> $(call RelativePath,/foo/bar/baz/,/foo/bar/baz) -> SEGFAULT >>> $(call RelativePath,/foo/bar/baz/banan,/foo/bar/) -> " ./baz/banan" >>> $(call RelativePath,/foo/bar/baz,/foo/bar/banan) -> " ../baz" >>> >>> As you can see, 1st case is just plain wrong, 2nd crashes make >>> because of infinite loop, 3rd can be simplified and all of them have >>> leading whitespaces >>> First commit in this PR fixes all these issues and adds >>> corresponding test cases and second commit replaces usage of >>> `realpath` in idea.sh with `RelativePath` macro in idea.gmk and >>> fixes problems, when paths are incorrectly treated by IDEA >> This pull request has now been integrated. >> >> Changeset: 159cb6fa >> Author:??? Nikita Gubarkov >> Committer: Alexey Ushakov >> URL: >> https://git.openjdk.java.net/jdk/commit/159cb6facc668acc30552665e46b18edf58c3a91 >> Stats:???? 219 lines in 11 files changed: 107 ins; 47 del; 65 mod >> >> 8268083: JDK-8267706 breaks bin/idea.sh on a Mac >> >> Reviewed-by: erikj >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/4369 From mcimadamore at openjdk.java.net Tue Jun 15 14:11:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 14:11:10 GMT Subject: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways Message-ID: As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any _targeted_ fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: https://openjdk.java.net/groups/ide-support/ ------------- Commit messages: - Revert idea.sh - Revert idea support changes Changes: https://git.openjdk.java.net/jdk/pull/4492/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4492&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268768 Stats: 690 lines in 12 files changed: 492 ins; 63 del; 135 mod Patch: https://git.openjdk.java.net/jdk/pull/4492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4492/head:pull/4492 PR: https://git.openjdk.java.net/jdk/pull/4492 From dfranken.jdk at gmail.com Tue Jun 15 14:15:26 2021 From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com) Date: Tue, 15 Jun 2021 16:15:26 +0200 Subject: Some possible enhancements for java.time.Duration? Message-ID: Dear readers, I think java.time.Duration is a pretty useful class and after having to work a lot with it, I recognized there might be some enhancements we could make (where 'enhancement' is a subjective term of course). For instance: Comparison ---------- boolean isGreaterThan(Duration duration) / isLongerThan(..) boolean isSmallerThan(Duration duration) / isShorterThan(..) English is not my primary language so I don't know which of these aliases would be better. Given that classes such as Instant and OffsetDateTime also have comparison methods (isAfter, isBefore), I think it would be useful if Duration had easy comparison methods. Of course we have compareTo(..) but I always get confused what it actually means when I get a positive or negative number. :) More comparison --------------- static Duration max(Duration d1, Duration d2) static Duration min(Duration d1, Duration d2) Returns the longest resp. shortest of the two durations, where negative durations are shorter than positive durations. Side note: I have not found an easy method to obtain the max resp. min values of elements which implement Comparable, I could only come up with something like: Stream.of(Duration.ZERO, Duration.ofSeconds(1L)) .max/min(Comparator.naturalOrder()) .orElse(null); It could be worthwile to add generic methods such as public static > T max(T... elements) public static > T min(T... elements) in the Comparator class. Disallowing negative value -------------------------- Okay, this one is a bit more farfetched, but a method which would be useful for my use case is to have an alternative of between() which is never negative and just truncates to zero if it happens to be negative. I'm measuring a duration between timestamps which come from different systems which should be in sync with their NTP servers (and each other), but there may still be some time dilation which could lead to weird results making it look like the effect happened before the cause. So I could see some use for a method like: Duration positiveOrZero() Kind regards, Dave Franken From scolebourne at joda.org Tue Jun 15 14:44:52 2021 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 15 Jun 2021 15:44:52 +0100 Subject: Some possible enhancements for java.time.Duration? In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 at 15:16, wrote: > Comparison > ---------- > boolean isGreaterThan(Duration duration) / isLongerThan(..) > boolean isSmallerThan(Duration duration) / isShorterThan(..) > > English is not my primary language so I don't know which of these > aliases would be better. Given that classes such as Instant and > OffsetDateTime also have comparison methods (isAfter, isBefore), I > think it would be useful if Duration had easy comparison methods. Of > course we have compareTo(..) but I always get confused what it actually > means when I get a positive or negative number. :) Maybe. Classes like OffsetDateTime have such methods because equals() and compareTo() have different definitions. My gut feeling is that this should not be done until Valhalla project has decided what if anything it will do with the need for operator overloading on value types. > More comparison > --------------- > static Duration max(Duration d1, Duration d2) > static Duration min(Duration d1, Duration d2) I don't see the point of this. If such methods are to be added, they should be generic, taking any Comparable > Disallowing negative value > -------------------------- > Okay, this one is a bit more farfetched, but a method which would be > useful for my use case is to have an alternative of between() which is > never negative and just truncates to zero if it happens to be negative. > > I'm measuring a duration between timestamps which come from different > systems which should be in sync with their NTP servers (and each > other), but there may still be some time dilation which could lead to > weird results making it look like the effect happened before the cause. I understand the use case, but it is too marginal for Duration IMO. thanks Stephen From psandoz at openjdk.java.net Tue Jun 15 15:02:44 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 15 Jun 2021 15:02:44 GMT Subject: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any _targeted_ fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ Agreed, let's back up and reevaluate. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4492 From jjg at openjdk.java.net Tue Jun 15 15:23:38 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 15 Jun 2021 15:23:38 GMT Subject: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any _targeted_ fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ Does this need backported to 17 (or pushed to 17 and "back"ported into 18)? ------------- PR: https://git.openjdk.java.net/jdk/pull/4492 From mcimadamore at openjdk.java.net Tue Jun 15 15:38:42 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 15:38:42 GMT Subject: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any _targeted_ fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ I can push to 17 if desired, but I'll need a new PR for that ------------- PR: https://git.openjdk.java.net/jdk/pull/4492 From jjg at openjdk.java.net Tue Jun 15 16:00:43 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 15 Jun 2021 16:00:43 GMT Subject: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 15:35:14 GMT, Maurizio Cimadamore wrote: > I can push to 17 if desired, but I'll need a new PR for that pushing to 17 would be nice; the script is equally broken and unusable there. ------------- PR: https://git.openjdk.java.net/jdk/pull/4492 From mcimadamore at openjdk.java.net Tue Jun 15 16:09:40 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 16:09:40 GMT Subject: Withdrawn: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any _targeted_ fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4492 From mcimadamore at openjdk.java.net Tue Jun 15 16:09:40 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 16:09:40 GMT Subject: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any _targeted_ fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ closing - and recreating against 17 ------------- PR: https://git.openjdk.java.net/jdk/pull/4492 From mcimadamore at openjdk.java.net Tue Jun 15 16:18:05 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 16:18:05 GMT Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways Message-ID: As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any targeted fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: https://openjdk.java.net/groups/ide-support/ ------------- Commit messages: - Add missing files - Initial push Changes: https://git.openjdk.java.net/jdk17/pull/61/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=61&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268768 Stats: 690 lines in 12 files changed: 492 ins; 63 del; 135 mod Patch: https://git.openjdk.java.net/jdk17/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk17/pull/61 From erikj at openjdk.java.net Tue Jun 15 16:31:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 16:31:41 GMT Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any targeted fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ I think reverting this is fine. In the original review, I tried to point out that it needed to be looked at by people who actually use this functionality, but that never happened. I wasn't aware of the ide-support mailing list. Would you like me to add automatic filtering in Skara so that changes touching these files are automatically labelled and mailed to that list? ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/61 From robert at marcanoonline.com Tue Jun 15 16:48:45 2021 From: robert at marcanoonline.com (Robert Marcano) Date: Tue, 15 Jun 2021 12:48:45 -0400 Subject: Some possible enhancements for java.time.Duration? In-Reply-To: References: Message-ID: <00396476-6bd9-8e53-13f0-74fc1921c31a@marcanoonline.com> On 6/15/21 10:15 AM, dfranken.jdk at gmail.com wrote: > Dear readers, > > I think java.time.Duration is a pretty useful class and after having to > work a lot with it, I recognized there might be some enhancements we > could make (where 'enhancement' is a subjective term of course). > > For instance: > > Comparison > ---------- > boolean isGreaterThan(Duration duration) / isLongerThan(..) > boolean isSmallerThan(Duration duration) / isShorterThan(..) > > English is not my primary language so I don't know which of these > aliases would be better. Given that classes such as Instant and > OffsetDateTime also have comparison methods (isAfter, isBefore), I > think it would be useful if Duration had easy comparison methods. Of > course we have compareTo(..) but I always get confused what it actually > means when I get a positive or negative number. :) A small tip when using compareTo, don?t think about the numbers but the operation. Always compare to 0 object1.compareTo(object2) > 0 ==> object1 > object2 You only change the comparison operator, and it always means object1 object2 > > More comparison > --------------- > static Duration max(Duration d1, Duration d2) > static Duration min(Duration d1, Duration d2) > > Returns the longest resp. shortest of the two durations, where negative > durations are shorter than positive durations. > > Side note: I have not found an easy method to obtain the max resp. min > values of elements which implement Comparable, I could only come up > with something like: > > Stream.of(Duration.ZERO, Duration.ofSeconds(1L)) > .max/min(Comparator.naturalOrder()) > .orElse(null); > > It could be worthwile to add generic methods such as > public static > T max(T... elements) > public static > T min(T... elements) > in the Comparator class. > > Disallowing negative value > -------------------------- > Okay, this one is a bit more farfetched, but a method which would be > useful for my use case is to have an alternative of between() which is > never negative and just truncates to zero if it happens to be negative. > > I'm measuring a duration between timestamps which come from different > systems which should be in sync with their NTP servers (and each > other), but there may still be some time dilation which could lead to > weird results making it look like the effect happened before the cause. > > So I could see some use for a method like: > > Duration positiveOrZero() > > > Kind regards, > > Dave Franken > From joehw at openjdk.java.net Tue Jun 15 17:13:43 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 15 Jun 2021 17:13:43 GMT Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano wrote: > Hi all, > > Could you please review the 8268457 bug fixes? > > The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair. > This fix changes the processing for non-surrogate pairs to the else condition. The fix looks good to me. For ToHTMLStream, please update the copyright year to 2021 (s/2019/2021) and s/@LastModified: Aug 2019/ @LastModified: June 2021. For the test, please move it to test/jaxp/javax/xml/jaxp/unittest/transform and make it a testng test (add @run testng transform.SurrogateTest, and @Test to each test case). For the test itself, you may replace the try-finally block with a try-with-resources statement. For comparing with the gold files, please take a look at the existing test library, specifically test/jaxp/javax/xml/jaxp/libs/jaxp/library/JAXPTestUtilities.java, and do it the testng way, e.g. Assert.assertTrue(compareWithGold(goldFile, outputFile)); ------------- PR: https://git.openjdk.java.net/jdk/pull/4474 From darcy at openjdk.java.net Tue Jun 15 18:12:02 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Jun 2021 18:12:02 GMT Subject: [jdk17] RFR: 8268736: Use apiNote in AutoCloseable.close javadoc Message-ID: The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like @apiNote. However, some of the discussion contained in AutoCloseable.close is more appropriate as an apiNote that normal text. ------------- Commit messages: - 8268736: Use apiNote in AutoCloseable.close javadoc Changes: https://git.openjdk.java.net/jdk17/pull/63/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=63&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268736 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/63.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/63/head:pull/63 PR: https://git.openjdk.java.net/jdk17/pull/63 From maurizio.cimadamore at oracle.com Tue Jun 15 18:14:29 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 19:14:29 +0100 Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On 15/06/2021 17:31, Erik Joelsson wrote: > On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore wrote: > >> As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). >> >> For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any targeted fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: >> >> https://openjdk.java.net/groups/ide-support/ > I think reverting this is fine. In the original review, I tried to point out that it needed to be looked at by people who actually use this functionality, but that never happened. > > I wasn't aware of the ide-support mailing list. Would you like me to add automatic filtering in Skara so that changes touching these files are automatically labelled and mailed to that list? That would be welcome, yes! Unfortunately cc'ing ide-support using the PR command doesn't work either, so some changes is needed on the Skara side. Thanks Maurizio > > ------------- > > Marked as reviewed by erikj (Reviewer). > > PR: https://git.openjdk.java.net/jdk17/pull/61 From bpb at openjdk.java.net Tue Jun 15 18:17:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 15 Jun 2021 18:17:38 GMT Subject: [jdk17] RFR: 8268736: Use apiNote in AutoCloseable.close javadoc In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote: > The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like @apiNote. However, some of the discussion contained in AutoCloseable.close is more appropriate as an apiNote that normal text. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/63 From naoto at openjdk.java.net Tue Jun 15 18:38:38 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 15 Jun 2021 18:38:38 GMT Subject: [jdk17] RFR: 8268736: Use apiNote in AutoCloseable.close javadoc In-Reply-To: References: Message-ID: <3Yy2TpLbztemf8meah1qbND66haB9LzPlvmgNmmME9g=.3fd50a6a-e348-448a-b238-4c3a87af7b90@github.com> On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote: > The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like @apiNote. However, some of the discussion contained in AutoCloseable.close is more appropriate as an apiNote that normal text. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/63 From prappo at openjdk.java.net Tue Jun 15 18:38:38 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 15 Jun 2021 18:38:38 GMT Subject: [jdk17] RFR: 8268736: Use apiNote in AutoCloseable.close javadoc In-Reply-To: References: Message-ID: <_2FHEPTk-RndwOygV0PJJgbH3xAUdtItUfoHkow7pkw=.3db1394f-f0fc-430b-842a-a6ba895815ef@github.com> On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote: > The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like @apiNote. However, some of the discussion contained in AutoCloseable.close is more appropriate as an apiNote that normal text. I'm confused: I thought that both https://openjdk.java.net/jeps/8068562 and the actual usages of `@apiNote` in `java.base` accumulated since then are advisory to the API users rather than to API implementors. ------------- PR: https://git.openjdk.java.net/jdk17/pull/63 From erikj at openjdk.java.net Tue Jun 15 18:49:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 18:49:41 GMT Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any targeted fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ Exactly, I need to add the label and the mailing list config. ------------- PR: https://git.openjdk.java.net/jdk17/pull/61 From darcy at openjdk.java.net Tue Jun 15 18:55:46 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Jun 2021 18:55:46 GMT Subject: [jdk17] Integrated: 8268736: Use apiNote in AutoCloseable.close javadoc In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote: > The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like @apiNote. However, some of the discussion contained in AutoCloseable.close is more appropriate as an apiNote that normal text. This pull request has now been integrated. Changeset: 31a055e6 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk17/commit/31a055e67a9a579a6b6ab26519271202da53a295 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8268736: Use apiNote in AutoCloseable.close javadoc Reviewed-by: bpb, naoto ------------- PR: https://git.openjdk.java.net/jdk17/pull/63 From erikj at openjdk.java.net Tue Jun 15 19:35:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 19:35:42 GMT Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: <81tArZjuobGMNn69AFs0Cf0rp63P8hnYK129kwoN44Y=.780a77da-a579-4200-8e74-30e57bbeef92@github.com> On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any targeted fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ Making the change here https://github.com/openjdk/skara/pull/1189 ------------- PR: https://git.openjdk.java.net/jdk17/pull/61 From erikj at openjdk.java.net Tue Jun 15 19:53:13 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 19:53:13 GMT Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any targeted fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ This comment should now end up in ide-support-dev as well. ------------- PR: https://git.openjdk.java.net/jdk17/pull/61 From mcimadamore at openjdk.java.net Tue Jun 15 20:27:30 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 20:27:30 GMT Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 19:50:12 GMT, Erik Joelsson wrote: > This comment should now end up in ide-support-dev as well. Not really (at least for now) :-) ------------- PR: https://git.openjdk.java.net/jdk17/pull/61 From erikj at openjdk.java.net Tue Jun 15 20:35:10 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 20:35:10 GMT Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: <2sVzrAc2Trd7YOsPd33QcMp-8sIQX4mc7KXWqgfLuoY=.13bd3b1e-a1e1-4b4e-a5e3-4803ae4e8ae0@github.com> On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any targeted fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ It got stuck in moderation. Tim has fixed the config now, so this message should hopefully appear. ------------- PR: https://git.openjdk.java.net/jdk17/pull/61 From mcimadamore at openjdk.java.net Tue Jun 15 20:40:40 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 20:40:40 GMT Subject: [jdk17] RFR: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: <2sVzrAc2Trd7YOsPd33QcMp-8sIQX4mc7KXWqgfLuoY=.13bd3b1e-a1e1-4b4e-a5e3-4803ae4e8ae0@github.com> References: <2sVzrAc2Trd7YOsPd33QcMp-8sIQX4mc7KXWqgfLuoY=.13bd3b1e-a1e1-4b4e-a5e3-4803ae4e8ae0@github.com> Message-ID: On Tue, 15 Jun 2021 20:31:52 GMT, Erik Joelsson wrote: > It got stuck in moderation. Tim has fixed the config now, so this message should hopefully appear. Yep - I see emails now. Thanks this is really useful! ------------- PR: https://git.openjdk.java.net/jdk17/pull/61 From mcimadamore at openjdk.java.net Tue Jun 15 20:40:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 15 Jun 2021 20:40:41 GMT Subject: [jdk17] Integrated: 8268768: idea.sh has been updated in surprising and incompatible ways In-Reply-To: References: Message-ID: <_R-KLkuGvNEqaQHiYDNoaUn2cuPZvpPJj0ULIz0_erI=.69f5dd00-b7a2-4f43-8194-d2e1f32e9794@github.com> On Tue, 15 Jun 2021 16:10:01 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the issues in more details), the IDE support for IntelliJ has been updated with many enhancements as part of a seemingly innocuous "path handling" fix. The IDE doesn't appear to be usable in the same way it was in the past and many functionalities have been broken as a result (including support for jtreg test execution using the plugin). > > For the above reasons, I'm reverting the plugin and idea.sh code to last known working version. Any targeted fix can be re-applied after the revert. Larger enhancements need to be discussed in the proper venue: > > https://openjdk.java.net/groups/ide-support/ This pull request has now been integrated. Changeset: 788b3095 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk17/commit/788b309563610b690306211790af17954f7556cb Stats: 690 lines in 12 files changed: 492 ins; 63 del; 135 mod 8268768: idea.sh has been updated in surprising and incompatible ways Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk17/pull/61 From jwilhelm at openjdk.java.net Tue Jun 15 22:01:09 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:01:09 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge jdk17 - 8268768: idea.sh has been updated in surprising and incompatible ways - 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64 - 8268723: Problem list SA core file tests on OSX when using ZGC - 8268736: Use apiNote in AutoCloseable.close javadoc - 8263321: Regression 8% in javadoc-steady in 17-b11 - 8268125: ZGC: Clone oop array gets wrong acopy stub - 8268663: Crash when guards contain boolean expression - 8268347: C2: nested locks optimization may create unbalanced monitor enter/exit code - 8268643: SVML lib shouldn't be generated when C2 is absent - ... and 7 more: https://git.openjdk.java.net/jdk/compare/0b09129f...e748b877 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4499/files Stats: 1606 lines in 62 files changed: 1180 ins; 181 del; 245 mod Patch: https://git.openjdk.java.net/jdk/pull/4499.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4499/head:pull/4499 PR: https://git.openjdk.java.net/jdk/pull/4499 From jwilhelm at openjdk.java.net Tue Jun 15 22:49:40 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:49:40 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson 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: - Merge jdk17 - 8268620: InfiniteLoopException test may fail on x86 platforms Reviewed-by: prr, trebari, azvegint - 8268125: ZGC: Clone oop array gets wrong acopy stub Reviewed-by: kvn, vlivanov - 8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name Co-authored-by: Markus GaisBauer Reviewed-by: stuefe, luhenry - 8268626: Remove native pre-jdk9 support for jtreg failure handler Reviewed-by: erikj - 8268699: Shenandoah: Add test for JDK-8268127 Reviewed-by: rkennke - Merge Reviewed-by: dcubed - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" Reviewed-by: prr - 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow Reviewed-by: dcubed, stefank, kbarrett - 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException Reviewed-by: darcy, jfranck - ... and 15 more: https://git.openjdk.java.net/jdk/compare/6da37cd0...e748b877 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4499/files - new: https://git.openjdk.java.net/jdk/pull/4499/files/e748b877..e748b877 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4499&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4499.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4499/head:pull/4499 PR: https://git.openjdk.java.net/jdk/pull/4499 From jwilhelm at openjdk.java.net Tue Jun 15 22:49:41 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 15 Jun 2021 22:49:41 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 21:51:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: e0f6f70d Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/e0f6f70d3f9e748d2bc53f371beca487e9343d4a Stats: 1606 lines in 62 files changed: 1180 ins; 181 del; 245 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4499 From sviswanathan at openjdk.java.net Wed Jun 16 00:20:32 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 16 Jun 2021 00:20:32 GMT Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz wrote: > Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/47 From jiefu at openjdk.java.net Wed Jun 16 01:23:38 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 16 Jun 2021 01:23:38 GMT Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz wrote: > Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. The test logic should be changed. If C2 is absent, libsvml.so would not be generated after JDK-8268643. Thanks. ------------- Changes requested by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/47 From avoitylov at openjdk.java.net Wed Jun 16 07:51:35 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Wed, 16 Jun 2021 07:51:35 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v7] In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 10:03:44 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thanks Mandy. I used your suggestions in the updated version. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Wed Jun 16 07:51:32 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Wed, 16 Jun 2021 07:51:32 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v8] In-Reply-To: References: Message-ID: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> > Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. > > Problem being fixed: > > The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. > > Proposed fix: > > The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. > > The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. > > Testing: jtreg and jck testing with no regressions. A new regression test was developed. Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3976/files - new: https://git.openjdk.java.net/jdk/pull/3976/files/f8423b97..b6ceda35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3976&range=06-07 Stats: 28 lines in 4 files changed: 7 ins; 6 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/3976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3976/head:pull/3976 PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Wed Jun 16 07:51:38 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Wed, 16 Jun 2021 07:51:38 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v7] In-Reply-To: References: Message-ID: <0Jtm5YFNGupbzMry9k62Z68kG5CW9ybMlAxmynuRyZs=.1c8e1711-d347-4de9-9dd8-e116d75e2b87@github.com> On Mon, 14 Jun 2021 18:30:23 GMT, Mandy Chung wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/LoadLibraryDeadlock.java line 44: > >> 42: try { >> 43: // an instance of unsigned class that loads a native library >> 44: Class c1 = Class.forName("Class1"); > > nit: `s/Class/Class/ ` avoid raw type (same in line 58) Changed as suggested. > test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java line 67: > >> 65: public Class loadClass(String name) throws ClassNotFoundException { >> 66: synchronized (getClassLoadingLock(name)) { >> 67: Class clazz = findLoadedClass(name); > > nit: `s/Class/Class/` Changed as suggested. > test/jdk/java/lang/ClassLoader/loadLibraryUnload/p/Class1.java line 40: > >> 38: System.loadLibrary("loadLibraryUnload"); >> 39: System.out.println("Native library loaded from Class1."); >> 40: } catch (Exception ignore) { > > should this exception just be thrown? Yep. Removed try-catch. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From yyang at openjdk.java.net Wed Jun 16 08:25:51 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 16 Jun 2021 08:25:51 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible Message-ID: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> After JDK-8265518, it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. ------------- Commit messages: - use checkIndex globally Changes: https://git.openjdk.java.net/jdk/pull/4507/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268698 Stats: 206 lines in 34 files changed: 31 ins; 111 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/4507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507 PR: https://git.openjdk.java.net/jdk/pull/4507 From github.com+741251+turbanoff at openjdk.java.net Wed Jun 16 09:22:49 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Jun 2021 09:22:49 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 16:05:06 GMT, Michael Bien wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. >> I checked only places where `Vector` was used as local variable. > > src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 592: > >> 590: >> 591: SignerInfo[] result = new SignerInfo[intResult.size()]; >> 592: return intResult.toArray(result); > > could be simplified to > `return intResult.toArray(new SignerInfo[0]);` > which would eliminate array zeroing as bonus as I have learned from your other PR ;) I considered this, when I was preparing the patch. But decided to reduce scope of changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From github.com+114367+mbien at openjdk.java.net Wed Jun 16 09:22:48 2021 From: github.com+114367+mbien at openjdk.java.net (Michael Bien) Date: Wed, 16 Jun 2021 09:22:48 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. > I checked only places where `Vector` was used as local variable. src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 592: > 590: > 591: SignerInfo[] result = new SignerInfo[intResult.size()]; > 592: return intResult.toArray(result); could be simplified to `return intResult.toArray(new SignerInfo[0]);` which would eliminate array zeroing as bonus as I have learned from your other PR ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From github.com+741251+turbanoff at openjdk.java.net Wed Jun 16 09:22:47 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Jun 2021 09:22:47 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base Message-ID: Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. I checked only places where `Vector` was used as local variable. ------------- Commit messages: - [PATCH] Unnecessary Vector usage in java.base - [PATCH] Unnecessary Vector usage in JarIndex.read Changes: https://git.openjdk.java.net/jdk/pull/4482/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4482&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268873 Stats: 18 lines in 3 files changed: 1 ins; 4 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/4482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4482/head:pull/4482 PR: https://git.openjdk.java.net/jdk/pull/4482 From github.com+10835776+stsypanov at openjdk.java.net Wed Jun 16 09:22:47 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 16 Jun 2021 09:22:47 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov wrote: > Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. > I checked only places where `Vector` was used as local variable. I've filed https://bugs.openjdk.java.net/browse/JDK-8268873 for this, just put `/issue 8268873` as a comment for this ticket to bind it to the issue src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 154: > 152: while (tokenizer.hasMoreTokens()) > 153: v.add(tokenizer.nextToken()); > 154: ciphers = new String [v.size()]; Looks like this whole `else` block can be simplified to `ciphers = cipherString.split(",");` ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From github.com+741251+turbanoff at openjdk.java.net Wed Jun 16 09:52:38 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 16 Jun 2021 09:52:38 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: References: Message-ID: <-EAGwB2tzRt86ysHiUsCDlvWmd62GIPZfk24c7T5nuM=.e332b6c0-2754-4c60-9e20-a90a311fc1ad@github.com> On Wed, 16 Jun 2021 09:01:30 GMT, ?????? ??????? wrote: >> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. >> I checked only places where `Vector` was used as local variable. > > src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 154: > >> 152: while (tokenizer.hasMoreTokens()) >> 153: v.add(tokenizer.nextToken()); >> 154: ciphers = new String [v.size()]; > > Looks like this whole `else` block can be simplified to `ciphers = cipherString.split(",");` It's not a drop-in replacement. Result is different for some Strings. For example for `, A` I would prefer to preserve existing behavior under this cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From jboes at openjdk.java.net Wed Jun 16 10:03:49 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 16 Jun 2021 10:03:49 GMT Subject: [jdk17] RFR: 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException Message-ID: In the methods in question, `RejectedExecutionException` is an expected exception that was previously unhandled (it is a `RuntimeException`, not a subclass of `ExecutionException`). This change adds `RejectedExecutionException` to the existing catch clause. ------------- Commit messages: - initial change Changes: https://git.openjdk.java.net/jdk17/pull/74/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=74&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268080 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk17/pull/74.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/74/head:pull/74 PR: https://git.openjdk.java.net/jdk17/pull/74 From chegar at openjdk.java.net Wed Jun 16 10:25:35 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 16 Jun 2021 10:25:35 GMT Subject: [jdk17] RFR: 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException In-Reply-To: References: Message-ID: <4Ez2noGzhw4o76tHeMW7Nf6GIuxknhAMMkIg8Gkr4rA=.8efa3f20-5895-44b4-8cc3-d962d76e409e@github.com> On Wed, 16 Jun 2021 09:57:29 GMT, Julia Boes wrote: > In the methods in question, `RejectedExecutionException` is an expected exception that was previously unhandled (it is a `RuntimeException`, not a subclass of `ExecutionException`). This change adds `RejectedExecutionException` to the existing catch clause. Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/74 From prappo at openjdk.java.net Wed Jun 16 10:31:34 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 16 Jun 2021 10:31:34 GMT Subject: [jdk17] RFR: 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 09:57:29 GMT, Julia Boes wrote: > In the methods in question, `RejectedExecutionException` is an expected exception that was previously unhandled (it is a `RuntimeException`, not a subclass of `ExecutionException`). This change adds `RejectedExecutionException` to the existing catch clause. test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAny.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. Why did you replace the year rather than append it? ------------- PR: https://git.openjdk.java.net/jdk17/pull/74 From dfuchs at openjdk.java.net Wed Jun 16 10:36:35 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Jun 2021 10:36:35 GMT Subject: [jdk17] RFR: 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 09:57:29 GMT, Julia Boes wrote: > In the methods in question, `RejectedExecutionException` is an expected exception that was previously unhandled (it is a `RuntimeException`, not a subclass of `ExecutionException`). This change adds `RejectedExecutionException` to the existing catch clause. Marked as reviewed by dfuchs (Reviewer). test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNow.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. Same remark that Pavel made below. Otherwise look good. Please fix the copyright years to `2020, 2021,` before integrating. ------------- PR: https://git.openjdk.java.net/jdk17/pull/74 From dfuchs at openjdk.java.net Wed Jun 16 10:48:54 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 16 Jun 2021 10:48:54 GMT Subject: [jdk17] RFR: 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException [v2] In-Reply-To: References: Message-ID: <1FQf2bNJxpc-NgFwbPSFR97p3ZpzrJLzKligKFvwpII=.1b2ef35e-2745-4bf4-9c0d-5dc7a5258505@github.com> On Wed, 16 Jun 2021 10:45:20 GMT, Julia Boes wrote: >> In the methods in question, `RejectedExecutionException` is an expected exception that was previously unhandled (it is a `RuntimeException`, not a subclass of `ExecutionException`). This change adds `RejectedExecutionException` to the existing catch clause. > > Julia Boes has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright year Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/74 From jboes at openjdk.java.net Wed Jun 16 10:48:54 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 16 Jun 2021 10:48:54 GMT Subject: [jdk17] RFR: 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException [v2] In-Reply-To: References: Message-ID: > In the methods in question, `RejectedExecutionException` is an expected exception that was previously unhandled (it is a `RuntimeException`, not a subclass of `ExecutionException`). This change adds `RejectedExecutionException` to the existing catch clause. Julia Boes has updated the pull request incrementally with one additional commit since the last revision: fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/74/files - new: https://git.openjdk.java.net/jdk17/pull/74/files/9e2f2da1..7a1d82b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=74&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=74&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/74.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/74/head:pull/74 PR: https://git.openjdk.java.net/jdk17/pull/74 From jboes at openjdk.java.net Wed Jun 16 10:48:56 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Wed, 16 Jun 2021 10:48:56 GMT Subject: [jdk17] RFR: 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException [v2] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 10:28:11 GMT, Pavel Rappo wrote: >> Julia Boes has updated the pull request incrementally with one additional commit since the last revision: >> >> fix copyright year > > test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAny.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > > Why did you replace the year rather than append it? Oops, thanks for spotting! ------------- PR: https://git.openjdk.java.net/jdk17/pull/74 From pconcannon at openjdk.java.net Wed Jun 16 10:57:12 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 16 Jun 2021 10:57:12 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: On Wed, 9 Jun 2021 22:03:54 GMT, Stephen Colebourne wrote: >> Patrick Concannon 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: >> >> - 8268469: Removed excessive spacing; corrected misplaced comments >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - 8268469: Update java.time to use switch expressions > > src/java.base/share/classes/java/time/LocalDate.java line 608: > >> 606: if (chronoField.isDateBased()) { >> 607: return switch (chronoField) { >> 608: case DAY_OF_MONTH -> ValueRange.of(1, lengthOfMonth()); > > For the record, I hate code that is aligned like this. It makes refactoring much more noisy, as the author has to readjust all the associated lines. I also don't believe it is within the spirit of Java's traditional coding guidelines. Hi Stephen. Thanks for your comments. I've tried removing the excessive spacing as you suggested. Please let me know what you think. See commit 2ae4a57 > src/java.base/share/classes/java/time/format/SignStyle.java line 129: > >> 127: // valid if negative or (positive and lenient) >> 128: case 0 -> !positive || !strict;// NORMAL >> 129: case 1, 4 -> true; // ALWAYS, EXCEEDS_PAD > > Extra space before `4` Extra space removed. Please see commit 2ae4a57 ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From pconcannon at openjdk.java.net Wed Jun 16 10:57:28 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 16 Jun 2021 10:57:28 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: <77duiMdW0OcTvKM8GHE9QSzauQK2JVPIRj2myEdqYKk=.467f310d-5c10-4f85-b222-a54b560aa9df@github.com> References: <77duiMdW0OcTvKM8GHE9QSzauQK2JVPIRj2myEdqYKk=.467f310d-5c10-4f85-b222-a54b560aa9df@github.com> Message-ID: <-UiqdJDiRVGPRlICiOE0TyF1YgY6gTnK42JAG4ceT3Y=.9df4e507-437c-4e59-819b-1d2eb2466406@github.com> On Wed, 9 Jun 2021 16:31:10 GMT, Daniel Fuchs wrote: >> Patrick Concannon 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: >> >> - 8268469: Removed excessive spacing; corrected misplaced comments >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - 8268469: Update java.time to use switch expressions > > src/java.base/share/classes/java/time/Month.java line 491: > >> 489: case OCTOBER -> 274 + leap; >> 490: case NOVEMBER -> 305 + leap; >> 491: default -> 335 + leap; > > It would be better to keep `DECEMBER` here for clarity - even if only in a comment - e.g: > > > case NOVEMBER -> 305 + leap; > // otherwise (DECEMBER) > default -> 335 + leap; Hi Daniel. Thanks for your suggestion. Comment added. Please see commit 2ae4a57 > src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java line 334: > >> 332: >> 333: default -> with(isoDate.with(field, newValue)); >> 334: }; > > My preference would be to keep the imbricated switch structure: it is not obvious whether this change is correct. Have you verified that `getChronology().range(chronoField).checkValidIntValue(newValue, chronoField);` is a no op when chronoField == ERA? I've reverted these changes as requested. Please see commit 2ae4a57 > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 4992: > >> 4990: } >> 4991: default -> throw new IllegalStateException("unreachable"); >> 4992: }; > > Not sure I like the new version more than the old, as it seems to lead to more duplication. > Maybe the 'Y' case should be tested before entering the switch - then the switch could be used to assign > `var field = switch (chr) {...};` Reverted these changes as requested. Please see commit 2ae4a57 ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From pconcannon at openjdk.java.net Wed Jun 16 10:57:07 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 16 Jun 2021 10:57:07 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: > Hi, > > Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? > > Kind regards, > Patrick Patrick Concannon 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: - 8268469: Removed excessive spacing; corrected misplaced comments - Merge remote-tracking branch 'origin/master' into JDK-8268469 - Merge remote-tracking branch 'origin/master' into JDK-8268469 - 8268469: Update java.time to use switch expressions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4433/files - new: https://git.openjdk.java.net/jdk/pull/4433/files/2abbea11..2ae4a574 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=01-02 Stats: 12287 lines in 307 files changed: 9481 ins; 1521 del; 1285 mod Patch: https://git.openjdk.java.net/jdk/pull/4433.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4433/head:pull/4433 PR: https://git.openjdk.java.net/jdk/pull/4433 From pconcannon at openjdk.java.net Wed Jun 16 10:57:19 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 16 Jun 2021 10:57:19 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: <66Q2Tvm4vf5IZJKVW2wA9HhvFsNrtDLsdegxtkPB2Mo=.136c3947-16f3-4115-9c14-01b61dc79742@github.com> On Wed, 9 Jun 2021 16:25:55 GMT, Naoto Sato wrote: >> Patrick Concannon 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: >> >> - 8268469: Removed excessive spacing; corrected misplaced comments >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - 8268469: Update java.time to use switch expressions > > src/java.base/share/classes/java/time/LocalDateTime.java line 1188: > >> 1186: case HOURS -> plusHours(amountToAdd); >> 1187: case HALF_DAYS -> plusDays(amountToAdd / 256).plusHours((amountToAdd % 256) * 12); >> 1188: default -> with(date.plus(amountToAdd, unit), time); // no overflow (256 is multiple of 2) > > The comment is misplaced. Hi Naoto. Thanks for spotting this. I've corrected that now. Please see commit 2ae4a57 > src/java.base/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java line 310: > >> 308: case HOURS -> plusHours(amountToAdd); >> 309: case HALF_DAYS -> plusDays(amountToAdd / 256).plusHours((amountToAdd % 256) * 12); >> 310: default -> with(date.plus(amountToAdd, unit), time); // no overflow (256 is multiple of 2) > > Misplaced comment here too. Comment corrected. Please see commit 2ae4a57 > src/java.base/share/classes/java/time/format/SignStyle.java line 127: > >> 125: boolean parse(boolean positive, boolean strict, boolean fixedWidth) { >> 126: return switch (ordinal()) { >> 127: // valid if negative or (positive and lenient) > > The comment should apply only to the `case 0`. Comment corrected. Please see commit 2ae4a57 ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From scolebourne at openjdk.java.net Wed Jun 16 11:06:43 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 16 Jun 2021 11:06:43 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 10:57:07 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon 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: > > - 8268469: Removed excessive spacing; corrected misplaced comments > - Merge remote-tracking branch 'origin/master' into JDK-8268469 > - Merge remote-tracking branch 'origin/master' into JDK-8268469 > - 8268469: Update java.time to use switch expressions src/java.base/share/classes/java/time/LocalDate.java line 607: > 605: if (field instanceof ChronoField chronoField) { > 606: if (chronoField.isDateBased()) { > 607: int n = switch (chronoField) { This logic is harder to read than before, and it requires the CPU to perform an extra branch on `(n == -1)`. It should just be a `return switch ...` src/java.base/share/classes/java/time/LocalDateTime.java line 1181: > 1179: if (unit instanceof ChronoUnit chronoUnit) { > 1180: return switch (chronoUnit) { > 1181: case NANOS -> plusNanos(amountToAdd); Still has unnecessary alignment There are lots of cases in the PR where `->` is still aligned. I'd like to see all of them unaligned. src/java.base/share/classes/java/time/Month.java line 480: > 478: int leap = leapYear ? 1 : 0; > 479: return switch (this) { > 480: case JANUARY -> 1; Unnecessary alignment ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From pconcannon at openjdk.java.net Wed Jun 16 11:14:45 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Wed, 16 Jun 2021 11:14:45 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: <7asoItHRvYVjU9eCFoI75KZFFKHooZG9wUJ3qoZkA64=.f20271ce-6653-4d6b-bb39-664106d6e498@github.com> On Wed, 9 Jun 2021 22:11:59 GMT, Stephen Colebourne wrote: >> Patrick Concannon 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: >> >> - 8268469: Removed excessive spacing; corrected misplaced comments >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - 8268469: Update java.time to use switch expressions > > src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java line 331: > >> 329: yield with(isoDate.withYear(nvalue - YEARS_DIFFERENCE)); >> 330: } >> 331: case ERA -> with(isoDate.withYear((1 - getProlepticYear()) - YEARS_DIFFERENCE)); > > `checkValidIntValue` performs validation, so removing it has changed the behavoiur Changes reverted. See 2ae4a57 ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From chegar at openjdk.java.net Wed Jun 16 11:14:40 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 16 Jun 2021 11:14:40 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 10:59:59 GMT, Stephen Colebourne wrote: >> Patrick Concannon 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: >> >> - 8268469: Removed excessive spacing; corrected misplaced comments >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - Merge remote-tracking branch 'origin/master' into JDK-8268469 >> - 8268469: Update java.time to use switch expressions > > src/java.base/share/classes/java/time/Month.java line 480: > >> 478: int leap = leapYear ? 1 : 0; >> 479: return switch (this) { >> 480: case JANUARY -> 1; > > Unnecessary alignment The vertical alignment improves readability in these short-line cases. Removing the spaces before the arrows will make it a little harder to discern the difference between the cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From jvernee at openjdk.java.net Wed Jun 16 11:25:58 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Jun 2021 11:25:58 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails Message-ID: Upstream a critical fix from the panama-foreign repo. See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 Testing: tier 1-2, local run of run-test-jdk_foreign. ------------- Commit messages: - Fix a couple of CI build problems - Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails Changes: https://git.openjdk.java.net/jdk17/pull/76/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=76&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268717 Stats: 197 lines in 12 files changed: 196 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/76.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/76/head:pull/76 PR: https://git.openjdk.java.net/jdk17/pull/76 From maurizio.cimadamore at oracle.com Wed Jun 16 13:11:38 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 14:11:38 +0100 Subject: jpackage issue with --dest Message-ID: Hi, I'm relatively new to jpackage and I found a weird issue on linux where the name of a --dest folder can affect the correct behavior of the generated application image. I have put together an hello world application, with a jarfile. If I jpackage it with the following command line: ``` $ jpackage --type app-image --name HelloWorld --input out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest output ``` Everything works correctly, and launching the generated app prints "Hello world": ``` $ output/HelloWorld/bin/HelloWorld Hello world! ``` However, if the destination directory contains "bin" (even as a nested subfolder), there are issues. Here's the jextract command line: ``` $ jpackage --type app-image --name HelloWorld --input out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest bin ``` (the only thihng that changed is the --dest parameter) And here's what I get: ``` $ bin/HelloWorld/bin/HelloWorld Error: could not find libjava.so Error: Could not find Java SE Runtime Environment. ``` I use Ubuntu 20.04. A colleague of mine using MacOS does not seem to have the same issue, so it seems to be system specific. I'm using the latest jpackage from jdk/jdk. Is this a known issue? Cheers Maurizio From david.lloyd at redhat.com Wed Jun 16 13:18:14 2021 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 16 Jun 2021 08:18:14 -0500 Subject: JEP 411: Deprecation with removal would break most existing Java libraries In-Reply-To: References: <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com> <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au> Message-ID: On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone wrote: > SecurityManager depends on Permission, currently there are Permission > checks throughout the JVM, however Permission implementation classes > will be removed, although the Permission class itself won't be. This is incorrect AFAICT. The relevant JEP text is: > Permission and subclasses ? Other significant classes, such as ProtectionDomain, depend on Permission. Many of the subclasses of Permission, however, are specific to use cases which will likely no longer be relevant after the Security Manager is removed. The maintainers of these subclasses can deprecate and remove them separately, after evaluating the compatibility risk. > Permission references can be replaced with Guard references (which > Permissions are instances of). I guess you've got something fairly complex in mind, could you give some practical examples of how this would work? > The Permission implementations of Guard::check call SecurityManager, so > checks will continue working as expected, but it allows us to intercept > them and do something different. What do you envision these checks looking like? Where would the JDK find these Guard instances? > By replacing Permission references with Guard, it allows us to implement > our own checks in these locations, and OpenJDK doesn't need to maintain > Permission instances, and or, we don't need to make use of unmaintained > Permission implementations. As I said I don't think there is an intention to remove the permission classes just yet, and I don't think that it is a fair statement to say that the permission implementations would be unmaintained. Most of those classes have not needed to be touched in many years; there's just not a lot of complexity there for the vast majority of them. > There are already issues with Permission implementations, take for > example SocketPermission, it consults DNS and it isn't possible to enter > a range of IP addresses (such as the local subnet, and a list of public > IP addresses), for now, every single IP address must be entered and this > isn't practical. The proposed API would allow us to re-implement > SocketPermission functionality, as well as other Permission implementations. Sure, this would be nice to clean up. I just don't understand the proposed mechanism. > > On Mon, Jun 14, 2021 at 12:57 AM Alan Bateman wrote: > >> AccessController::doPriv just runs the action. > > TBH this should have always been the case. Implementation-wise, if > > one were constructing an access control context based on stack > > walking, one would stop at points where `AccessController` is on the > > stack (which is easily determinable) to do special work on assembling > > the access control context based on the method called at that frame. > > Yes, one can do that, but these classes will also eventually be removed. Sure. This was mainly a practical observation about the current implementation. And any replacement third-party stack-based authorization system could (and should) use a similar mechanism regardless of whether these exact methods stay in the JDK for 5 or 50 more years. -- - DML ? he/him From jlahoda at openjdk.java.net Wed Jun 16 15:25:13 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 16 Jun 2021 15:25:13 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved Message-ID: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding. How does this look? ------------- Commit messages: - Adding and fixing test. - Merging master. - 8268766: Desugaring of pattern matching enum switch should be improved Changes: https://git.openjdk.java.net/jdk17/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268766 Stats: 313 lines in 6 files changed: 165 ins; 76 del; 72 mod Patch: https://git.openjdk.java.net/jdk17/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81 PR: https://git.openjdk.java.net/jdk17/pull/81 From psandoz at openjdk.java.net Wed Jun 16 15:29:19 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 16 Jun 2021 15:29:19 GMT Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image [v2] In-Reply-To: References: Message-ID: > Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Require C2. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/47/files - new: https://git.openjdk.java.net/jdk17/pull/47/files/a0c66bd6..ed59678e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=47&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=47&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/47/head:pull/47 PR: https://git.openjdk.java.net/jdk17/pull/47 From psandoz at openjdk.java.net Wed Jun 16 15:37:35 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 16 Jun 2021 15:37:35 GMT Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image [v2] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 01:20:39 GMT, Jie Fu wrote: >> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: >> >> Require C2. > > The test logic should be changed. > > If C2 is absent, libsvml.so would not be generated after JDK-8268643. > Thanks. @DamonFool thanks. I updated the test to require C2. This is not exactly what i want but i think is sufficient for now. ------------- PR: https://git.openjdk.java.net/jdk17/pull/47 From mcimadamore at openjdk.java.net Wed Jun 16 15:57:44 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 15:57:44 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 11:19:37 GMT, Jorn Vernee wrote: > Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. I've approved a similar changeset on panama-dev. Looks still good :-) ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/76 From mchung at openjdk.java.net Wed Jun 16 16:02:42 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 16 Jun 2021 16:02:42 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v8] In-Reply-To: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> References: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> Message-ID: <5JG8spPlGwIAlYtUrro-tXArYdYTc0gIhzdcAttYYgo=.ea130dbe-1ece-4052-8f91-fe08654e40b7@github.com> On Wed, 16 Jun 2021 07:51:32 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 95: > 93: Collections.addAll(args, "cvf", Paths.get(testClassPath, outputJar).toString()); > 94: for (String c : classes) { > 95: Collections.addAll(args, "-C", testClassPath, c); I believe only one single `-C` option is good enough for this case since the classes are all in one single directory. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From mchung at openjdk.java.net Wed Jun 16 16:07:42 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 16 Jun 2021 16:07:42 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v8] In-Reply-To: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> References: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> Message-ID: On Wed, 16 Jun 2021 07:51:32 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Looks good. Do you want to fix this in JDK 17? You will need to create a new PR for jdk17 repo and withdraw this one. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From naoto at openjdk.java.net Wed Jun 16 16:18:45 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Jun 2021 16:18:45 GMT Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano wrote: > Hi all, > > Could you please review the 8268457 bug fixes? > > The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair. > This fix changes the processing for non-surrogate pairs to the else condition. src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java line 1455: > 1453: } > 1454: else > 1455: */ I just wonder the bug was caused by this commenting out, which erroneously removed the `else` here. If the comment-out portion is no longer needed, we could just delete it for good. ------------- PR: https://git.openjdk.java.net/jdk/pull/4474 From scolebourne at openjdk.java.net Wed Jun 16 16:46:41 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 16 Jun 2021 16:46:41 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 11:11:30 GMT, Chris Hegarty wrote: >> src/java.base/share/classes/java/time/Month.java line 480: >> >>> 478: int leap = leapYear ? 1 : 0; >>> 479: return switch (this) { >>> 480: case JANUARY -> 1; >> >> Unnecessary alignment > > The vertical alignment improves readability in these short-line cases. Removing the spaces before the arrows will make it a little harder to discern the difference between the cases. It is your codebase, not mine, so it is up to you. Aligning things by column is generally frowned on in most style guides because it handles refactoring poorly, resulting in lots of needless change (or people forgetting to realign things - I had to deal with a rogue aligned Javadoc signature today in a PR where exactly that had happened). I also don't see how you write a style guide rule for when these should be aligned and when they should not. Anyway, this PR isn't really the right place for this discussion - I'm not blocking the PR on this basis (and I'm not an official Reviewer anyway). ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From brian.goetz at oracle.com Wed Jun 16 16:54:16 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 16 Jun 2021 12:54:16 -0400 Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: Bootstrap methods are cheap. If you have one that is semantically different, better to write a separate bootstrap than to try and cram two sets of functionality into one.? So +1 for "make a new bootstrap for enums." On 6/16/2021 11:25 AM, Jan Lahoda wrote: > Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding. > > How does this look? > > ------------- > > Commit messages: > - Adding and fixing test. > - Merging master. > - 8268766: Desugaring of pattern matching enum switch should be improved > > Changes: https://git.openjdk.java.net/jdk17/pull/81/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8268766 > Stats: 313 lines in 6 files changed: 165 ins; 76 del; 72 mod > Patch: https://git.openjdk.java.net/jdk17/pull/81.diff > Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81 > > PR: https://git.openjdk.java.net/jdk17/pull/81 From alexey.semenyuk at oracle.com Wed Jun 16 17:28:09 2021 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 16 Jun 2021 13:28:09 -0400 Subject: jpackage issue with --dest In-Reply-To: References: Message-ID: Hi Maurizio, This is not known issue. Can you run the app with "JPACKAGE_DEBUG" env variable set to "true". In this case the app launcher will produce debug output that will help to understand why it can't find libjava.so. - Alexey On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote: > Hi, > I'm relatively new to jpackage and I found a weird issue on linux > where the name of a --dest folder can affect the correct behavior of > the generated application image. > > I have put together an hello world application, with a jarfile. If I > jpackage it with the following command line: > > ``` > $ jpackage --type app-image --name HelloWorld --input > out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest > output > ``` > > Everything works correctly, and launching the generated app prints > "Hello world": > > ``` > $ output/HelloWorld/bin/HelloWorld > Hello world! > ``` > > However, if the destination directory contains "bin" (even as a nested > subfolder), there are issues. Here's the jextract command line: > > ``` > $ jpackage --type app-image --name HelloWorld --input > out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest bin > ``` > > (the only thihng that changed is the --dest parameter) > > And here's what I get: > > ``` > $ bin/HelloWorld/bin/HelloWorld > Error: could not find libjava.so > Error: Could not find Java SE Runtime Environment. > ``` > > I use Ubuntu 20.04. A colleague of mine using MacOS does not seem to > have the same issue, so it seems to be system specific. > > I'm using the latest jpackage from jdk/jdk. > > Is this a known issue? > > Cheers > Maurizio > From jvernee at openjdk.java.net Wed Jun 16 17:39:38 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Jun 2021 17:39:38 GMT Subject: [jdk17] RFR: 8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken Message-ID: <4KuMCXKzbvdVI0v5C7zyx4NX216Wk_7G73lzrIhsZsU=.601fe18b-500f-413a-9a2e-067d08338b27@github.com> Upstream fix for 8268230 to mainline JDK. Prior review thread can be found here: https://github.com/openjdk/panama-foreign/pull/554 Testing: jdk_foreign test suite on Windows and Linux (WSL). ------------- Commit messages: - 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken - 8268633: CLinker::toJavaString doesn't check for NULL address Changes: https://git.openjdk.java.net/jdk17/pull/77/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=77&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268888 Stats: 315 lines in 6 files changed: 148 ins; 154 del; 13 mod Patch: https://git.openjdk.java.net/jdk17/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/77/head:pull/77 PR: https://git.openjdk.java.net/jdk17/pull/77 From maurizio.cimadamore at oracle.com Wed Jun 16 17:52:17 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 18:52:17 +0100 Subject: jpackage issue with --dest In-Reply-To: References: Message-ID: <12421ff3-be38-b232-6fe2-5b36b35dacfb@oracle.com> This is what I get when I run jpackage: ``` $ jpackage --type app-image --name HelloWorld --input /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest bin [18:50:09.375] jpackage argument list: [--type, app-image, --name, HelloWorld, --input, /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar, --main-jar, jpackage-test.jar, --dest, bin] [18:50:09.409] Running dpkg [18:50:09.420] Command [PID: 399487]: ??? dpkg --print-architecture [18:50:09.420] Output: ??? amd64 [18:50:09.422] Returned: 0 [18:50:09.431] Creating app package: HelloWorld in /tmp/bin [18:50:13.288] Command [PID: -1]: ??? jlink --output bin/HelloWorld/lib/runtime --module-path /w/lt/jdk/dev/build/linux-x86_64-server-release/images/jdk/jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.sctp,jdk.jsobject,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.logging,java.transaction.xa,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files [18:50:13.288] Output: ??? WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.vector [18:50:13.288] Returned: 0 [18:50:13.292] Using default package resource JavaApp.png [icon] (add HelloWorld.png to the resource-dir to customize). [18:50:13.302] Succeeded in building Linux Application Image package ``` And this is what happens when I run the generated binary: ``` $ bin/HelloWorld/bin/HelloWorld popen: (rpm --queryformat '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) popen: exit: 32512 popen: (dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) popen: exit: 256 [TRACE] app.cpp:123: Entering launch [TRACE] Executor.cpp:41: Reading output of [rpm --queryformat '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command [TRACE] Executor.cpp:41: Reading output of [dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command [TRACE] LinuxLauncherLib.cpp:121: Set _JPACKAGE_LAUNCHER=[0] [TRACE] AppLauncher.cpp:99: Launcher config file path: "/tmp/bin/HelloWorld/lib/app/HelloWorld.cfg" [TRACE] JvmLauncher.cpp:43: Jvm(0x55a49cb86750)::Jvm() [TRACE] AppLauncher.cpp:71: Property "app.runtime" not found in "Application" section of launcher config file. Using Java runtime from "/tmp/bin/HelloWorld/lib/runtime" directory [TRACE] app.cpp:0: Exiting launch (entered at app.cpp:123) [TRACE] JvmLauncher.cpp:48: Jvm(0x55a49cb86750)::~Jvm() [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer [TRACE] JvmLauncher.cpp:269: Initialized 310 bytes at 0x55a49cb86cc0 address [TRACE] LinuxLauncherLib.cpp:157: unload jli lib: [/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so] jli arg[0]: [/tmp/bin/HelloWorld/bin/HelloWorld] jli arg[1]: [-classpath] jli arg[2]: [/tmp/bin/HelloWorld/lib/app/jpackage-test.jar] jli arg[3]: [-Djpackage.app-version=1.0] jli arg[4]: [-Djpackage.app-path=/tmp/bin/HelloWorld/bin/HelloWorld] jli arg[5]: [main.Main] Error: could not find libjava.so Error: Could not find Java SE Runtime Environment. ``` Does that clarify things? Thanks Maurizio On 16/06/2021 18:28, Alexey Semenyuk wrote: > Hi Maurizio, > > This is not known issue. > Can you run the app with "JPACKAGE_DEBUG" env variable set to "true". > In this case the app launcher will produce debug output that will help > to understand why it can't find libjava.so. > > - Alexey > > On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote: >> Hi, >> I'm relatively new to jpackage and I found a weird issue on linux >> where the name of a --dest folder can affect the correct behavior of >> the generated application image. >> >> I have put together an hello world application, with a jarfile. If I >> jpackage it with the following command line: >> >> ``` >> $ jpackage --type app-image --name HelloWorld --input >> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest >> output >> ``` >> >> Everything works correctly, and launching the generated app prints >> "Hello world": >> >> ``` >> $ output/HelloWorld/bin/HelloWorld >> Hello world! >> ``` >> >> However, if the destination directory contains "bin" (even as a >> nested subfolder), there are issues. Here's the jextract command line: >> >> ``` >> $ jpackage --type app-image --name HelloWorld --input >> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest bin >> ``` >> >> (the only thihng that changed is the --dest parameter) >> >> And here's what I get: >> >> ``` >> $ bin/HelloWorld/bin/HelloWorld >> Error: could not find libjava.so >> Error: Could not find Java SE Runtime Environment. >> ``` >> >> I use Ubuntu 20.04. A colleague of mine using MacOS does not seem to >> have the same issue, so it seems to be system specific. >> >> I'm using the latest jpackage from jdk/jdk. >> >> Is this a known issue? >> >> Cheers >> Maurizio >> > From erikj at openjdk.java.net Wed Jun 16 18:31:17 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Jun 2021 18:31:17 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: References: Message-ID: <3W5BzWLZfdLQsyUogaHRLbensa4yVdcYJoIIHRMjfyU=.840abb1d-d52e-4941-af51-a7b04f853563@github.com> On Wed, 16 Jun 2021 11:19:37 GMT, Jorn Vernee wrote: > Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/76 From jlahoda at openjdk.java.net Wed Jun 16 18:40:30 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 16 Jun 2021 18:40:30 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: On Wed, 16 Jun 2021 15:15:25 GMT, Jan Lahoda wrote: > Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding. > > How does this look? I was thinking of having a new bootstrap method for enums, but then (in a discussion with Maurizio), it turned out it might be better to reuse `typeSwitch` for consistency and orthogonality. The usecase is not really much different from e.g. pattern switches over Strings (or Integers). One can write something like: String sel = ""; switch (sel) { case "a" -> {} case String s && s.length() < 5 -> {} case "toolong" -> {} case String s -> {} } And javac will use `typeSwitch` for that (and I think it is more or less necessary to mix constants and patterns in the static arguments of the bootstrap method, as the switch may mix constants and patterns with guards in any order). We can do something similar with enums: E sel = null; switch (sel) { case A -> {} case E e && "B".equals(e.name()) -> {} case C -> {} case E e -> {} } Does not seem much different, the only change is that the constants are enum constants, not String constants (which brings some challenges - like the possibility that the enum constant cannot be resolved). But I can create a separate bootstrap method, if strongly preferred. ------------- PR: https://git.openjdk.java.net/jdk17/pull/81 From alexey.semenyuk at oracle.com Wed Jun 16 20:12:44 2021 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 16 Jun 2021 16:12:44 -0400 Subject: jpackage issue with --dest In-Reply-To: <12421ff3-be38-b232-6fe2-5b36b35dacfb@oracle.com> References: <12421ff3-be38-b232-6fe2-5b36b35dacfb@oracle.com> Message-ID: Hi Maurizio, Thank you for the provided output. According to the log, app launcher loaded libjli.so and it failed in JLI_Launch() function. Probably the problem is that you use jpackage from the build that has https://bugs.openjdk.java.net/browse/JDK-8263157 fix that resulted in a number of regressions fixed with https://bugs.openjdk.java.net/browse/JDK-8267598 patch. Chances are your local build doesn't contain a patch for JDK-8267598. The latest jdk17 build at https://jdk.java.net/17/ contains patch for JDK-8267598. Can you try it? - Alexey On 6/16/2021 1:52 PM, Maurizio Cimadamore wrote: > This is what I get when I run jpackage: > > ``` > $ jpackage --type app-image --name HelloWorld --input > /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar > --main-jar jpackage-test.jar --dest bin > [18:50:09.375] > jpackage argument list: > [--type, app-image, --name, HelloWorld, --input, > /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar, > --main-jar, jpackage-test.jar, --dest, bin] > > [18:50:09.409] Running dpkg > [18:50:09.420] Command [PID: 399487]: > ??? dpkg --print-architecture > [18:50:09.420] Output: > ??? amd64 > [18:50:09.422] Returned: 0 > > [18:50:09.431] Creating app package: HelloWorld in /tmp/bin > [18:50:13.288] Command [PID: -1]: > ??? jlink --output bin/HelloWorld/lib/runtime --module-path > /w/lt/jdk/dev/build/linux-x86_64-server-release/images/jdk/jmods > --add-modules > jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.sctp,jdk.jsobject,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.logging,java.transaction.xa,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata > --strip-native-commands --strip-debug --no-man-pages --no-header-files > [18:50:13.288] Output: > ??? WARNING: Using incubator modules: jdk.incubator.foreign, > jdk.incubator.vector > > [18:50:13.288] Returned: 0 > > [18:50:13.292] Using default package resource JavaApp.png [icon] (add > HelloWorld.png to the resource-dir to customize). > [18:50:13.302] Succeeded in building Linux Application Image package > ``` > > And this is what happens when I run the generated binary: > > ``` > $ bin/HelloWorld/bin/HelloWorld > popen: (rpm --queryformat '%{NAME}' -qf > '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) > popen: exit: 32512 > popen: (dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) > popen: exit: 256 > [TRACE] app.cpp:123: Entering launch > [TRACE] Executor.cpp:41: Reading output of [rpm --queryformat > '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command > [TRACE] Executor.cpp:41: Reading output of [dpkg -S > '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command > [TRACE] LinuxLauncherLib.cpp:121: Set _JPACKAGE_LAUNCHER=[0] > [TRACE] AppLauncher.cpp:99: Launcher config file path: > "/tmp/bin/HelloWorld/lib/app/HelloWorld.cfg" > [TRACE] JvmLauncher.cpp:43: Jvm(0x55a49cb86750)::Jvm() > [TRACE] AppLauncher.cpp:71: Property "app.runtime" not found in > "Application" section of launcher config file. Using Java runtime from > "/tmp/bin/HelloWorld/lib/runtime" directory > [TRACE] app.cpp:0: Exiting launch (entered at app.cpp:123) > [TRACE] JvmLauncher.cpp:48: Jvm(0x55a49cb86750)::~Jvm() > [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer > [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer > [TRACE] JvmLauncher.cpp:269: Initialized 310 bytes at 0x55a49cb86cc0 > address > [TRACE] LinuxLauncherLib.cpp:157: unload > jli lib: [/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so] > jli arg[0]: [/tmp/bin/HelloWorld/bin/HelloWorld] > jli arg[1]: [-classpath] > jli arg[2]: [/tmp/bin/HelloWorld/lib/app/jpackage-test.jar] > jli arg[3]: [-Djpackage.app-version=1.0] > jli arg[4]: [-Djpackage.app-path=/tmp/bin/HelloWorld/bin/HelloWorld] > jli arg[5]: [main.Main] > Error: could not find libjava.so > Error: Could not find Java SE Runtime Environment. > ``` > > Does that clarify things? > > Thanks > Maurizio > > > On 16/06/2021 18:28, Alexey Semenyuk wrote: >> Hi Maurizio, >> >> This is not known issue. >> Can you run the app with "JPACKAGE_DEBUG" env variable set to "true". >> In this case the app launcher will produce debug output that will >> help to understand why it can't find libjava.so. >> >> - Alexey >> >> On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote: >>> Hi, >>> I'm relatively new to jpackage and I found a weird issue on linux >>> where the name of a --dest folder can affect the correct behavior of >>> the generated application image. >>> >>> I have put together an hello world application, with a jarfile. If I >>> jpackage it with the following command line: >>> >>> ``` >>> $ jpackage --type app-image --name HelloWorld --input >>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest >>> output >>> ``` >>> >>> Everything works correctly, and launching the generated app prints >>> "Hello world": >>> >>> ``` >>> $ output/HelloWorld/bin/HelloWorld >>> Hello world! >>> ``` >>> >>> However, if the destination directory contains "bin" (even as a >>> nested subfolder), there are issues. Here's the jextract command line: >>> >>> ``` >>> $ jpackage --type app-image --name HelloWorld --input >>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest bin >>> ``` >>> >>> (the only thihng that changed is the --dest parameter) >>> >>> And here's what I get: >>> >>> ``` >>> $ bin/HelloWorld/bin/HelloWorld >>> Error: could not find libjava.so >>> Error: Could not find Java SE Runtime Environment. >>> ``` >>> >>> I use Ubuntu 20.04. A colleague of mine using MacOS does not seem to >>> have the same issue, so it seems to be system specific. >>> >>> I'm using the latest jpackage from jdk/jdk. >>> >>> Is this a known issue? >>> >>> Cheers >>> Maurizio >>> >> From rriggs at openjdk.java.net Wed Jun 16 20:34:30 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Jun 2021 20:34:30 GMT Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific Deserialization Filters Message-ID: Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property. Fix description in the example of a filter allowing platform classes. Suppress some warnings about use of SecurityManager in tests. ------------- Commit messages: - JDK-8268827: Cleanup Implement Context-Specific Deserialization Filters Changes: https://git.openjdk.java.net/jdk17/pull/85/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268826 Stats: 29 lines in 4 files changed: 10 ins; 13 del; 6 mod Patch: https://git.openjdk.java.net/jdk17/pull/85.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85 PR: https://git.openjdk.java.net/jdk17/pull/85 From sviswanathan at openjdk.java.net Wed Jun 16 20:57:27 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 16 Jun 2021 20:57:27 GMT Subject: [jdk17] RFR: 8266518: Refactor and expand scatter/gather tests In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 16:26:17 GMT, Paul Sandoz wrote: > Refactor scatter/gather tests to be included in the load/store test classes and expand to support access between `ShortVector` and and `char[]`, and access between `ByteVector` and `boolean[]`. > > Vector tests pass on linux-x64 linux-aarch64 macosx-x64, and windows-x64. Thanks for refactoring and adding new scatter/gather tests for boolean and char. Other than the duplicate data provider in byte/boolean tests, the rest looks good to me. test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java line 1248: > 1246: toArray(Object[][]::new); > 1247: } > 1248: The byteGatherScatterProvider and byteGatherScatterMaskProvider seem to be same as gatherScatterProvider and gatherScatterMaskProvider above. ------------- Marked as reviewed by sviswanathan (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/48 From maurizio.cimadamore at oracle.com Wed Jun 16 21:11:11 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 22:11:11 +0100 Subject: jpackage issue with --dest In-Reply-To: References: <12421ff3-be38-b232-6fe2-5b36b35dacfb@oracle.com> Message-ID: Hi, I've built my JDK this morning. I checked now with `git log` and I do have: https://bugs.openjdk.java.net/browse/JDK-8267598 Maurizio On 16/06/2021 21:12, Alexey Semenyuk wrote: > Hi Maurizio, > > Thank you for the provided output. > According to the log, app launcher loaded libjli.so and it failed in > JLI_Launch() function. > Probably the problem is that you use jpackage from the build that has > https://bugs.openjdk.java.net/browse/JDK-8263157 fix that resulted in > a number of regressions fixed with > https://bugs.openjdk.java.net/browse/JDK-8267598 patch. > Chances are your local build doesn't contain a patch for JDK-8267598. > The latest jdk17 build at https://jdk.java.net/17/ contains patch for > JDK-8267598. Can you try it? > > - Alexey > > On 6/16/2021 1:52 PM, Maurizio Cimadamore wrote: >> This is what I get when I run jpackage: >> >> ``` >> $ jpackage --type app-image --name HelloWorld --input >> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar >> --main-jar jpackage-test.jar --dest bin >> [18:50:09.375] >> jpackage argument list: >> [--type, app-image, --name, HelloWorld, --input, >> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar, >> --main-jar, jpackage-test.jar, --dest, bin] >> >> [18:50:09.409] Running dpkg >> [18:50:09.420] Command [PID: 399487]: >> ??? dpkg --print-architecture >> [18:50:09.420] Output: >> ??? amd64 >> [18:50:09.422] Returned: 0 >> >> [18:50:09.431] Creating app package: HelloWorld in /tmp/bin >> [18:50:13.288] Command [PID: -1]: >> ??? jlink --output bin/HelloWorld/lib/runtime --module-path >> /w/lt/jdk/dev/build/linux-x86_64-server-release/images/jdk/jmods >> --add-modules >> jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.sctp,jdk.jsobject,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.logging,java.transaction.xa,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata >> --strip-native-commands --strip-debug --no-man-pages --no-header-files >> [18:50:13.288] Output: >> ??? WARNING: Using incubator modules: jdk.incubator.foreign, >> jdk.incubator.vector >> >> [18:50:13.288] Returned: 0 >> >> [18:50:13.292] Using default package resource JavaApp.png [icon] (add >> HelloWorld.png to the resource-dir to customize). >> [18:50:13.302] Succeeded in building Linux Application Image package >> ``` >> >> And this is what happens when I run the generated binary: >> >> ``` >> $ bin/HelloWorld/bin/HelloWorld >> popen: (rpm --queryformat '%{NAME}' -qf >> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >> popen: exit: 32512 >> popen: (dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >> popen: exit: 256 >> [TRACE] app.cpp:123: Entering launch >> [TRACE] Executor.cpp:41: Reading output of [rpm --queryformat >> '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command >> [TRACE] Executor.cpp:41: Reading output of [dpkg -S >> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command >> [TRACE] LinuxLauncherLib.cpp:121: Set _JPACKAGE_LAUNCHER=[0] >> [TRACE] AppLauncher.cpp:99: Launcher config file path: >> "/tmp/bin/HelloWorld/lib/app/HelloWorld.cfg" >> [TRACE] JvmLauncher.cpp:43: Jvm(0x55a49cb86750)::Jvm() >> [TRACE] AppLauncher.cpp:71: Property "app.runtime" not found in >> "Application" section of launcher config file. Using Java runtime >> from "/tmp/bin/HelloWorld/lib/runtime" directory >> [TRACE] app.cpp:0: Exiting launch (entered at app.cpp:123) >> [TRACE] JvmLauncher.cpp:48: Jvm(0x55a49cb86750)::~Jvm() >> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer >> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer >> [TRACE] JvmLauncher.cpp:269: Initialized 310 bytes at 0x55a49cb86cc0 >> address >> [TRACE] LinuxLauncherLib.cpp:157: unload >> jli lib: [/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so] >> jli arg[0]: [/tmp/bin/HelloWorld/bin/HelloWorld] >> jli arg[1]: [-classpath] >> jli arg[2]: [/tmp/bin/HelloWorld/lib/app/jpackage-test.jar] >> jli arg[3]: [-Djpackage.app-version=1.0] >> jli arg[4]: [-Djpackage.app-path=/tmp/bin/HelloWorld/bin/HelloWorld] >> jli arg[5]: [main.Main] >> Error: could not find libjava.so >> Error: Could not find Java SE Runtime Environment. >> ``` >> >> Does that clarify things? >> >> Thanks >> Maurizio >> >> >> On 16/06/2021 18:28, Alexey Semenyuk wrote: >>> Hi Maurizio, >>> >>> This is not known issue. >>> Can you run the app with "JPACKAGE_DEBUG" env variable set to >>> "true". In this case the app launcher will produce debug output that >>> will help to understand why it can't find libjava.so. >>> >>> - Alexey >>> >>> On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote: >>>> Hi, >>>> I'm relatively new to jpackage and I found a weird issue on linux >>>> where the name of a --dest folder can affect the correct behavior >>>> of the generated application image. >>>> >>>> I have put together an hello world application, with a jarfile. If >>>> I jpackage it with the following command line: >>>> >>>> ``` >>>> $ jpackage --type app-image --name HelloWorld --input >>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest >>>> output >>>> ``` >>>> >>>> Everything works correctly, and launching the generated app prints >>>> "Hello world": >>>> >>>> ``` >>>> $ output/HelloWorld/bin/HelloWorld >>>> Hello world! >>>> ``` >>>> >>>> However, if the destination directory contains "bin" (even as a >>>> nested subfolder), there are issues. Here's the jextract command line: >>>> >>>> ``` >>>> $ jpackage --type app-image --name HelloWorld --input >>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar --dest >>>> bin >>>> ``` >>>> >>>> (the only thihng that changed is the --dest parameter) >>>> >>>> And here's what I get: >>>> >>>> ``` >>>> $ bin/HelloWorld/bin/HelloWorld >>>> Error: could not find libjava.so >>>> Error: Could not find Java SE Runtime Environment. >>>> ``` >>>> >>>> I use Ubuntu 20.04. A colleague of mine using MacOS does not seem >>>> to have the same issue, so it seems to be system specific. >>>> >>>> I'm using the latest jpackage from jdk/jdk. >>>> >>>> Is this a known issue? >>>> >>>> Cheers >>>> Maurizio >>>> >>> > From maurizio.cimadamore at oracle.com Wed Jun 16 21:14:08 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Jun 2021 22:14:08 +0100 Subject: jpackage issue with --dest In-Reply-To: References: <12421ff3-be38-b232-6fe2-5b36b35dacfb@oracle.com> Message-ID: <4c630ec1-57f4-cf8a-6b4f-9bd0b0818d1a@oracle.com> Also, if --dest is removed, or if it is set to something which doesn't contain the "bin" subfolder, everything works... that seems different from the issue you linked? Maurizio On 16/06/2021 22:11, Maurizio Cimadamore wrote: > Hi, > I've built my JDK this morning. I checked now with `git log` and I do > have: > > https://bugs.openjdk.java.net/browse/JDK-8267598 > > Maurizio > > On 16/06/2021 21:12, Alexey Semenyuk wrote: >> Hi Maurizio, >> >> Thank you for the provided output. >> According to the log, app launcher loaded libjli.so and it failed in >> JLI_Launch() function. >> Probably the problem is that you use jpackage from the build that has >> https://bugs.openjdk.java.net/browse/JDK-8263157 fix that resulted in >> a number of regressions fixed with >> https://bugs.openjdk.java.net/browse/JDK-8267598 patch. >> Chances are your local build doesn't contain a patch for JDK-8267598. >> The latest jdk17 build at https://jdk.java.net/17/ contains patch for >> JDK-8267598. Can you try it? >> >> - Alexey >> >> On 6/16/2021 1:52 PM, Maurizio Cimadamore wrote: >>> This is what I get when I run jpackage: >>> >>> ``` >>> $ jpackage --type app-image --name HelloWorld --input >>> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar >>> --main-jar jpackage-test.jar --dest bin >>> [18:50:09.375] >>> jpackage argument list: >>> [--type, app-image, --name, HelloWorld, --input, >>> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar, >>> --main-jar, jpackage-test.jar, --dest, bin] >>> >>> [18:50:09.409] Running dpkg >>> [18:50:09.420] Command [PID: 399487]: >>> ??? dpkg --print-architecture >>> [18:50:09.420] Output: >>> ??? amd64 >>> [18:50:09.422] Returned: 0 >>> >>> [18:50:09.431] Creating app package: HelloWorld in /tmp/bin >>> [18:50:13.288] Command [PID: -1]: >>> ??? jlink --output bin/HelloWorld/lib/runtime --module-path >>> /w/lt/jdk/dev/build/linux-x86_64-server-release/images/jdk/jmods >>> --add-modules >>> jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.sctp,jdk.jsobject,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.logging,java.transaction.xa,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata >>> --strip-native-commands --strip-debug --no-man-pages --no-header-files >>> [18:50:13.288] Output: >>> ??? WARNING: Using incubator modules: jdk.incubator.foreign, >>> jdk.incubator.vector >>> >>> [18:50:13.288] Returned: 0 >>> >>> [18:50:13.292] Using default package resource JavaApp.png [icon] >>> (add HelloWorld.png to the resource-dir to customize). >>> [18:50:13.302] Succeeded in building Linux Application Image package >>> ``` >>> >>> And this is what happens when I run the generated binary: >>> >>> ``` >>> $ bin/HelloWorld/bin/HelloWorld >>> popen: (rpm --queryformat '%{NAME}' -qf >>> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >>> popen: exit: 32512 >>> popen: (dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >>> popen: exit: 256 >>> [TRACE] app.cpp:123: Entering launch >>> [TRACE] Executor.cpp:41: Reading output of [rpm --queryformat >>> '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command >>> [TRACE] Executor.cpp:41: Reading output of [dpkg -S >>> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command >>> [TRACE] LinuxLauncherLib.cpp:121: Set _JPACKAGE_LAUNCHER=[0] >>> [TRACE] AppLauncher.cpp:99: Launcher config file path: >>> "/tmp/bin/HelloWorld/lib/app/HelloWorld.cfg" >>> [TRACE] JvmLauncher.cpp:43: Jvm(0x55a49cb86750)::Jvm() >>> [TRACE] AppLauncher.cpp:71: Property "app.runtime" not found in >>> "Application" section of launcher config file. Using Java runtime >>> from "/tmp/bin/HelloWorld/lib/runtime" directory >>> [TRACE] app.cpp:0: Exiting launch (entered at app.cpp:123) >>> [TRACE] JvmLauncher.cpp:48: Jvm(0x55a49cb86750)::~Jvm() >>> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer >>> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData buffer >>> [TRACE] JvmLauncher.cpp:269: Initialized 310 bytes at 0x55a49cb86cc0 >>> address >>> [TRACE] LinuxLauncherLib.cpp:157: unload >>> jli lib: [/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so] >>> jli arg[0]: [/tmp/bin/HelloWorld/bin/HelloWorld] >>> jli arg[1]: [-classpath] >>> jli arg[2]: [/tmp/bin/HelloWorld/lib/app/jpackage-test.jar] >>> jli arg[3]: [-Djpackage.app-version=1.0] >>> jli arg[4]: [-Djpackage.app-path=/tmp/bin/HelloWorld/bin/HelloWorld] >>> jli arg[5]: [main.Main] >>> Error: could not find libjava.so >>> Error: Could not find Java SE Runtime Environment. >>> ``` >>> >>> Does that clarify things? >>> >>> Thanks >>> Maurizio >>> >>> >>> On 16/06/2021 18:28, Alexey Semenyuk wrote: >>>> Hi Maurizio, >>>> >>>> This is not known issue. >>>> Can you run the app with "JPACKAGE_DEBUG" env variable set to >>>> "true". In this case the app launcher will produce debug output >>>> that will help to understand why it can't find libjava.so. >>>> >>>> - Alexey >>>> >>>> On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> I'm relatively new to jpackage and I found a weird issue on linux >>>>> where the name of a --dest folder can affect the correct behavior >>>>> of the generated application image. >>>>> >>>>> I have put together an hello world application, with a jarfile. If >>>>> I jpackage it with the following command line: >>>>> >>>>> ``` >>>>> $ jpackage --type app-image --name HelloWorld --input >>>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar >>>>> --dest output >>>>> ``` >>>>> >>>>> Everything works correctly, and launching the generated app prints >>>>> "Hello world": >>>>> >>>>> ``` >>>>> $ output/HelloWorld/bin/HelloWorld >>>>> Hello world! >>>>> ``` >>>>> >>>>> However, if the destination directory contains "bin" (even as a >>>>> nested subfolder), there are issues. Here's the jextract command >>>>> line: >>>>> >>>>> ``` >>>>> $ jpackage --type app-image --name HelloWorld --input >>>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar >>>>> --dest bin >>>>> ``` >>>>> >>>>> (the only thihng that changed is the --dest parameter) >>>>> >>>>> And here's what I get: >>>>> >>>>> ``` >>>>> $ bin/HelloWorld/bin/HelloWorld >>>>> Error: could not find libjava.so >>>>> Error: Could not find Java SE Runtime Environment. >>>>> ``` >>>>> >>>>> I use Ubuntu 20.04. A colleague of mine using MacOS does not seem >>>>> to have the same issue, so it seems to be system specific. >>>>> >>>>> I'm using the latest jpackage from jdk/jdk. >>>>> >>>>> Is this a known issue? >>>>> >>>>> Cheers >>>>> Maurizio >>>>> >>>> >> From jvernee at openjdk.java.net Wed Jun 16 22:23:45 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 16 Jun 2021 22:23:45 GMT Subject: [jdk17] RFR: 8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken [v2] In-Reply-To: <4KuMCXKzbvdVI0v5C7zyx4NX216Wk_7G73lzrIhsZsU=.601fe18b-500f-413a-9a2e-067d08338b27@github.com> References: <4KuMCXKzbvdVI0v5C7zyx4NX216Wk_7G73lzrIhsZsU=.601fe18b-500f-413a-9a2e-067d08338b27@github.com> Message-ID: > Upstream fix for 8268230 to mainline JDK. > > Prior review thread can be found here: https://github.com/openjdk/panama-foreign/pull/554 > > Testing: jdk_foreign test suite on Windows and Linux (WSL). Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Exclude test on unsupported platforms This test indirectly initializes CABI, which fails on Linux x86 ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/77/files - new: https://git.openjdk.java.net/jdk17/pull/77/files/08a8b081..20565c87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=77&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=77&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/77/head:pull/77 PR: https://git.openjdk.java.net/jdk17/pull/77 From jiefu at openjdk.java.net Wed Jun 16 23:08:13 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 16 Jun 2021 23:08:13 GMT Subject: [jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image [v2] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 15:29:19 GMT, Paul Sandoz wrote: >> Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. > > Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: > > Require C2. LGTM Thanks for your update. ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/47 From dholmes at openjdk.java.net Thu Jun 17 00:27:22 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Jun 2021 00:27:22 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 11:19:37 GMT, Jorn Vernee wrote: > Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. Hi Jorn, Seems okay but I have one query below. Thanks, David src/hotspot/share/runtime/frame.inline.hpp line 54: > 52: inline bool frame::is_first_frame() const { > 53: return (is_entry_frame() && entry_frame_is_first()) > 54: || (is_optimized_entry_frame() && optimized_entry_frame_is_first()); Given `optimized_entry_frame_is_first` is only defined on a couple of platforms, it is far from obvious that this call can never happen on the other platforms. A comment explaining this would be useful. ------------- PR: https://git.openjdk.java.net/jdk17/pull/76 From dholmes at openjdk.java.net Thu Jun 17 01:54:09 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Jun 2021 01:54:09 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com> On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. I skimmed through all these and the changes seem fine in principal. I have two mild concerns: 1. How does this change the class initialization order on VM startup? 2. Do any tests need adjusting due to potential changes in the exact message used by the IndexOutOfBoundsException? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From yyang at openjdk.java.net Thu Jun 17 03:35:13 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 17 Jun 2021 03:35:13 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> <0Kkr7Ka5KRp5WD0axZwvexYA5cP8Z8rvUyk42Jp8hmA=.cde62503-a9eb-4c1f-b6d4-82e61616e32f@github.com> Message-ID: <4yPb1iqPV0JAYphfov1jMn-bLr8NjA3e3EJDi6_Qg-E=.39756447-7617-4e72-aeaa-e0dd5ad0b64c@github.com> On Thu, 17 Jun 2021 01:51:41 GMT, David Holmes wrote: > I skimmed through all these and the changes seem fine in principal. > I have two mild concerns: > > 1. How does this change the class initialization order on VM startup? > 2. Do any tests need adjusting due to potential changes in the exact message used by the IndexOutOfBoundsException? > > Thanks, > David Hi David, your concerns are reasonable. I think this change would not affect the class initialization order, because regardless of whether the patch is applied or not, `java -Xlog:class+load -version` prints identical class initialization order(for j.l.Objects and jdk.internal.util.Preconditions) as far as I can see. [class_load.log](https://github.com/openjdk/jdk/files/6667168/class_load.log). And tier1 tests are all passed w/o any modifications. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From dholmes at openjdk.java.net Thu Jun 17 05:19:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Jun 2021 05:19:11 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. Class loading order is different to class initialization order. There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From github.com+1059453+fleshgrinder at openjdk.java.net Thu Jun 17 06:16:16 2021 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Thu, 17 Jun 2021 06:16:16 GMT Subject: Withdrawn: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant In-Reply-To: References: Message-ID: <-qseYV9fU0dWUK1YczZpRMAKATilSbXkzZIjmdyQuDw=.b4fb9abe-0143-46c6-a9f2-4436e68078c2@github.com> On Thu, 26 Nov 2020 18:51:10 GMT, Richard Fussenegger wrote: > 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1467 From github.com+1059453+fleshgrinder at openjdk.java.net Thu Jun 17 06:16:19 2021 From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger) Date: Thu, 17 Jun 2021 06:16:19 GMT Subject: Withdrawn: 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput In-Reply-To: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com> References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com> Message-ID: On Thu, 26 Nov 2020 18:24:22 GMT, Richard Fussenegger wrote: > Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set. > > Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1465 From duke at openjdk.java.net Thu Jun 17 07:04:16 2021 From: duke at openjdk.java.net (duke) Date: Thu, 17 Jun 2021 07:04:16 GMT Subject: Withdrawn: 8199594: Add doc describing how (?x) ignores spaces in character classes In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 20:43:26 GMT, Ian Graves wrote: > Clarifying note on comments mode to explicitly note that whitespace within character classes is ignored. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3577 From github.com+10835776+stsypanov at openjdk.java.net Thu Jun 17 08:20:15 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Jun 2021 08:20:15 GMT Subject: RFR: 8268873: Unnecessary Vector usage in java.base In-Reply-To: <-EAGwB2tzRt86ysHiUsCDlvWmd62GIPZfk24c7T5nuM=.e332b6c0-2754-4c60-9e20-a90a311fc1ad@github.com> References: <-EAGwB2tzRt86ysHiUsCDlvWmd62GIPZfk24c7T5nuM=.e332b6c0-2754-4c60-9e20-a90a311fc1ad@github.com> Message-ID: On Wed, 16 Jun 2021 09:49:17 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java line 154: >> >>> 152: while (tokenizer.hasMoreTokens()) >>> 153: v.add(tokenizer.nextToken()); >>> 154: ciphers = new String [v.size()]; >> >> Looks like this whole `else` block can be simplified to `ciphers = cipherString.split(",");` > > It's not a drop-in replacement. Result is different for some Strings. For example for `, A` > I would prefer to preserve existing behavior under this cleanup. Then let's keep it as is ------------- PR: https://git.openjdk.java.net/jdk/pull/4482 From dfuchs at openjdk.java.net Thu Jun 17 08:38:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Jun 2021 08:38:08 GMT Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific Deserialization Filters In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 20:22:17 GMT, Roger Riggs wrote: > Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property. > Fix description in the example of a filter allowing platform classes. > Suppress some warnings about use of SecurityManager in tests. Looks reasonable to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/85 From jboes at openjdk.java.net Thu Jun 17 09:13:12 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Thu, 17 Jun 2021 09:13:12 GMT Subject: [jdk17] Integrated: 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 09:57:29 GMT, Julia Boes wrote: > In the methods in question, `RejectedExecutionException` is an expected exception that was previously unhandled (it is a `RuntimeException`, not a subclass of `ExecutionException`). This change adds `RejectedExecutionException` to the existing catch clause. This pull request has now been integrated. Changeset: 344e3edf Author: Julia Boes URL: https://git.openjdk.java.net/jdk17/commit/344e3edf7602d8b788334bd103e9a63a8d74a6f8 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod 8268080: java/util/concurrent/forkjoin/AsyncShutdownNow.java fails with java.util.concurrent.RejectedExecutionException Co-authored-by: Doug Lea
    Reviewed-by: chegar, dfuchs ------------- PR: https://git.openjdk.java.net/jdk17/pull/74 From alanb at openjdk.java.net Thu Jun 17 10:28:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Jun 2021 10:28:15 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. I looked through the changes in java.base and only spotted one case where a different (and more specific) exception is thrown. The changes to to files in java.util.zip lead to annoying long lines so would be good to fix all those. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 471: > 469: */ > 470: public int offsetByCodePoints(int index, int codePointOffset) { > 471: checkOffset(index, count); String.offsetByCodePoints is specified to throw IOOBE. checkOffset may throw the more specific StringIndexOutOfBoundsException. That's a compatible change but I worry that we might want to throw the less specific exception in the further because code. I only mention is because there have been cases in java.lang where IOOBE was specified and AIOOBE by the implementation and it has been problematic to touch the implementation as a result. src/java.base/share/classes/java/util/Base64.java line 934: > 932: if (closed) > 933: throw new IOException("Stream is closed"); > 934: Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException()); You might to split this really long line to avoid inconsistent line length in this source file. ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From alanb at openjdk.java.net Thu Jun 17 10:50:13 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Jun 2021 10:50:13 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote: > There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception). ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From jvernee at openjdk.java.net Thu Jun 17 11:28:59 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 17 Jun 2021 11:28:59 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 00:23:19 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment about optimized entry frames only being generated on x86_64 > > src/hotspot/share/runtime/frame.inline.hpp line 54: > >> 52: inline bool frame::is_first_frame() const { >> 53: return (is_entry_frame() && entry_frame_is_first()) >> 54: || (is_optimized_entry_frame() && optimized_entry_frame_is_first()); > > Given `optimized_entry_frame_is_first` is only defined on a couple of platforms, it is far from obvious that this call can never happen on the other platforms. A comment explaining this would be useful. Thanks, I've added the following comment: ```C++ inline bool frame::is_first_frame() const { return (is_entry_frame() && entry_frame_is_first()) // optimized_entry_frame_is_first is currently only implemented on x86_64. // This is okay since optimized entry frames are only generated on x86_64 // as well (see ProgrammableUpcallHandler::generate_optimized_upcall_stub // in universalUpcallHandler_x86_64.cpp), so is_optimized_entry_frame will // always return false on platforms where optimized_entry_frame_is_first // is not implemented. || (is_optimized_entry_frame() && optimized_entry_frame_is_first()); } ------------- PR: https://git.openjdk.java.net/jdk17/pull/76 From jvernee at openjdk.java.net Thu Jun 17 11:28:54 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 17 Jun 2021 11:28:54 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2] In-Reply-To: References: Message-ID: > Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Add comment about optimized entry frames only being generated on x86_64 ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/76/files - new: https://git.openjdk.java.net/jdk17/pull/76/files/97fe0555..d2110fa4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=76&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=76&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/76.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/76/head:pull/76 PR: https://git.openjdk.java.net/jdk17/pull/76 From david.holmes at oracle.com Thu Jun 17 12:25:07 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jun 2021 22:25:07 +1000 Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: <59f05d6a-66a7-129c-4897-e45b4dd564ab@oracle.com> On 17/06/2021 8:50 pm, Alan Bateman wrote: > On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote: > >> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing. > > It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception). tiers 1-3 on Linux-x64 passed okay. Any change to the exact type of exception thrown should be affirmed through a CSR request. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/4507 > From david.holmes at oracle.com Thu Jun 17 12:29:09 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jun 2021 22:29:09 +1000 Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2] In-Reply-To: References: Message-ID: <66467767-84b2-0d42-4910-ad95610e4e65@oracle.com> Hi Jorn, On 17/06/2021 9:28 pm, Jorn Vernee wrote: > On Thu, 17 Jun 2021 00:23:19 GMT, David Holmes wrote: > >>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Add comment about optimized entry frames only being generated on x86_64 >> >> src/hotspot/share/runtime/frame.inline.hpp line 54: >> >>> 52: inline bool frame::is_first_frame() const { >>> 53: return (is_entry_frame() && entry_frame_is_first()) >>> 54: || (is_optimized_entry_frame() && optimized_entry_frame_is_first()); >> >> Given `optimized_entry_frame_is_first` is only defined on a couple of platforms, it is far from obvious that this call can never happen on the other platforms. A comment explaining this would be useful. > > Thanks, I've added the following comment: > > ```C++ > inline bool frame::is_first_frame() const { > return (is_entry_frame() && entry_frame_is_first()) > // optimized_entry_frame_is_first is currently only implemented on x86_64. > // This is okay since optimized entry frames are only generated on x86_64 > // as well (see ProgrammableUpcallHandler::generate_optimized_upcall_stub > // in universalUpcallHandler_x86_64.cpp), so is_optimized_entry_frame will > // always return false on platforms where optimized_entry_frame_is_first > // is not implemented. > || (is_optimized_entry_frame() && optimized_entry_frame_is_first()); > } Now that you have explained it I think a much simpler comment will suffice :) return (is_entry_frame() && entry_frame_is_first()) || // Optimized entry frames are only present on certain platforms (is_optimized_entry_frame() && optimized_entry_frame_is_first()); Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk17/pull/76 > From mbaesken at openjdk.java.net Thu Jun 17 12:34:35 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 17 Jun 2021 12:34:35 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups Message-ID: Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding if (!cg_infos[PIDS_IDX]._data_complete) { log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); // keep the other controller info, pids is optional } ------------- Commit messages: - JDK-8266490 Changes: https://git.openjdk.java.net/jdk/pull/4518/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266490 Stats: 203 lines in 16 files changed: 159 ins; 2 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/4518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518 PR: https://git.openjdk.java.net/jdk/pull/4518 From jvernee at openjdk.java.net Thu Jun 17 12:53:45 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 17 Jun 2021 12:53:45 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v3] In-Reply-To: References: Message-ID: > Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Remove whitespace - Simplify comment ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/76/files - new: https://git.openjdk.java.net/jdk17/pull/76/files/d2110fa4..ce4acfd5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=76&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=76&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/76.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/76/head:pull/76 PR: https://git.openjdk.java.net/jdk17/pull/76 From jvernee at openjdk.java.net Thu Jun 17 12:53:49 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 17 Jun 2021 12:53:49 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v3] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 12:50:10 GMT, Jorn Vernee wrote: >> Upstream a critical fix from the panama-foreign repo. >> >> See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 >> >> Testing: tier 1-2, local run of run-test-jdk_foreign. > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Remove whitespace > - Simplify comment src/hotspot/share/runtime/frame.inline.hpp line 54: > 52: inline bool frame::is_first_frame() const { > 53: return (is_entry_frame() && entry_frame_is_first()) > 54: // Optimized entry frames are only present on certain platforms Suggestion: // Optimized entry frames are only present on certain platforms ------------- PR: https://git.openjdk.java.net/jdk17/pull/76 From jvernee at openjdk.java.net Thu Jun 17 12:53:46 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 17 Jun 2021 12:53:46 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails In-Reply-To: <66467767-84b2-0d42-4910-ad95610e4e65@oracle.com> References: <66467767-84b2-0d42-4910-ad95610e4e65@oracle.com> Message-ID: <2k1Yx7J3mSHnupWgANXEIvxCWKdtL6Qy8MzRfQczj5k=.bd0242a0-51d3-4bda-ae21-8d381b73a4c5@github.com> On Thu, 17 Jun 2021 12:30:46 GMT, David Holmes wrote: > Now that you have explained it I think a much simpler comment will suffice :) Ok, I've shortened the comment. Thanks :) ------------- PR: https://git.openjdk.java.net/jdk17/pull/76 From jvernee at openjdk.java.net Thu Jun 17 12:53:55 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 17 Jun 2021 12:53:55 GMT Subject: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2] In-Reply-To: References: Message-ID: <4G3ERV8f0_IAsg6vSR3CBUCFT2uoLKljWd0PqQ77mz0=.a7ac5bbb-868e-484b-803d-fa10a6c6a9d1@github.com> On Thu, 17 Jun 2021 11:28:54 GMT, Jorn Vernee wrote: >> Upstream a critical fix from the panama-foreign repo. >> >> See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558 >> >> Testing: tier 1-2, local run of run-test-jdk_foreign. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about optimized entry frames only being generated on x86_64 src/hotspot/share/runtime/frame.inline.hpp line 59: > 57: // in universalUpcallHandler_x86_64.cpp), so is_optimized_entry_frame will > 58: // always return false on platforms where optimized_entry_frame_is_first > 59: // is not implemented. Suggestion: // Optimized entry frames are only present on certain platforms ------------- PR: https://git.openjdk.java.net/jdk17/pull/76 From dfuchs at openjdk.java.net Thu Jun 17 14:01:04 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Jun 2021 14:01:04 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 10:57:07 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions? >> >> Kind regards, >> Patrick > > Patrick Concannon 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: > > - 8268469: Removed excessive spacing; corrected misplaced comments > - Merge remote-tracking branch 'origin/master' into JDK-8268469 > - Merge remote-tracking branch 'origin/master' into JDK-8268469 > - 8268469: Update java.time to use switch expressions src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2793: > 2791: case NOT_NEGATIVE -> throw new DateTimeException("Field " + field + > 2792: " cannot be printed as the value " + value + > 2793: " cannot be negative according to the SignStyle"); Maybe in this case you could revert the alignment. In this case it would allow lines 2792 to 2793 to be shorter ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From dfuchs at openjdk.java.net Thu Jun 17 14:00:49 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 17 Jun 2021 14:00:49 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 16:43:20 GMT, Stephen Colebourne wrote: >> The vertical alignment improves readability in these short-line cases. Removing the spaces before the arrows will make it a little harder to discern the difference between the cases. > > It is your codebase, not mine, so it is up to you. Aligning things by column is generally frowned on in most style guides because it handles refactoring poorly, resulting in lots of needless change (or people forgetting to realign things - I had to deal with a rogue aligned Javadoc signature today in a PR where exactly that had happened). I also don't see how you write a style guide rule for when these should be aligned and when they should not. > > Anyway, this PR isn't really the right place for this discussion - I'm not blocking the PR on this basis (and I'm not an official Reviewer anyway). I have a slight preference for the aligned version in the cases where the lines are short and the number of spaces used for padding is not unreasonable. I find the code gains in readability in these cases. In the case where the lines are long - I agree with Stephen that the alignment doesn't bring much readability - and sometime it may even be detrimental as it makes long lines longer. Stephen, would that be an acceptable compromise? ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From sgehwolf at openjdk.java.net Thu Jun 17 14:39:31 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 17 Jun 2021 14:39:31 GMT Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 12:27:25 GMT, Matthias Baesken wrote: > Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory" on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional , see the coding > > > if (!cg_infos[PIDS_IDX]._data_complete) { > log_debug(os, container)("Optional cgroup v1 pids subsystem not found"); > // keep the other controller info, pids is optional > } Thanks for this work. How did you test this? Did you run container tests on a cgroups v1 and cgroups v2 system? src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 136: > 134: char *p; > 135: bool is_cgroupsV2; > 136: // true iff all required controllers, memory, cpu, cpuset, cpuacct enabled *are* enabled, please. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 193: > 191: all_required_controllers_enabled = true; > 192: for (int i = 0; i < CG_INFO_LENGTH; i++) { > 193: // the pids controller is not there on older Linux distros Suggestion: Change the code comment to `// pids controller is optional. All other controllers are required` src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 198: > 196: all_required_controllers_enabled = all_required_controllers_enabled && cg_infos[i]._enabled; > 197: } > 198: if (! cg_infos[i]._enabled) { This if is only present for debug logging and should be guarded to that effect. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 424: > 422: return false; > 423: } > 424: if (!cg_infos[PIDS_IDX]._data_complete) { Same here, this if should be guarded with debug logging being enabled. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 252: > 250: * maximum number of tasks > 251: * -1 for no setup > 252: * -3 for "max" (special value) I'd suggest to use: -1 if unlimited OSCONTAINER_ERROR for not supported src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 261: > 259: "Maximum number of tasks is: " JLONG_FORMAT, JLONG_FORMAT, pidsmax); > 260: if (pidsmax < 0) { > 261: // check for potential special value It would be clearer if this comment mentioned that the value might be `max` and, thus, wouldn't be parseable with `GET_CONTAINER_INFO`. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 266: > 264: err2 = subsystem_file_line_contents(_pids, "/pids.max", NULL, "%1023s", myline); > 265: if (err2 != 0) { > 266: if (strncmp(myline, "max", 3) == 0) return -3; We use `-1` for "unlimited" elsewhere and should probably do the same here. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 266: > 264: err2 = subsystem_file_line_contents(_pids, "/pids.max", NULL, "%1023s", myline); > 265: if (err2 != 0) { > 266: if (strncmp(myline, "max", 3) == 0) return -3; This looks like it should use `GET_CONTAINER_INFO_CPTR` macro and then `limit_from_str` from cgroups v2 code. Perhaps move `limit_from_str` method to the base class. src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 260: > 258: } > 259: } > 260: return pidsmax; We have this pattern of needing to handle `max` elsewhere in cgroups v2 code. See for example: `CgroupV2Subsystem::cpu_quota()`. We should handle it similarly here. src/hotspot/os/linux/os_linux.cpp line 2319: > 2317: st->print_cr("max"); > 2318: } else { > 2319: st->print_cr("%s", j == OSCONTAINER_ERROR ? "not supported" : "unlimited"); We should treat the unlimited case similar to how we handle them elsewhere. I'm not sure this magic constant of `-3` gives us any more info that we'd get with `-1` that we use elsewhere. src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 415: > 413: ****************************************************************/ > 414: public long getPidsMax() { > 415: return CgroupV1SubsystemController.longValOrUnlimited(getLongValue(pids, "pids.max")); Since this value may be `max` we should use the same logic than for v2. I.e.: String pidsMaxStr = CgroupSubsystemController.getStringValue(pids, "pids.max"); return CgroupSubsystemController.limitFromString(pidsMaxStr); test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java line 172: > 170: "net_prio 5 1 1\n" + > 171: "hugetlb 6 1 1\n" + > 172: "pids 9 80 1"; // the 3 did not match 9 This comment leaves the reader none the wiser. I think you are alluding to controller id matching between `/proc/cgroups` and `/proc/self/cgroup`. If so, please use that info. ------------- Changes requested by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4518 From psandoz at openjdk.java.net Thu Jun 17 14:58:37 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 17 Jun 2021 14:58:37 GMT Subject: [jdk17] Integrated: 8268353: Test libsvml.so is and is not present in jdk image In-Reply-To: References: Message-ID: <6k4yu7pnj3kiZ_MISPhvFHSQxZ-6BaQbXy5UiC9_Ugs=.948a238b-8773-42d4-9940-0fdb14cdec03@github.com> On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz wrote: > Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. This pull request has now been integrated. Changeset: 091bc4a1 Author: Paul Sandoz URL: https://git.openjdk.java.net/jdk17/commit/091bc4a1a6ca687aab0c9064f11408b93511a520 Stats: 100 lines in 2 files changed: 97 ins; 0 del; 3 mod 8268353: Test libsvml.so is and is not present in jdk image Reviewed-by: sviswanathan, jiefu ------------- PR: https://git.openjdk.java.net/jdk17/pull/47 From psandoz at openjdk.java.net Thu Jun 17 15:09:20 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 17 Jun 2021 15:09:20 GMT Subject: [jdk17] RFR: 8266518: Refactor and expand scatter/gather tests [v2] In-Reply-To: References: Message-ID: On Wed, 16 Jun 2021 20:42:56 GMT, Sandhya Viswanathan wrote: >> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundatem data providers. > > test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java line 1248: > >> 1246: toArray(Object[][]::new); >> 1247: } >> 1248: > > The byteGatherScatterProvider and byteGatherScatterMaskProvider seem to be same as gatherScatterProvider and gatherScatterMaskProvider above. Well spotted. I removed the data providers. ------------- PR: https://git.openjdk.java.net/jdk17/pull/48 From psandoz at openjdk.java.net Thu Jun 17 15:09:17 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 17 Jun 2021 15:09:17 GMT Subject: [jdk17] RFR: 8266518: Refactor and expand scatter/gather tests [v2] In-Reply-To: References: Message-ID: > Refactor scatter/gather tests to be included in the load/store test classes and expand to support access between `ShortVector` and and `char[]`, and access between `ByteVector` and `boolean[]`. > > Vector tests pass on linux-x64 linux-aarch64 macosx-x64, and windows-x64. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Remove redundatem data providers. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/48/files - new: https://git.openjdk.java.net/jdk17/pull/48/files/6455ae43..2dbb5dee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=48&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=48&range=00-01 Stats: 144 lines in 6 files changed: 0 ins; 120 del; 24 mod Patch: https://git.openjdk.java.net/jdk17/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/48/head:pull/48 PR: https://git.openjdk.java.net/jdk17/pull/48 From psandoz at openjdk.java.net Thu Jun 17 15:48:32 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 17 Jun 2021 15:48:32 GMT Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible In-Reply-To: References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com> Message-ID: <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com> On Thu, 17 Jun 2021 10:21:35 GMT, Alan Bateman wrote: >> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase. > > src/java.base/share/classes/java/util/Base64.java line 934: > >> 932: if (closed) >> 933: throw new IOException("Stream is closed"); >> 934: Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException()); > > You might want to split this really long line too, to avoid inconsistent line length in this source file. I would suggest factoring out `(xa, xb) -> new ArrayIndexOutOfBoundsException()` as a reusable component on `Preconditions`, and maybe even supplying an exception message (since it is rather useful, and way better than no message). See the usages of `Preconditions.outOfBoundsExceptionFormatter` (where there just happens to be many repeated cases of supplying AIOOBE with a message, that could also be consolidated, separate fix perhaps). ------------- PR: https://git.openjdk.java.net/jdk/pull/4507 From joehw at openjdk.java.net Thu Jun 17 16:20:45 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 17 Jun 2021 16:20:45 GMT Subject: [jdk17] RFR: 8265073: XML transformation and indentation when using xml:space Message-ID: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it. ------------- Commit messages: - 8265073: XML transformation and indentation when using xml:space Changes: https://git.openjdk.java.net/jdk17/pull/89/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=89&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265073 Stats: 59 lines in 2 files changed: 51 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/89/head:pull/89 PR: https://git.openjdk.java.net/jdk17/pull/89 From scolebourne at openjdk.java.net Thu Jun 17 16:31:34 2021 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Thu, 17 Jun 2021 16:31:34 GMT Subject: RFR: 8268469: Update java.time to use switch expressions [v3] In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 13:56:00 GMT, Daniel Fuchs wrote: >> It is your codebase, not mine, so it is up to you. Aligning things by column is generally frowned on in most style guides because it handles refactoring poorly, resulting in lots of needless change (or people forgetting to realign things - I had to deal with a rogue aligned Javadoc signature today in a PR where exactly that had happened). I also don't see how you write a style guide rule for when these should be aligned and when they should not. >> >> Anyway, this PR isn't really the right place for this discussion - I'm not blocking the PR on this basis (and I'm not an official Reviewer anyway). > > I have a slight preference for the aligned version in the cases where the lines are short and the number of spaces used for padding is not unreasonable. I find the code gains in readability in these cases. In the case where the lines are long - I agree with Stephen that the alignment doesn't bring much readability - and sometime it may even be detrimental as it makes long lines longer. Stephen, would that be an acceptable compromise? Its certainly a reasonable position to take (ie. if thats what OpenJDK wants to do, its fine by me). I'm more interested to see how you would write such a thing down in the coding standards that doesn't make the standard worthless. ------------- PR: https://git.openjdk.java.net/jdk/pull/4433 From dcubed at openjdk.java.net Thu Jun 17 16:43:40 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 17 Jun 2021 16:43:40 GMT Subject: [jdk17] RFR: 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64 Message-ID: A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64. ------------- Commit messages: - 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64 Changes: https://git.openjdk.java.net/jdk17/pull/90/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=90&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268971 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/90/head:pull/90 PR: https://git.openjdk.java.net/jdk17/pull/90 From dcubed at openjdk.java.net Thu Jun 17 16:56:27 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 17 Jun 2021 16:56:27 GMT Subject: [jdk17] RFR: 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64 In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 16:49:49 GMT, Andy Herrick wrote: >> A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64. > > Marked as reviewed by herrick (Reviewer). @andyherrick - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk17/pull/90 From herrick at openjdk.java.net Thu Jun 17 16:56:26 2021 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 17 Jun 2021 16:56:26 GMT Subject: [jdk17] RFR: 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64 In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 16:32:52 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64. Marked as reviewed by herrick (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/90 From dcubed at openjdk.java.net Thu Jun 17 16:56:27 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 17 Jun 2021 16:56:27 GMT Subject: [jdk17] Integrated: 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64 In-Reply-To: References: Message-ID: On Thu, 17 Jun 2021 16:32:52 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64. This pull request has now been integrated. Changeset: b66001a5 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk17/commit/b66001a5946252b621bab27d6ee32006a4d7bab5 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64 Reviewed-by: herrick ------------- PR: https://git.openjdk.java.net/jdk17/pull/90 From github.com+1701815+mkarg at openjdk.java.net Thu Jun 17 17:02:59 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 17 Jun 2021 17:02:59 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: References: Message-ID: <8Oflif9jz-Vib2Fxcj-QES7T-AIUZ1PleMTgio9j-z4=.486b0ceb-b556-4e62-9e0d-ffa75bb99a14@github.com> On Sun, 30 May 2021 17:30:56 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? @AlanBateman I'm done with the changes you requested and kindly like to ask where to go from here. Great ideas, will do as you say, stay tuned! Didn't know that using `var` is a no-go, sorry for that. Pattern matching is definitively a great idea! Replaced `var` by actual type in https://github.com/openjdk/jdk/pull/4263/commits/b3c62b0951124550a686386b9419f7246c214dc6. Replaced casting by pattern matching for `instanceof` in https://github.com/openjdk/jdk/pull/4263/commits/ac62cdb9acffc133bfaaa97ee77d5c7b3b704994. There had been no more comments since one week. How to proceed? As there had been no more change requests within one week, I assume this means you all rate this PR as read-to-review, so hereby I change its state and explicitly invite everybody to review this proposal. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Thu Jun 17 17:02:59 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 17 Jun 2021 17:02:59 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo Message-ID: 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? ------------- Commit messages: - Draft: Correctly positioning channel in case of exception - Draft: Corrected try-catch block - Draft: Moving I/O ops into the for statement block - Draft: Replaced custom bounds check by Objects.checkFromIndexSize() - Draft: Replaced casting by pattern matching for instanceof - Draft: Replacing var by actual type - Draft: Hiding ChannelOutputStream from the API - Draft: Removing final everywhere but kept only for constants - Draft: Using Thread-Local Buffer Cache - Draft: Increased DEFAULT_BUFFER_SIZE - ... and 1 more: https://git.openjdk.java.net/jdk/compare/66274320...ed49098a Changes: https://git.openjdk.java.net/jdk/pull/4263/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265891 Stats: 286 lines in 4 files changed: 205 ins; 76 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/4263.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263 PR: https://git.openjdk.java.net/jdk/pull/4263 From alanb at openjdk.java.net Thu Jun 17 17:03:00 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Jun 2021 17:03:00 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: <8Oflif9jz-Vib2Fxcj-QES7T-AIUZ1PleMTgio9j-z4=.486b0ceb-b556-4e62-9e0d-ffa75bb99a14@github.com> References: <8Oflif9jz-Vib2Fxcj-QES7T-AIUZ1PleMTgio9j-z4=.486b0ceb-b556-4e62-9e0d-ffa75bb99a14@github.com> Message-ID: On Sat, 5 Jun 2021 15:11:55 GMT, Markus KARG wrote: > @AlanBateman I'm done with the changes you requested and kindly like to ask where to go from here. Moving ChannelOutputStream to sun.nio.ch looks right. The implementation of transferTo will need a few rounds of cleanup, it's a look very messy right now. Most usages of var need to be replaced as it is impossible for the reader to know what the types are. Pattern matching for instanceof can be used to avoid the casts. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Thu Jun 17 17:03:00 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 17 Jun 2021 17:03:00 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: References: <8Oflif9jz-Vib2Fxcj-QES7T-AIUZ1PleMTgio9j-z4=.486b0ceb-b556-4e62-9e0d-ffa75bb99a14@github.com> Message-ID: On Tue, 8 Jun 2021 11:49:55 GMT, Alan Bateman wrote: >> @AlanBateman I'm done with the changes you requested and kindly like to ask where to go from here. > >> @AlanBateman I'm done with the changes you requested and kindly like to ask where to go from here. > > Moving ChannelOutputStream to sun.nio.ch looks right. The implementation of transferTo will need a few rounds of cleanup, it's a look very messy right now. Most usages of var need to be replaced as it is impossible for the reader to know what the types are. Pattern matching for instanceof can be used to avoid the casts. @AlanBateman Pushed the requested changes. More change requests? :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From alanb at openjdk.java.net Thu Jun 17 17:03:05 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 17 Jun 2021 17:03:05 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: References: Message-ID: <2xWgYiscCqpLF_-mf4QnqmPisCZPTApveOMDOGloH6Y=.323cf745-c212-467b-bca4-74133ed00c60@github.com> On Sun, 30 May 2021 17:30:56 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? src/java.base/share/classes/java/nio/channels/Channels.java line 145: > 143: * @since 18 > 144: */ > 145: public static class ChannelOutputStream extends OutputStream { This adds Channels.ChannelOutputStream to the API, you will need to justify that. src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 148: > 146: > 147: @Override > 148: public long transferTo(final OutputStream out) throws IOException { Please try to keep to existing style, e.g. most/all "final" are noise and can be removed. src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 158: > 156: for (long n = size - pos; i < n; > 157: i += fc.transferTo(pos + i, Long.MAX_VALUE, oc)); > 158: fc.position(size); The patch is improving but needs cleanup so that it is easy to maintain. I think I would move the I/O ops out of the update code and into the for statement/block. Also this will need the update to the channel position to be a finally block so that the it is adjusted when there are partial transfers. src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 177: > 175: } > 176: > 177: final var bb = ByteBuffer.allocateDirect(TRANSFER_SIZE); This will probably need to be changed to the use the TL buffer cache. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From bpb at openjdk.java.net Thu Jun 17 17:03:19 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 17 Jun 2021 17:03:19 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: References: Message-ID: On Sun, 30 May 2021 17:30:56 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? src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 113: > 111: if ((off < 0) || (off > bs.length) || (len < 0) || > 112: ((off + len) > bs.length) || ((off + len) < 0)) { > 113: throw new IndexOutOfBoundsException(); Could the bounds checking be done as follows? `Objects.checkFromIndexSize(off, len, bs.length);` Same comment applies to lines 146 and 219 in `java.nio.channels.Channels`. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Thu Jun 17 17:03:13 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 17 Jun 2021 17:03:13 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: <2xWgYiscCqpLF_-mf4QnqmPisCZPTApveOMDOGloH6Y=.323cf745-c212-467b-bca4-74133ed00c60@github.com> References: <2xWgYiscCqpLF_-mf4QnqmPisCZPTApveOMDOGloH6Y=.323cf745-c212-467b-bca4-74133ed00c60@github.com> Message-ID: On Wed, 2 Jun 2021 09:03:03 GMT, Alan Bateman 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? > > src/java.base/share/classes/java/nio/channels/Channels.java line 145: > >> 143: * @since 18 >> 144: */ >> 145: public static class ChannelOutputStream extends OutputStream { > > This adds Channels.ChannelOutputStream to the API, you will need to justify that. You mean as a source comment or just here in this discussion thread? In fact it might be better to not add it to a package with is part of the API, but to move it to the `sun` package, which is not, right? The justification is that I need to refer to this class from `ChannelInputStream::transferTo()` to be able to get hold of this previously anonymous class's inner member "ch", which in turn is key to the whole story of this PR: Using NIO transfer between the channels instead of moving bytes through the JVM's memory. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 148: > >> 146: >> 147: @Override >> 148: public long transferTo(final OutputStream out) throws IOException { > > Please try to keep to existing style, e.g. most/all "final" are noise and can be removed. Sorry I am new do this project and didn't know that final is banned generally. To get it right: Is it banned only in parameters or also for variables and class members? > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 158: > >> 156: for (long n = size - pos; i < n; >> 157: i += fc.transferTo(pos + i, Long.MAX_VALUE, oc)); >> 158: fc.position(size); > > The patch is improving but needs cleanup so that it is easy to maintain. I think I would move the I/O ops out of the update code and into the for statement/block. Also this will need the update to the channel position to be a finally block so that the it is adjusted when there are partial transfers. Moved I/O operations into the `for` statement by https://github.com/openjdk/jdk/pull/4263/commits/562b1023e62c4ff0a36e55ebc119cee6fb69809c. > src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 177: > >> 175: } >> 176: >> 177: final var bb = ByteBuffer.allocateDirect(TRANSFER_SIZE); > > This will probably need to be changed to the use the TL buffer cache. Uhm... Maybe this is a dumb beginner's question, but: What is "the TL buffer cache"? ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Thu Jun 17 17:03:16 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 17 Jun 2021 17:03:16 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: References: <2xWgYiscCqpLF_-mf4QnqmPisCZPTApveOMDOGloH6Y=.323cf745-c212-467b-bca4-74133ed00c60@github.com> Message-ID: <7tabZuGT_VbnKGt4vHjvmesbKWnUrk4_fD0z2-QzEf0=.e00267c2-7122-4f40-b0c5-d4bcfb779245@github.com> On Sat, 5 Jun 2021 07:25:44 GMT, Markus KARG wrote: >> You mean as a source comment or just here in this discussion thread? >> >> In fact it might be better to not add it to a package with is part of the API, but to move it to the `sun` package, which is not, right? >> >> The justification is that I need to refer to this class from `ChannelInputStream::transferTo()` to be able to get hold of this previously anonymous class's inner member "ch", which in turn is key to the whole story of this PR: Using NIO transfer between the channels instead of moving bytes through the JVM's memory. > > Will move the class (and the needed utility methods) to the `sun` package to prevent addition to the API. Stay tuned. :-) `ChannelOutputStream` isn't part of the API anymore as I moved it to the `sun` package by commit https://github.com/openjdk/jdk/pull/4263/commits/b6dc6a7eadb5168531459aa032f169b344cadb47. Thankyou for pointing this out! >> Moved I/O operations into the `for` statement by https://github.com/openjdk/jdk/pull/4263/commits/562b1023e62c4ff0a36e55ebc119cee6fb69809c. > > Correctly positioning channel in case of exception by https://github.com/openjdk/jdk/pull/4263/commits/ed49098a4712bf23cb6d218c27695717ba3312c2. Honestly, for me the code looks perfectly comprehensible now, so I actually do not know what to simplify any further (besides adjusting to personal code style likes or dislikes). If there actually *is* something hard to read or understand, please don't hesitate to express your detailed concerns and/or propose an actual change. I will be happy to adopt it in this PR. >> Uhm... Maybe this is a dumb beginner's question, but: What is "the TL buffer cache"? > > I think I found what you mean and will use it: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/Util.java#L221 Done in https://github.com/openjdk/jdk/pull/4263/commits/8f589867154f8bc22ca6f6bb7a26d7ae841fe714. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Thu Jun 17 17:03:16 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 17 Jun 2021 17:03:16 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: References: <2xWgYiscCqpLF_-mf4QnqmPisCZPTApveOMDOGloH6Y=.323cf745-c212-467b-bca4-74133ed00c60@github.com> Message-ID: On Thu, 3 Jun 2021 17:29:14 GMT, Markus KARG wrote: >> src/java.base/share/classes/java/nio/channels/Channels.java line 145: >> >>> 143: * @since 18 >>> 144: */ >>> 145: public static class ChannelOutputStream extends OutputStream { >> >> This adds Channels.ChannelOutputStream to the API, you will need to justify that. > > You mean as a source comment or just here in this discussion thread? > > In fact it might be better to not add it to a package with is part of the API, but to move it to the `sun` package, which is not, right? > > The justification is that I need to refer to this class from `ChannelInputStream::transferTo()` to be able to get hold of this previously anonymous class's inner member "ch", which in turn is key to the whole story of this PR: Using NIO transfer between the channels instead of moving bytes through the JVM's memory. Will move the class (and the needed utility methods) to the `sun` package to prevent addition to the API. Stay tuned. :-) >> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 148: >> >>> 146: >>> 147: @Override >>> 148: public long transferTo(final OutputStream out) throws IOException { >> >> Please try to keep to existing style, e.g. most/all "final" are noise and can be removed. > > Sorry I am new do this project and didn't know that final is banned generally. To get it right: Is it banned only in parameters or also for variables and class members? Checked the existing code and removed most `final`s but kept it only for immitable members and real constants in https://github.com/openjdk/jdk/pull/4263/commits/df1a57a12cc81bbdcb36d3caf66a7aea7cc542cb. >> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 158: >> >>> 156: for (long n = size - pos; i < n; >>> 157: i += fc.transferTo(pos + i, Long.MAX_VALUE, oc)); >>> 158: fc.position(size); >> >> The patch is improving but needs cleanup so that it is easy to maintain. I think I would move the I/O ops out of the update code and into the for statement/block. Also this will need the update to the channel position to be a finally block so that the it is adjusted when there are partial transfers. > > Moved I/O operations into the `for` statement by https://github.com/openjdk/jdk/pull/4263/commits/562b1023e62c4ff0a36e55ebc119cee6fb69809c. Correctly positioning channel in case of exception by https://github.com/openjdk/jdk/pull/4263/commits/ed49098a4712bf23cb6d218c27695717ba3312c2. >> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 177: >> >>> 175: } >>> 176: >>> 177: final var bb = ByteBuffer.allocateDirect(TRANSFER_SIZE); >> >> This will probably need to be changed to the use the TL buffer cache. > > Uhm... Maybe this is a dumb beginner's question, but: What is "the TL buffer cache"? I think I found what you mean and will use it: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/ch/Util.java#L221 ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From bpb at openjdk.java.net Thu Jun 17 17:03:22 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 17 Jun 2021 17:03:22 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: <9noNLNqP2t9FnvwjnRRt3W2eAt-q2Gg3i88Sijo7FVM=.005cba93-4bb6-4bac-bf44-bd127a12958b@github.com> References: <9noNLNqP2t9FnvwjnRRt3W2eAt-q2Gg3i88Sijo7FVM=.005cba93-4bb6-4bac-bf44-bd127a12958b@github.com> Message-ID: <0JQh4Ae25-Tx3qDCpye5spAkEI-eAZsPo1XHhbJ1Iwg=.db5bd01f-04e5-48f8-9afc-93cb99c45f7c@github.com> On Tue, 8 Jun 2021 20:20:58 GMT, Markus KARG wrote: >> src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 113: >> >>> 111: if ((off < 0) || (off > bs.length) || (len < 0) || >>> 112: ((off + len) > bs.length) || ((off + len) < 0)) { >>> 113: throw new IndexOutOfBoundsException(); >> >> Could the bounds checking be done as follows? >> >> `Objects.checkFromIndexSize(off, len, bs.length);` >> >> Same comment applies to lines 146 and 219 in `java.nio.channels.Channels`. > > I'd like to abstain from changes in ChannelOutputStream, as I did not write that code at all. It is simply moved from being an inner class. Please let's concentrate on the code I actually wrote in this PR. Thanks. That's fine. Sometimes we make small changes like that while we are in nearby code. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Thu Jun 17 17:03:23 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 17 Jun 2021 17:03:23 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: <0JQh4Ae25-Tx3qDCpye5spAkEI-eAZsPo1XHhbJ1Iwg=.db5bd01f-04e5-48f8-9afc-93cb99c45f7c@github.com> References: <9noNLNqP2t9FnvwjnRRt3W2eAt-q2Gg3i88Sijo7FVM=.005cba93-4bb6-4bac-bf44-bd127a12958b@github.com> <0JQh4Ae25-Tx3qDCpye5spAkEI-eAZsPo1XHhbJ1Iwg=.db5bd01f-04e5-48f8-9afc-93cb99c45f7c@github.com> Message-ID: On Tue, 8 Jun 2021 20:34:15 GMT, Brian Burkhalter wrote: >> I'd like to abstain from changes in ChannelOutputStream, as I did not write that code at all. It is simply moved from being an inner class. Please let's concentrate on the code I actually wrote in this PR. Thanks. > > That's fine. Sometimes we make small changes like that while we are in nearby code. I see. Changed by https://github.com/openjdk/jdk/pull/4263/commits/599181bd5289a1c31e0a3bb596c979a9e6491ccd. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From github.com+1701815+mkarg at openjdk.java.net Thu Jun 17 17:03:21 2021 From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG) Date: Thu, 17 Jun 2021 17:03:21 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: References: Message-ID: <9noNLNqP2t9FnvwjnRRt3W2eAt-q2Gg3i88Sijo7FVM=.005cba93-4bb6-4bac-bf44-bd127a12958b@github.com> On Tue, 8 Jun 2021 19:26:14 GMT, Brian Burkhalter 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? > > src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 113: > >> 111: if ((off < 0) || (off > bs.length) || (len < 0) || >> 112: ((off + len) > bs.length) || ((off + len) < 0)) { >> 113: throw new IndexOutOfBoundsException(); > > Could the bounds checking be done as follows? > > `Objects.checkFromIndexSize(off, len, bs.length);` > > Same comment applies to lines 146 and 219 in `java.nio.channels.Channels`. I'd like to abstain from changes in ChannelOutputStream, as I did not write that code at all. It is simply moved from being an inner class. Please let's concentrate on the code I actually wrote in this PR. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From alexey.semenyuk at oracle.com Thu Jun 17 17:52:54 2021 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 17 Jun 2021 13:52:54 -0400 Subject: jpackage issue with --dest In-Reply-To: <4c630ec1-57f4-cf8a-6b4f-9bd0b0818d1a@oracle.com> References: <12421ff3-be38-b232-6fe2-5b36b35dacfb@oracle.com> <4c630ec1-57f4-cf8a-6b4f-9bd0b0818d1a@oracle.com> Message-ID: <68788a0b-5609-b456-5bca-afd72a4f0716@oracle.com> Seems like a new issue. Please file a bug in Jira. - Alexey On 6/16/2021 5:14 PM, Maurizio Cimadamore wrote: > Also, if --dest is removed, or if it is set to something which doesn't > contain the "bin" subfolder, everything works... that seems different > from the issue you linked? > > Maurizio > > On 16/06/2021 22:11, Maurizio Cimadamore wrote: >> Hi, >> I've built my JDK this morning. I checked now with `git log` and I do >> have: >> >> https://bugs.openjdk.java.net/browse/JDK-8267598 >> >> Maurizio >> >> On 16/06/2021 21:12, Alexey Semenyuk wrote: >>> Hi Maurizio, >>> >>> Thank you for the provided output. >>> According to the log, app launcher loaded libjli.so and it failed in >>> JLI_Launch() function. >>> Probably the problem is that you use jpackage from the build that >>> has https://bugs.openjdk.java.net/browse/JDK-8263157 fix that >>> resulted in a number of regressions fixed with >>> https://bugs.openjdk.java.net/browse/JDK-8267598 patch. >>> Chances are your local build doesn't contain a patch for >>> JDK-8267598. The latest jdk17 build at https://jdk.java.net/17/ >>> contains patch for JDK-8267598. Can you try it? >>> >>> - Alexey >>> >>> On 6/16/2021 1:52 PM, Maurizio Cimadamore wrote: >>>> This is what I get when I run jpackage: >>>> >>>> ``` >>>> $ jpackage --type app-image --name HelloWorld --input >>>> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar >>>> --main-jar jpackage-test.jar --dest bin >>>> [18:50:09.375] >>>> jpackage argument list: >>>> [--type, app-image, --name, HelloWorld, --input, >>>> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar, >>>> --main-jar, jpackage-test.jar, --dest, bin] >>>> >>>> [18:50:09.409] Running dpkg >>>> [18:50:09.420] Command [PID: 399487]: >>>> ??? dpkg --print-architecture >>>> [18:50:09.420] Output: >>>> ??? amd64 >>>> [18:50:09.422] Returned: 0 >>>> >>>> [18:50:09.431] Creating app package: HelloWorld in /tmp/bin >>>> [18:50:13.288] Command [PID: -1]: >>>> ??? jlink --output bin/HelloWorld/lib/runtime --module-path >>>> /w/lt/jdk/dev/build/linux-x86_64-server-release/images/jdk/jmods >>>> --add-modules >>>> jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.sctp,jdk.jsobject,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.logging,java.transaction.xa,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata >>>> --strip-native-commands --strip-debug --no-man-pages --no-header-files >>>> [18:50:13.288] Output: >>>> ??? WARNING: Using incubator modules: jdk.incubator.foreign, >>>> jdk.incubator.vector >>>> >>>> [18:50:13.288] Returned: 0 >>>> >>>> [18:50:13.292] Using default package resource JavaApp.png [icon] >>>> (add HelloWorld.png to the resource-dir to customize). >>>> [18:50:13.302] Succeeded in building Linux Application Image package >>>> ``` >>>> >>>> And this is what happens when I run the generated binary: >>>> >>>> ``` >>>> $ bin/HelloWorld/bin/HelloWorld >>>> popen: (rpm --queryformat '%{NAME}' -qf >>>> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >>>> popen: exit: 32512 >>>> popen: (dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >>>> popen: exit: 256 >>>> [TRACE] app.cpp:123: Entering launch >>>> [TRACE] Executor.cpp:41: Reading output of [rpm --queryformat >>>> '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] >>>> command >>>> [TRACE] Executor.cpp:41: Reading output of [dpkg -S >>>> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command >>>> [TRACE] LinuxLauncherLib.cpp:121: Set _JPACKAGE_LAUNCHER=[0] >>>> [TRACE] AppLauncher.cpp:99: Launcher config file path: >>>> "/tmp/bin/HelloWorld/lib/app/HelloWorld.cfg" >>>> [TRACE] JvmLauncher.cpp:43: Jvm(0x55a49cb86750)::Jvm() >>>> [TRACE] AppLauncher.cpp:71: Property "app.runtime" not found in >>>> "Application" section of launcher config file. Using Java runtime >>>> from "/tmp/bin/HelloWorld/lib/runtime" directory >>>> [TRACE] app.cpp:0: Exiting launch (entered at app.cpp:123) >>>> [TRACE] JvmLauncher.cpp:48: Jvm(0x55a49cb86750)::~Jvm() >>>> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData >>>> buffer >>>> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData >>>> buffer >>>> [TRACE] JvmLauncher.cpp:269: Initialized 310 bytes at >>>> 0x55a49cb86cc0 address >>>> [TRACE] LinuxLauncherLib.cpp:157: unload >>>> jli lib: [/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so] >>>> jli arg[0]: [/tmp/bin/HelloWorld/bin/HelloWorld] >>>> jli arg[1]: [-classpath] >>>> jli arg[2]: [/tmp/bin/HelloWorld/lib/app/jpackage-test.jar] >>>> jli arg[3]: [-Djpackage.app-version=1.0] >>>> jli arg[4]: [-Djpackage.app-path=/tmp/bin/HelloWorld/bin/HelloWorld] >>>> jli arg[5]: [main.Main] >>>> Error: could not find libjava.so >>>> Error: Could not find Java SE Runtime Environment. >>>> ``` >>>> >>>> Does that clarify things? >>>> >>>> Thanks >>>> Maurizio >>>> >>>> >>>> On 16/06/2021 18:28, Alexey Semenyuk wrote: >>>>> Hi Maurizio, >>>>> >>>>> This is not known issue. >>>>> Can you run the app with "JPACKAGE_DEBUG" env variable set to >>>>> "true". In this case the app launcher will produce debug output >>>>> that will help to understand why it can't find libjava.so. >>>>> >>>>> - Alexey >>>>> >>>>> On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote: >>>>>> Hi, >>>>>> I'm relatively new to jpackage and I found a weird issue on linux >>>>>> where the name of a --dest folder can affect the correct behavior >>>>>> of the generated application image. >>>>>> >>>>>> I have put together an hello world application, with a jarfile. >>>>>> If I jpackage it with the following command line: >>>>>> >>>>>> ``` >>>>>> $ jpackage --type app-image --name HelloWorld --input >>>>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar >>>>>> --dest output >>>>>> ``` >>>>>> >>>>>> Everything works correctly, and launching the generated app >>>>>> prints "Hello world": >>>>>> >>>>>> ``` >>>>>> $ output/HelloWorld/bin/HelloWorld >>>>>> Hello world! >>>>>> ``` >>>>>> >>>>>> However, if the destination directory contains "bin" (even as a >>>>>> nested subfolder), there are issues. Here's the jextract command >>>>>> line: >>>>>> >>>>>> ``` >>>>>> $ jpackage --type app-image --name HelloWorld --input >>>>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar >>>>>> --dest bin >>>>>> ``` >>>>>> >>>>>> (the only thihng that changed is the --dest parameter) >>>>>> >>>>>> And here's what I get: >>>>>> >>>>>> ``` >>>>>> $ bin/HelloWorld/bin/HelloWorld >>>>>> Error: could not find libjava.so >>>>>> Error: Could not find Java SE Runtime Environment. >>>>>> ``` >>>>>> >>>>>> I use Ubuntu 20.04. A colleague of mine using MacOS does not seem >>>>>> to have the same issue, so it seems to be system specific. >>>>>> >>>>>> I'm using the latest jpackage from jdk/jdk. >>>>>> >>>>>> Is this a known issue? >>>>>> >>>>>> Cheers >>>>>> Maurizio >>>>>> >>>>> >>> From maurizio.cimadamore at oracle.com Thu Jun 17 18:01:31 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 17 Jun 2021 19:01:31 +0100 Subject: jpackage issue with --dest In-Reply-To: <68788a0b-5609-b456-5bca-afd72a4f0716@oracle.com> References: <12421ff3-be38-b232-6fe2-5b36b35dacfb@oracle.com> <4c630ec1-57f4-cf8a-6b4f-9bd0b0818d1a@oracle.com> <68788a0b-5609-b456-5bca-afd72a4f0716@oracle.com> Message-ID: Filed this: https://bugs.openjdk.java.net/browse/JDK-8268974 Maurizio On 17/06/2021 18:52, Alexey Semenyuk wrote: > Seems like a new issue. Please file a bug in Jira. > > - Alexey > > On 6/16/2021 5:14 PM, Maurizio Cimadamore wrote: >> Also, if --dest is removed, or if it is set to something which >> doesn't contain the "bin" subfolder, everything works... that seems >> different from the issue you linked? >> >> Maurizio >> >> On 16/06/2021 22:11, Maurizio Cimadamore wrote: >>> Hi, >>> I've built my JDK this morning. I checked now with `git log` and I >>> do have: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8267598 >>> >>> Maurizio >>> >>> On 16/06/2021 21:12, Alexey Semenyuk wrote: >>>> Hi Maurizio, >>>> >>>> Thank you for the provided output. >>>> According to the log, app launcher loaded libjli.so and it failed >>>> in JLI_Launch() function. >>>> Probably the problem is that you use jpackage from the build that >>>> has https://bugs.openjdk.java.net/browse/JDK-8263157 fix that >>>> resulted in a number of regressions fixed with >>>> https://bugs.openjdk.java.net/browse/JDK-8267598 patch. >>>> Chances are your local build doesn't contain a patch for >>>> JDK-8267598. The latest jdk17 build at https://jdk.java.net/17/ >>>> contains patch for JDK-8267598. Can you try it? >>>> >>>> - Alexey >>>> >>>> On 6/16/2021 1:52 PM, Maurizio Cimadamore wrote: >>>>> This is what I get when I run jpackage: >>>>> >>>>> ``` >>>>> $ jpackage --type app-image --name HelloWorld --input >>>>> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar >>>>> --main-jar jpackage-test.jar --dest bin >>>>> [18:50:09.375] >>>>> jpackage argument list: >>>>> [--type, app-image, --name, HelloWorld, --input, >>>>> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar, >>>>> --main-jar, jpackage-test.jar, --dest, bin] >>>>> >>>>> [18:50:09.409] Running dpkg >>>>> [18:50:09.420] Command [PID: 399487]: >>>>> ??? dpkg --print-architecture >>>>> [18:50:09.420] Output: >>>>> ??? amd64 >>>>> [18:50:09.422] Returned: 0 >>>>> >>>>> [18:50:09.431] Creating app package: HelloWorld in /tmp/bin >>>>> [18:50:13.288] Command [PID: -1]: >>>>> ??? jlink --output bin/HelloWorld/lib/runtime --module-path >>>>> /w/lt/jdk/dev/build/linux-x86_64-server-release/images/jdk/jmods >>>>> --add-modules >>>>> jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.sctp,jdk.jsobject,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.logging,java.transaction.xa,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata >>>>> --strip-native-commands --strip-debug --no-man-pages >>>>> --no-header-files >>>>> [18:50:13.288] Output: >>>>> ??? WARNING: Using incubator modules: jdk.incubator.foreign, >>>>> jdk.incubator.vector >>>>> >>>>> [18:50:13.288] Returned: 0 >>>>> >>>>> [18:50:13.292] Using default package resource JavaApp.png [icon] >>>>> (add HelloWorld.png to the resource-dir to customize). >>>>> [18:50:13.302] Succeeded in building Linux Application Image package >>>>> ``` >>>>> >>>>> And this is what happens when I run the generated binary: >>>>> >>>>> ``` >>>>> $ bin/HelloWorld/bin/HelloWorld >>>>> popen: (rpm --queryformat '%{NAME}' -qf >>>>> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >>>>> popen: exit: 32512 >>>>> popen: (dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >>>>> popen: exit: 256 >>>>> [TRACE] app.cpp:123: Entering launch >>>>> [TRACE] Executor.cpp:41: Reading output of [rpm --queryformat >>>>> '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] >>>>> command >>>>> [TRACE] Executor.cpp:41: Reading output of [dpkg -S >>>>> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command >>>>> [TRACE] LinuxLauncherLib.cpp:121: Set _JPACKAGE_LAUNCHER=[0] >>>>> [TRACE] AppLauncher.cpp:99: Launcher config file path: >>>>> "/tmp/bin/HelloWorld/lib/app/HelloWorld.cfg" >>>>> [TRACE] JvmLauncher.cpp:43: Jvm(0x55a49cb86750)::Jvm() >>>>> [TRACE] AppLauncher.cpp:71: Property "app.runtime" not found in >>>>> "Application" section of launcher config file. Using Java runtime >>>>> from "/tmp/bin/HelloWorld/lib/runtime" directory >>>>> [TRACE] app.cpp:0: Exiting launch (entered at app.cpp:123) >>>>> [TRACE] JvmLauncher.cpp:48: Jvm(0x55a49cb86750)::~Jvm() >>>>> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData >>>>> buffer >>>>> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData >>>>> buffer >>>>> [TRACE] JvmLauncher.cpp:269: Initialized 310 bytes at >>>>> 0x55a49cb86cc0 address >>>>> [TRACE] LinuxLauncherLib.cpp:157: unload >>>>> jli lib: [/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so] >>>>> jli arg[0]: [/tmp/bin/HelloWorld/bin/HelloWorld] >>>>> jli arg[1]: [-classpath] >>>>> jli arg[2]: [/tmp/bin/HelloWorld/lib/app/jpackage-test.jar] >>>>> jli arg[3]: [-Djpackage.app-version=1.0] >>>>> jli arg[4]: [-Djpackage.app-path=/tmp/bin/HelloWorld/bin/HelloWorld] >>>>> jli arg[5]: [main.Main] >>>>> Error: could not find libjava.so >>>>> Error: Could not find Java SE Runtime Environment. >>>>> ``` >>>>> >>>>> Does that clarify things? >>>>> >>>>> Thanks >>>>> Maurizio >>>>> >>>>> >>>>> On 16/06/2021 18:28, Alexey Semenyuk wrote: >>>>>> Hi Maurizio, >>>>>> >>>>>> This is not known issue. >>>>>> Can you run the app with "JPACKAGE_DEBUG" env variable set to >>>>>> "true". In this case the app launcher will produce debug output >>>>>> that will help to understand why it can't find libjava.so. >>>>>> >>>>>> - Alexey >>>>>> >>>>>> On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote: >>>>>>> Hi, >>>>>>> I'm relatively new to jpackage and I found a weird issue on >>>>>>> linux where the name of a --dest folder can affect the correct >>>>>>> behavior of the generated application image. >>>>>>> >>>>>>> I have put together an hello world application, with a jarfile. >>>>>>> If I jpackage it with the following command line: >>>>>>> >>>>>>> ``` >>>>>>> $ jpackage --type app-image --name HelloWorld --input >>>>>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar >>>>>>> --dest output >>>>>>> ``` >>>>>>> >>>>>>> Everything works correctly, and launching the generated app >>>>>>> prints "Hello world": >>>>>>> >>>>>>> ``` >>>>>>> $ output/HelloWorld/bin/HelloWorld >>>>>>> Hello world! >>>>>>> ``` >>>>>>> >>>>>>> However, if the destination directory contains "bin" (even as a >>>>>>> nested subfolder), there are issues. Here's the jextract command >>>>>>> line: >>>>>>> >>>>>>> ``` >>>>>>> $ jpackage --type app-image --name HelloWorld --input >>>>>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar >>>>>>> --dest bin >>>>>>> ``` >>>>>>> >>>>>>> (the only thihng that changed is the --dest parameter) >>>>>>> >>>>>>> And here's what I get: >>>>>>> >>>>>>> ``` >>>>>>> $ bin/HelloWorld/bin/HelloWorld >>>>>>> Error: could not find libjava.so >>>>>>> Error: Could not find Java SE Runtime Environment. >>>>>>> ``` >>>>>>> >>>>>>> I use Ubuntu 20.04. A colleague of mine using MacOS does not >>>>>>> seem to have the same issue, so it seems to be system specific. >>>>>>> >>>>>>> I'm using the latest jpackage from jdk/jdk. >>>>>>> >>>>>>> Is this a known issue? >>>>>>> >>>>>>> Cheers >>>>>>> Maurizio >>>>>>> >>>>>> >>>> > From alexey.semenyuk at oracle.com Thu Jun 17 18:03:45 2021 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 17 Jun 2021 14:03:45 -0400 Subject: jpackage issue with --dest In-Reply-To: References: <12421ff3-be38-b232-6fe2-5b36b35dacfb@oracle.com> <4c630ec1-57f4-cf8a-6b4f-9bd0b0818d1a@oracle.com> <68788a0b-5609-b456-5bca-afd72a4f0716@oracle.com> Message-ID: Thanks. I'll look into it. - Alexey On 6/17/2021 2:01 PM, Maurizio Cimadamore wrote: > Filed this: > > https://bugs.openjdk.java.net/browse/JDK-8268974 > > Maurizio > > On 17/06/2021 18:52, Alexey Semenyuk wrote: >> Seems like a new issue. Please file a bug in Jira. >> >> - Alexey >> >> On 6/16/2021 5:14 PM, Maurizio Cimadamore wrote: >>> Also, if --dest is removed, or if it is set to something which >>> doesn't contain the "bin" subfolder, everything works... that seems >>> different from the issue you linked? >>> >>> Maurizio >>> >>> On 16/06/2021 22:11, Maurizio Cimadamore wrote: >>>> Hi, >>>> I've built my JDK this morning. I checked now with `git log` and I >>>> do have: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8267598 >>>> >>>> Maurizio >>>> >>>> On 16/06/2021 21:12, Alexey Semenyuk wrote: >>>>> Hi Maurizio, >>>>> >>>>> Thank you for the provided output. >>>>> According to the log, app launcher loaded libjli.so and it failed >>>>> in JLI_Launch() function. >>>>> Probably the problem is that you use jpackage from the build that >>>>> has https://bugs.openjdk.java.net/browse/JDK-8263157 fix that >>>>> resulted in a number of regressions fixed with >>>>> https://bugs.openjdk.java.net/browse/JDK-8267598 patch. >>>>> Chances are your local build doesn't contain a patch for >>>>> JDK-8267598. The latest jdk17 build at https://jdk.java.net/17/ >>>>> contains patch for JDK-8267598. Can you try it? >>>>> >>>>> - Alexey >>>>> >>>>> On 6/16/2021 1:52 PM, Maurizio Cimadamore wrote: >>>>>> This is what I get when I run jpackage: >>>>>> >>>>>> ``` >>>>>> $ jpackage --type app-image --name HelloWorld --input >>>>>> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar >>>>>> --main-jar jpackage-test.jar --dest bin >>>>>> [18:50:09.375] >>>>>> jpackage argument list: >>>>>> [--type, app-image, --name, HelloWorld, --input, >>>>>> /home/maurizio/Desktop/panama-test/jpackage-test/out/artifacts/jpackage_test_jar, >>>>>> --main-jar, jpackage-test.jar, --dest, bin] >>>>>> >>>>>> [18:50:09.409] Running dpkg >>>>>> [18:50:09.420] Command [PID: 399487]: >>>>>> ??? dpkg --print-architecture >>>>>> [18:50:09.420] Output: >>>>>> ??? amd64 >>>>>> [18:50:09.422] Returned: 0 >>>>>> >>>>>> [18:50:09.431] Creating app package: HelloWorld in /tmp/bin >>>>>> [18:50:13.288] Command [PID: -1]: >>>>>> ??? jlink --output bin/HelloWorld/lib/runtime --module-path >>>>>> /w/lt/jdk/dev/build/linux-x86_64-server-release/images/jdk/jmods >>>>>> --add-modules >>>>>> jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.sctp,jdk.jsobject,java.smartcardio,jdk.unsupported,jdk.jlink,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,jdk.incubator.vector,java.sql,java.logging,java.transaction.xa,java.xml.crypto,jdk.jfr,jdk.crypto.cryptoki,jdk.random,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata >>>>>> --strip-native-commands --strip-debug --no-man-pages >>>>>> --no-header-files >>>>>> [18:50:13.288] Output: >>>>>> ??? WARNING: Using incubator modules: jdk.incubator.foreign, >>>>>> jdk.incubator.vector >>>>>> >>>>>> [18:50:13.288] Returned: 0 >>>>>> >>>>>> [18:50:13.292] Using default package resource JavaApp.png [icon] >>>>>> (add HelloWorld.png to the resource-dir to customize). >>>>>> [18:50:13.302] Succeeded in building Linux Application Image package >>>>>> ``` >>>>>> >>>>>> And this is what happens when I run the generated binary: >>>>>> >>>>>> ``` >>>>>> $ bin/HelloWorld/bin/HelloWorld >>>>>> popen: (rpm --queryformat '%{NAME}' -qf >>>>>> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >>>>>> popen: exit: 32512 >>>>>> popen: (dpkg -S '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null) >>>>>> popen: exit: 256 >>>>>> [TRACE] app.cpp:123: Entering launch >>>>>> [TRACE] Executor.cpp:41: Reading output of [rpm --queryformat >>>>>> '%{NAME}' -qf '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] >>>>>> command >>>>>> [TRACE] Executor.cpp:41: Reading output of [dpkg -S >>>>>> '/tmp/bin/HelloWorld/bin/HelloWorld' 2>/dev/null] command >>>>>> [TRACE] LinuxLauncherLib.cpp:121: Set _JPACKAGE_LAUNCHER=[0] >>>>>> [TRACE] AppLauncher.cpp:99: Launcher config file path: >>>>>> "/tmp/bin/HelloWorld/lib/app/HelloWorld.cfg" >>>>>> [TRACE] JvmLauncher.cpp:43: Jvm(0x55a49cb86750)::Jvm() >>>>>> [TRACE] AppLauncher.cpp:71: Property "app.runtime" not found in >>>>>> "Application" section of launcher config file. Using Java runtime >>>>>> from "/tmp/bin/HelloWorld/lib/runtime" directory >>>>>> [TRACE] app.cpp:0: Exiting launch (entered at app.cpp:123) >>>>>> [TRACE] JvmLauncher.cpp:48: Jvm(0x55a49cb86750)::~Jvm() >>>>>> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData >>>>>> buffer >>>>>> [TRACE] JvmLauncher.cpp:272: Need 310 bytes for JvmlLauncherData >>>>>> buffer >>>>>> [TRACE] JvmLauncher.cpp:269: Initialized 310 bytes at >>>>>> 0x55a49cb86cc0 address >>>>>> [TRACE] LinuxLauncherLib.cpp:157: unload >>>>>> jli lib: [/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so] >>>>>> jli arg[0]: [/tmp/bin/HelloWorld/bin/HelloWorld] >>>>>> jli arg[1]: [-classpath] >>>>>> jli arg[2]: [/tmp/bin/HelloWorld/lib/app/jpackage-test.jar] >>>>>> jli arg[3]: [-Djpackage.app-version=1.0] >>>>>> jli arg[4]: [-Djpackage.app-path=/tmp/bin/HelloWorld/bin/HelloWorld] >>>>>> jli arg[5]: [main.Main] >>>>>> Error: could not find libjava.so >>>>>> Error: Could not find Java SE Runtime Environment. >>>>>> ``` >>>>>> >>>>>> Does that clarify things? >>>>>> >>>>>> Thanks >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 16/06/2021 18:28, Alexey Semenyuk wrote: >>>>>>> Hi Maurizio, >>>>>>> >>>>>>> This is not known issue. >>>>>>> Can you run the app with "JPACKAGE_DEBUG" env variable set to >>>>>>> "true". In this case the app launcher will produce debug output >>>>>>> that will help to understand why it can't find libjava.so. >>>>>>> >>>>>>> - Alexey >>>>>>> >>>>>>> On 6/16/2021 9:11 AM, Maurizio Cimadamore wrote: >>>>>>>> Hi, >>>>>>>> I'm relatively new to jpackage and I found a weird issue on >>>>>>>> linux where the name of a --dest folder can affect the correct >>>>>>>> behavior of the generated application image. >>>>>>>> >>>>>>>> I have put together an hello world application, with a jarfile. >>>>>>>> If I jpackage it with the following command line: >>>>>>>> >>>>>>>> ``` >>>>>>>> $ jpackage --type app-image --name HelloWorld --input >>>>>>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar >>>>>>>> --dest output >>>>>>>> ``` >>>>>>>> >>>>>>>> Everything works correctly, and launching the generated app >>>>>>>> prints "Hello world": >>>>>>>> >>>>>>>> ``` >>>>>>>> $ output/HelloWorld/bin/HelloWorld >>>>>>>> Hello world! >>>>>>>> ``` >>>>>>>> >>>>>>>> However, if the destination directory contains "bin" (even as a >>>>>>>> nested subfolder), there are issues. Here's the jextract >>>>>>>> command line: >>>>>>>> >>>>>>>> ``` >>>>>>>> $ jpackage --type app-image --name HelloWorld --input >>>>>>>> out/artifacts/jpackage_test_jar --main-jar jpackage-test.jar >>>>>>>> --dest bin >>>>>>>> ``` >>>>>>>> >>>>>>>> (the only thihng that changed is the --dest parameter) >>>>>>>> >>>>>>>> And here's what I get: >>>>>>>> >>>>>>>> ``` >>>>>>>> $ bin/HelloWorld/bin/HelloWorld >>>>>>>> Error: could not find libjava.so >>>>>>>> Error: Could not find Java SE Runtime Environment. >>>>>>>> ``` >>>>>>>> >>>>>>>> I use Ubuntu 20.04. A colleague of mine using MacOS does not >>>>>>>> seem to have the same issue, so it seems to be system specific. >>>>>>>> >>>>>>>> I'm using the latest jpackage from jdk/jdk. >>>>>>>> >>>>>>>> Is this a known issue? >>>>>>>> >>>>>>>> Cheers >>>>>>>> Maurizio >>>>>>>> >>>>>>> >>>>> >> From avoitylov at openjdk.java.net Thu Jun 17 18:15:35 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 17 Jun 2021 18:15:35 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v8] In-Reply-To: <5JG8spPlGwIAlYtUrro-tXArYdYTc0gIhzdcAttYYgo=.ea130dbe-1ece-4052-8f91-fe08654e40b7@github.com> References: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> <5JG8spPlGwIAlYtUrro-tXArYdYTc0gIhzdcAttYYgo=.ea130dbe-1ece-4052-8f91-fe08654e40b7@github.com> Message-ID: On Wed, 16 Jun 2021 15:59:44 GMT, Mandy Chung wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> address review comments > > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 95: > >> 93: Collections.addAll(args, "cvf", Paths.get(testClassPath, outputJar).toString()); >> 94: for (String c : classes) { >> 95: Collections.addAll(args, "-C", testClassPath, c); > > I believe only one single `-C` option is good enough for this case since the classes are all in one single directory. Contrary to the man which says "-C DIR Changes the specified directory and includes the files specified at the end of the command line.", here is how it works: bash-3.2$ find . . ./dir ./dir/B.class ./dir/A.class bash-3.2$ jar cvf a.jar -C dir A.class B.class B.class : no such file or directory added manifest adding: A.class(in = 176) (out= 149)(deflated 15%) and no jar is produced. Lines 614 and 647 of src/jdk.jartool/share/classes/sun/tools/jar/Main.java explain why. IIRC the intent was to mimic tar -C behaviour where -C applies to all files that follow, but jar does not work that way currently. It's probably worth reaching consensus that it's a problem worth fixing first (a scary one to fix by the way, provided how many tools could rely on the current behaviour). Alternatively, man could be adjusted to reflect the current order. I could work on that as a follow up. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From avoitylov at openjdk.java.net Thu Jun 17 18:18:32 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 17 Jun 2021 18:18:32 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v8] In-Reply-To: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> References: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> Message-ID: On Wed, 16 Jun 2021 07:51:32 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thanks Mandy for the thorough review, I'll definitely do that. Shall we wait for Alan opinion as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From jlahoda at openjdk.java.net Thu Jun 17 18:33:56 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 17 Jun 2021 18:33:56 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v2] In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: > Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding. > > How does this look? Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Creating a new bootstrap method for (pattern matching) enum switches, as suggested. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/81/files - new: https://git.openjdk.java.net/jdk17/pull/81/files/053c4895..4e1977a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=00-01 Stats: 227 lines in 6 files changed: 144 ins; 44 del; 39 mod Patch: https://git.openjdk.java.net/jdk17/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81 PR: https://git.openjdk.java.net/jdk17/pull/81 From mchung at openjdk.java.net Thu Jun 17 18:51:34 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 17 Jun 2021 18:51:34 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v8] In-Reply-To: References: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> <5JG8spPlGwIAlYtUrro-tXArYdYTc0gIhzdcAttYYgo=.ea130dbe-1ece-4052-8f91-fe08654e40b7@github.com> Message-ID: On Thu, 17 Jun 2021 18:12:19 GMT, Aleksei Voitylov wrote: >> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 95: >> >>> 93: Collections.addAll(args, "cvf", Paths.get(testClassPath, outputJar).toString()); >>> 94: for (String c : classes) { >>> 95: Collections.addAll(args, "-C", testClassPath, c); >> >> I believe only one single `-C` option is good enough for this case since the classes are all in one single directory. > > Contrary to the man which says "-C DIR Changes the specified directory and includes the files specified at the end of the command line.", here is how it works: > > > bash-3.2$ find . > . > ./dir > ./dir/B.class > ./dir/A.class > bash-3.2$ jar cvf a.jar -C dir A.class B.class > B.class : no such file or directory > added manifest > adding: A.class(in = 176) (out= 149)(deflated 15%) > > > and no jar is produced. Lines 614 and 647 of src/jdk.jartool/share/classes/sun/tools/jar/Main.java explain why. IIRC the intent was to mimic tar -C behaviour where -C applies to all files that follow, but jar does not work that way currently. > > It's probably worth reaching consensus that it's a problem worth fixing first (a scary one to fix by the way, provided how many tools could rely on the current behaviour). Alternatively, man could be adjusted to reflect the current order. I could work on that as a follow up. You are probably right. I have no more comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From mchung at openjdk.java.net Thu Jun 17 18:51:34 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 17 Jun 2021 18:51:34 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v8] In-Reply-To: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> References: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> Message-ID: On Wed, 16 Jun 2021 07:51:32 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation. >> >> Problem being fixed: >> >> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread. >> >> Proposed fix: >> >> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method. >> >> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared. >> >> Testing: jtreg and jck testing with no regressions. A new regression test was developed. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From mchung at openjdk.java.net Thu Jun 17 19:10:35 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 17 Jun 2021 19:10:35 GMT Subject: RFR: 8266310: deadlock while loading the JNI code [v8] In-Reply-To: References: <-LHsGU2_Bd86tLYrb7dbkawg79DB6Q-8KvlkrdOAC14=.fe984df1-e573-41ef-b3ad-101431cb709c@github.com> Message-ID: On Thu, 17 Jun 2021 18:15:52 GMT, Aleksei Voitylov wrote: > Thanks Mandy for the thorough review, I'll definitely do that. Shall we wait for Alan opinion as well? I think you can proceed posting a PR for jdk17 as the new version has addressed Alan's concern of using ThreadLocal. Alan can review the new PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3976 From github.com+114367+mbien at openjdk.java.net Thu Jun 17 20:11:27 2021 From: github.com+114367+mbien at openjdk.java.net (Michael Bien) Date: Thu, 17 Jun 2021 20:11:27 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo In-Reply-To: References: Message-ID: On Sun, 30 May 2021 17:30:56 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? src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 216: > 214: } > 215: > 216: return super.transferTo(out); (i am no reviewer) wouldn't this method be more intuitive if it wouldn't try to avoid using "else if" and "else"? If there are sequential if blocks with return in them, part of me is always trying to find the fall-through scenario, but in this case its all distinct code paths. Using branches would make that obvious + if there would be a fall through in future, the compiler would generate a "missing return" error right away. example: if (out instanceof ChannelOutputStream cos) { WritableByteChannel oc = cos.channel(); long i = 0L; if (ch instanceof FileChannel fc) { long pos = fc.position(); long size = fc.size(); try { for (long n = size - pos; i < n;) i += fc.transferTo(pos + i, Long.MAX_VALUE, oc); return i; } finally { fc.position(pos + i); } } else if (oc instanceof FileChannel fc) { long fcpos = fc.position(); if (ch instanceof SeekableByteChannel sbc) { long pos = sbc.position(); long size = sbc.size(); try { for (long n = size - pos; i < n;) i += fc.transferFrom(ch, fcpos + i, Long.MAX_VALUE); return i; } finally { fc.position(fcpos + i); } } else { ByteBuffer bb = Util.getTemporaryDirectBuffer(TRANSFER_SIZE); try { int r; do { i += fc.transferFrom(ch, fcpos + i, Long.MAX_VALUE); r = ch.read(bb); // detect end-of-stream if (r > -1) { bb.flip(); while (bb.hasRemaining()) oc.write(bb); bb.clear(); i += r; } } while (r > -1); return i; } finally { fc.position(fcpos + i); Util.releaseTemporaryDirectBuffer(bb); } } } else { ByteBuffer bb = Util.getTemporaryDirectBuffer(TRANSFER_SIZE); try { for (int r = ch.read(bb); r > -1; r = ch.read(bb)) { bb.flip(); while (bb.hasRemaining()) oc.write(bb); bb.clear(); i += r; } return i; } finally { Util.releaseTemporaryDirectBuffer(bb); } } } else { return super.transferTo(out); } ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From naoto at openjdk.java.net Thu Jun 17 20:17:30 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 17 Jun 2021 20:17:30 GMT Subject: [jdk17] RFR: 8265073: XML transformation and indentation when using xml:space In-Reply-To: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> References: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> Message-ID: On Thu, 17 Jun 2021 16:13:49 GMT, Joe Wang wrote: > The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it. Looks good overall. Some minor comments in the test. test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java line 206: > 204: * source and expected output > 205: */ > 206: @DataProvider(name = "preserveSpace") You would not need the name, since the default name is the DataProvider method name. test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java line 207: > 205: */ > 206: @DataProvider(name = "preserveSpace") > 207: public Object[][] preserveSpace() throws Exception { `throws Exception` may be eliminated. test/jaxp/javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java line 220: > 218: * @param xml the source > 219: * @param expected the expected result > 220: * @throws Exception if the test fails `Exception` is thrown from `transform` method. So the description is not wrong, but it may imply the objective of this test failed, i.e. the result of `assertEquals()`. ------------- PR: https://git.openjdk.java.net/jdk17/pull/89 From sviswanathan at openjdk.java.net Thu Jun 17 20:35:29 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 17 Jun 2021 20:35:29 GMT Subject: [jdk17] RFR: 8266518: Refactor and expand scatter/gather tests [v2] In-Reply-To: References: Message-ID: <54WNqQW1KmZDdIfdzKHQeHXyBv6y1yUFyy37U1DapNs=.ce97e868-8f64-46b5-a662-9f78cba64b77@github.com> On Thu, 17 Jun 2021 15:09:17 GMT, Paul Sandoz wrote: >> Refactor scatter/gather tests to be included in the load/store test classes and expand to support access between `ShortVector` and and `char[]`, and access between `ByteVector` and `boolean[]`. >> >> Vector tests pass on linux-x64 linux-aarch64 macosx-x64, and windows-x64. > > Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundatem data providers. Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk17/pull/48 From mcimadamore at openjdk.java.net Thu Jun 17 21:24:39 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 17 Jun 2021 21:24:39 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v2] In-Reply-To: References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com> On Thu, 17 Jun 2021 18:33:56 GMT, Jan Lahoda wrote: >> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding. >> >> How does this look? > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Creating a new bootstrap method for (pattern matching) enum switches, as suggested. Very good piece of work. I like all the code that can be removed because of this. I assume that the new code only kicks in if there's at least a pattern in the switch, otherwise we fallback to legacy translation (meaning that compiling with source < 17 is still ok), right? I left some comments to help and clarify the javadoc text of the enum BSM. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 173: > 171: > 172: /** > 173: * Bootstrap method for linking an {@code invokedynamic} call site that This should be made clearer - e.g. the first argument is of type `Class` and represents the enum we want to switch on. The remaining constants should be of type `String`, the names of the various constants. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 178: > 176: * {@code String} (representing enum constants) or {@code Class}. > 177: *

    > 178: * The type of the returned {@code CallSite}'s method handle will have Suggestion: * The returned {@code CallSite}'s method handle will have src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 179: > 177: *

    > 178: * The type of the returned {@code CallSite}'s method handle will have > 179: * a return type of {@code int}. It has two parameters: the first argument Suggestion: * a return type of {@code int}. It has two parameters: the first argument Suggestion: * a return type of {@code int} and accepts two parameters: the first argument test/langtools/tools/javac/patterns/EnumTypeChanges.java line 80: > 78: A, > 79: B; > 80: } missing newline here test/langtools/tools/javac/patterns/EnumTypeChanges2.java line 27: > 25: A, > 26: C; > 27: } missing newline here ------------- PR: https://git.openjdk.java.net/jdk17/pull/81 From forax at openjdk.java.net Thu Jun 17 21:59:31 2021 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 17 Jun 2021 21:59:31 GMT Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch should be improved [v2] In-Reply-To: References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com> Message-ID: On Thu, 17 Jun 2021 18:33:56 GMT, Jan Lahoda wrote: >> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding. >> >> How does this look? > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Creating a new bootstrap method for (pattern matching) enum switches, as suggested. src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 222: > 220: String invocationName, > 221: MethodType invocationType, > 222: Object... labels) throws Throwable { Is it not better to take a Class and a String... as separated parameters instead of taking Object... and doing the conversion to a Class and an array of String later in Java src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 238: > 236: MethodHandle target = > 237: MethodHandles.insertArguments(DO_ENUM_SWITCH, 2, (Object) labels); > 238: target = MethodHandles.explicitCastArguments(target, invocationType); why explicitCast is used here instead of the classical cast asType() ? ------------- PR: https://git.openjdk.java.net/jdk17/pull/81 From joehw at openjdk.java.net Thu Jun 17 22:03:46 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 17 Jun 2021 22:03:46 GMT Subject: [jdk17] RFR: 8265073: XML transformation and indentation when using xml:space [v2] In-Reply-To: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> References: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> Message-ID: <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> > The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: Thanks Naoto. Updated accordingly. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/89/files - new: https://git.openjdk.java.net/jdk17/pull/89/files/509a101c..32ba04d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=89&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=89&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/89.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/89/head:pull/89 PR: https://git.openjdk.java.net/jdk17/pull/89 From lancea at openjdk.java.net Thu Jun 17 22:15:29 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 17 Jun 2021 22:15:29 GMT Subject: [jdk17] RFR: 8265073: XML transformation and indentation when using xml:space [v2] In-Reply-To: <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> References: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> Message-ID: On Thu, 17 Jun 2021 22:03:46 GMT, Joe Wang wrote: >> The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > Thanks Naoto. Updated accordingly. Looks fine. I still add the DataProvider name out of habit myself even though it is always the same as the method names for me (some habits are hard to break) ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/89 From joehw at openjdk.java.net Thu Jun 17 22:22:29 2021 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 17 Jun 2021 22:22:29 GMT Subject: [jdk17] RFR: 8265073: XML transformation and indentation when using xml:space [v2] In-Reply-To: <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> References: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> Message-ID: On Thu, 17 Jun 2021 22:03:46 GMT, Joe Wang wrote: >> The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > Thanks Naoto. Updated accordingly. Thanks Lance. Indeed, me too. So this is the first without the name parameter :-) ------------- PR: https://git.openjdk.java.net/jdk17/pull/89 From naoto at openjdk.java.net Thu Jun 17 22:22:28 2021 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 17 Jun 2021 22:22:28 GMT Subject: [jdk17] RFR: 8265073: XML transformation and indentation when using xml:space [v2] In-Reply-To: <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> References: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> Message-ID: On Thu, 17 Jun 2021 22:03:46 GMT, Joe Wang wrote: >> The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > Thanks Naoto. Updated accordingly. Looks good. Thanks for the fix! ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/89 From iris at openjdk.java.net Thu Jun 17 22:54:24 2021 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 17 Jun 2021 22:54:24 GMT Subject: [jdk17] RFR: 8265073: XML transformation and indentation when using xml:space [v2] In-Reply-To: <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> References: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com> <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com> Message-ID: On Thu, 17 Jun 2021 22:03:46 GMT, Joe Wang wrote: >> The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > Thanks Naoto. Updated accordingly. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/89 From jwilhelm at openjdk.java.net Thu Jun 17 23:34:36 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 17 Jun 2021 23:34:36 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8268371: C2: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed - 8268676: assert(!ik->is_interface() && !ik->has_subklass()) failed: inconsistent klass hierarchy - 8268265: MutableSpaceUsedHelper::take_sample() hits assert(left >= right) failed: avoid overflow - 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64 - 8264843: Javac crashes with NullPointerException when finding unencoded XML in 

     tag
 - 8265297: javax/net/ssl/SSLSession/TestEnabledProtocols.java failed with "RuntimeException: java.net.SocketException: Connection reset"
 - 8268353: Test libsvml.so is and is not present in jdk image
 - 8249899: jdk/javadoc/tool/InlineTagsWithBraces.java uses @ignore w/o bug-id
 - 8268776: Test `ADatagramSocket.java` missing /othervm from @run tag
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/bb24fa65...a3951c44

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4525/files
  Stats: 845 lines in 26 files changed: 408 ins; 384 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4525.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4525/head:pull/4525

PR: https://git.openjdk.java.net/jdk/pull/4525

From joehw at openjdk.java.net  Fri Jun 18 00:56:27 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 18 Jun 2021 00:56:27 GMT
Subject: [jdk17] RFR: 8265073: XML transformation and indentation when
 using xml:space [v2]
In-Reply-To: <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com>
References: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com>
 <-BODC808-hcdwRzY2MrjN5lT70hDatrIp21mK-sfhdA=.2422429a-8c06-4a55-95f5-a2879866cee6@github.com>
Message-ID: <23fXFJlWdt5QJoHr5_Fx-evdUvAAyquYisU-I_fCclE=.a1f96c3b-fa03-4b40-9107-639c614bad17@github.com>

On Thu, 17 Jun 2021 22:03:46 GMT, Joe Wang  wrote:

>> The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thanks Naoto. Updated accordingly.

Thanks Iris.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/89

From jwilhelm at openjdk.java.net  Fri Jun 18 00:56:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 00:56:32 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 23:26:26 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: a051e735
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/a051e735cda0d5ee5cb6ce0738aa549a7319a28c
Stats:     845 lines in 26 files changed: 408 ins; 384 del; 53 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4525

From peter.firmstone at zeus.net.au  Fri Jun 18 03:18:02 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 18 Jun 2021 13:18:02 +1000
Subject: JEP 411: Deprecation with removal would break most existing Java
 libraries
In-Reply-To: 
References: 
 <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com>
 <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au>
 
 
 
Message-ID: 


On 16/06/2021 11:18 pm, David Lloyd wrote:
> On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
>  wrote:
>
>> Permission references can be replaced with Guard references (which
>> Permissions are instances of).
> I guess you've got something fairly complex in mind, could you give
> some practical examples of how this would work?


The same service provider mechanism encryption uses.? So implementation 
may utilize authorization access check points without any dependencies 
on current SecurityManager, Policy or Permission API's.

It's completely up to the implementation to determine how to manage.


>
>> The Permission implementations of Guard::check call SecurityManager, so
>> checks will continue working as expected, but it allows us to intercept
>> them and do something different.
> What do you envision these checks looking like?  Where would the JDK
> find these Guard instances?


GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");

Guard localhostConnectAccept = socketGuardFactory.orders("localhost", 
"connect,accept");

// Permission check

localHostConnectAccept.check();



GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");

Guard createClassLoader = 
runtimeGuardFactory.orders("createClassLoader", null);

// Permission check

createClassLoader.check();

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.


From myano at openjdk.java.net  Fri Jun 18 04:56:06 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 18 Jun 2021 04:56:06 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
> Could you please review the 8268457 bug fixes?
> 
> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
> This fix changes the processing for non-surrogate pairs to the else condition.

Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:

  Reflect the review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4474/files
  - new: https://git.openjdk.java.net/jdk/pull/4474/files/81975b58..d5792a87

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4474&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4474&range=00-01

  Stats: 266 lines in 8 files changed: 104 ins; 160 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4474.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4474/head:pull/4474

PR: https://git.openjdk.java.net/jdk/pull/4474

From myano at openjdk.java.net  Fri Jun 18 04:56:07 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 18 Jun 2021 04:56:07 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano  wrote:

> Hi all,
> 
> Could you please review the 8268457 bug fixes?
> 
> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
> This fix changes the processing for non-surrogate pairs to the else condition.

Thank you for reviewing. I reflected the review comments to my change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From yyang at openjdk.java.net  Fri Jun 18 05:54:05 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 05:54:05 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: 

On Thu, 17 Jun 2021 10:19:43 GMT, Alan Bateman  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 471:
> 
>> 469:      */
>> 470:     public int offsetByCodePoints(int index, int codePointOffset) {
>> 471:         checkOffset(index, count);
> 
> String.offsetByCodePoints is specified to throw IOOBE. checkOffset may throw the more specific StringIndexOutOfBoundsException. That's a compatible change but I worry that we might want to throw the less specific exception in the future. I only mention it because there have been cases in java.lang where IOOBE was specified and AIOOBE by the implementation and it has been problematic to touch the implementation as a result.

Yes, changing the type of thrown exception may break something. And as David said, this also requires a CSR approval, which is a relatively long process, so I restored the original code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Fri Jun 18 05:54:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 05:54:01 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  restore IndexOfOufBoundsException; split exception line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/593bf995..ec0a4d44

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=00-01

  Stats: 30 lines in 8 files changed: 15 ins; 2 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Fri Jun 18 06:10:27 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 06:10:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: 

On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore IndexOfOufBoundsException; split exception line

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [serviceability-dev](mailto:serviceability-dev at mail.openjdk.java.net):_
> 
> On 17/06/2021 8:50 pm, Alan Bateman wrote:
> 
> > On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes  wrote:
> > > There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them. If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
> > 
> > 
> > It would be good to run tier 1-3. Off hand I can't think of any tests that are dependent on the exception message, I think I'm more concerned about changing behavior (once you throw a more specific IOOBE is some of the very core classes then it's hard to change it because libraries get dependent on the more specific exception).
> 
> tiers 1-3 on Linux-x64 passed okay.
> 
> Any change to the exact type of exception thrown should be affirmed
> through a CSR request.
> 
> Cheers,
> David

Thank you David for running these tests!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Fri Jun 18 06:10:27 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 18 Jun 2021 06:10:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 <3vZDbR7Mvc1q5evU7jG0IkHSoL9gJArATqeUDPnZxfw=.256faaf6-8f80-4e36-8ccf-555c1fd63d2a@github.com>
Message-ID: <_doEJsq2BCo-Bkj8aoB6EemEkhPS-eTcr_Zq8NIf0qM=.012d8685-d7eb-4133-bdf7-9366ee394004@github.com>

On Thu, 17 Jun 2021 15:45:47 GMT, Paul Sandoz  wrote:

>> src/java.base/share/classes/java/util/Base64.java line 934:
>> 
>>> 932:             if (closed)
>>> 933:                 throw new IOException("Stream is closed");
>>> 934:             Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException());
>> 
>> You might want to split this really long line too, to avoid inconsistent line length in this source file.
>
> I would suggest factoring out `(xa, xb) -> new ArrayIndexOutOfBoundsException()` as a reusable component on `Preconditions`, and maybe even supplying an exception message (since it is rather useful, and way better than no message).
> 
> See the usages of `Preconditions.outOfBoundsExceptionFormatter` (where there just happens to be many repeated cases of supplying AIOOBE with a message, that could also be consolidated, separate fix perhaps).

Ok, I've replaced

Preconditions.checkFromIndexSize(len, off, b.length, (xa, xb) -> new ArrayIndexOutOfBoundsException());

with 

Preconditions.checkFromIndexSize(len, off, b.length,
    Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));


----

I am curious about the motivations of current APIs:

public static 
int checkIndex(int index, int length,
               BiFunction, X> oobef) {
    if (index < 0 || index >= length)
        throw outOfBoundsCheckIndex(oobef, index, length);
    return index;
}

Are they over-engineered? When I checked all checkIndex-like patterns in the whole jdk codebase, I found that in most cases, providing an API that accepts custom exception should be enough for scalability:

int checkIndex(int index, int length, IndexOutOfBoundException iooe) {
    if (index < 0 || index >= length)
        throw iooe;
    return index;
}

In addition to the ease-of-use problem, there is another problem with the current API design.

Some methods in j.l.String are good replacement candidates for Preconditions.check{Index,...}:

https://github.com/openjdk/jdk/blob/a051e735cda0d5ee5cb6ce0738aa549a7319a28c/src/java.base/share/classes/java/lang/String.java#L4558-L4604

But we **can not** do such replacement after my practice.

The third parameter of Preconditions.checkIndex is a BiFunction, which can be passed a lambda as its argument. The generated lambda method exercises many other codes like MethodHandles, j.l.Package, etc, eventually it called j.l.String.checkIndex itself, so if we replace j.l.String.checkIndex with `Preconditions.checkIndex(a,b,(x1,x2)->....)`, a StackOverflowError would occur at VM startup. 

If there is an API that accepts user-defined exceptions, I think we can apply Preconditions in more places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From github.com+1701815+mkarg at openjdk.java.net  Fri Jun 18 08:23:27 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Fri, 18 Jun 2021 08:23:27 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 17 Jun 2021 20:08:08 GMT, Michael Bien  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?
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 216:
> 
>> 214:         }
>> 215: 
>> 216:         return super.transferTo(out);
> 
> (i am no reviewer)
> wouldn't this method be more intuitive if it wouldn't try to avoid using "else if" and "else"? If there are sequential if blocks with return in them, part of me is always trying to find the fall-through scenario, but in this case its all distinct code paths. Using branches would make that obvious + if there would be a fall through in future, the compiler would generate a "missing return" error right away. 
> 
> example:
> 
>         if (out instanceof ChannelOutputStream cos) {
>             
>             WritableByteChannel oc = cos.channel();
>             long i = 0L;
> 
>             if (ch instanceof FileChannel fc) {
>                 
>                 long pos = fc.position();
>                 long size = fc.size();
>                 try {
>                     for (long n = size - pos; i < n;)
>                         i += fc.transferTo(pos + i, Long.MAX_VALUE, oc);
>                     return i;
>                 } finally {
>                     fc.position(pos + i);
>                 }
>                 
>             } else if (oc instanceof FileChannel fc) {
>                 
>                 long fcpos = fc.position();
> 
>                 if (ch instanceof SeekableByteChannel sbc) {
>                     
>                     long pos = sbc.position();
>                     long size = sbc.size();
>                     try {
>                         for (long n = size - pos; i < n;)
>                             i += fc.transferFrom(ch, fcpos + i, Long.MAX_VALUE);
>                         return i;
>                     } finally {
>                         fc.position(fcpos + i);
>                     }
>                     
>                 } else {
>                     
>                     ByteBuffer bb = Util.getTemporaryDirectBuffer(TRANSFER_SIZE);
>                     try {
>                         int r;
>                         do {
>                             i += fc.transferFrom(ch, fcpos + i, Long.MAX_VALUE);
>                             r = ch.read(bb); // detect end-of-stream
>                             if (r > -1) {
>                                 bb.flip();
>                                 while (bb.hasRemaining())
>                                     oc.write(bb);
>                                 bb.clear();
>                                 i += r;
>                             }
>                         } while (r > -1);
>                         return i;
>                     } finally {
>                         fc.position(fcpos + i);
>                         Util.releaseTemporaryDirectBuffer(bb);
>                     }
>                 }
> 
>             } else {
>                 
>                 ByteBuffer bb = Util.getTemporaryDirectBuffer(TRANSFER_SIZE);
>                 try {
>                     for (int r = ch.read(bb); r > -1; r = ch.read(bb)) {
>                         bb.flip();
>                         while (bb.hasRemaining())
>                             oc.write(bb);
>                         bb.clear();
>                         i += r;
>                     }
>                     return i;
>                 } finally {
>                     Util.releaseTemporaryDirectBuffer(bb);
>                 }
>             }
>         } else {
>             return super.transferTo(out);
>         }

This is just about personal likes and dislikes. In fact, there is no "missing" case at all as this is not about "there must be THIS solution OR that solution", but this is just about doing "the standard case" vs. doing optimizations "if applicable" -- which is a different semantic. I personally dislike your proposal as it makes the code overly cluttered and hard to read. No other reviewer wanted it that way. So until a majority of reviewers actually wants me to clutter the code with else cases, I'd rather abstain from your proposal.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From jlahoda at openjdk.java.net  Fri Jun 18 09:03:30 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Jun 2021 09:03:30 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>
Message-ID: 

On Thu, 17 Jun 2021 21:03:58 GMT, Maurizio Cimadamore  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 173:
> 
>> 171: 
>> 172:     /**
>> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
> 
> This should be made clearer - e.g. the first argument is of type `Class` and represents the enum we want to switch on. The remaining constants should be of type `String`, the names of the various constants.

That is not quite what the labels represent. The target Enum type is inferred from the bootstrap method's invocation MethodType. (Alternatively, we can add a new Class parameter to the bootstrap method.)

For the labels, please consider this switch:

         E sel = null;
         switch (sel) {
             case A -> {}
             case E e && "B".equals(e.name()) -> {}
             case C -> {}
             case E e -> {}
         }


The patterns and the constants are mixed, and the order needs to be represented somehow in the labels array, so that the switch will classify the input correctly. The method in this proposal will use `{"A", E.class, "C", E.class}` as the labels array (which is mostly consistent with the `typeSwitch` method), but we could use different encodings if needed.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From jlahoda at openjdk.java.net  Fri Jun 18 09:11:26 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Jun 2021 09:11:26 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
Message-ID: 

On Thu, 17 Jun 2021 21:56:21 GMT, R?mi Forax  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 222:
> 
>> 220:                                       String invocationName,
>> 221:                                       MethodType invocationType,
>> 222:                                       Object... labels) throws Throwable {
> 
> Is it not better to take a Class and a String... as separated parameters instead of taking Object... and doing the conversion to a Class and an array of String later in Java

This is to represent cases like:

         E sel = null;
         switch (sel) {
             case A -> {}
             case E e && "B".equals(e.name()) -> {}
             case C -> {}
             case E e -> {}
         }


The method needs to know which cases represent constants and which represent patterns (even though the primary type of all the patterns will be the enum type), so we cannot easily put the `Class` first (or elide it), and then a `String...`, unless we represent the patterns in the `String...` array somehow.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From jlahoda at openjdk.java.net  Fri Jun 18 09:14:31 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Jun 2021 09:14:31 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 <2h5cKY6Dcez1aTsH9d9NoJ-4vMBYTrCoPCKz-JkcV8o=.ecfd36ec-afef-4484-9cb9-e54cffc6881e@github.com>
Message-ID: 

On Thu, 17 Jun 2021 21:21:14 GMT, Maurizio Cimadamore  wrote:

> Very good piece of work. I like all the code that can be removed because of this.

Thanks!

> 
> I assume that the new code only kicks in if there's at least a pattern in the switch, otherwise we fallback to legacy translation (meaning that compiling with source < 17 is still ok), right?

Yes, it is only for pattern matching switches. Traditional switches are still desugared in the way they were.

> 
> I left some comments to help and clarify the javadoc text of the enum BSM.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From forax at openjdk.java.net  Fri Jun 18 09:50:28 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 18 Jun 2021 09:50:28 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
 
Message-ID: 

On Fri, 18 Jun 2021 09:08:04 GMT, Jan Lahoda  wrote:

>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 222:
>> 
>>> 220:                                       String invocationName,
>>> 221:                                       MethodType invocationType,
>>> 222:                                       Object... labels) throws Throwable {
>> 
>> Is it not better to take a Class and a String... as separated parameters instead of taking Object... and doing the conversion to a Class and an array of String later in Java
>
> This is to represent cases like:
> 
>          E sel = null;
>          switch (sel) {
>              case A -> {}
>              case E e && "B".equals(e.name()) -> {}
>              case C -> {}
>              case E e -> {}
>          }
> 
> 
> The method needs to know which cases represent constants and which represent patterns (even though the primary type of all the patterns will be the enum type), so we cannot easily put the `Class` first (or elide it), and then a `String...`, unless we represent the patterns in the `String...` array somehow.

Ok got it,
At some point, we will have to represent patterns either as String and parse them or as Condy of condy if we want a more structured recursive way.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From avoitylov at openjdk.java.net  Fri Jun 18 09:58:12 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 18 Jun 2021 09:58:12 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and JNI
 FindClass loading another class
Message-ID: 

Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.

This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.

Further details can be found in the original PR.

Testing: jtreg and jck testing with no regressions. A new regression test was developed.

-------------

Commit messages:
 - JDK-8266310: deadlock between System.loadLibrary and JNI FindClass loading another class

Changes: https://git.openjdk.java.net/jdk17/pull/96/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=96&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266310
  Stats: 913 lines in 10 files changed: 894 ins; 1 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/96.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/96/head:pull/96

PR: https://git.openjdk.java.net/jdk17/pull/96

From jlahoda at openjdk.java.net  Fri Jun 18 13:23:57 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Jun 2021 13:23:57 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v3]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
> 
> How does this look?

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Updating javadoc, code and tests as suggested.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/4e1977a7..06a1bebf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=01-02

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

PR: https://git.openjdk.java.net/jdk17/pull/81

From alanb at openjdk.java.net  Fri Jun 18 13:36:31 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 18 Jun 2021 13:36:31 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo
In-Reply-To: 
References: 
Message-ID: 

On Sun, 30 May 2021 17:30:56 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?

Adding an override of transferTo may require new tests. @bplb Do you if we have good tests for all the scenarios where input stream returned by Channels.newInputStream is the source?

I think we also need to decide if this PR is about Channels.newInputStream or the input stream return by Files.newInputStream as the latter could return its own input stream implementation, it doesn't need to ChannelInputStream.

If the approach on the table goes ahead then ChannelInputStream.transferTo can be split into 4 simple methods to make it easier to maintain. You can use something like "total" or "bytesWritten" for the total number of bytes written rather than "i".

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From psandoz at openjdk.java.net  Fri Jun 18 14:25:27 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 18 Jun 2021 14:25:27 GMT
Subject: [jdk17] Integrated: 8266518: Refactor and expand scatter/gather tests
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Jun 2021 16:26:17 GMT, Paul Sandoz  wrote:

> Refactor scatter/gather tests to be included in the load/store test classes and expand to support access between `ShortVector` and and `char[]`, and access between `ByteVector` and `boolean[]`.
> 
> Vector tests pass on linux-x64 linux-aarch64 macosx-x64, and windows-x64.

This pull request has now been integrated.

Changeset: dab00ee5
Author:    Paul Sandoz 
URL:       https://git.openjdk.java.net/jdk17/commit/dab00ee59b73bcd5b8632d127b3d0a324e48e4e5
Stats:     11673 lines in 72 files changed: 6367 ins; 5271 del; 35 mod

8266518: Refactor and expand scatter/gather tests

Reviewed-by: sviswanathan

-------------

PR: https://git.openjdk.java.net/jdk17/pull/48

From mcimadamore at openjdk.java.net  Fri Jun 18 14:29:31 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 18 Jun 2021 14:29:31 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v2]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
 
 
Message-ID: 

On Fri, 18 Jun 2021 09:47:29 GMT, R?mi Forax  wrote:

>> This is to represent cases like:
>> 
>>          E sel = null;
>>          switch (sel) {
>>              case A -> {}
>>              case E e && "B".equals(e.name()) -> {}
>>              case C -> {}
>>              case E e -> {}
>>          }
>> 
>> 
>> The method needs to know which cases represent constants and which represent patterns (even though the primary type of all the patterns will be the enum type), so we cannot easily put the `Class` first (or elide it), and then a `String...`, unless we represent the patterns in the `String...` array somehow.
>
> Ok got it,
> At some point, we will have to represent patterns either as String and parse them or as Condy of condy if we want a more structured recursive way.

Of course - I missed it! Thanks for the explanation.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From mcimadamore at openjdk.java.net  Fri Jun 18 14:40:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 18 Jun 2021 14:40:38 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v3]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: 

On Fri, 18 Jun 2021 13:23:57 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating javadoc, code and tests as suggested.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:

> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
> 174:      * implements a {@code switch} on a target of an enum type.  The static
> 175:      * arguments are an array of case labels which must be non-null and of type

This sentence can still be improved and made cleared. Example:

> The static arguments are used to encode the case labels associated to the `switch` construct, where each label can be encoded as a `String` (e.g. to represent an enum constant), or, alternatively, as a `Class` (e.g. to represent a type test pattern whose type is an enum type).

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 179:

> 177:      * 
    
> 178:      * The returned {@code CallSite}'s method handle will have
> 179:      * a return type of {@code int} and accepts two parameters: the first argument

By writing the javadoc text above, it came to mind that, perhaps, some validation is in order for the static arguments. For instance:

* the enum type of a Class parameter doesn't match that of the BSM
* the static arguments contain more than one Class parameter (I think even if they are all of the same "correct" type, that's bogus, right?)

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From joehw at openjdk.java.net  Fri Jun 18 16:06:31 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 18 Jun 2021 16:06:31 GMT
Subject: [jdk17] Integrated: 8265073: XML transformation and indentation when
 using xml:space
In-Reply-To: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com>
References: <0SDoIF-ln2vf56zUyZlPjdGofF0HwvvdmvqG7jcDzZk=.06caf17c-ef80-4de2-a847-195a553d3091@github.com>
Message-ID: <0LfmuzI8q6gZy833cG7dgBNXh-bF9oxmXjOT1V6gHpo=.0dd0c30f-57ab-4a6d-9903-674b6db47dce@github.com>

On Thu, 17 Jun 2021 16:13:49 GMT, Joe Wang  wrote:

> The issue was that the attribute was processed before the variable was set (e.g. m_preserveSpaces.push). Reversing the order fixed it.

This pull request has now been integrated.

Changeset: 7e03cf29
Author:    Joe Wang 
URL:       https://git.openjdk.java.net/jdk17/commit/7e03cf2916a69f947c46ac85b222ee7a99f68ad8
Stats:     60 lines in 2 files changed: 52 ins; 6 del; 2 mod

8265073: XML transformation and indentation when using xml:space

Reviewed-by: naoto, lancea, iris

-------------

PR: https://git.openjdk.java.net/jdk17/pull/89

From mchung at openjdk.java.net  Fri Jun 18 16:51:30 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 18 Jun 2021 16:51:30 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:

> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
> 
> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Further details can be found in the original PR.
> 
> Testing: jtreg and jck testing with no regressions. A new regression test was developed.

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/96

From jbhateja at openjdk.java.net  Fri Jun 18 17:13:53 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 18 Jun 2021 17:13:53 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 8 Jun 2021 10:29:44 GMT, Jatin Bhateja  wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | --
>> ? | ? | ? | ? | ? | ? | ? | ? | ?
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
>> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
>> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
>> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
>> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
>> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
>> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>  - 8266054: Removing redundant teat templates.
>  - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform.
>  - 8266054: Removing redundant test templates.
>  - 8266054: Review comments resolution.
>  - 8266054: Review comments resolution.
>  - 8266054: Review comments resolution.
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/61ab4b9d...debb09f2

Hi @iwanowww, @neliasso , kindly review compiler side changes and share your feedback.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From brian.burkhalter at oracle.com  Fri Jun 18 17:30:49 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 18 Jun 2021 17:30:49 +0000
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo
In-Reply-To: 
References: 
 
Message-ID: 


On Jun 18, 2021, at 6:36 AM, Alan Bateman > wrote:

Adding an override of transferTo may require new tests. @bplb Do you if we have good tests for all the scenarios where input stream returned by Channels.newInputStream is the source?

There are not a lot of tests for the `InputStream` returned by `Channels.newInputStream`:

 `java/nio/channels/Channels`:

`Basic.java` - reading from a wrapped `FileChannel`
`ReadByte.java` - trivial
`Basic2.java` - reading at random offsets from a wrapped `AsynchronousSocketChannel`
`ReadOffset.java` - trivial

Elsewhere:

`sun/nio/ch/TempBuffer.java`
`jdk/nio/zipfs/ZipFSTester.java`


I don?t see that `transferTo()` on such a stream is tested anywhere.

From psandoz at openjdk.java.net  Fri Jun 18 18:23:33 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 18 Jun 2021 18:23:33 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: 

On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore IndexOfOufBoundsException; split exception line

@kahatlen for cases earlier in VM startup you need to avoid method references and lambda expressions. See the implementation of `outOfBoundsExceptionFormatter`, and see the usage in `VarHandle` for two examples.

Custom exception formaters should ideally be constants held in static final fields.

I think the API complexity comes down to whether it is necessary to preserve existing exception messages or not when converting existing code to use the precondition methods. The API is designed to do that and composes reasonably well for default exception messages with a non-default exceptions. We could argue (i would!) it is preferable to have a consistent exception messages for index out of bounds exceptions, thereby we could collapse and simplify, but this is sometimes considered a change in behaviour.

src/java.base/share/classes/java/util/Base64.java line 935:

> 933:                 throw new IOException("Stream is closed");
> 934:             Preconditions.checkFromIndexSize(len, off, b.length,
> 935:                 Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));

`outOfBoundsExceptionFormatter` will allocate. Store the result of `Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new))` in a public static final on `Preconditions`, and replace the method ref with a inner class (thereby making it usable earlier at VM startup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From mullan at openjdk.java.net  Fri Jun 18 18:31:32 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 18 Jun 2021 18:31:32 GMT
Subject: RFR: 8268873: Unnecessary Vector usage in java.base
In-Reply-To: 
References: 
Message-ID: <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com>

On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov  wrote:

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.
> I checked only places where `Vector` was used as local variable.

The change to `PKCS7::verify(byte[])` looks fine.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4482

From naoto at openjdk.java.net  Fri Jun 18 20:33:47 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 18 Jun 2021 20:33:47 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Jun 2021 04:56:06 GMT, Masanori Yano  wrote:

>> Hi all,
>> 
>> Could you please review the 8268457 bug fixes?
>> 
>> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
>> This fix changes the processing for non-surrogate pairs to the else condition.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect the review comments

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java line 1454:

> 1452:                     writer.write(ch);  // no escaping in this case
> 1453:                     }
> 1454:                     else

I was suggesting removing the entire comment-out block if it is not needed (and confusing), but I will defer the decision to Joe.

test/jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest1.xml line 4:

> 2: 
> 3:     ??
> 4: 

Add a new line at the end of the file (and other newly created files too).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From joehw at openjdk.java.net  Fri Jun 18 21:12:31 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 18 Jun 2021 21:12:31 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <9Yr6xab5AYv8lh3HLpoX-F0mmIS1HPSq_Mos6S9AQ4g=.0cdbf2b7-7693-4bc6-b978-23e5710c1f01@github.com>

On Fri, 18 Jun 2021 20:27:13 GMT, Naoto Sato  wrote:

>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect the review comments
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java line 1454:
> 
>> 1452:                     writer.write(ch);  // no escaping in this case
>> 1453:                     }
>> 1454:                     else
> 
> I was suggesting removing the entire comment-out block if it is not needed (and confusing), but I will defer the decision to Joe.

I agree. It's very obsolete. The comment-out block from line 1445 to 1454 can be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From github.com+6704669+asgibbons at openjdk.java.net  Fri Jun 18 22:12:11 2021
From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons)
Date: Fri, 18 Jun 2021 22:12:11 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
> 
> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
> 
> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
> 
> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
> 
> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
> 
> 
> Benchmark Name | Base Score | Optimized Score | Gain
> -- | -- | -- | --
> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Added comments.  Streamlined flow for decode.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4368/files
  - new: https://git.openjdk.java.net/jdk/pull/4368/files/247f2245..bb73df6c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=03-04

  Stats: 44 lines in 1 file changed: 18 ins; 10 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4368.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368

PR: https://git.openjdk.java.net/jdk/pull/4368

From jwilhelm at openjdk.java.net  Fri Jun 18 22:26:34 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 22:26:34 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8268316: Typo in JFR jdk.Deserialization event
 - 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
 - 8264775: ClhsdbFindPC still fails with java.lang.RuntimeException: 'In java stack' missing from stdout/stderr
 - 8265073: XML transformation and indentation when using xml:space
 - 8269025: jsig/Testjsig.java doesn't check exit code
 - 8266518: Refactor and expand scatter/gather tests
 - 8268903: JFR: RecordingStream::dump is missing @since
 - 8265369: [macos-aarch64] java/net/MulticastSocket/Promiscuous.java failed with "SocketException: Cannot allocate memory"
 - 8268564: mark hotspot serviceability/attach tests which ignore external VM flags
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/8f2456e5...ed622f4b

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4533/files
  Stats: 12229 lines in 119 files changed: 6768 ins; 5337 del; 124 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4533.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4533/head:pull/4533

PR: https://git.openjdk.java.net/jdk/pull/4533

From bchristi at openjdk.java.net  Fri Jun 18 22:27:32 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 18 Jun 2021 22:27:32 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters
In-Reply-To: 
References: 
Message-ID: <8nK2uA1BpLC81RwoCfxmR_xusQN9BDRF7Z9FH46PkAg=.4cadd8f5-bb23-4df1-ad17-7f221130c969@github.com>

On Wed, 16 Jun 2021 20:22:17 GMT, Roger Riggs  wrote:

> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.

OVERRIDE is also mentioned in `src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security`

-------------

Changes requested by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/85

From duke at openjdk.java.net  Fri Jun 18 22:46:38 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 18 Jun 2021 22:46:38 GMT
Subject: Withdrawn: 8200559: Java agents doing instrumentation need a means to
 define auxiliary classes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 16 Apr 2021 13:44:16 GMT, Rafael Winterhalter  wrote:

> To allow agents the definition of auxiliary classes, an API is needed to allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed from `sun.misc.Unsafe`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3546

From asemenyuk at openjdk.java.net  Fri Jun 18 22:54:52 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 18 Jun 2021 22:54:52 GMT
Subject: RFR: 8268974: jpackage fails to handle --dest option containing "bin"
 folder
Message-ID: 

GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

-------------

Commit messages:
 - 8268974: jpackage fails to handle --dest option containing "bin" folder

Changes: https://git.openjdk.java.net/jdk/pull/4534/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4534&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268974
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4534.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4534/head:pull/4534

PR: https://git.openjdk.java.net/jdk/pull/4534

From almatvee at openjdk.java.net  Fri Jun 18 23:08:31 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 18 Jun 2021 23:08:31 GMT
Subject: RFR: 8268974: jpackage fails to handle --dest option containing
 "bin" folder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk  wrote:

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4534

From jwilhelm at openjdk.java.net  Fri Jun 18 23:08:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 23:08:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:

 - Merge
 - 8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header
   
   Co-authored-by: Chris Cole 
   Reviewed-by: dsamersoff
 - 8268964: Remove unused ReferenceProcessorAtomicMutator
   
   Reviewed-by: tschatzl, pliden
 - 8268900: com/sun/net/httpserver/Headers.java: Fix indentation and whitespace
   
   Reviewed-by: dfuchs, chegar, michaelm
 - Merge
 - 8268678: LetsEncryptCA.java test fails as Let?s Encrypt Authority X3 is retired
   
   Reviewed-by: xuelei
 - 8267189: Remove duplicated unregistered classes from dynamic archive
   
   Reviewed-by: ccheung, minqi
 - 8268638: semaphores of AsyncLogWriter may be broken when JVM is exiting.
   
   Reviewed-by: dholmes, phh
 - 8268556: Use bitmap for storing regions that failed evacuation
   
   Reviewed-by: kbarrett, iwalulya, sjohanss
 - 8268294: Reusing HttpClient in a WebSocket.Listener hangs.
   
   Reviewed-by: dfuchs
 - ... and 36 more: https://git.openjdk.java.net/jdk/compare/b8f073be...ed622f4b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4533/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4533&range=01
  Stats: 8681 lines in 159 files changed: 7992 ins; 386 del; 303 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4533.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4533/head:pull/4533

PR: https://git.openjdk.java.net/jdk/pull/4533

From jwilhelm at openjdk.java.net  Fri Jun 18 23:08:36 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 18 Jun 2021 23:08:36 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: <2lNbBvRChZKSawaU5THoDLfbazhJcqIyt1V_Ew-3kNY=.f7fb1cfd-ecda-4fd3-874d-311a6d8362b9@github.com>

On Fri, 18 Jun 2021 22:17:41 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b7d78a5b
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/b7d78a5b661e2b00f271298db3b6cc873cf754e7
Stats:     12229 lines in 119 files changed: 6768 ins; 5337 del; 124 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4533

From sviswanathan at openjdk.java.net  Sat Jun 19 00:49:38 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 19 Jun 2021 00:49:38 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Jun 2021 22:12:11 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comments.  Streamlined flow for decode.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6004:

> 6002:       __ BIND(L_continue);
> 6003: 
> 6004:       __ vpxor(errorvec, errorvec, errorvec, Assembler::AVX_512bit);

Why clearing errorvec is needed here?

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6023:

> 6021:       __ evmovdquq(tmp16_op3, pack16_op, Assembler::AVX_512bit);
> 6022:       __ evmovdquq(tmp16_op2, pack16_op, Assembler::AVX_512bit);
> 6023:       __ evmovdquq(tmp16_op1, pack16_op, Assembler::AVX_512bit);

Why do we need 3 additional copies of pack16_op?

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6026:

> 6024:       __ evmovdquq(tmp32_op3, pack32_op, Assembler::AVX_512bit);
> 6025:       __ evmovdquq(tmp32_op2, pack32_op, Assembler::AVX_512bit);
> 6026:       __ evmovdquq(tmp32_op1, pack32_op, Assembler::AVX_512bit);

Why do we need 3 additional copies of pack32_op?

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6051:

> 6049:       __ vpternlogd(t0, 0xfe, input1, input2, Assembler::AVX_512bit);
> 6050: 
> 6051:       __ vpternlogd(t1, 0xfe, translated0, translated1, Assembler::AVX_512bit);

The comment here could be something like below for easy understanding:
// OR all of the inputs and translations together ...
// Here t0 has input0 and t1 has input3

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6055:

> 6053:       __ vpternlogd(t2, 0xfe, translated3, t0, Assembler::AVX_512bit);
> 6054:       __ evmovdquq(errorvec, t0, Assembler::AVX_512bit);
> 6055:       __ vpternlogd(errorvec, 0xfe, t1, t2, Assembler::AVX_512bit);

Could this be simplified as:
__ vpternlogd(t0, 0xfe, translated2, translated3, Assembler::AVX_512bit);
__ vpor(errorvec, t0, t1, Assembler::AVX_512bit);

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6060:

> 6058:       __ evpmovb2m(k3, errorvec, Assembler::AVX_512bit);
> 6059:       __ kortestql(k3, k3);
> 6060:       __ vpxor(errorvec, errorvec, errorvec, Assembler::AVX_512bit);

Why clearing errorvec is needed here? Seems to be not necessary for the 256 byte processing loop.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6069:

> 6067:       __ vpmaddubsw(merge_ab_bc0, translated0, tmp16_op3, Assembler::AVX_512bit);
> 6068:       __ vpmaddubsw(merge_ab_bc1, translated1, tmp16_op2, Assembler::AVX_512bit);
> 6069:       __ vpmaddubsw(merge_ab_bc2, translated2, tmp16_op1, Assembler::AVX_512bit);

Could we not use pack16_op directly here instead of its copies tmp16_*?

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6078:

> 6076:       __ vpmaddwd(merged0, merge_ab_bc0, tmp32_op2, Assembler::AVX_512bit);
> 6077:       __ vpmaddwd(merged1, merge_ab_bc1, tmp32_op1, Assembler::AVX_512bit);
> 6078:       __ vpmaddwd(merged2, merge_ab_bc2, tmp32_op3, Assembler::AVX_512bit);

Could we not use pack32_op directly here instead of its copies tmp32_*?

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6086:

> 6084:       __ evpermt2b(arr01, join01, merged1, Assembler::AVX_512bit);
> 6085:       __ evpermt2b(arr12, join12, merged2, Assembler::AVX_512bit);
> 6086:       __ evpermt2b(arr23, join23, merged3, Assembler::AVX_512bit);

arr01 is same as merged0, arr12 is same as merged1, arr23 is same as merged2.
So the above will be easy to understand if coded as below:
__ evpermt2b(merged0, join01, merged1, Assembler::AVX_512bit);
__ evpermt2b(merged1, join12, merged2, Assembler::AVX_512bit);
__ evpermt2b(merged2, join23, merged3, Assembler::AVX_512bit);

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6091:

> 6089:       __ evmovdquq(Address(dest, dp, Address::times_1, 0x00), arr01, Assembler::AVX_512bit);
> 6090:       __ evmovdquq(Address(dest, dp, Address::times_1, 0x40), arr12, Assembler::AVX_512bit);
> 6091:       __ evmovdquq(Address(dest, dp, Address::times_1, 0x80), arr23, Assembler::AVX_512bit);

Here you can directly used the merged0, merged1 and merged2 inplace of arr01, arr12 and arr23 respectively.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6122:

> 6120:       __ evpermt2b(translated0, input0, lookup_hi, Assembler::AVX_512bit);
> 6121: 
> 6122:       __ vpternlogd(errorvec, 0xfe, translated0, input0, Assembler::AVX_512bit);

This could be a simple vpor:
__ vpor(errorvec, translated0, input0, Assembler::AVX_512bit);

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From herrick at openjdk.java.net  Sat Jun 19 10:25:25 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sat, 19 Jun 2021 10:25:25 GMT
Subject: RFR: 8268974: jpackage fails to handle --dest option containing
 "bin" folder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk  wrote:

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4534

From sviswanathan at openjdk.java.net  Sat Jun 19 20:33:31 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 19 Jun 2021 20:33:31 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 18 Jun 2021 22:12:11 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comments.  Streamlined flow for decode.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6155:

> 6153:       __ subl(output_size, length);
> 6154:       __ movq(rax, -1);
> 6155:       __ shrxq(rax, rax, output_size);    // Input mask in rax

I think this could also be implemented as:
__ movq(rax, -1);
__ bzhiq(rax, rax, length);

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6173:

> 6171:       __ movq(rax, 64);
> 6172:       __ subq(rax, output_size);
> 6173:       __ shrxq(output_mask, output_mask, rax);

The output mask can also be computed using bzhiq:
__ movq(output_mask, -1);
__ bzhiq(output_mask, output_mask, output_size);

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6243:

> 6241: 
> 6242:       __ BIND(L_padding);
> 6243:       __ decrementq(r13, 1);

It will be good to use output_size here instead of r13.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6249:

> 6247:       __ jcc(Assembler::notEqual, L_donePadding);
> 6248: 
> 6249:       __ decrementq(r13, 1);

It will be good to use output_size here instead of r13.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6320:

> 6318:     __ BIND(L_bottomLoop);
> 6319:     __ load_signed_byte(byte1, Address(source, start_offset, Address::times_1, 0x00));
> 6320:     __ load_signed_byte(byte2, Address(source, start_offset, Address::times_1, 0x01));

This should be unsigned_byte.

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6324:

> 6322:     __ load_signed_byte(byte2, Address(decode_table, byte2));
> 6323:     __ load_signed_byte(byte3, Address(source, start_offset, Address::times_1, 0x02));
> 6324:     __ load_signed_byte(byte4, Address(source, start_offset, Address::times_1, 0x03));

This should be unsigned_byte.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From peter.firmstone at zeus.net.au  Sun Jun 20 03:58:24 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 20 Jun 2021 13:58:24 +1000
Subject: JEP 411: Deprecation with removal would break most existing Java
 libraries
In-Reply-To: 
References: 
 <4dee507e-320f-70cf-444c-5c8490f550c2@oracle.com>
 <6ceb86ed-3249-26cb-62e8-6c7f6fa17580@zeus.net.au>
 
 
 
Message-ID: 


On 16/06/2021 11:18 pm, David Lloyd wrote:
>> There are already issues with Permission implementations, take for
>> example SocketPermission, it consults DNS and it isn't possible to enter
>> a range of IP addresses (such as the local subnet, and a list of public
>> IP addresses), for now, every single IP address must be entered and this
>> isn't practical.   The proposed API would allow us to re-implement
>> SocketPermission functionality, as well as other Permission implementations.
> Sure, this would be nice to clean up.


What the above example enhances:

  * Generation of policy files during integration testing.
  * Specifying Properties, to replace local information contained in URL
    and file paths, for later policy expansion.
  * In this specific case, I could substitute an IP address with a
    property that specified an allowed subnet mask, this would
    automatically expand the SocketPermission to the local subnet, and
    it would shrink the size of the generated policy file by eliminating
    other SocketPermission grants to IP addresses on the subnet.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.


From alanb at openjdk.java.net  Sun Jun 20 07:28:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 20 Jun 2021 07:28:41 GMT
Subject: RFR: 8268974: jpackage fails to handle --dest option containing
 "bin" folder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk  wrote:

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

Is it possible to add a test for this that is completely independent of jpackage? I think there are a few existing tests that copy the run-time image to a new location for testing purposes.

We may need to rename the JBS description to make it clearer what this issue is about.

A minor nit is that "pathisso" will be confusing to anyone looking at this code, maybe find a better name or put a comment in TruncatePath to explain it. I assume the comments at the findLastPathComponent use site will also need to be clarified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4534

From Alan.Bateman at oracle.com  Sun Jun 20 07:32:07 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 20 Jun 2021 08:32:07 +0100
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo
In-Reply-To: 
References: 
 
 
Message-ID: <7d8a3379-c93a-522a-d900-6a3b631ff61c@oracle.com>

On 18/06/2021 18:30, Brian Burkhalter wrote:
>
>> On Jun 18, 2021, at 6:36 AM, Alan Bateman > > wrote:
>>
>> Adding an override of transferTo may require new tests. @bplb Do you 
>> if we have good tests for all the scenarios where input stream 
>> returned by Channels.newInputStream is the source?
>
> There are not a lot of tests for the `InputStream` returned by 
> `Channels.newInputStream`:
>
> ?`java/nio/channels/Channels`:
>
> `Basic.java` - reading from a wrapped `FileChannel`
> `ReadByte.java` - trivial
> `Basic2.java` - reading at random offsets from a wrapped 
> `AsynchronousSocketChannel`
> `ReadOffset.java` - trivial
>
> Elsewhere:
>
> `sun/nio/ch/TempBuffer.java`
> `jdk/nio/zipfs/ZipFSTester.java`
>
>
> I don?t see that `transferTo()` on such a stream is tested anywhere.

InputStream/TransferTo.java tests the default implementation. Maybe we 
re-structured this to use a data provider so that the tests exercise 
both the default implementation and the various overrides. Alternatively 
a new test that exercises the various overrides in different scenarios. 
In any case, I think the feedback for PR 4263 is that it is essentially 
several implementations of transferTo and each of those need to have 
test coverage.

-Alan

From yyang at openjdk.java.net  Mon Jun 21 03:25:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 03:25:04 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v2]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 
Message-ID: 

On Fri, 18 Jun 2021 18:03:44 GMT, Paul Sandoz  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore IndexOfOufBoundsException; split exception line
>
> src/java.base/share/classes/java/util/Base64.java line 935:
> 
>> 933:                 throw new IOException("Stream is closed");
>> 934:             Preconditions.checkFromIndexSize(len, off, b.length,
>> 935:                 Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));
> 
> `outOfBoundsExceptionFormatter` will allocate. Store the result of `Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new))` in a public static final on `Preconditions`, and replace the method ref with a inner class (thereby making it usable earlier at VM startup.

Thanks for the clarification! Fixed.

This incremental change does many stuff:
- Create inner classes and public static final fields within Preconditions
- Use Preconditions.check* in j.l.String
- Use Preconditions.*IOOBE_FORMATTER in java.util.zip.* classes
- Use Preconditions.*IOOBE_FORMATTER in java.util.Base64
- Use Preconditions.*IOOBE_FORMATTER in X-VarHandle.java.template and X-VarHandleByteArrayView.java.template
- Use Preconditions.*IOOBE_FORMATTER in sun.security.provider.DigestBase
- Use Preconditions.*IOOBE_FORMATTER in sun.security.util.ArrayUtil

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Mon Jun 21 03:25:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 03:25:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v3]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  new Preconditions.IOOBE_FORMATTER

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/ec0a4d44..c1dd2f76

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=01-02

  Stats: 129 lines in 13 files changed: 43 ins; 40 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Mon Jun 21 04:17:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 04:17:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v4]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  format

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/c1dd2f76..154989a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=02-03

  Stats: 15 lines in 1 file changed: 4 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Mon Jun 21 04:46:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 04:46:00 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v5]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  more replacements

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/154989a0..c8b2106e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=03-04

  Stats: 59 lines in 8 files changed: 11 ins; 37 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Mon Jun 21 05:17:09 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 21 Jun 2021 05:17:09 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  more replacement 2

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/c8b2106e..3a8875ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=04-05

  Stats: 32 lines in 2 files changed: 1 ins; 20 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From jvernee at openjdk.java.net  Mon Jun 21 12:10:43 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 21 Jun 2021 12:10:43 GMT
Subject: [jdk17] Integrated: 8268717: Upstream: 8268673: Stack walk across
 optimized entry frame on fresh native thread fails
In-Reply-To: 
References: 
Message-ID: <48y3dj2CbgnTSFbw905vP2NC7Z-V6xQCZegUZ7Ot744=.a30d849f-2826-40f0-ace4-4164866aad87@github.com>

On Wed, 16 Jun 2021 11:19:37 GMT, Jorn Vernee  wrote:

> Upstream a critical fix from the panama-foreign repo.
> 
> See the prior review thread here: https://github.com/openjdk/panama-foreign/pull/558
> 
> Testing: tier 1-2, local run of run-test-jdk_foreign.

This pull request has now been integrated.

Changeset: f25e7197
Author:    Jorn Vernee 
URL:       https://git.openjdk.java.net/jdk17/commit/f25e7197fef76cc87a15da7cc96a42b84d69bbfe
Stats:     198 lines in 12 files changed: 197 ins; 0 del; 1 mod

8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails

Reviewed-by: mcimadamore, erikj

-------------

PR: https://git.openjdk.java.net/jdk17/pull/76

From lancea at openjdk.java.net  Mon Jun 21 12:33:31 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 21 Jun 2021 12:33:31 GMT
Subject: RFR: 8153490: Cannot setBytes() if incoming buffer's length is
 bigger than number of elements we want to insert. [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 24 May 2021 11:18:57 GMT, Mitsuru Kariya  wrote:

>> Fix `SerialBlob.setBytes(long pos, byte[] bytes, int offset, int length)` in the following cases:
>> 
>> 1. `pos - 1 + bytes.length - offset > this.length() && pos - 1 + length <= this.length()`
>>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
>>    (test31)
>> 
>> 2. `pos - 1 + length > this.length()`
>>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully. *1
>>    (test32)
>> 
>> 3. `pos == this.length() + 1`
>>    The original implementation throws `SerialException` but this case should end successfully. *2
>>    (test33)
>> 
>> 4. `length < 0`
>>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should throw `SerialException`.
>>    (test34)
>> 
>> 5. `offset + length > Integer.MAX_VALUE`
>>    The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`.
>>    (test35)
>> 
>> Additionally, fix `SerialClob.setString(long pos, String str, int offset, int length)` in the following cases:
>> 
>> 1. `offset > str.length()`
>>    The original implementaion throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`.
>>    (test39)
>> 
>> 2. `pos - 1 + str.length() - offset > this.length() && pos - 1 + length <= this.length()`
>>    The original implementation throws `ArrayIndexOutOfBoundsException` but this case should end successfully.
>>    (test32)
>> 
>> 3. `pos - 1 + length > this.length()`
>>    The original implementaion throws `SerialException` but this case should end successfully. *3
>>    (test40)
>> 
>> 4. `pos == this.length() + 1`
>>    The original implementaion throws `SerialException` but this case should end successfully. *4
>>    (test41)
>> 
>> 5. `length < 0`
>>    The original implementation throws `StringIndexOutOfBoundsException` but this case should throw `SerialException`.
>>    (test42)
>> 
>> 6. `offset + length > Integer.MAX_VALUE`
>>    The original implementation throws `ArrayIndexOutOfBoundsException` (or `OutOfMemoryError` in most cases) but this case should throw `SerialException`.
>>    (test43)
>> 
>> 
>> The javadoc has also been modified according to the above.
>> 
>> *1 The documentation of `Blob.setBytes()` says, "If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accommodate the extra bytes."
>> 
>> *2 The documentation of `Blob.setBytes()` says, "If the value specified for pos is greater than the length+1 of the BLOB value then the behavior is undefined."
>>    So, it should work correctly when pos == length+1 of the BLOB value.
>> 
>> *3 The documentation of `Clob.setString()` says, "If the end of the Clob value is eached while writing the given string, then the length of the Clob value will be increased to accommodate the extra characters."
>> 
>> *4 The documentation of `Clob.setString()` says, "If the value specified for pos is greater than the length+1 of the CLOB value then the behavior is undefined."
>>    So, it should work correctly when pos == length+1 of the CLOB value.
>
> Mitsuru Kariya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify javadoc for consistency

I hope to get to the CSR this week.  Sorry for the delay

-------------

PR: https://git.openjdk.java.net/jdk/pull/4001

From alanb at openjdk.java.net  Mon Jun 21 13:29:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 21 Jun 2021 13:29:27 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:

> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
> 
> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Further details can be found in the original PR.
> 
> Testing: jtreg and jck testing with no regressions. A new regression test was developed.

@voitylov JDK 17 is an RDP 1 and I wonder if this long standing issue is critical or not. I've skimmed through the changes and I don't see any issue but if this is really intended for openjdk/jdk17 then I think it would be useful to have more eyes on it.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From asemenyuk at openjdk.java.net  Mon Jun 21 15:33:32 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 21 Jun 2021 15:33:32 GMT
Subject: RFR: 8268974: jpackage fails to handle --dest option containing
 "bin" folder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk  wrote:

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

The test should use java launcher dynamically linked to libjli.so. So the standard java launcher wouldn't work. I can provide C source code of a test java launcher dynamically linked to libjli.so though. The test will need to compile java launcher from the source code. This looks more sophisticated compared to providing another jpackage test for this use case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4534

From asemenyuk at openjdk.java.net  Mon Jun 21 15:51:56 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 21 Jun 2021 15:51:56 GMT
Subject: RFR: 8268974: jpackage fails to handle --dest option containing
 "bin" folder [v2]
In-Reply-To: 
References: 
Message-ID: 

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  - Comments updated.
  - pathisso -> pathisdll.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4534/files
  - new: https://git.openjdk.java.net/jdk/pull/4534/files/7028e74f..18aa7427

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4534&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4534&range=00-01

  Stats: 13 lines in 1 file changed: 8 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4534.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4534/head:pull/4534

PR: https://git.openjdk.java.net/jdk/pull/4534

From mchung at openjdk.java.net  Mon Jun 21 16:52:29 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 21 Jun 2021 16:52:29 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:

> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
> 
> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Further details can be found in the original PR.
> 
> Testing: jtreg and jck testing with no regressions. A new regression test was developed.

@dholmes-ora @ChrisHegarty @plevart reviewed PR openjdk/jdk#3976.  Can you re-review this PR?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From rriggs at openjdk.java.net  Mon Jun 21 17:15:03 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 21 Jun 2021 17:15:03 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v2]
In-Reply-To: 
References: 
Message-ID: 

> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove jdk.serialFilterFactory "OVERRIDE" special handling.
  Correct description of the example of allowing platform or bootstrap classes in OIF.
  Cleanup of logging of filter tracing.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/85/files
  - new: https://git.openjdk.java.net/jdk17/pull/85/files/9471e4e0..0add8a1c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=00-01

  Stats: 61 lines in 6 files changed: 9 ins; 26 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85

PR: https://git.openjdk.java.net/jdk17/pull/85

From avoitylov at openjdk.java.net  Mon Jun 21 18:23:27 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Mon, 21 Jun 2021 18:23:27 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 13:26:14 GMT, Alan Bateman  wrote:

>> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
>> 
>> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
>> 
>> Further details can be found in the original PR.
>> 
>> Testing: jtreg and jck testing with no regressions. A new regression test was developed.
>
> @voitylov JDK 17 is an RDP 1 and I wonder if this long standing issue is critical or not. I've skimmed through the changes and I don't see any issue but if this is really intended for openjdk/jdk17 then I think it would be useful to have more eyes on it.

@AlanBateman I think it's worth to be included in JDK17 because in case someone hits this (like netty), the impact is high (a framework or an application can't start) and there is no viable workaround without rewriting code. The scope of change in the last version, at the same time, is limited.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From naoto at openjdk.java.net  Mon Jun 21 18:32:42 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 21 Jun 2021 18:32:42 GMT
Subject: RFR: 8266901: Clarify the method description of Duration.toDaysPart()
Message-ID: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>

Please review this doc clarification fix to `toDaysPart()` method. CSR will also be filed accordingly.

-------------

Commit messages:
 - 8266901: Clarify the method description of Duration.toDaysPart()

Changes: https://git.openjdk.java.net/jdk/pull/4542/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4542&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266901
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4542.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4542/head:pull/4542

PR: https://git.openjdk.java.net/jdk/pull/4542

From bpb at openjdk.java.net  Mon Jun 21 18:40:32 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 21 Jun 2021 18:40:32 GMT
Subject: RFR: 8266901: Clarify the method description of
 Duration.toDaysPart()
In-Reply-To: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
References: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
Message-ID: 

On Mon, 21 Jun 2021 18:22:26 GMT, Naoto Sato  wrote:

> Please review this doc clarification fix to `toDaysPart()` method. CSR will also be filed accordingly.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4542

From rriggs at openjdk.java.net  Mon Jun 21 18:49:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 21 Jun 2021 18:49:27 GMT
Subject: RFR: 8266901: Clarify the method description of
 Duration.toDaysPart()
In-Reply-To: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
References: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
Message-ID: 

On Mon, 21 Jun 2021 18:22:26 GMT, Naoto Sato  wrote:

> Please review this doc clarification fix to `toDaysPart()` method. CSR will also be filed accordingly.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4542

From lancea at openjdk.java.net  Mon Jun 21 18:56:31 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 21 Jun 2021 18:56:31 GMT
Subject: RFR: 8266901: Clarify the method description of
 Duration.toDaysPart()
In-Reply-To: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
References: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
Message-ID: <3VpIH69MHsmB12YUz0Fe9JMN0VDNKeVKsIqObIZQTO4=.f74e1ada-3aaf-47fd-987e-feea2de1da7e@github.com>

On Mon, 21 Jun 2021 18:22:26 GMT, Naoto Sato  wrote:

> Please review this doc clarification fix to `toDaysPart()` method. CSR will also be filed accordingly.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4542

From iris at openjdk.java.net  Mon Jun 21 20:00:28 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 21 Jun 2021 20:00:28 GMT
Subject: RFR: 8266901: Clarify the method description of
 Duration.toDaysPart()
In-Reply-To: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
References: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
Message-ID: 

On Mon, 21 Jun 2021 18:22:26 GMT, Naoto Sato  wrote:

> Please review this doc clarification fix to `toDaysPart()` method. CSR will also be filed accordingly.

Associated CSR also reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4542

From herrick at openjdk.java.net  Mon Jun 21 20:29:40 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 21 Jun 2021 20:29:40 GMT
Subject: [jdk17] RFR: JDK-8268404: [TESTBUG]
 tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError:
 Failed: Check icon"
Message-ID: 

?t.java failed "AssertionError: Failed: Check icon"

-------------

Commit messages:
 -     JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

Changes: https://git.openjdk.java.net/jdk17/pull/111/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=111&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268404
  Stats: 79 lines in 2 files changed: 0 ins; 59 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/111.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/111/head:pull/111

PR: https://git.openjdk.java.net/jdk17/pull/111

From asemenyuk at openjdk.java.net  Mon Jun 21 20:46:31 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 21 Jun 2021 20:46:31 GMT
Subject: [jdk17] RFR: JDK-8268404: [TESTBUG]
 tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError:
 Failed: Check icon"
In-Reply-To: 
References: 
Message-ID: 

On Mon, 21 Jun 2021 20:21:58 GMT, Andy Herrick  wrote:

> ?t.java failed "AssertionError: Failed: Check icon"

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 75:

> 73: 
> 74:         // Create another installer with custom icon.
> 75:         long size3 = createInstaller(customIcon, "WithCustom3Icon");

The test should produce WinInstallerIconTest-1.0.exe artifact referenced in SQE test spec. But this patch will not produce it. It will produce WinInstallerIconTestWithDefaultIcon-1.0.exe, WinInstallerIconTestWithCustom2Icon-1.0.exe and WinInstallerIconTestWithCustom3Icon-1.0.exe artifacts and all of them will be deleted.

test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 114:

> 112:             size = installerExePath[0].toFile().length();
> 113:             TKit.trace(" installer: " + installerExePath[0] + " - size: " + size);
> 114:             if (nameSuffix != "3") {

Value of `nameSuffix` parameter is never equals to "3"

-------------

PR: https://git.openjdk.java.net/jdk17/pull/111

From psandoz at openjdk.java.net  Mon Jun 21 21:02:30 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 21 Jun 2021 21:02:30 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: 

On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more replacement 2

All the updates to the check* methods look ok (requires some careful looking!).

I cannot recall what others said about the change in exception messages. @jddarcy any advice here?

src/java.base/share/classes/jdk/internal/util/Preconditions.java line 78:

> 76:             = Preconditions.outOfBoundsExceptionFormatter(new StringIndexOutOfBoundsExceptionProducer());
> 77: 
> 78:     public static final BiFunction, StringIndexOutOfBoundsException> AIOOBE_FORMATTER

Using incorrect exception type. Suggest you embed as inner class rather than separate declaration, since they are only used in one place.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From mcimadamore at openjdk.java.net  Mon Jun 21 21:15:31 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Jun 2021 21:15:31 GMT
Subject: [jdk17] RFR: 8268888: Upstream 8268230: Foreign Linker API &
 Windows user32/kernel32: String conversion seems broken [v2]
In-Reply-To: 
References: <4KuMCXKzbvdVI0v5C7zyx4NX216Wk_7G73lzrIhsZsU=.601fe18b-500f-413a-9a2e-067d08338b27@github.com>
 
Message-ID: 

On Wed, 16 Jun 2021 22:23:45 GMT, Jorn Vernee  wrote:

>> Upstream fix for 8268230 to mainline JDK.
>> 
>> Prior review thread can be found here: https://github.com/openjdk/panama-foreign/pull/554
>> 
>> Testing: jdk_foreign test suite on Windows and Linux (WSL).
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude test on unsupported platforms
>   
>   This test indirectly initializes CABI, which fails on Linux x86

Looks good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/77

From scolebourne at openjdk.java.net  Mon Jun 21 21:53:29 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 21 Jun 2021 21:53:29 GMT
Subject: RFR: 8266901: Clarify the method description of
 Duration.toDaysPart()
In-Reply-To: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
References: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
Message-ID: 

On Mon, 21 Jun 2021 18:22:26 GMT, Naoto Sato  wrote:

> Please review this doc clarification fix to `toDaysPart()` method. CSR will also be filed accordingly.

Marked as reviewed by scolebourne (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4542

From jwilhelm at openjdk.java.net  Mon Jun 21 22:11:54 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 21 Jun 2021 22:11:54 GMT
Subject: RFR: Merge jdk17
Message-ID: <4D0KACEvY4TGf4sVl6GUP8Z7byPVOfOy7iCrCtz1Z1o=.712c74cf-1b4e-42be-b7eb-319cce468aa3@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8268672: C2: assert(!loop->is_member(u_loop)) failed: can be in outer loop or out of both loops only
 - 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails
 - 8268362: [REDO] C2 crash when compile negative Arrays.copyOf length after loop
 - 8268702: JFR diagnostic commands lack argument descriptors when viewed using Platform MBean Server
 - 8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header
 - 8269063: Build failure due to VerifyReceiverTypes was not declared after JDK-8268405

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4545&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4545&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4545/files
  Stats: 608 lines in 25 files changed: 578 ins; 17 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4545.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4545/head:pull/4545

PR: https://git.openjdk.java.net/jdk/pull/4545

From rriggs at openjdk.java.net  Mon Jun 21 22:35:45 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 21 Jun 2021 22:35:45 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
Message-ID: 

Add java.util.Objects.newIdentity to supply a unique object with identity.
This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.

-------------

Commit messages:
 - Copyright update and cleanup punctuation
 - 8269096: Add java.util.Objects.newIdentity method

Changes: https://git.openjdk.java.net/jdk17/pull/112/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269096
  Stats: 29 lines in 2 files changed: 28 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk17/pull/112

From bchristi at openjdk.java.net  Mon Jun 21 22:39:28 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 21 Jun 2021 22:39:28 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v2]
In-Reply-To: 
References: 
 
Message-ID: <7VCVqUuAosqIcDGBGa-H-2_mKu8bQPhAacJtIyKtwCc=.021bb39c-c149-4553-8b7b-53a807144e72@github.com>

On Mon, 21 Jun 2021 17:15:03 GMT, Roger Riggs  wrote:

>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.serialFilterFactory "OVERRIDE" special handling.
>   Correct description of the example of allowing platform or bootstrap classes in OIF.
>   Cleanup of logging of filter tracing.

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/85

From mchung at openjdk.java.net  Mon Jun 21 22:40:25 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 21 Jun 2021 22:40:25 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
In-Reply-To: 
References: 
Message-ID: <8gKp6AbHSa_qmWbKTPAl0u3pAtAjGioQ-aBKKrPvjA4=.e137299f-273f-4479-9a45-ea11af122053@github.com>

On Mon, 21 Jun 2021 22:25:49 GMT, Roger Riggs  wrote:

> Add java.util.Objects.newIdentity to supply a unique object with identity.
> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.

Looks okay in general.   It'd be useful for the javadoc of `Object()` constructor to suggest using `Objects::newIdentity` instead of the constructor.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From herrick at openjdk.java.net  Mon Jun 21 22:59:25 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 21 Jun 2021 22:59:25 GMT
Subject: [jdk17] RFR: JDK-8268404: [TESTBUG]
 tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError:
 Failed: Check icon"
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 20:42:54 GMT, Alexey Semenyuk  wrote:

>> ?t.java failed "AssertionError: Failed: Check icon"
>
> test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 75:
> 
>> 73: 
>> 74:         // Create another installer with custom icon.
>> 75:         long size3 = createInstaller(customIcon, "WithCustom3Icon");
> 
> The test should produce WinInstallerIconTest-1.0.exe artifact referenced in SQE test spec. But this patch will not produce it. It will produce WinInstallerIconTestWithDefaultIcon-1.0.exe, WinInstallerIconTestWithCustom2Icon-1.0.exe and WinInstallerIconTestWithCustom3Icon-1.0.exe artifacts and all of them will be deleted.

yes - I was changing the names to be the same length in attempt to create repeatable exe size - but that doesn't matter, so will restore the suffix's to what they were so WinInstallerIconTest-1.0.exe  will be left for JPKG001-024 in Test Spec.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/111

From jwilhelm at openjdk.java.net  Mon Jun 21 23:13:35 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 21 Jun 2021 23:13:35 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <4D0KACEvY4TGf4sVl6GUP8Z7byPVOfOy7iCrCtz1Z1o=.712c74cf-1b4e-42be-b7eb-319cce468aa3@github.com>
References: <4D0KACEvY4TGf4sVl6GUP8Z7byPVOfOy7iCrCtz1Z1o=.712c74cf-1b4e-42be-b7eb-319cce468aa3@github.com>
Message-ID: <0DZcV1V15Eo794hocKR8fbsedv13NPolxXHTnDwma4c=.a0e9754f-5f23-4f6e-a040-0d8f82461708@github.com>

On Mon, 21 Jun 2021 22:03:59 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 0458113c
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/0458113c6b1cf500ffdf049c1e3a698b16ce12ce
Stats:     608 lines in 25 files changed: 578 ins; 17 del; 13 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4545

From jwilhelm at openjdk.java.net  Mon Jun 21 23:13:34 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 21 Jun 2021 23:13:34 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <4D0KACEvY4TGf4sVl6GUP8Z7byPVOfOy7iCrCtz1Z1o=.712c74cf-1b4e-42be-b7eb-319cce468aa3@github.com>
References: <4D0KACEvY4TGf4sVl6GUP8Z7byPVOfOy7iCrCtz1Z1o=.712c74cf-1b4e-42be-b7eb-319cce468aa3@github.com>
Message-ID: <6_vIbsJ6HFVVhVo491H1wJI-2gof1AIDJZHJ-OpfE8Q=.af0d1f7f-6381-4b10-9e80-22ce54b777c5@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits:

 - Merge
 - 8268458: Add verification type for evacuation failures
   
   Reviewed-by: kbarrett, iwalulya
 - 8268952: Automatically update heap sizes in G1MonitoringScope
   
   Reviewed-by: kbarrett, iwalulya
 - 8269029: compiler/codegen/TestCharVect2.java fails for client VMs
   
   Reviewed-by: kvn, jiefu
 - 8017163: G1: Refactor remembered sets
   8048504: G1: Investigate replacing the coarse and fine grained data structures in the remembered sets
   6949259: G1: Merge sparse and fine remembered set hash tables
   
   Co-authored-by: Ivan Walulya 
   Co-authored-by: Thomas Schatzl 
   Reviewed-by: sjohanss, iwalulya
 - 8266082: AssertionError in Annotate.fromAnnotations with -Xdoclint
   
   Reviewed-by: vromero
 - Merge
 - 8267042: bug in monitor locking/unlocking on ARM32 C1 due to uninitialized BasicObjectLock::_displaced_header
   
   Co-authored-by: Chris Cole 
   Reviewed-by: dsamersoff
 - 8268964: Remove unused ReferenceProcessorAtomicMutator
   
   Reviewed-by: tschatzl, pliden
 - 8268900: com/sun/net/httpserver/Headers.java: Fix indentation and whitespace
   
   Reviewed-by: dfuchs, chegar, michaelm
 - ... and 42 more: https://git.openjdk.java.net/jdk/compare/d3ad8cd3...40c550db

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4545/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4545&range=01
  Stats: 14796 lines in 230 files changed: 12511 ins; 1719 del; 566 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4545.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4545/head:pull/4545

PR: https://git.openjdk.java.net/jdk/pull/4545

From dholmes at openjdk.java.net  Mon Jun 21 23:48:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 21 Jun 2021 23:48:27 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:

> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
> 
> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Further details can be found in the original PR.
> 
> Testing: jtreg and jck testing with no regressions. A new regression test was developed.

I've re-reviewed the locking aspect of this, but can't comment on the NativeLibraryContext changes.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/96

From vromero at openjdk.java.net  Tue Jun 22 00:45:02 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 22 Jun 2021 00:45:02 GMT
Subject: [jdk17] RFR: 8267421:
 j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't
 conform to the spec regarding REF_invokeInterface handling [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk.
> 
> Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter
> 
> TIA

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8267421
 - updating after review comments
 - 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/29/files
  - new: https://git.openjdk.java.net/jdk17/pull/29/files/8ed4cdb3..be1a932c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=29&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=29&range=01-02

  Stats: 16865 lines in 275 files changed: 10155 ins; 6060 del; 650 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/29/head:pull/29

PR: https://git.openjdk.java.net/jdk17/pull/29

From mchung at openjdk.java.net  Tue Jun 22 00:48:32 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 22 Jun 2021 00:48:32 GMT
Subject: [jdk17] RFR: 8267421:
 j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't
 conform to the spec regarding REF_invokeInterface handling [v2]
In-Reply-To: <-AWxe73HwY-dRtFmCot7-gB5T3QciRfYScrEls-Ezeo=.fe6e88c2-db17-4b38-9729-8a923c04efec@github.com>
References: 
 <-AWxe73HwY-dRtFmCot7-gB5T3QciRfYScrEls-Ezeo=.fe6e88c2-db17-4b38-9729-8a923c04efec@github.com>
Message-ID: 

On Fri, 11 Jun 2021 18:17:10 GMT, Vicente Romero  wrote:

>> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk.
>> 
>> Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating after review comments

Marked as reviewed by mchung (Reviewer).

src/java.base/share/classes/java/lang/constant/DirectMethodHandleDesc.java line 138:

> 136:             int i = tableIndex(refKind, isInterface);
> 137:             if (i >= 2 && i < TABLE.length) {
> 138:                 return TABLE[i];

This fix looks good.   The resulting `TABLE` has two entries per `refKind` for `isInterface` = `true` and `false`.

test/jdk/java/lang/constant/MethodHandleDescTest.java line 379:

> 377:         for (int refKind : isInterfaceIgnored) {
> 378:             assertEquals(Kind.valueOf(refKind, false), Kind.valueOf(refKind, true));
> 379:         }

Can you also add the test cases to verify `Kind::valueOf` with `REF_invokeStatic` and `REF_invokeSpecial`?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/29

From vromero at openjdk.java.net  Tue Jun 22 01:24:53 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 22 Jun 2021 01:24:53 GMT
Subject: [jdk17] RFR: 8267421:
 j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't
 conform to the spec regarding REF_invokeInterface handling [v2]
In-Reply-To: 
References: 
 <-AWxe73HwY-dRtFmCot7-gB5T3QciRfYScrEls-Ezeo=.fe6e88c2-db17-4b38-9729-8a923c04efec@github.com>
 
Message-ID: 

On Tue, 22 Jun 2021 00:45:36 GMT, Mandy Chung  wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updating after review comments
>
> test/jdk/java/lang/constant/MethodHandleDescTest.java line 379:
> 
>> 377:         for (int refKind : isInterfaceIgnored) {
>> 378:             assertEquals(Kind.valueOf(refKind, false), Kind.valueOf(refKind, true));
>> 379:         }
> 
> Can you also add the test cases to verify `Kind::valueOf` with `REF_invokeStatic` and `REF_invokeSpecial`?

please see them below, thanks

-------------

PR: https://git.openjdk.java.net/jdk17/pull/29

From vromero at openjdk.java.net  Tue Jun 22 01:24:52 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 22 Jun 2021 01:24:52 GMT
Subject: [jdk17] RFR: 8267421:
 j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't
 conform to the spec regarding REF_invokeInterface handling [v4]
In-Reply-To: 
References: 
Message-ID: <2imShuoGWMHNuoDt_YtlNT349EdVn1QxbKnhUZ2Wz54=.4962e4a7-c5aa-47f7-a055-09d254c6739d@github.com>

> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk.
> 
> Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/29/files
  - new: https://git.openjdk.java.net/jdk17/pull/29/files/be1a932c..d36a5528

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=29&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=29&range=02-03

  Stats: 9 lines in 1 file changed: 8 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/29/head:pull/29

PR: https://git.openjdk.java.net/jdk17/pull/29

From vromero at openjdk.java.net  Tue Jun 22 02:11:31 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 22 Jun 2021 02:11:31 GMT
Subject: [jdk17] Integrated: 8267421:
 j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't
 conform to the spec regarding REF_invokeInterface handling
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Jun 2021 15:01:20 GMT, Vicente Romero  wrote:

> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk.
> 
> Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading of the method's spec is that if the value of the refKind parameter is: MethodHandleInfo.REF_invokeInterface, then DirectMethodHandleDesc.Kind.valueOf(int, boolean) should be called with a value of true for its second argument, currently it is invoked with false regardless of the value of the refKind parameter
> 
> TIA

This pull request has now been integrated.

Changeset: 6b14c8a1
Author:    Vicente Romero 
URL:       https://git.openjdk.java.net/jdk17/commit/6b14c8a1e5316b6c8584e93ee7a94d9eaec676cf
Stats:     36 lines in 2 files changed: 23 ins; 8 del; 5 mod

8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling

Reviewed-by: mchung

-------------

PR: https://git.openjdk.java.net/jdk17/pull/29

From yyang at openjdk.java.net  Tue Jun 22 02:39:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 02:39:04 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 
Message-ID: 

On Mon, 21 Jun 2021 20:49:56 GMT, Paul Sandoz  wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more replacement 2
>
> src/java.base/share/classes/jdk/internal/util/Preconditions.java line 78:
> 
>> 76:             = Preconditions.outOfBoundsExceptionFormatter(new StringIndexOutOfBoundsExceptionProducer());
>> 77: 
>> 78:     public static final BiFunction, StringIndexOutOfBoundsException> AIOOBE_FORMATTER
> 
> Using incorrect exception type. Suggest you embed as inner class rather than separate declaration, since they are only used in one place.

Fixed.

FYI: Current exception message looks like this:

Exception in thread "main" java.lang.StringIndexOutOfBoundsException: Range [3, 1) out of bounds for length 6
	at CheckIndex$StringIndexOutOfBoundsExceptionProducer.apply(CheckIndex.java:77)
	at CheckIndex$StringIndexOutOfBoundsExceptionProducer.apply(CheckIndex.java:72)
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:159)
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:156)
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:62)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Preconditions.java:76)
	at java.base/jdk.internal.util.Preconditions.checkFromToIndex(Preconditions.java:295)
	at CheckIndex.main(CheckIndex.java:110)

I think now it expresses more exception information than before(and more consistent).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Tue Jun 22 02:39:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 02:39:01 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  correct exception type; use anonymous inner classes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/3a8875ec..2330ee38

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=05-06

  Stats: 21 lines in 1 file changed: 0 ins; 9 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From yyang at openjdk.java.net  Tue Jun 22 03:01:35 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 22 Jun 2021 03:01:35 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
Message-ID: <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>

On Tue, 22 Jun 2021 02:39:01 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct exception type; use anonymous inner classes

I found that after solving the problem that Preconditions cannot be used during the VM startup, a series of functions such as String.checkIndex/checkOffset/.. can also be harmlessly replaced, but this changeset is somewhat large and may overwrite the previous review progress. If it will confuse the current review progress for reviewers involving in this PR, I'd like to file a new PR to do this change later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From igraves at openjdk.java.net  Tue Jun 22 04:31:38 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 22 Jun 2021 04:31:38 GMT
Subject: RFR: 8268664: The documentation of the Scanner.hasNextLine is
 incorrect
Message-ID: 

8268664: The documentation of the Scanner.hasNextLine is incorrect

-------------

Commit messages:
 - Clarifying docs on Scanner.hasNextLine() regarding line separators

Changes: https://git.openjdk.java.net/jdk/pull/4547/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4547&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268664
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4547.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4547/head:pull/4547

PR: https://git.openjdk.java.net/jdk/pull/4547

From pconcannon at openjdk.java.net  Tue Jun 22 09:58:55 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 22 Jun 2021 09:58:55 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions?
> 
> Kind regards,
> Patrick

Patrick Concannon 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:

 - 8268469: Removed alignment of arrow operators in some cases; reverted logic of switch/case in LocalDate
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - 8268469: Removed excessive spacing; corrected misplaced comments
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - 8268469: Update java.time to use switch expressions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4433/files
  - new: https://git.openjdk.java.net/jdk/pull/4433/files/2ae4a574..24ae9e53

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=02-03

  Stats: 24105 lines in 400 files changed: 15347 ins; 7613 del; 1145 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4433/head:pull/4433

PR: https://git.openjdk.java.net/jdk/pull/4433

From pconcannon at openjdk.java.net  Tue Jun 22 09:59:01 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 22 Jun 2021 09:59:01 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <5PcPYmea4OthvEzXmzewVOaAknTANVzZFt0V_DV7vDo=.9913ea2e-4030-4a58-a1ab-4c2c88f0ff68@github.com>

On Wed, 16 Jun 2021 10:58:22 GMT, Stephen Colebourne  wrote:

>> Patrick Concannon 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:
>> 
>>  - 8268469: Removed excessive spacing; corrected misplaced comments
>>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>>  - 8268469: Update java.time to use switch expressions
>
> src/java.base/share/classes/java/time/LocalDate.java line 607:
> 
>> 605:         if (field instanceof ChronoField chronoField) {
>> 606:             if (chronoField.isDateBased()) {
>> 607:                 int n = switch (chronoField) {
> 
> This logic is harder to read than before, and it requires the CPU to perform an extra branch on `(n == -1)`. It should just be a `return switch ...`

Reverted logic as requested. See 24ae9e5

-------------

PR: https://git.openjdk.java.net/jdk/pull/4433

From pconcannon at openjdk.java.net  Tue Jun 22 09:59:07 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 22 Jun 2021 09:59:07 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v3]
In-Reply-To: 
References: 
 
 
Message-ID: <3J4XzQ5wF3AYVa3P5TzsxFLezZY7AGhkVLpy-pDI0Lw=.d429c232-01ab-4522-945e-9690e6f4fd53@github.com>

On Thu, 17 Jun 2021 13:51:27 GMT, Daniel Fuchs  wrote:

>> Patrick Concannon 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:
>> 
>>  - 8268469: Removed excessive spacing; corrected misplaced comments
>>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>>  - 8268469: Update java.time to use switch expressions
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2793:
> 
>> 2791:                     case NOT_NEGATIVE                -> throw new DateTimeException("Field " + field +
>> 2792:                                                             " cannot be printed as the value " + value +
>> 2793:                                                             " cannot be negative according to the SignStyle");
> 
> Maybe in this case you could revert the alignment. In this case it would allow lines 2792 to 2793 to be shorter

I've removed the alignment of arrow operators as requested. See 24ae9e5

-------------

PR: https://git.openjdk.java.net/jdk/pull/4433

From pconcannon at openjdk.java.net  Tue Jun 22 10:57:45 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 22 Jun 2021 10:57:45 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part II)
Message-ID: 

Hi,

Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?

This PR was split into two parts due to the large number of files affected.

Kind regards,

Patrick

-------------

Commit messages:
 - 8269124: Update java.time to use switch expressions (part II)

Changes: https://git.openjdk.java.net/jdk/pull/4552/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269124
  Stats: 359 lines in 16 files changed: 0 ins; 48 del; 311 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4552.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4552/head:pull/4552

PR: https://git.openjdk.java.net/jdk/pull/4552

From coffeys at openjdk.java.net  Tue Jun 22 12:08:46 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 12:08:46 GMT
Subject: RFR: 8269034: AccessControlException for SunPKCS11 daemon threads
Message-ID: 

Sufficient permissions missing if this code was ever to run with SecurityManager. 

Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
Test case coverage extended to cover the SecurityManager scenario.

Reviewer request: @valeriepeng

-------------

Commit messages:
 - 8269034: AccessControlException for SunPKCS11 daemon threads

Changes: https://git.openjdk.java.net/jdk/pull/4555/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4555&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269034
  Stats: 112 lines in 5 files changed: 73 ins; 17 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4555.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4555/head:pull/4555

PR: https://git.openjdk.java.net/jdk/pull/4555

From herrick at openjdk.java.net  Tue Jun 22 12:34:04 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 22 Jun 2021 12:34:04 GMT
Subject: [jdk17] RFR: JDK-8268404: [TESTBUG]
 tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError:
 Failed: Check icon" [v2]
In-Reply-To: 
References: 
Message-ID: 

> ?t.java failed "AssertionError: Failed: Check icon"

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/111/files
  - new: https://git.openjdk.java.net/jdk17/pull/111/files/cf5b0242..f8714c8a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=111&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=111&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/111.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/111/head:pull/111

PR: https://git.openjdk.java.net/jdk17/pull/111

From herrick at openjdk.java.net  Tue Jun 22 12:34:06 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 22 Jun 2021 12:34:06 GMT
Subject: [jdk17] RFR: JDK-8268404: [TESTBUG]
 tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError:
 Failed: Check icon" [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 21 Jun 2021 22:56:32 GMT, Andy Herrick  wrote:

>> test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 75:
>> 
>>> 73: 
>>> 74:         // Create another installer with custom icon.
>>> 75:         long size3 = createInstaller(customIcon, "WithCustom3Icon");
>> 
>> The test should produce WinInstallerIconTest-1.0.exe artifact referenced in SQE test spec. But this patch will not produce it. It will produce WinInstallerIconTestWithDefaultIcon-1.0.exe, WinInstallerIconTestWithCustom2Icon-1.0.exe and WinInstallerIconTestWithCustom3Icon-1.0.exe artifacts and all of them will be deleted.
>
> yes - I was changing the names to be the same length in attempt to create repeatable exe size - but that doesn't matter, so will restore the suffix's to what they were so WinInstallerIconTest-1.0.exe  will be left for JPKG001-024 in Test Spec.

done - name change and test reverted so remaining artifact is WinInstallerIconTest-1.0.exe (and it contains the custom icon)

-------------

PR: https://git.openjdk.java.net/jdk17/pull/111

From coffeys at openjdk.java.net  Tue Jun 22 12:38:27 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 12:38:27 GMT
Subject: RFR: 8269034: AccessControlException for SunPKCS11 daemon threads
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 12:01:07 GMT, Sean Coffey  wrote:

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

Please ignore - I'm going to open a PR against jdk17 for this

-------------

PR: https://git.openjdk.java.net/jdk/pull/4555

From coffeys at openjdk.java.net  Tue Jun 22 12:38:27 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 12:38:27 GMT
Subject: Withdrawn: 8269034: AccessControlException for SunPKCS11 daemon
 threads
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 12:01:07 GMT, Sean Coffey  wrote:

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4555

From github.com+10835776+stsypanov at openjdk.java.net  Tue Jun 22 12:59:35 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 22 Jun 2021 12:59:35 GMT
Subject: RFR: 8268873: Unnecessary Vector usage in java.base
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov  wrote:

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed.
> I checked only places where `Vector` was used as local variable.

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4482

From coffeys at openjdk.java.net  Tue Jun 22 13:32:45 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 13:32:45 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads
Message-ID: 

Sufficient permissions missing if this code was ever to run with SecurityManager. 

Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
Test case coverage extended to cover the SecurityManager scenario.

Reviewer request: @valeriepeng

-------------

Commit messages:
 - 8269034: AccessControlException for SunPKCS11 daemon threads

Changes: https://git.openjdk.java.net/jdk17/pull/117/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269034
  Stats: 112 lines in 5 files changed: 73 ins; 17 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/117.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117

PR: https://git.openjdk.java.net/jdk17/pull/117

From rriggs at openjdk.java.net  Tue Jun 22 13:34:36 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Jun 2021 13:34:36 GMT
Subject: RFR: 8268664: The documentation of the Scanner.hasNextLine is
 incorrect
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 04:22:34 GMT, Ian Graves  wrote:

> 8268664: The documentation of the Scanner.hasNextLine is incorrect

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4547

From dfuchs at openjdk.java.net  Tue Jun 22 13:48:32 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 22 Jun 2021 13:48:32 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v4]
In-Reply-To: 
References: 
 
Message-ID: <3ORyUGmElcdn5tU2Boe0yfaUhmljtdlCdTwXOhEe4Qw=.2d7d8371-a43d-4c13-9336-c9c8e6bf63a3@github.com>

On Tue, 22 Jun 2021 09:58:55 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon 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:
> 
>  - 8268469: Removed alignment of arrow operators in some cases; reverted logic of switch/case in LocalDate
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - 8268469: Removed excessive spacing; corrected misplaced comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - 8268469: Update java.time to use switch expressions

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4433

From dfuchs at openjdk.java.net  Tue Jun 22 13:56:26 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 22 Jun 2021 13:56:26 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part II)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 10:50:17 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

The proposed changes look reasonable to me. Make sure to run all the tests of course.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4552

From vtewari at openjdk.java.net  Tue Jun 22 14:51:34 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Tue, 22 Jun 2021 14:51:34 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part II)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 10:50:17 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Changes looks OK to me, although i can see, in existing code couple of places we are doing conversion from long to int((int) newValue * 1000_000;)

-------------

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4552

From rriggs at openjdk.java.net  Tue Jun 22 14:52:13 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Jun 2021 14:52:13 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v3]
In-Reply-To: 
References: 
Message-ID: 

> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Simplify error case handling during filter factory initialization
  by ensuring that Config.setSerialFilterFactory throws IllegalStateException
  if called as a side effect of class loading and initialization.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/85/files
  - new: https://git.openjdk.java.net/jdk17/pull/85/files/0add8a1c..cf6f5edb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=01-02

  Stats: 16 lines in 1 file changed: 2 ins; 9 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85

PR: https://git.openjdk.java.net/jdk17/pull/85

From jvernee at openjdk.java.net  Tue Jun 22 15:30:41 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 22 Jun 2021 15:30:41 GMT
Subject: [jdk17] Integrated: 8268888: Upstream 8268230: Foreign Linker API &
 Windows user32/kernel32: String conversion seems broken
In-Reply-To: <4KuMCXKzbvdVI0v5C7zyx4NX216Wk_7G73lzrIhsZsU=.601fe18b-500f-413a-9a2e-067d08338b27@github.com>
References: <4KuMCXKzbvdVI0v5C7zyx4NX216Wk_7G73lzrIhsZsU=.601fe18b-500f-413a-9a2e-067d08338b27@github.com>
Message-ID: 

On Wed, 16 Jun 2021 12:20:48 GMT, Jorn Vernee  wrote:

> Upstream fix for 8268230 to mainline JDK.
> 
> Prior review thread can be found here: https://github.com/openjdk/panama-foreign/pull/554
> 
> Testing: jdk_foreign test suite on Windows and Linux (WSL).

This pull request has now been integrated.

Changeset: 8fa25208
Author:    Jorn Vernee 
URL:       https://git.openjdk.java.net/jdk17/commit/8fa2520803c9b9be41b26b4b34b7d2040a7b1dfb
Stats:     316 lines in 6 files changed: 149 ins; 154 del; 13 mod

8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk17/pull/77

From asemenyuk at openjdk.java.net  Tue Jun 22 15:38:33 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 22 Jun 2021 15:38:33 GMT
Subject: [jdk17] RFR: JDK-8268404: [TESTBUG]
 tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError:
 Failed: Check icon" [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 12:34:04 GMT, Andy Herrick  wrote:

>> ?t.java failed "AssertionError: Failed: Check icon"
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/111

From aefimov at openjdk.java.net  Tue Jun 22 15:44:29 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 22 Jun 2021 15:44:29 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part II)
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 10:50:17 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Changes requested by aefimov (Committer).

src/java.base/share/classes/java/time/Instant.java line 852:

> 850:     public Instant plus(long amountToAdd, TemporalUnit unit) {
> 851:         if (unit instanceof ChronoUnit) {
> 852:             switch ((ChronoUnit) unit) {

It looks like we need to put `return` here, otherwise `UnsupportedTemporalTypeException` will be thrown every time the method is called:

jshell> Instant.now()
$2 ==> 2021-06-22T15:35:28.771128667Z

jshell> $2.plus(10L, ChronoUnit.SECONDS)
|  Exception java.time.temporal.UnsupportedTemporalTypeException: Unsupported unit: Seconds
|        at Instant.plus (Instant.java:862)
|        at (#5:1)

src/java.base/share/classes/java/time/ZonedDateTime.java line 1311:

> 1309:                 }
> 1310:                 default -> resolveLocal(dateTime.with(field, newValue));
> 1311:         };

It looks like that the closing braces `}` is missing here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From pconcannon at openjdk.java.net  Tue Jun 22 16:07:12 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 22 Jun 2021 16:07:12 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8269124: Added missing brace; fixed build issue

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4552/files
  - new: https://git.openjdk.java.net/jdk/pull/4552/files/a9497fd4..5fa4e3c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=00-01

  Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4552.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4552/head:pull/4552

PR: https://git.openjdk.java.net/jdk/pull/4552

From pconcannon at openjdk.java.net  Tue Jun 22 16:07:16 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 22 Jun 2021 16:07:16 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 15:40:12 GMT, Aleksei Efimov  wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269124: Added missing brace; fixed build issue
>
> src/java.base/share/classes/java/time/Instant.java line 852:
> 
>> 850:     public Instant plus(long amountToAdd, TemporalUnit unit) {
>> 851:         if (unit instanceof ChronoUnit) {
>> 852:             switch ((ChronoUnit) unit) {
> 
> It looks like we need to put `return` here, otherwise `UnsupportedTemporalTypeException` will be thrown every time the method is called:
> 
> jshell> Instant.now()
> $2 ==> 2021-06-22T15:35:28.771128667Z
> 
> jshell> $2.plus(10L, ChronoUnit.SECONDS)
> |  Exception java.time.temporal.UnsupportedTemporalTypeException: Unsupported unit: Seconds
> |        at Instant.plus (Instant.java:862)
> |        at (#5:1)

I've made that change now. See 5fa4e3c

> src/java.base/share/classes/java/time/ZonedDateTime.java line 1311:
> 
>> 1309:                 }
>> 1310:                 default -> resolveLocal(dateTime.with(field, newValue));
>> 1311:         };
> 
> It looks like that the closing braces `}` is missing here.

Hi Aleksei, thanks for spotting this. I've added that in now. See 5fa4e3c

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From rriggs at openjdk.java.net  Tue Jun 22 16:08:51 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Jun 2021 16:08:51 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Add java.util.Objects.newIdentity to supply a unique object with identity.
> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add @see link to java.lang.Object to Objects.newIdentity

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/112/files
  - new: https://git.openjdk.java.net/jdk17/pull/112/files/6c871906..42883a17

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk17/pull/112

From aefimov at openjdk.java.net  Tue Jun 22 16:17:31 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 22 Jun 2021 16:17:31 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 16:07:12 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added missing brace; fixed build issue

Thanks for quickly addressing the issues.
The latest version looks good to me.

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4552

From rriggs at openjdk.java.net  Tue Jun 22 16:18:11 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Jun 2021 16:18:11 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Add java.util.Objects.newIdentity to supply a unique object with identity.
> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright in BasicObjectsTest

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/112/files
  - new: https://git.openjdk.java.net/jdk17/pull/112/files/42883a17..bc73f6dd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk17/pull/112

From mchung at openjdk.java.net  Tue Jun 22 16:30:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 22 Jun 2021 16:30:27 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 16:18:11 GMT, Roger Riggs  wrote:

>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright in BasicObjectsTest

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From bpb at openjdk.java.net  Tue Jun 22 17:21:30 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 22 Jun 2021 17:21:30 GMT
Subject: RFR: 8268664: The documentation of the Scanner.hasNextLine is
 incorrect
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 04:22:34 GMT, Ian Graves  wrote:

> 8268664: The documentation of the Scanner.hasNextLine is incorrect

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4547

From bpb at openjdk.java.net  Tue Jun 22 17:23:29 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 22 Jun 2021 17:23:29 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 16:18:11 GMT, Roger Riggs  wrote:

>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright in BasicObjectsTest

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From iris at openjdk.java.net  Tue Jun 22 17:28:36 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 22 Jun 2021 17:28:36 GMT
Subject: RFR: 8268664: The documentation of the Scanner.hasNextLine is
 incorrect
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 04:22:34 GMT, Ian Graves  wrote:

> 8268664: The documentation of the Scanner.hasNextLine is incorrect

Associated CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4547

From naoto at openjdk.java.net  Tue Jun 22 17:31:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 22 Jun 2021 17:31:36 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 09:58:55 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon 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:
> 
>  - 8268469: Removed alignment of arrow operators in some cases; reverted logic of switch/case in LocalDate
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - 8268469: Removed excessive spacing; corrected misplaced comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - 8268469: Update java.time to use switch expressions

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4433

From iris at openjdk.java.net  Tue Jun 22 17:39:33 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 22 Jun 2021 17:39:33 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 16:07:12 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added missing brace; fixed build issue

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From iris at openjdk.java.net  Tue Jun 22 17:43:36 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 22 Jun 2021 17:43:36 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 09:58:55 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon 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:
> 
>  - 8268469: Removed alignment of arrow operators in some cases; reverted logic of switch/case in LocalDate
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - 8268469: Removed excessive spacing; corrected misplaced comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - 8268469: Update java.time to use switch expressions

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4433

From pconcannon at openjdk.java.net  Tue Jun 22 17:50:05 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 22 Jun 2021 17:50:05 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8269124: Added missing return

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4552/files
  - new: https://git.openjdk.java.net/jdk/pull/4552/files/5fa4e3c5..9c629c82

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4552.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4552/head:pull/4552

PR: https://git.openjdk.java.net/jdk/pull/4552

From naoto at openjdk.java.net  Tue Jun 22 17:50:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 22 Jun 2021 17:50:10 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 16:07:12 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added missing brace; fixed build issue

src/java.base/share/classes/java/time/Instant.java line 562:

> 560:     public int get(TemporalField field) {
> 561:         if (field instanceof ChronoField) {
> 562:             return switch ((ChronoField) field) {

Not really comment on the change itself, but Is this a leftover from the `instanceof` pattern variable exercise, or will we have another round for that? I see other locations which could be leftovers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From naoto at openjdk.java.net  Tue Jun 22 17:52:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 22 Jun 2021 17:52:30 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 16:18:11 GMT, Roger Riggs  wrote:

>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright in BasicObjectsTest

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From chegar at openjdk.java.net  Tue Jun 22 17:56:32 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 22 Jun 2021 17:56:32 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 09:58:55 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon 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:
> 
>  - 8268469: Removed alignment of arrow operators in some cases; reverted logic of switch/case in LocalDate
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - 8268469: Removed excessive spacing; corrected misplaced comments
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - Merge remote-tracking branch 'origin/master' into JDK-8268469
>  - 8268469: Update java.time to use switch expressions

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4433

From psandoz at openjdk.java.net  Tue Jun 22 17:57:27 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 22 Jun 2021 17:57:27 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v7]
In-Reply-To: <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 <8yRvKCvVqdLlGk-r_rwdTrdqHGYArdV1gaZwVj48TQY=.60035c0c-06b2-4f5f-99f9-029a3317f1b0@github.com>
Message-ID: 

On Tue, 22 Jun 2021 02:58:28 GMT, Yi Yang  wrote:

> I found that after solving the problem that Preconditions cannot be used during the VM startup, a series of functions such as String.checkIndex/checkOffset/.. can also be harmlessly replaced, but this changeset is somewhat large and may overwrite the previous review progress. If it will confuse the current review progress for reviewers involving in this PR, I'd like to file a new PR to do this change later.

Yes, I think that helps to review. It's often easier, review-wise, to have separate PRs for specific areas, rather than keep expanding an existing PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4507

From chegar at openjdk.java.net  Tue Jun 22 18:04:27 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 22 Jun 2021 18:04:27 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v3]
In-Reply-To: 
References: 
 
Message-ID: <3t8rxAL4nDNgOCiVhGR6DpeFyKV_iIaotaonsuIEyDI=.2498ea2d-6815-4c50-acab-703e9aefb81d@github.com>

On Tue, 22 Jun 2021 16:18:11 GMT, Roger Riggs  wrote:

>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright in BasicObjectsTest

src/java.base/share/classes/java/util/Objects.java line 492:

> 490:     /**
> 491:      * {@return a new instance of an unspecified class}
> 492:      * The object has a unique identity; no other references to it exist.

Is this a new javadoc style/tag ?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From lancea at openjdk.java.net  Tue Jun 22 18:12:30 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 22 Jun 2021 18:12:30 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 17:50:05 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added missing return

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From rriggs at openjdk.java.net  Tue Jun 22 18:50:31 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Jun 2021 18:50:31 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v3]
In-Reply-To: <3t8rxAL4nDNgOCiVhGR6DpeFyKV_iIaotaonsuIEyDI=.2498ea2d-6815-4c50-acab-703e9aefb81d@github.com>
References: 
 
 <3t8rxAL4nDNgOCiVhGR6DpeFyKV_iIaotaonsuIEyDI=.2498ea2d-6815-4c50-acab-703e9aefb81d@github.com>
Message-ID: 

On Tue, 22 Jun 2021 18:01:46 GMT, Chris Hegarty  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright in BasicObjectsTest
>
> src/java.base/share/classes/java/util/Objects.java line 492:
> 
>> 490:     /**
>> 491:      * {@return a new instance of an unspecified class}
>> 492:      * The object has a unique identity; no other references to it exist.
> 
> Is this a new javadoc style/tag ?

Yes, it optimizes the case where the first sentence and the @ return tags have the same string.
See [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778): Add javadoc tag to avoid duplication of return information in simple situations.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From herrick at openjdk.java.net  Tue Jun 22 19:12:33 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 22 Jun 2021 19:12:33 GMT
Subject: [jdk17] Integrated: JDK-8268404: [TESTBUG]
 tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError:
 Failed: Check icon"
In-Reply-To: 
References: 
Message-ID: <7fKIj4DUSa7Fdi2Q_E_YsTtU5OdZ2Vezhi0WVAoj0XQ=.1a0e165f-2ea0-4b4e-8609-6d83cb5d0454@github.com>

On Mon, 21 Jun 2021 20:21:58 GMT, Andy Herrick  wrote:

> ?t.java failed "AssertionError: Failed: Check icon"

This pull request has now been integrated.

Changeset: 35e4c272
Author:    Andy Herrick 
URL:       https://git.openjdk.java.net/jdk17/commit/35e4c2720df64ea6cb68ba8fb62aeeb0562c2907
Stats:     79 lines in 2 files changed: 0 ins; 59 del; 20 mod

8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk17/pull/111

From jlahoda at openjdk.java.net  Tue Jun 22 19:41:56 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 22 Jun 2021 19:41:56 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v3]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
Message-ID: 

On Fri, 18 Jun 2021 14:35:42 GMT, Maurizio Cimadamore  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating javadoc, code and tests as suggested.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:
> 
>> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
>> 174:      * implements a {@code switch} on a target of an enum type.  The static
>> 175:      * arguments are an array of case labels which must be non-null and of type
> 
> This sentence can still be improved and made cleared. Example:
> 
>> The static arguments are used to encode the case labels associated to the `switch` construct, where each label can be encoded as a `String` (e.g. to represent an enum constant), or, alternatively, as a `Class` (e.g. to represent a type test pattern whose type is an enum type).

Thanks. I've updated the javadoc and improved the validation a little, checking the `Class` objects provided.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From jlahoda at openjdk.java.net  Tue Jun 22 19:41:55 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 22 Jun 2021 19:41:55 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v4]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
> 
> How does this look?

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Updating javadoc, as suggested.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/06a1bebf..196e106f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=02-03

  Stats: 21 lines in 2 files changed: 17 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

PR: https://git.openjdk.java.net/jdk17/pull/81

From iris at openjdk.java.net  Tue Jun 22 19:58:36 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 22 Jun 2021 19:58:36 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v3]
In-Reply-To: 
References: 
 
Message-ID: <6AFaFw_5BAh18JyEH-KSfxhXyI9yHkIgD3Ig5LfkVJ0=.f8d06878-f307-4ace-8cb2-f11a14621c56@github.com>

On Tue, 22 Jun 2021 17:50:05 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added missing return

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From coffeys at openjdk.java.net  Tue Jun 22 20:08:03 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 22 Jun 2021 20:08:03 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
Message-ID: 

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Move TokenPoller to Runnable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/117/files
  - new: https://git.openjdk.java.net/jdk17/pull/117/files/2a168946..03af6494

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/117.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117

PR: https://git.openjdk.java.net/jdk17/pull/117

From github.com+6704669+asgibbons at openjdk.java.net  Tue Jun 22 20:47:55 2021
From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons)
Date: Tue, 22 Jun 2021 20:47:55 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
> 
> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
> 
> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
> 
> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
> 
> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
> 
> 
> Benchmark Name | Base Score | Optimized Score | Gain
> -- | -- | -- | --
> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review comments.
  
  1. Changed errorvec handling
  2. Removed unnecessary register copies and aliasing
  3. Streamlined mask generation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4368/files
  - new: https://git.openjdk.java.net/jdk/pull/4368/files/bb73df6c..e1b4af9e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=04-05

  Stats: 55 lines in 1 file changed: 0 ins; 29 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4368.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368

PR: https://git.openjdk.java.net/jdk/pull/4368

From mcimadamore at openjdk.java.net  Tue Jun 22 20:48:28 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 22 Jun 2021 20:48:28 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v4]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: 

On Tue, 22 Jun 2021 19:41:55 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating javadoc, as suggested.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:

> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
> 174:      * implements a {@code switch} on a target of an enum type. The static
> 175:      * arguments are used to encode the case labels associated to the switch

`String` and `Class` should appear in code blocks perhaps, or link tags? Also, I think this text could be improved by splitting the sentence by using a bullet list:


The static arguments are used to encode the case labels associated to the switch
construct, where each label can be encoded in two ways:
* as a String value, which represents the name of the enum constant associated with the label
* as a Class value, which represents the enum type associated with a type test pattern

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 218:

> 216:      * {@code Class} of the target enum type.
> 217:      * @throws Throwable if there is any error linking the call site
> 218:      * @jvms 4.4.6 The CONSTANT_NameAndType_info Structure

Not sure what we do for other bootstraps, but I wonder if the throws clause here should be more specific - for instance the LambdaMetafactory tells when an exception is gonna be triggered. Here it seems like there are a couple of cases which can be called out, where we know that linkage is going to fail.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From sviswanathan at openjdk.java.net  Tue Jun 22 21:07:30 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 22 Jun 2021 21:07:30 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 20:47:55 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments.
>   
>   1. Changed errorvec handling
>   2. Removed unnecessary register copies and aliasing
>   3. Streamlined mask generation

Marked as reviewed by sviswanathan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From amenkov at openjdk.java.net  Tue Jun 22 21:09:55 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 22 Jun 2021 21:09:55 GMT
Subject: RFR: 8260540: serviceability/jdwp/AllModulesCommandTest.java failed
 with "Debuggee error: 'ERROR: transport error 202: bind failed: Address
 already in use'"
Message-ID: 

Updated AllModulesCommandTest to use dynamic port launching debuggee.
Parsing debuggee listening address functionality is required in several tests (and we have other tests which need to be fixed the same way), so moved the code to new class in jdk.test.lib

-------------

Commit messages:
 - JDK-8260540

Changes: https://git.openjdk.java.net/jdk/pull/4560/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4560&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260540
  Stats: 121 lines in 7 files changed: 62 ins; 33 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4560/head:pull/4560

PR: https://git.openjdk.java.net/jdk/pull/4560

From sviswanathan at openjdk.java.net  Tue Jun 22 21:11:36 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 22 Jun 2021 21:11:36 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v6]
In-Reply-To: 
References: 
 
Message-ID: <-YJZMeuxz5By5y7uZnipoRkIB2A9Ha9cDADsb6MRR4M=.3e941c7c-2c4c-4524-9230-782001e8fc28@github.com>

On Tue, 22 Jun 2021 20:47:55 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments.
>   
>   1. Changed errorvec handling
>   2. Removed unnecessary register copies and aliasing
>   3. Streamlined mask generation

@asgibbons The patch looks good to me.

@vnkozlov We need one more review for this patch. Could you please help?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From almatvee at openjdk.java.net  Tue Jun 22 22:05:42 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 22 Jun 2021 22:05:42 GMT
Subject: [jdk17] RFR: 8269036: tools/jpackage/share/AppImagePackageTest.java
 failed with "hdiutil: create failed - Resource busy"
Message-ID: 

Looks like another "Resource busy" issue similar to recent fixes for "hdiutil convert" and "hdiutil detach". Workaround in same way by repeating "create" command. Modified RetryExecutor to pass write to file flag, otherwise "hdiutil create" might deadlock.
Also, repeat is done only for creating DMG using size instead of creating from app image. In some cases create DMG from app image might run for very long time and eventually fail, this is why fallback to create DMG from size was added.

-------------

Commit messages:
 - 8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"

Changes: https://git.openjdk.java.net/jdk17/pull/122/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=122&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269036
  Stats: 16 lines in 2 files changed: 13 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/122.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/122/head:pull/122

PR: https://git.openjdk.java.net/jdk17/pull/122

From bpb at openjdk.java.net  Wed Jun 23 00:15:35 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 23 Jun 2021 00:15:35 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear that
 it doesn't create the temporary directory
Message-ID: 

Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.

-------------

Commit messages:
 - Merge
 - 4847239: (spec) File.createTempFile() should make it clear that it doesn't create the temporary directory

Changes: https://git.openjdk.java.net/jdk/pull/4561/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4561&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-4847239
  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4561/head:pull/4561

PR: https://git.openjdk.java.net/jdk/pull/4561

From jwilhelm at openjdk.java.net  Wed Jun 23 00:31:30 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 00:31:30 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"
 - 8267652: c2 loop unrolling by 8 results in reading memory past array
 - 8267399: C2: java/text/Normalizer/ConformanceTest.java test failed with assertion
 - 8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken
 - 8268524: nmethod::post_compiled_method_load_event racingly called on zombie
 - 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec
 - 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling
 - 8268349: Provide clear run-time warnings about Security Manager deprecation
 - 8268293: VectorAPI cast operation on mask and shuffle is broken
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/0c693e2f...7bf4b35f

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4562/files
  Stats: 1931 lines in 60 files changed: 653 ins; 1061 del; 217 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4562/head:pull/4562

PR: https://git.openjdk.java.net/jdk/pull/4562

From github.com+6704669+asgibbons at openjdk.java.net  Wed Jun 23 00:31:55 2021
From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons)
Date: Wed, 23 Jun 2021 00:31:55 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v7]
In-Reply-To: 
References: 
Message-ID: 

> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
> 
> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
> 
> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
> 
> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
> 
> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
> 
> 
> Benchmark Name | Base Score | Optimized Score | Gain
> -- | -- | -- | --
> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fixing Windows build warnings

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4368/files
  - new: https://git.openjdk.java.net/jdk/pull/4368/files/e1b4af9e..58461b80

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=05-06

  Stats: 24 lines in 1 file changed: 8 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4368.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368

PR: https://git.openjdk.java.net/jdk/pull/4368

From asemenyuk at openjdk.java.net  Wed Jun 23 00:53:31 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 23 Jun 2021 00:53:31 GMT
Subject: [jdk17] RFR: 8269036:
 tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create
 failed - Resource busy"
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 21:59:43 GMT, Alexander Matveev  wrote:

> Looks like another "Resource busy" issue similar to recent fixes for "hdiutil convert" and "hdiutil detach". Workaround in same way by repeating "create" command. Modified RetryExecutor to pass write to file flag, otherwise "hdiutil create" might deadlock.
> Also, repeat is done only for creating DMG using size instead of creating from app image. In some cases create DMG from app image might run for very long time and eventually fail, this is why fallback to create DMG from size was added.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/122

From jwilhelm at openjdk.java.net  Wed Jun 23 01:09:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 01:09:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge
 - 8268290: Improve LockFreeQueue<> utility
   
   Reviewed-by: iwalulya, tschatzl
 - 8264941: Remove CodeCache::mark_for_evol_deoptimization() method
   
   Reviewed-by: kvn, vlivanov, sspitsyn
 - 8269031: linux x86_64 check for binutils 2.25 or higher after 8265783
   
   Reviewed-by: ihse, erikj
 - 8267657: Add missing PrintC1Statistics before incrementing counters
   
   Reviewed-by: iveresov
 - 8268857: Merge VM_PrintJNI and VM_PrintThreads and remove the unused field 'is_deadlock' of DeadlockCycle
   
   Reviewed-by: dholmes
 - 8269077: TestSystemGC uses "require vm.gc.G1" for large pages subtest
   
   Reviewed-by: tschatzl, kbarrett
 - Merge
 - 8268458: Add verification type for evacuation failures
   
   Reviewed-by: kbarrett, iwalulya
 - 8268952: Automatically update heap sizes in G1MonitoringScope
   
   Reviewed-by: kbarrett, iwalulya
 - ... and 49 more: https://git.openjdk.java.net/jdk/compare/35e4c272...7bf4b35f

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4562/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4562&range=01
  Stats: 16267 lines in 261 files changed: 13210 ins; 2433 del; 624 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4562/head:pull/4562

PR: https://git.openjdk.java.net/jdk/pull/4562

From jwilhelm at openjdk.java.net  Wed Jun 23 01:09:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 23 Jun 2021 01:09:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: <_z9pXnmkit5l3vbQ1LT3mAP67fTQ2wh8P8g7ScaZVGw=.91f3374b-1abd-416d-a80b-d0a540f6889e@github.com>

On Wed, 23 Jun 2021 00:21:57 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b6cfca8a
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/b6cfca8a89810c7ed63ebc34ed9855b66ebcb5d9
Stats:     1931 lines in 60 files changed: 653 ins; 1061 del; 217 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4562

From dholmes at openjdk.java.net  Wed Jun 23 02:20:32 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 23 Jun 2021 02:20:32 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 00:31:55 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing Windows build warnings

What testing has been done for this change? I do not see that the Github Actions have been run for this PR. Has this been tested on a range of x86 systems with differing AVX capabilities?

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From yyang at openjdk.java.net  Wed Jun 23 03:54:55 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 23 Jun 2021 03:54:55 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: 

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  tests rely on IOOBE exception message

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/2330ee38..ab1b509d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4507&range=06-07

  Stats: 104 lines in 2 files changed: 18 ins; 2 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

PR: https://git.openjdk.java.net/jdk/pull/4507

From alanb at openjdk.java.net  Wed Jun 23 06:23:28 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 23 Jun 2021 06:23:28 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey  wrote:

>> Sufficient permissions missing if this code was ever to run with SecurityManager. 
>> 
>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>> 
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move TokenPoller to Runnable

src/java.base/share/classes/module-info.java line 202:

> 200:         jdk.charsets,
> 201:         jdk.compiler,
> 202:         jdk.crypto.cryptoki,

At some point I'd like to see this re-visited so we can avoid exporting this package to modules defined to the platform class loader.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From sean.coffey at oracle.com  Wed Jun 23 07:10:45 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 23 Jun 2021 08:10:45 +0100
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads
In-Reply-To: <1a4b1ff4-9265-b31a-0a58-1cad4fa06b79@zeus.net.au>
References: 
 <1a4b1ff4-9265-b31a-0a58-1cad4fa06b79@zeus.net.au>
Message-ID: <1e660217-b2ba-8191-d2d6-8deb7a9719c7@oracle.com>

Thank for the feedback Peter. Comments inline.

On 22/06/2021 22:40, Peter Firmstone wrote:
> Was ever to run with SecurityManager?
I found the issue while porting to jdk8u where Solaris uses a 
configuration file with the SunPKCS11 Provider by default - We have 
tests to register Providers while SecurityManager is in place. This 
failed for SunPKCS11.
>
> When you see an AccessControlException, I'd recommend setting the 
> following security debug property, so you can capture the 
> ProtectionDomain that failed the access check: 
> -Djava.security.debug=access:failure? Clearly there's a 
> ProtectionDomain on the calling threads stack that doesn't have the 
> necessary permission.? If you knew which one it was, you could just 
> grant it java.lang.RuntimePermission "setContextClassLoader" 
> permission in the policy file.
Yes - that was one of my first actions. [1]. The jdk.crypto.cryptoki 
ProtectionDomain lacks the permission and rightly so IMO. The default 
policy doesn't grant "setContextClassLoader" permission to any JDK 
module. It's not required when we use InnocuousThread.
>
> In NativeResourceCleaner the original constructor is setting the 
> Context ClassLoader of the calling thread to null, prior to calling 
> the Thread superclass constructor, so that both the calling thread and 
> new thread will nave a null context ClassLoader.? In your new 
> implementation, you are asserting the context class loader of the 
> created thread is null, without setting the context ClassLoader of the 
> original calling thread, is that the intended behaviour?
>
> Alternatively you could set the context ClassLoader of the calling 
> thread to null using a PrivilegedAction, prior to creating the new 
> thread and restore it?
Use of InnocuousThread is made in various JDK classes for similar 
purpose where daemon threads need to be run with limited privilege. 
Similar use seen in networking and ldap classes.

>
> If the original intent was to set the context ClassLoader of the new 
> thread to null, then why not just do that, rather than use an assertion?
InnocuousThread sets this to null. The assert is just a belt and braces 
approach which is a useful check during test runs. Again, similar 
approach done in other JDK libraries.
>
> If assertions are not enabled it may run with a non null context 
> ClassLoader??? What are the consequences?? It appears to me, the fix 
> has created a bigger problem, rather than fixed it.? Just my 2 cents.

see above. We shouldn't have an issue. A non-null classloader would lead 
to classloader memory leak in some environments.

regards,
Sean.

>
> We use SecurityManager by default following principles of least 
> privilege (only the code paths we need to execute), and the original 
> reported bug is a non problem for us, we would capture the missing 
> permission and grant it, these are permission grants for Java 16:
>
> grant codebase "jrt:/jdk.crypto.cryptoki"
> {
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util";
> };
>
> grant codebase "jrt:/jdk.crypto.ec"
> {
> ??? permission java.security.SecurityPermission 
> "putProviderProperty.SunEC";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.jca";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.pkcs";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util.math";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util.math.intpoly";
> ??? permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.x509";
> };
>
> Good call making NativeResourceCleaner implement Runnable instead of 
> extending Thread though.


[1]

access: domain that failed ProtectionDomain (jrt:/jdk.crypto.cryptoki 
)
 ?jdk.internal.loader.ClassLoaders$PlatformClassLoader at 5433274e
 ?
 ?java.security.Permissions at 7006c658 (
 ?("java.io.FilePermission" "<>" "read")
 ?("java.net.SocketPermission" "localhost:0" "listen,resolve")
 ?("java.security.SecurityPermission" "clearProviderProperties.*")
 ?("java.security.SecurityPermission" 
"getProperty.auth.login.defaultCallbackHandler")
 ?("java.security.SecurityPermission" "putProviderProperty.*")
 ?("java.security.SecurityPermission" "authProvider.*")
 ?("java.security.SecurityPermission" "removeProviderProperty.*")
 ?("java.util.PropertyPermission" "java.specification.version" "read")
 ?("java.util.PropertyPermission" "java.vm.vendor" "read")
 ?("java.util.PropertyPermission" "path.separator" "read")
 ?("java.util.PropertyPermission" "os.version" "read")
 ?("java.util.PropertyPermission" "java.vendor.url" "read")
 ?("java.util.PropertyPermission" "java.vm.name" "read")
 ?("java.util.PropertyPermission" "java.vm.specification.version" "read")
 ?("java.util.PropertyPermission" "os.name" "read")
 ?("java.util.PropertyPermission" 
"sun.security.pkcs11.allowSingleThreadedModules" "read")
 ?("java.util.PropertyPermission" 
"sun.security.pkcs11.disableKeyExtraction" "read")
 ?("java.util.PropertyPermission" "java.version" "read")
 ?("java.util.PropertyPermission" "os.arch" "read")
 ?("java.util.PropertyPermission" "java.specification.vendor" "read")
 ?("java.util.PropertyPermission" "java.vm.specification.name" "read")
 ?("java.util.PropertyPermission" "file.separator" "read")
 ?("java.util.PropertyPermission" "line.separator" "read")
 ?("java.util.PropertyPermission" "java.vm.specification.vendor" "read")
 ?("java.util.PropertyPermission" "java.specification.name" "read")
 ?("java.util.PropertyPermission" "java.vendor" "read")
 ?("java.util.PropertyPermission" "java.vm.version" "read")
 ?("java.util.PropertyPermission" "jdk.crypto.KeyAgreement.legacyKDF" 
"read")
 ?("java.util.PropertyPermission" "java.class.version" "read")
 ?("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans.*")
 ?("java.lang.RuntimePermission" "accessClassInPackage.sun.security.*")
 ?("java.lang.RuntimePermission" 
"accessClassInPackage.com.sun.crypto.provider")
 ?("java.lang.RuntimePermission" "accessClassInPackage.com.apple.*")
 ?("java.lang.RuntimePermission" 
"accessClassInPackage.com.sun.java.swing.plaf.*")
 ?("java.lang.RuntimePermission" "accessSystemModules")
 ?("java.lang.RuntimePermission" "accessClassInPackage.sun.nio.ch")
 ?("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans")
 ?("java.lang.RuntimePermission" "loadLibrary.j2pkcs11")
)

Exception in thread "main" java.security.ProviderException: 
Initialization failed
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:386)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:117)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:114)
 ??????? at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:114)
 ??????? at 
java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:257)
 ??????? at 
java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:248)
 ??????? at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
 ??????? at 
java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:248)
 ??????? at 
java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:226)
 ??????? at 
java.base/sun.security.jca.ProviderList.loadAll(ProviderList.java:317)
 ??????? at 
java.base/sun.security.jca.ProviderList.removeInvalid(ProviderList.java:334)
 ??????? at 
java.base/sun.security.jca.Providers.getFullProviderList(Providers.java:175)
 ??????? at java.base/java.security.Security.getProviders(Security.java:458)
 ??????? at DefaultPKCS11.main(DefaultPKCS11.java:13)
Caused by: java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" "setContextClassLoader")
 ??????? 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.Thread.setContextClassLoader(Thread.java:1525)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$NativeResourceCleaner.(SunPKCS11.java:982)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.initToken(SunPKCS11.java:1193)
 ??????? at 
jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:377)
 ??????? ... 14 more


From myano at openjdk.java.net  Wed Jun 23 07:34:06 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 23 Jun 2021 07:34:06 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi all,
> 
> Could you please review the 8268457 bug fixes?
> 
> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
> This fix changes the processing for non-surrogate pairs to the else condition.

Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:

  remove unnecessally comments and add eof line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4474/files
  - new: https://git.openjdk.java.net/jdk/pull/4474/files/d5792a87..1183c2f6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4474&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4474&range=01-02

  Stats: 14 lines in 4 files changed: 0 ins; 11 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4474.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4474/head:pull/4474

PR: https://git.openjdk.java.net/jdk/pull/4474

From myano at openjdk.java.net  Wed Jun 23 07:34:09 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 23 Jun 2021 07:34:09 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v3]
In-Reply-To: <9Yr6xab5AYv8lh3HLpoX-F0mmIS1HPSq_Mos6S9AQ4g=.0cdbf2b7-7693-4bc6-b978-23e5710c1f01@github.com>
References: 
 
 
 <9Yr6xab5AYv8lh3HLpoX-F0mmIS1HPSq_Mos6S9AQ4g=.0cdbf2b7-7693-4bc6-b978-23e5710c1f01@github.com>
Message-ID: <3MrBLIQAVc9k-7sJWQblwMnMMICXgYLw8ujiSL0O1tY=.8e69d3f3-d11c-430b-b6f6-7d61da38a9fd@github.com>

On Fri, 18 Jun 2021 21:09:39 GMT, Joe Wang  wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java line 1454:
>> 
>>> 1452:                     writer.write(ch);  // no escaping in this case
>>> 1453:                     }
>>> 1454:                     else
>> 
>> I was suggesting removing the entire comment-out block if it is not needed (and confusing), but I will defer the decision to Joe.
>
> I agree. It's very obsolete. The comment-out block from line 1445 to 1454 can be removed.

I was mistaken. I deleted the entire comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From myano at openjdk.java.net  Wed Jun 23 07:37:26 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 23 Jun 2021 07:37:26 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <834MoQfyugTgA6-77bGzZ_mdW7WrW40xi7aMosT6ZfM=.dbd8a223-99a8-4a39-b9af-1a56fd731ba8@github.com>

On Fri, 18 Jun 2021 20:28:06 GMT, Naoto Sato  wrote:

>> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect the review comments
>
> test/jaxp/javax/xml/jaxp/unittest/transform/SurrogateTest1.xml line 4:
> 
>> 2: 
>> 3:     ??
>> 4: 
> 
> Add a new line at the end of the file (and other newly created files too).

I added a new line at the end of every new file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From chegar at openjdk.java.net  Wed Jun 23 10:07:34 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 23 Jun 2021 10:07:34 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 16:18:11 GMT, Roger Riggs  wrote:

>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright in BasicObjectsTest

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From chegar at openjdk.java.net  Wed Jun 23 10:08:24 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 23 Jun 2021 10:08:24 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:

> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
> 
> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Further details can be found in the original PR.
> 
> Testing: jtreg and jck testing with no regressions. A new regression test was developed.

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From pconcannon at openjdk.java.net  Wed Jun 23 10:42:27 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 23 Jun 2021 10:42:27 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 22 Jun 2021 17:27:58 GMT, Naoto Sato  wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269124: Added missing brace; fixed build issue
>
> src/java.base/share/classes/java/time/Instant.java line 562:
> 
>> 560:     public int get(TemporalField field) {
>> 561:         if (field instanceof ChronoField) {
>> 562:             return switch ((ChronoField) field) {
> 
> Not really comment on the change itself, but Is this a leftover from the `instanceof` pattern variable exercise, or will we have another round for that? I see other locations which could be leftovers.

Hi Naoto, I decided to only introduce the`instanceof` pattern variable where I thought it would add additional value to the code. In situations like this one, I thought there wasn't much point as the cast variable is only used once (in the switch). However, if you think I've overlooked something that would be beneficial to change, I'd be happy to take a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From jlahoda at openjdk.java.net  Wed Jun 23 11:58:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 11:58:10 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v4]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
 
Message-ID: 

On Tue, 22 Jun 2021 20:43:03 GMT, Maurizio Cimadamore  wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating javadoc, as suggested.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 175:
> 
>> 173:      * Bootstrap method for linking an {@code invokedynamic} call site that
>> 174:      * implements a {@code switch} on a target of an enum type. The static
>> 175:      * arguments are used to encode the case labels associated to the switch
> 
> `String` and `Class` should appear in code blocks perhaps, or link tags? Also, I think this text could be improved by splitting the sentence by using a bullet list:
> 
> 
> The static arguments are used to encode the case labels associated to the switch
> construct, where each label can be encoded in two ways:
> * as a String value, which represents the name of the enum constant associated with the label
> * as a Class value, which represents the enum type associated with a type test pattern

Thanks! I've (tried to) updated the javadoc as suggested.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From jlahoda at openjdk.java.net  Wed Jun 23 11:58:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 23 Jun 2021 11:58:06 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v5]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumConstant` that converts the enum constant name to the enum constant, returning `null`, if the constant does not exist. It delegates to `ConstantBootstraps.enumConstant` to do the actual conversion. And `typeSwitch` accepts `null`s as padding.
> 
> How does this look?

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Improving javadoc.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/196e106f..0c371364

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=03-04

  Stats: 13 lines in 1 file changed: 6 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

PR: https://git.openjdk.java.net/jdk17/pull/81

From aefimov at openjdk.java.net  Wed Jun 23 12:06:31 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 23 Jun 2021 12:06:31 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 17:50:05 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added missing return

Marked as reviewed by aefimov (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From avoitylov at openjdk.java.net  Wed Jun 23 12:23:25 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Wed, 23 Jun 2021 12:23:25 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 21 Jun 2021 16:49:30 GMT, Mandy Chung  wrote:

>> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
>> 
>> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
>> 
>> Further details can be found in the original PR.
>> 
>> Testing: jtreg and jck testing with no regressions. A new regression test was developed.
>
> @dholmes-ora @ChrisHegarty @plevart reviewed PR openjdk/jdk#3976.  Can you re-review this PR?

Thank you @mlchung @dholmes-ora @ChrisHegarty for re-reviews.

@AlanBateman is it ok with you?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From mbaesken at openjdk.java.net  Wed Jun 23 13:37:59 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 23 Jun 2021 13:37:59 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
> 
> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
> 
> 
>   if (!cg_infos[PIDS_IDX]._data_complete) {
>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>     // keep the other controller info, pids is optional
>   }

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjustments following Severins comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4518/files
  - new: https://git.openjdk.java.net/jdk/pull/4518/files/0e6ecb8e..afd7bf61

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=00-01

  Stats: 125 lines in 11 files changed: 56 ins; 48 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518

PR: https://git.openjdk.java.net/jdk/pull/4518

From mbaesken at openjdk.java.net  Wed Jun 23 13:41:28 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 23 Jun 2021 13:41:28 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 13:37:59 GMT, Matthias Baesken  wrote:

>> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
>> 
>> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
>> 
>> 
>>   if (!cg_infos[PIDS_IDX]._data_complete) {
>>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>>     // keep the other controller info, pids is optional
>>   }
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjustments following Severins comments

Hi Severin , thanks for all the comments.   I prepared a second version with those changes
added a couple of log_is_enabled checks like you suggested
moved limit_from_str to CgroupSubsystem
added helpers pids_max_val()  and swicthed to GET_CONTAINER_INFO_CPTR
pids_max() now returns -1 for unlimited/max , and the -3 is gone
moved limitFromString java coding to src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystem.java
added a better comment to test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java about pids hiearchy values

Regarding your questions about tests, I run the exisiting docker/cgroup related tests; and also checked 
the hs_err output (on SLES/Ubuntu)  for new added "maximum number of tasks"  (this is present because systemd cgroup usage).
But I think that the testing needs to be enhanced (e.g. with some added docker tests?).  Do you have some good suggestions
where I could look at existing (docker?) tests and  adjust those for the new pids.max ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From lancea at openjdk.java.net  Wed Jun 23 14:06:31 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 23 Jun 2021 14:06:31 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 07:34:06 GMT, Masanori Yano  wrote:

>> Hi all,
>> 
>> Could you please review the 8268457 bug fixes?
>> 
>> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
>> This fix changes the processing for non-surrogate pairs to the else condition.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessally comments and add eof line

The updated changes look reasonable to me.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4474

From sgehwolf at openjdk.java.net  Wed Jun 23 14:51:31 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 23 Jun 2021 14:51:31 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 23 Jun 2021 13:38:58 GMT, Matthias Baesken  wrote:

> But I think that the testing needs to be enhanced (e.g. with some added docker tests?). Do you have some good suggestions
> where I could look at existing (docker?) tests and adjust those for the new pids.max ?

Have a look at `test/hotspot/jtreg/containers/docker/TestMisc.java` which already does some assertions on `print_container_info()` output. Either extend that test with some actual pid limits (`--pids-limit=` option) in place or write a similar one. That would cover the hotspot side.

Then consider adding the pids limit to the `-Xshowsettings:system` output (see `LauncherHelper.printSystemMetrics()`) using the Java API and add a docker test using that in `test/jdk/jdk/internal/platform/docker/`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From naoto at openjdk.java.net  Wed Jun 23 16:38:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 23 Jun 2021 16:38:30 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 23 Jun 2021 10:39:06 GMT, Patrick Concannon  wrote:

>> src/java.base/share/classes/java/time/Instant.java line 562:
>> 
>>> 560:     public int get(TemporalField field) {
>>> 561:         if (field instanceof ChronoField) {
>>> 562:             return switch ((ChronoField) field) {
>> 
>> Not really comment on the change itself, but Is this a leftover from the `instanceof` pattern variable exercise, or will we have another round for that? I see other locations which could be leftovers.
>
> Hi Naoto, I decided to only introduce the`instanceof` pattern variable where I thought it would add additional value to the code. In situations like this one, I thought there wasn't much point as the cast variable is only used once (in the switch). However, if you think I've overlooked something that would be beneficial to change, I'd be happy to take a look.

I'd personally replace all the applicable locations, as otherwise, it would confuse why there are two idioms. But it is outside of this PR so probably for another day.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From naoto at openjdk.java.net  Wed Jun 23 16:38:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 23 Jun 2021 16:38:30 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 17:50:05 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added missing return

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From naoto at openjdk.java.net  Wed Jun 23 16:50:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 23 Jun 2021 16:50:30 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 00:06:25 GMT, Brian Burkhalter  wrote:

> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.

Looks good. Do we have a test case that verifies the behavior?

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4561

From bpb at openjdk.java.net  Wed Jun 23 17:04:29 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 23 Jun 2021 17:04:29 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 00:06:25 GMT, Brian Burkhalter  wrote:

> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.

Surprisingly it does not look like there is a verifying test. I checked it manually but I had better add a specific test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4561

From naoto at openjdk.java.net  Wed Jun 23 17:06:33 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 23 Jun 2021 17:06:33 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 07:34:06 GMT, Masanori Yano  wrote:

>> Hi all,
>> 
>> Could you please review the 8268457 bug fixes?
>> 
>> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
>> This fix changes the processing for non-surrogate pairs to the else condition.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessally comments and add eof line

Looks good. Thank you for the fix!

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4474

From dfuchs at openjdk.java.net  Wed Jun 23 17:57:31 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 23 Jun 2021 17:57:31 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: <-8itTd_L5z6m5xtgGIpw48oN06RxiTT83WNFWfFg4V0=.fbe7c07b-c454-4ba3-b350-e21bc38306f3@github.com>

On Wed, 23 Jun 2021 16:35:30 GMT, Naoto Sato  wrote:

>> Hi Naoto, I decided to only introduce the`instanceof` pattern variable where I thought it would add additional value to the code. In situations like this one, I thought there wasn't much point as the cast variable is only used once (in the switch). However, if you think I've overlooked something that would be beneficial to change, I'd be happy to take a look.
>
> I'd personally replace all the applicable locations, as otherwise, it would confuse why there are two idioms. But it is outside of this PR so probably for another day.

I agree with Naoto that it's a bit strange.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From iris at openjdk.java.net  Wed Jun 23 18:15:29 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 23 Jun 2021 18:15:29 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 07:34:06 GMT, Masanori Yano  wrote:

>> Hi all,
>> 
>> Could you please review the 8268457 bug fixes?
>> 
>> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
>> This fix changes the processing for non-surrogate pairs to the else condition.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessally comments and add eof line

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From rriggs at openjdk.java.net  Wed Jun 23 19:12:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 23 Jun 2021 19:12:06 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v4]
In-Reply-To: 
References: 
Message-ID: 

> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Improve exception cases and messages when the jdk.serialFilterFactory
  is misconfigured and test those faults.
  Fix typo in java.security-extra-factory test config

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/85/files
  - new: https://git.openjdk.java.net/jdk17/pull/85/files/cf6f5edb..0ac107e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=02-03

  Stats: 121 lines in 4 files changed: 112 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85

PR: https://git.openjdk.java.net/jdk17/pull/85

From psandoz at openjdk.java.net  Wed Jun 23 19:19:01 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 23 Jun 2021 19:19:01 GMT
Subject: [jdk17] RFR: 8269246: Scoped ByteBuffer vector access
Message-ID: 

The Foreign Memory API supports viewing a `MemorySegment` as a `ByteBuffer`, an instance of which can then be passed to the vector load/store access methods.

Such `ByteBuffer` access requires accesses are scoped (a method annotated with `ScopedMemoryAccess.Scoped`) and the `ByteBuffer`'s scope (instance of `ScopedMemoryAccess.Scope`) checked for validity. Thereby ensuring exceptional failure if the underlying segment is shared and is closed. 

All Vector tests pass on linux-x64, linux-aarch64, macosx-x64, and windows-x64.

-------------

Commit messages:
 - Move byte buffer test data specifics to separate class
 - Move scoped methods to ScopedMemoryAccess
 - 8269246: Scoped ByteBuffer vector access

Changes: https://git.openjdk.java.net/jdk17/pull/129/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=129&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269246
  Stats: 455 lines in 42 files changed: 186 ins; 95 del; 174 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/129.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/129/head:pull/129

PR: https://git.openjdk.java.net/jdk17/pull/129

From rriggs at openjdk.java.net  Wed Jun 23 19:21:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 23 Jun 2021 19:21:02 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Add java.util.Objects.newIdentity to supply a unique object with identity.
> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Updated spec of Objects.newIdentity with:
  "The class does not override any of the methods of {@code java.lang.Object}."

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/112/files
  - new: https://git.openjdk.java.net/jdk17/pull/112/files/bc73f6dd..eef1029c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk17/pull/112

From joehw at openjdk.java.net  Wed Jun 23 19:23:34 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 23 Jun 2021 19:23:34 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v3]
In-Reply-To: 
References: 
 
Message-ID: <5yC8fomW0n7kgKfEmqI-yqRbaMzb7BAyDkDuJFXz5Nk=.5301c0d4-ceb5-490f-b5b8-919b5e7e26d9@github.com>

On Wed, 23 Jun 2021 07:34:06 GMT, Masanori Yano  wrote:

>> Hi all,
>> 
>> Could you please review the 8268457 bug fixes?
>> 
>> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
>> This fix changes the processing for non-surrogate pairs to the else condition.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessally comments and add eof line

Marked as reviewed by joehw (Reviewer).

Thanks for the update. A full test passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From mcimadamore at openjdk.java.net  Wed Jun 23 20:13:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 23 Jun 2021 20:13:27 GMT
Subject: [jdk17] RFR: 8269246: Scoped ByteBuffer vector access
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 19:10:41 GMT, Paul Sandoz  wrote:

> The Foreign Memory API supports viewing a `MemorySegment` as a `ByteBuffer`, an instance of which can then be passed to the vector load/store access methods.
> 
> Such `ByteBuffer` access requires accesses are scoped (a method annotated with `ScopedMemoryAccess.Scoped`) and the `ByteBuffer`'s scope (instance of `ScopedMemoryAccess.Scope`) checked for validity. Thereby ensuring exceptional failure if the underlying segment is shared and is closed. 
> 
> All Vector tests pass on linux-x64, linux-aarch64, macosx-x64, and windows-x64.

Changes look good - thanks for taking the time to centralize the various vector operations inside ScopedMemoryAccess.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/129

From vromero at openjdk.java.net  Wed Jun 23 21:04:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 23 Jun 2021 21:04:44 GMT
Subject: RFR: 8266407: remove
 jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES
Message-ID: 

Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was not removed when Sealed Classes were made final because the build was failing without it. Now that the feature is final we should be able to safely removed it. This is the intention of this patch.

TIA,
Vicente

-------------

Commit messages:
 - 8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES

Changes: https://git.openjdk.java.net/jdk/pull/4578/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4578&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266407
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4578.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4578/head:pull/4578

PR: https://git.openjdk.java.net/jdk/pull/4578

From bchristi at openjdk.java.net  Wed Jun 23 22:04:29 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 23 Jun 2021 22:04:29 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 19:12:06 GMT, Roger Riggs  wrote:

>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve exception cases and messages when the jdk.serialFilterFactory
>   is misconfigured and test those faults.
>   Fix typo in java.security-extra-factory test config

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/85

From bpb at openjdk.java.net  Wed Jun 23 23:02:01 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 23 Jun 2021 23:02:01 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v2]
In-Reply-To: 
References: 
Message-ID: 

> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  4847239: Add test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4561/files
  - new: https://git.openjdk.java.net/jdk/pull/4561/files/cd931a77..453600c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4561&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4561&range=00-01

  Stats: 106 lines in 1 file changed: 106 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4561/head:pull/4561

PR: https://git.openjdk.java.net/jdk/pull/4561

From bpb at openjdk.java.net  Wed Jun 23 23:02:03 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 23 Jun 2021 23:02:03 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 00:06:25 GMT, Brian Burkhalter  wrote:

> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.

Test added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4561

From peter.firmstone at zeus.net.au  Thu Jun 24 00:18:31 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 24 Jun 2021 10:18:31 +1000
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads
In-Reply-To: <1e660217-b2ba-8191-d2d6-8deb7a9719c7@oracle.com>
References: 
 <1a4b1ff4-9265-b31a-0a58-1cad4fa06b79@zeus.net.au>
 <1e660217-b2ba-8191-d2d6-8deb7a9719c7@oracle.com>
Message-ID: 

Thanks Se?n,

A good explanation. :)

Solaris was a very good platform for exposing and debugging race 
conditions, of course we have very good static analysis now.

Regards,

Peter.

On 23/06/2021 5:10 pm, Se?n Coffey wrote:
> Thank for the feedback Peter. Comments inline.
>
> On 22/06/2021 22:40, Peter Firmstone wrote:
>> Was ever to run with SecurityManager?
> I found the issue while porting to jdk8u where Solaris uses a 
> configuration file with the SunPKCS11 Provider by default - We have 
> tests to register Providers while SecurityManager is in place. This 
> failed for SunPKCS11.
>>
>> When you see an AccessControlException, I'd recommend setting the 
>> following security debug property, so you can capture the 
>> ProtectionDomain that failed the access check: 
>> -Djava.security.debug=access:failure? Clearly there's a 
>> ProtectionDomain on the calling threads stack that doesn't have the 
>> necessary permission.? If you knew which one it was, you could just 
>> grant it java.lang.RuntimePermission "setContextClassLoader" 
>> permission in the policy file.
> Yes - that was one of my first actions. [1]. The jdk.crypto.cryptoki 
> ProtectionDomain lacks the permission and rightly so IMO. The default 
> policy doesn't grant "setContextClassLoader" permission to any JDK 
> module. It's not required when we use InnocuousThread.
>>
>> In NativeResourceCleaner the original constructor is setting the 
>> Context ClassLoader of the calling thread to null, prior to calling 
>> the Thread superclass constructor, so that both the calling thread 
>> and new thread will nave a null context ClassLoader.? In your new 
>> implementation, you are asserting the context class loader of the 
>> created thread is null, without setting the context ClassLoader of 
>> the original calling thread, is that the intended behaviour?
>>
>> Alternatively you could set the context ClassLoader of the calling 
>> thread to null using a PrivilegedAction, prior to creating the new 
>> thread and restore it?
> Use of InnocuousThread is made in various JDK classes for similar 
> purpose where daemon threads need to be run with limited privilege. 
> Similar use seen in networking and ldap classes.
>
>>
>> If the original intent was to set the context ClassLoader of the new 
>> thread to null, then why not just do that, rather than use an assertion?
> InnocuousThread sets this to null. The assert is just a belt and 
> braces approach which is a useful check during test runs. Again, 
> similar approach done in other JDK libraries.
>>
>> If assertions are not enabled it may run with a non null context 
>> ClassLoader??? What are the consequences?? It appears to me, the fix 
>> has created a bigger problem, rather than fixed it.? Just my 2 cents.
>
> see above. We shouldn't have an issue. A non-null classloader would 
> lead to classloader memory leak in some environments.
>
> regards,
> Sean.
>
>>
>> We use SecurityManager by default following principles of least 
>> privilege (only the code paths we need to execute), and the original 
>> reported bug is a non problem for us, we would capture the missing 
>> permission and grant it, these are permission grants for Java 16:
>>
>> grant codebase "jrt:/jdk.crypto.cryptoki"
>> {
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.util";
>> };
>>
>> grant codebase "jrt:/jdk.crypto.ec"
>> {
>> ??? permission java.security.SecurityPermission 
>> "putProviderProperty.SunEC";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.jca";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.pkcs";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.util";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.util.math";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.util.math.intpoly";
>> ??? permission java.lang.RuntimePermission 
>> "accessClassInPackage.sun.security.x509";
>> };
>>
>> Good call making NativeResourceCleaner implement Runnable instead of 
>> extending Thread though.
>
>
> [1]
>
> access: domain that failed ProtectionDomain (jrt:/jdk.crypto.cryptoki 
> )
> ?jdk.internal.loader.ClassLoaders$PlatformClassLoader at 5433274e
> ?
> ?java.security.Permissions at 7006c658 (
> ?("java.io.FilePermission" "<>" "read")
> ?("java.net.SocketPermission" "localhost:0" "listen,resolve")
> ?("java.security.SecurityPermission" "clearProviderProperties.*")
> ?("java.security.SecurityPermission" 
> "getProperty.auth.login.defaultCallbackHandler")
> ?("java.security.SecurityPermission" "putProviderProperty.*")
> ?("java.security.SecurityPermission" "authProvider.*")
> ?("java.security.SecurityPermission" "removeProviderProperty.*")
> ?("java.util.PropertyPermission" "java.specification.version" "read")
> ?("java.util.PropertyPermission" "java.vm.vendor" "read")
> ?("java.util.PropertyPermission" "path.separator" "read")
> ?("java.util.PropertyPermission" "os.version" "read")
> ?("java.util.PropertyPermission" "java.vendor.url" "read")
> ?("java.util.PropertyPermission" "java.vm.name" "read")
> ?("java.util.PropertyPermission" "java.vm.specification.version" "read")
> ?("java.util.PropertyPermission" "os.name" "read")
> ?("java.util.PropertyPermission" 
> "sun.security.pkcs11.allowSingleThreadedModules" "read")
> ?("java.util.PropertyPermission" 
> "sun.security.pkcs11.disableKeyExtraction" "read")
> ?("java.util.PropertyPermission" "java.version" "read")
> ?("java.util.PropertyPermission" "os.arch" "read")
> ?("java.util.PropertyPermission" "java.specification.vendor" "read")
> ?("java.util.PropertyPermission" "java.vm.specification.name" "read")
> ?("java.util.PropertyPermission" "file.separator" "read")
> ?("java.util.PropertyPermission" "line.separator" "read")
> ?("java.util.PropertyPermission" "java.vm.specification.vendor" "read")
> ?("java.util.PropertyPermission" "java.specification.name" "read")
> ?("java.util.PropertyPermission" "java.vendor" "read")
> ?("java.util.PropertyPermission" "java.vm.version" "read")
> ?("java.util.PropertyPermission" "jdk.crypto.KeyAgreement.legacyKDF" 
> "read")
> ?("java.util.PropertyPermission" "java.class.version" "read")
> ?("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans.*")
> ?("java.lang.RuntimePermission" "accessClassInPackage.sun.security.*")
> ?("java.lang.RuntimePermission" 
> "accessClassInPackage.com.sun.crypto.provider")
> ?("java.lang.RuntimePermission" "accessClassInPackage.com.apple.*")
> ?("java.lang.RuntimePermission" 
> "accessClassInPackage.com.sun.java.swing.plaf.*")
> ?("java.lang.RuntimePermission" "accessSystemModules")
> ?("java.lang.RuntimePermission" "accessClassInPackage.sun.nio.ch")
> ?("java.lang.RuntimePermission" "accessClassInPackage.com.sun.beans")
> ?("java.lang.RuntimePermission" "loadLibrary.j2pkcs11")
> )
>
> Exception in thread "main" java.security.ProviderException: 
> Initialization failed
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:386)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:117)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$1.run(SunPKCS11.java:114)
> ??????? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.configure(SunPKCS11.java:114)
> ??????? at 
> java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:257)
> ??????? at 
> java.base/sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:248)
> ??????? at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> ??????? at 
> java.base/sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:248)
> ??????? at 
> java.base/sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:226)
> ??????? at 
> java.base/sun.security.jca.ProviderList.loadAll(ProviderList.java:317)
> ??????? at 
> java.base/sun.security.jca.ProviderList.removeInvalid(ProviderList.java:334)
> ??????? at 
> java.base/sun.security.jca.Providers.getFullProviderList(Providers.java:175)
> ??????? at 
> java.base/java.security.Security.getProviders(Security.java:458)
> ??????? at DefaultPKCS11.main(DefaultPKCS11.java:13)
> Caused by: java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "setContextClassLoader")
> ??????? 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.Thread.setContextClassLoader(Thread.java:1525)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11$NativeResourceCleaner.(SunPKCS11.java:982)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.initToken(SunPKCS11.java:1193)
> ??????? at 
> jdk.crypto.cryptoki/sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:377)
> ??????? ... 14 more
>

From kvn at openjdk.java.net  Thu Jun 24 02:21:32 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 24 Jun 2021 02:21:32 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 00:31:55 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing Windows build warnings

I will run our internal testing before approving this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From kvn at openjdk.java.net  Thu Jun 24 06:11:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 24 Jun 2021 06:11:36 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v7]
In-Reply-To: 
References: 
 
Message-ID: <-y7T9-mZJhhRfkSPoi-F70b1Y9O0_ELxBUmKeqWZRNA=.bfb60493-b5bc-4cf5-954b-6ecd01d76161@github.com>

On Wed, 23 Jun 2021 00:31:55 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing Windows build warnings

I hit strange failure in compiler/intrinsics/base64/TestBase64.java test on Windows machine which have Intel 8167M cpu (AVX512).

#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff92bcbd99e, pid=24628, tid=6804
#
# Problematic frame:
# V  [jvm.dll+0xabd99e]  ObjectMonitor::object_peek+0xe
#

Current thread (0x0000016c923de2c0):  JavaThread "MainThread" [_thread_in_Java, id=6804, stack(0x00000060df600000,0x00000060df700000)]

Stack: [0x00000060df600000,0x00000060df700000],  sp=0x00000060df6fcb50,  free space=1010k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xabd99e]  ObjectMonitor::object_peek+0xe  (objectMonitor.cpp:304)
V  [jvm.dll+0xc48d5b]  ObjectSynchronizer::quick_enter+0x9b  (synchronizer.cpp:331)
V  [jvm.dll+0xb9b6f6]  SharedRuntime::monitor_enter_helper+0x36  (sharedRuntime.cpp:2112)
V  [jvm.dll+0x389894]  Runtime1::monitorenter+0x94  (c1_Runtime1.cpp:748)
C  0x0000016c99c4a757

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~RuntimeStub::monitorenter_nofpu Runtime1 stub
J 40 c1 java.util.concurrent.ConcurrentHashMap.putVal(Ljava/lang/Object;Ljava/lang/Object;Z)Ljava/lang/Object; java.base at 18-internal (432 bytes) @ 0x0000016c9a1801f8 [0x0000016c9a17e6a0+0x0000000000001b58]
J 43 c1 java.util.concurrent.ConcurrentHashMap.putIfAbsent(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base at 18-internal (8 bytes) @ 0x0000016c9a181c34 [0x0000016c9a181bc0+0x0000000000000074]
j  java.lang.ClassLoader.getClassLoadingLock(Ljava/lang/String;)Ljava/lang/Object;+23 java.base at 18-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Ljava/lang/String;Z)Ljava/lang/Class;+2 java.base at 18-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+3 java.base at 18-internal
j  jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 java.base at 18-internal
j  java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base at 18-internal
v  ~StubRoutines::call_stub
j  compiler.intrinsics.base64.TestBase64.test0(Lcompiler/intrinsics/base64/TestBase64$FileType;Lcompiler/intrinsics/base64/TestBase64$Base64Type;Ljava/util/Base64$Encoder;Ljava/util/Base64$Decoder;Ljava/lang/String;Ljava/lang/String;I)V+25
j  compiler.intrinsics.base64.TestBase64.main([Ljava/lang/String;)V+116
v  ~StubRoutines::call_stub
j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base at 18-internal
j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+133 java.base at 18-internal
j  jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 java.base at 18-internal
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 18-internal
j  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172
j  java.lang.Thread.run()V+11 java.base at 18-internal
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x00000000000000bc


Register to memory mapping:

RIP=0x00007ff92bcbd99e jvm.dll::ObjectMonitor::object_peek + 0xe
RAX=0x00000000000000ac is an unknown value
RBX=0x00000000000000ac is an unknown value
RCX=0x00000000000000ac is an unknown value
RDX=0x0 is NULL
RSP=0x00000060df6fcb50 is pointing into the stack for thread: 0x0000016c923de2c0
RBP=0x00000060df6fd110 is pointing into the stack for thread: 0x0000016c923de2c0
RSI=0x0000016c923de2c0 is a thread
RDI=0x0000016c923de2c0 is a thread
R8 =0x00000060df6fd1f0 is pointing into the stack for thread: 0x0000016c923de2c0
R9 =0x00000000000002f8 is an unknown value
R10=0x00007ff92b589800 jvm.dll::Runtime1::monitorenter + 0x0
R11=0x00000060df6fcc78 is pointing into the stack for thread: 0x0000016c923de2c0
R12=0x0 is NULL
R13=0x0000000000000200 is an unknown value
R14=0x0000000000000396 is an unknown value
R15=0x0000016c923de2c0 is a thread


Registers:
RAX=0x00000000000000ac, RBX=0x00000000000000ac, RCX=0x00000000000000ac, RDX=0x0000000000000000
RSP=0x00000060df6fcb50, RBP=0x00000060df6fd110, RSI=0x0000016c923de2c0, RDI=0x0000016c923de2c0
R8 =0x00000060df6fd1f0, R9 =0x00000000000002f8, R10=0x00007ff92b589800, R11=0x00000060df6fcc78
R12=0x0000000000000000, R13=0x0000000000000200, R14=0x0000000000000396, R15=0x0000016c923de2c0
RIP=0x00007ff92bcbd99e, EFLAGS=0x0000000000010206

Top of Stack: (sp=0x00000060df6fcb50)
0x00000060df6fcb50:   0000016c923de2c0 0000000000000000
0x00000060df6fcb60:   0000000000000000 00007ff92b8980a0
0x00000060df6fcb70:   0000016c923de2c0 00007ff92be48d5b
0x00000060df6fcb80:   00000000000000ac 000000074bd727d0
0x00000060df6fcb90:   0000000000000000 0000000000000000
0x00000060df6fcba0:   0000000000000000 00007ff92c1de2b0
0x00000060df6fcbb0:   0000016c923de2c0 00007ff92b8980a0
0x00000060df6fcbc0:   00000060df6fd1f0 00007ff92bd9b6f6
0x00000060df6fcbd0:   000000074bd727d0 0000016c923de2c0
0x00000060df6fcbe0:   00000060df6fd1f0 0000016c923de2c0
0x00000060df6fcbf0:   0000000000000000 0000000000000000
0x00000060df6fcc00:   0000000000000000 0000000000000000
0x00000060df6fcc10:   0000000000000000 0000000000000000
0x00000060df6fcc20:   000000074bd727d0 00007ff92b589894
0x00000060df6fcc30:   000000074bd727d0 00000060df6fd1f0
0x00000060df6fcc40:   0000016c923de2c0 00007ff92b8980a0 

Instructions: (pc=0x00007ff92bcbd99e)
0x00007ff92bcbd89e:   ff 48 8b c8 48 8b d8 48 8b 10 ff 52 48 48 8b 13
0x00007ff92bcbd8ae:   48 8b cb 84 c0 0f 84 83 00 00 00 ff 52 48 84 c0
0x00007ff92bcbd8be:   75 24 4c 8d 0d f1 7b 2e 00 ba 91 05 00 00 4c 8d
0x00007ff92bcbd8ce:   05 05 7c 2e 00 48 8d 0d c6 8b 2d 00 e8 71 aa a0
0x00007ff92bcbd8de:   ff e8 3c c3 01 00 8b 83 88 03 00 00 83 c0 fa a9
0x00007ff92bcbd8ee:   fd ff ff ff 74 23 4c 8d 0d c5 25 4f 00 41 b8 05
0x00007ff92bcbd8fe:   01 00 00 48 8d 15 e0 25 4f 00 b9 00 00 00 e0 e8
0x00007ff92bcbd90e:   4e a7 a0 ff e8 09 c3 01 00 48 8b 03 48 8b cb ff
0x00007ff92bcbd91e:   90 b8 00 00 00 84 c0 75 40 4c 8d 0d fa 25 4f 00
0x00007ff92bcbd92e:   ba 07 01 00 00 4c 8d 05 0e 26 4f 00 eb 1a ff 52
0x00007ff92bcbd93e:   40 84 c0 75 24 4c 8d 0d 7e 86 2d 00 ba 0b 01 00
0x00007ff92bcbd94e:   00 4c 8d 05 22 26 4f 00 48 8d 0d 8b 25 4f 00 e8
0x00007ff92bcbd95e:   ee a9 a0 ff e8 b9 c2 01 00 48 8b 44 24 30 48 8b
0x00007ff92bcbd96e:   48 10 48 85 c9 75 08 33 c0 48 83 c4 20 5b c3 48
0x00007ff92bcbd97e:   83 c4 20 5b 48 ff 25 8f f4 6f 00 cc cc cc cc cc
0x00007ff92bcbd98e:   cc cc 48 89 4c 24 08 48 83 ec 28 48 8b 44 24 30
0x00007ff92bcbd99e:   48 8b 48 10 48 85 c9 75 07 33 c0 48 83 c4 28 c3
0x00007ff92bcbd9ae:   48 83 c4 28 48 ff 25 5f f5 6f 00 cc cc cc cc cc
0x00007ff92bcbd9be:   cc cc 48 89 5c 24 18 48 89 54 24 10 48 89 4c 24
0x00007ff92bcbd9ce:   08 57 48 83 ec 20 48 8b 5c 24 30 48 8d 15 68 37
0x00007ff92bcbd9de:   4f 00 48 8b 7c 24 38 4c 8b c3 48 8b cf e8 50 8f
0x00007ff92bcbd9ee:   02 00 4c 8b 43 08 48 8d 15 6d 37 4f 00 48 8b cf
0x00007ff92bcbd9fe:   e8 3d 8f 02 00 48 8b 4b 10 48 85 c9 75 04 33 c0
0x00007ff92bcbda0e:   eb 06 ff 15 02 f5 6f 00 4c 8b c0 48 8d 15 60 37
0x00007ff92bcbda1e:   4f 00 48 8b cf e8 18 8f 02 00 48 8d 15 69 37 4f
0x00007ff92bcbda2e:   00 48 8b cf e8 09 8f 02 00 48 8d 15 6a 37 4f 00
0x00007ff92bcbda3e:   48 8b cf e8 fa 8e 02 00 48 8d 15 6b 37 4f 00 48
0x00007ff92bcbda4e:   8b cf e8 eb 8e 02 00 41 b8 2f 00 00 00 48 8d 15
0x00007ff92bcbda5e:   5e 37 4f 00 48 8b cf e8 d6 8e 02 00 48 8d 15 5f
0x00007ff92bcbda6e:   37 4f 00 48 8b cf e8 c7 8e 02 00 4c 8b 43 48 48
0x00007ff92bcbda7e:   8d 15 54 37 4f 00 48 8b cf e8 b4 8e 02 00 4c 8b
0x00007ff92bcbda8e:   43 50 48 8d 15 59 37 4f 00 48 8b cf e8 a1 8e 02 

Stack slot to memory mapping:
stack at sp + 0 slots: 0x0000016c923de2c0 is a thread
stack at sp + 1 slots: 0x0 is NULL
stack at sp + 2 slots: 0x0 is NULL
stack at sp + 3 slots: 0x00007ff92b8980a0 jvm.dll::VMEntryWrapper::VMEntryWrapper + 0x110
stack at sp + 4 slots: 0x0000016c923de2c0 is a thread
stack at sp + 5 slots: 0x00007ff92be48d5b jvm.dll::ObjectSynchronizer::quick_enter + 0x9b
stack at sp + 6 slots: 0x00000000000000ac is an unknown value
stack at sp + 7 slots: 0x000000074bd727d0 is an oop: java.util.concurrent.ConcurrentHashMap$Node 
{0x000000074bd727d0} - klass: 'java/util/concurrent/ConcurrentHashMap$Node'
 - ---- fields (total size 4 words):
 - final 'hash' 'I' @12  683507634 (28bd7fb2)
 - final 'key' 'Ljava/lang/Object;' @16  "java.util.Base64"{0x000000074bd72788} (e97ae4f1)
 - volatile 'val' 'Ljava/lang/Object;' @20  a 'java/lang/Object'{0x000000074bd727c0} (e97ae4f8)
 - volatile 'next' 'Ljava/util/concurrent/ConcurrentHashMap$Node;' @24  NULL (0)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From mbaesken at openjdk.java.net  Thu Jun 24 09:00:38 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 24 Jun 2021 09:00:38 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 23 Jun 2021 14:48:22 GMT, Severin Gehwolf  wrote:

> > But I think that the testing needs to be enhanced (e.g. with some added docker tests?). Do you have some good suggestions
> > where I could look at existing (docker?) tests and adjust those for the new pids.max ?
> 
> Have a look at `test/hotspot/jtreg/containers/docker/TestMisc.java` which already does some assertions on `print_container_info()` output. Either extend that test with some actual pid limits (`--pids-limit=` option) in place or write a similar one. That would cover the hotspot side.
> 
> Then consider adding the pids limit to the `-Xshowsettings:system` output (see `LauncherHelper.printSystemMetrics()`) using the Java API and add a docker test using that in `test/jdk/jdk/internal/platform/docker/`.

Hi Severin, thanks for the suggestions .
I'll have a look.

Best regards, Matthias

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From dfuchs at openjdk.java.net  Thu Jun 24 09:14:27 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 24 Jun 2021 09:14:27 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 19:12:06 GMT, Roger Riggs  wrote:

>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve exception cases and messages when the jdk.serialFilterFactory
>   is misconfigured and test those faults.
>   Fix typo in java.security-extra-factory test config

src/java.base/share/classes/java/io/ObjectInputFilter.java line 643:

> 641:                 } catch (RuntimeException re) {
> 642:                     configLog.log(ERROR,
> 643:                             "Error configuring filter: {0}", re);

You should either remove "{0}" from the string, or cast re to `Object` - as there is an overridden log method that takes a Throwable. If you want to display the exception stack trace, just call:


configLog.log(ERROR, "Error configuring filter", re);


If you don't want to display the stack trace, call:


configLog.log(ERROR, "Error configuring filter: {0}", (Object)re);

-------------

PR: https://git.openjdk.java.net/jdk17/pull/85

From pconcannon at openjdk.java.net  Thu Jun 24 10:16:09 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 24 Jun 2021 10:16:09 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v5]
In-Reply-To: 
References: 
Message-ID: <9gU8YD8xnBhGjhJ9u-KjtoTpw4h-56KQMuv3F9-rXiY=.93419fdc-560a-4135-a807-76a3f9c75634@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - 8268469: Removed alignment of arrow operators in some cases; reverted logic of switch/case in LocalDate
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - 8268469: Removed excessive spacing; corrected misplaced comments
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - 8268469: Update java.time to use switch expressions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4433/files
  - new: https://git.openjdk.java.net/jdk/pull/4433/files/24ae9e53..a841c3cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=03-04

  Stats: 5886 lines in 182 files changed: 2055 ins; 3315 del; 516 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4433/head:pull/4433

PR: https://git.openjdk.java.net/jdk/pull/4433

From lancea at openjdk.java.net  Thu Jun 24 10:29:29 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 24 Jun 2021 10:29:29 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 23:02:01 GMT, Brian Burkhalter  wrote:

>> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4847239: Add test

src/java.base/share/classes/java/io/File.java line 2116:

> 2114:      * abstract pathname is valid and denotes an existing directory, then the
> 2115:      * file will be created in that directory; otherwise, the file will not
> 2116:      * be created and an {@code IOException} will be thrown.  In no case will

I might suggest  reworking the 1st sentence as it is a tad long and we could probably reduce the 'then' usages.

Maybe instead of "In no case..." change to  "Under no circumstances ...."  Should it also indicate an IOException will be thrown if the directory does not exist?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4561

From pconcannon at openjdk.java.net  Thu Jun 24 11:15:55 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 24 Jun 2021 11:15:55 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8269124
 - 8269124: Added missing return
 - 8269124: Added missing brace; fixed build issue
 - 8269124: Update java.time to use switch expressions (part II)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4552/files
  - new: https://git.openjdk.java.net/jdk/pull/4552/files/9c629c82..0c6c4a2a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=02-03

  Stats: 5886 lines in 182 files changed: 2055 ins; 3315 del; 516 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4552.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4552/head:pull/4552

PR: https://git.openjdk.java.net/jdk/pull/4552

From pconcannon at openjdk.java.net  Thu Jun 24 12:01:05 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 24 Jun 2021 12:01:05 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v2]
In-Reply-To: <-8itTd_L5z6m5xtgGIpw48oN06RxiTT83WNFWfFg4V0=.fbe7c07b-c454-4ba3-b350-e21bc38306f3@github.com>
References: 
 
 
 
 
 <-8itTd_L5z6m5xtgGIpw48oN06RxiTT83WNFWfFg4V0=.fbe7c07b-c454-4ba3-b350-e21bc38306f3@github.com>
Message-ID: 

On Wed, 23 Jun 2021 17:54:30 GMT, Daniel Fuchs  wrote:

>> I'd personally replace all the applicable locations, as otherwise, it would confuse why there are two idioms. But it is outside of this PR so probably for another day.
>
> I agree with Naoto that it's a bit strange.

OK. If you guys think it's worthwhile. I've added in those changes now. Please see commit 3a1b716

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From pconcannon at openjdk.java.net  Thu Jun 24 12:01:04 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 24 Jun 2021 12:01:04 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8269124: Added instanceof pattern variables

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4552/files
  - new: https://git.openjdk.java.net/jdk/pull/4552/files/0c6c4a2a..3a1b7161

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4552&range=03-04

  Stats: 12 lines in 3 files changed: 0 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4552.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4552/head:pull/4552

PR: https://git.openjdk.java.net/jdk/pull/4552

From alanb at openjdk.java.net  Thu Jun 24 13:59:25 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 24 Jun 2021 13:59:25 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
 
Message-ID: <7kQ2YJFfUYjGFktoFhurt186BOXjoD7CSAb_8gTfmtQ=.0c652ab0-2b43-4b11-bdd5-df640535099b@github.com>

On Mon, 21 Jun 2021 13:26:14 GMT, Alan Bateman  wrote:

>> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
>> 
>> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
>> 
>> Further details can be found in the original PR.
>> 
>> Testing: jtreg and jck testing with no regressions. A new regression test was developed.
>
> @voitylov JDK 17 is an RDP 1 and I wonder if this long standing issue is critical or not. I've skimmed through the changes and I don't see any issue but if this is really intended for openjdk/jdk17 then I think it would be useful to have more eyes on it.

> @AlanBateman is it ok with you?

Okay with me but as a general point I don't think we should be fixing long standing issues in risky areas during RDP1. This is a change that really needs several months of bake time.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From rriggs at openjdk.java.net  Thu Jun 24 14:16:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 24 Jun 2021 14:16:27 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 24 Jun 2021 09:11:12 GMT, Daniel Fuchs  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve exception cases and messages when the jdk.serialFilterFactory
>>   is misconfigured and test those faults.
>>   Fix typo in java.security-extra-factory test config
>
> src/java.base/share/classes/java/io/ObjectInputFilter.java line 643:
> 
>> 641:                 } catch (RuntimeException re) {
>> 642:                     configLog.log(ERROR,
>> 643:                             "Error configuring filter: {0}", re);
> 
> You should either remove "{0}" from the string, or cast re to `Object` - as there is an overridden log method that takes a Throwable. If you want to display the exception stack trace, just call:
> 
> 
> configLog.log(ERROR, "Error configuring filter", re);
> 
> 
> If you don't want to display the stack trace, call:
> 
> 
> configLog.log(ERROR, "Error configuring filter: {0}", (Object)re);

Hard to spot that mis-use.
Also observed that if the jdk.serialFilter is ill formed (IAE), it gets logged but should also rethrow
the exception to prevent continuing without an expected filter.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/85

From kvn at openjdk.java.net  Thu Jun 24 14:53:32 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 24 Jun 2021 14:53:32 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v7]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 00:31:55 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing Windows build warnings

The rest of testing hs-tier1-4 and xcomp is finished and clean.
So this is the only failure. I attached hs_err file to RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From dfuchs at openjdk.java.net  Thu Jun 24 15:38:35 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 24 Jun 2021 15:38:35 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 12:01:04 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added instanceof pattern variables

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From psandoz at openjdk.java.net  Thu Jun 24 16:06:34 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 24 Jun 2021 16:06:34 GMT
Subject: [jdk17] Integrated: 8269246: Scoped ByteBuffer vector access
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 19:10:41 GMT, Paul Sandoz  wrote:

> The Foreign Memory API supports viewing a `MemorySegment` as a `ByteBuffer`, an instance of which can then be passed to the vector load/store access methods.
> 
> Such `ByteBuffer` access requires accesses are scoped (a method annotated with `ScopedMemoryAccess.Scoped`) and the `ByteBuffer`'s scope (instance of `ScopedMemoryAccess.Scope`) checked for validity. Thereby ensuring exceptional failure if the underlying segment is shared and is closed. 
> 
> All Vector tests pass on linux-x64, linux-aarch64, macosx-x64, and windows-x64.

This pull request has now been integrated.

Changeset: 63bcd333
Author:    Paul Sandoz 
URL:       https://git.openjdk.java.net/jdk17/commit/63bcd3336ecf77a8d256b243c13165397fc8e5bb
Stats:     455 lines in 42 files changed: 186 ins; 95 del; 174 mod

8269246: Scoped ByteBuffer vector access

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk17/pull/129

From github.com+6704669+asgibbons at openjdk.java.net  Thu Jun 24 17:02:03 2021
From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons)
Date: Thu, 24 Jun 2021 17:02:03 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v8]
In-Reply-To: 
References: 
Message-ID: 

> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
> 
> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
> 
> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
> 
> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
> 
> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
> 
> 
> Benchmark Name | Base Score | Optimized Score | Gain
> -- | -- | -- | --
> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26

Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fixed Windows register stomping.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4368/files
  - new: https://git.openjdk.java.net/jdk/pull/4368/files/58461b80..1729232c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4368&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4368.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4368/head:pull/4368

PR: https://git.openjdk.java.net/jdk/pull/4368

From github.com+6704669+asgibbons at openjdk.java.net  Thu Jun 24 17:17:43 2021
From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons)
Date: Thu, 24 Jun 2021 17:17:43 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v7]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 24 Jun 2021 14:50:01 GMT, Vladimir Kozlov  wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing Windows build warnings
>
> The rest of testing hs-tier1-4 and xcomp is finished and clean.
> So this is the only failure. I attached hs_err file to RFE.

Hi, @vnkozlov.  I just pushed a change that fixes a register overwrite.  Can you please start the tests again?

Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From naoto at openjdk.java.net  Thu Jun 24 17:27:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Jun 2021 17:27:31 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 12:01:04 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added instanceof pattern variables

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From lancea at openjdk.java.net  Thu Jun 24 17:55:30 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 24 Jun 2021 17:55:30 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v5]
In-Reply-To: 
References: 
 
Message-ID: <4E_jVbjEJQueUaM1VDj3g5nIXTbC76Tm8Ld5K7ffgDI=.7d0552c0-dfcc-468e-9b81-3339389c7aad@github.com>

On Thu, 24 Jun 2021 12:01:04 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added instanceof pattern variables

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From iris at openjdk.java.net  Thu Jun 24 18:03:27 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 24 Jun 2021 18:03:27 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 12:01:04 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added instanceof pattern variables

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From brian.burkhalter at oracle.com  Thu Jun 24 18:16:43 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 24 Jun 2021 18:16:43 +0000
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 


On Jun 24, 2021, at 3:29 AM, Lance Andersen > wrote:

src/java.base/share/classes/java/io/File.java line 2116:

2114:      * abstract pathname is valid and denotes an existing directory, then the
2115:      * file will be created in that directory; otherwise, the file will not
2116:      * be created and an {@code IOException} will be thrown.  In no case will

I might suggest  reworking the 1st sentence as it is a tad long and we could probably reduce the 'then' usages.

Maybe instead of "In no case..." change to  "Under no circumstances ...."

Good points, Lance. I updated the verbiage.

Should it also indicate an IOException will be thrown if the directory does not exist?

I think that this is implicit in the second sentence of the revised version.

From naoto at openjdk.java.net  Thu Jun 24 18:22:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Jun 2021 18:22:10 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 23:02:01 GMT, Brian Burkhalter  wrote:

>> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4847239: Add test

Thanks for adding the test. Some nits follow.

test/jdk/java/io/File/createTempFile/TargetDirectory.java line 58:

> 56:         if (Files.getFileStore(dir).supportsFileAttributeView("posix")) {
> 57:             PosixFileAttributeView view =
> 58:                 (PosixFileAttributeView)Files.getFileAttributeView(dir,

Casting seems not needed.

test/jdk/java/io/File/createTempFile/TargetDirectory.java line 83:

> 81:         try {
> 82:             File.createTempFile("readonly", null, target);
> 83:             throw new RuntimeException("Exception not thrown");

Probably replacing the message `Exception not thrown` with a more explanatory one would help, as there are other locations below, which could throw the same message.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4561

From bpb at openjdk.java.net  Thu Jun 24 18:22:05 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 24 Jun 2021 18:22:05 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v3]
In-Reply-To: 
References: 
Message-ID: 

> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  4847239: Modify File.createTempFile verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4561/files
  - new: https://git.openjdk.java.net/jdk/pull/4561/files/453600c1..0cd7310d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4561&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4561&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4561/head:pull/4561

PR: https://git.openjdk.java.net/jdk/pull/4561

From bpb at openjdk.java.net  Thu Jun 24 18:43:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 24 Jun 2021 18:43:00 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v4]
In-Reply-To: 
References: 
Message-ID: <7UZYlU_Odgq9lVasBlrHOJbWflPDABHuTo0UJYGCsw0=.9a9f3cd1-b9ca-405c-9d8f-32beb857617a@github.com>

> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.

Brian Burkhalter 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 two new commits since the last revision:

 - 4847239: Remove cast, improve exception messages in test
 - 4847239: Modify File.createTempFile verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4561/files
  - new: https://git.openjdk.java.net/jdk/pull/4561/files/0cd7310d..ce9d4ba6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4561&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4561&range=02-03

  Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4561/head:pull/4561

PR: https://git.openjdk.java.net/jdk/pull/4561

From bpb at openjdk.java.net  Thu Jun 24 18:43:06 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 24 Jun 2021 18:43:06 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 24 Jun 2021 17:40:55 GMT, Naoto Sato  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4847239: Add test
>
> test/jdk/java/io/File/createTempFile/TargetDirectory.java line 58:
> 
>> 56:         if (Files.getFileStore(dir).supportsFileAttributeView("posix")) {
>> 57:             PosixFileAttributeView view =
>> 58:                 (PosixFileAttributeView)Files.getFileAttributeView(dir,
> 
> Casting seems not needed.

Yes, I think you are correct.

> test/jdk/java/io/File/createTempFile/TargetDirectory.java line 83:
> 
>> 81:         try {
>> 82:             File.createTempFile("readonly", null, target);
>> 83:             throw new RuntimeException("Exception not thrown");
> 
> Probably replacing the message `Exception not thrown` with a more explanatory one would help, as there are other locations below, which could throw the same message.

I was not sure a message was even needed as one can identify what is happening by the line number in the stack trace. Probably clear messages would be better though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4561

From mchung at openjdk.java.net  Thu Jun 24 19:02:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 24 Jun 2021 19:02:53 GMT
Subject: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when
 accessing an arrayClass with a protected inner class as component class
Message-ID: 

`Lookup::accessClass` should determine the accessibility of the element type.  An array class is accessible if and only if its element type is accessible.

This also fixes a spec bug to document `@throws NullPointerException` if the argument is null.

Please review the CSR:
    https://bugs.openjdk.java.net/browse/JDK-8269312

-------------

Commit messages:
 - fix whitespace
 - JDK-8266269:  Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class

Changes: https://git.openjdk.java.net/jdk17/pull/137/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=137&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266269
  Stats: 103 lines in 5 files changed: 85 ins; 2 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/137/head:pull/137

PR: https://git.openjdk.java.net/jdk17/pull/137

From naoto at openjdk.java.net  Thu Jun 24 20:12:46 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Jun 2021 20:12:46 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v4]
In-Reply-To: <7UZYlU_Odgq9lVasBlrHOJbWflPDABHuTo0UJYGCsw0=.9a9f3cd1-b9ca-405c-9d8f-32beb857617a@github.com>
References: 
 <7UZYlU_Odgq9lVasBlrHOJbWflPDABHuTo0UJYGCsw0=.9a9f3cd1-b9ca-405c-9d8f-32beb857617a@github.com>
Message-ID: <8isW5UPC2vjQvybJBsqeCgnAnI7lowHdn3QkimBn7qM=.a5426457-1b92-4924-839d-4618ba68c579@github.com>

On Thu, 24 Jun 2021 18:43:00 GMT, Brian Burkhalter  wrote:

>> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.
>
> Brian Burkhalter 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.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4561

From lancea at openjdk.java.net  Thu Jun 24 20:12:49 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 24 Jun 2021 20:12:49 GMT
Subject: RFR: 4847239: (spec) File.createTempFile() should make it clear
 that it doesn't create the temporary directory [v4]
In-Reply-To: <7UZYlU_Odgq9lVasBlrHOJbWflPDABHuTo0UJYGCsw0=.9a9f3cd1-b9ca-405c-9d8f-32beb857617a@github.com>
References: 
 <7UZYlU_Odgq9lVasBlrHOJbWflPDABHuTo0UJYGCsw0=.9a9f3cd1-b9ca-405c-9d8f-32beb857617a@github.com>
Message-ID: 

On Thu, 24 Jun 2021 18:43:00 GMT, Brian Burkhalter  wrote:

>> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.
>
> Brian Burkhalter 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.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4561

From bpb at openjdk.java.net  Thu Jun 24 20:25:23 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 24 Jun 2021 20:25:23 GMT
Subject: RFR: 6633375: FileOutputStream_md.c should be merged into
 FileOutputStream.c
Message-ID: 

Merge identical Unix and Windows versions of FileOutputStream_md.c into single, common FileOutputStream.c.

-------------

Commit messages:
 - 6633375: FileOutputStream_md.c should be merged into FileOutputStream.c

Changes: https://git.openjdk.java.net/jdk/pull/4589/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4589&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6633375
  Stats: 77 lines in 2 files changed: 0 ins; 74 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4589.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4589/head:pull/4589

PR: https://git.openjdk.java.net/jdk/pull/4589

From joehw at openjdk.java.net  Thu Jun 24 20:44:31 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 24 Jun 2021 20:44:31 GMT
Subject: [jdk17] RFR: 8256919: BCEL: Utility.encode forget to close
Message-ID: 

Fix a regression caused by the previous BCEL update. The issue was fixed in the current BCEL repo with a reversal of the previous code, adding back "gos.close();". Note however, doing so will result in a warning: [try] explicit call to close() on an auto-closeable resource. This fix calls finish() instead.

-------------

Commit messages:
 - 8256919: BCEL: Utility.encode forget to close

Changes: https://git.openjdk.java.net/jdk17/pull/141/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=141&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256919
  Stats: 72 lines in 2 files changed: 72 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/141.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/141/head:pull/141

PR: https://git.openjdk.java.net/jdk17/pull/141

From lancea at openjdk.java.net  Thu Jun 24 21:02:59 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 24 Jun 2021 21:02:59 GMT
Subject: [jdk17] RFR: 8256919: BCEL: Utility.encode forget to close
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 20:36:29 GMT, Joe Wang  wrote:

> Fix a regression caused by the previous BCEL update. The issue was fixed in the current BCEL repo with a reversal of the previous code, adding back "gos.close();". Note however, doing so will result in a warning: [try] explicit call to close() on an auto-closeable resource. This fix calls finish() instead.

Looks OK to me

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/141

From naoto at openjdk.java.net  Thu Jun 24 21:06:22 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Jun 2021 21:06:22 GMT
Subject: RFR: 6633375: FileOutputStream_md.c should be merged into
 FileOutputStream.c
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 20:01:27 GMT, Brian Burkhalter  wrote:

> Merge identical Unix and Windows versions of FileOutputStream_md.c into single, common FileOutputStream.c.

Looks good. Would you consider removing `fos_fd` and passing it as a `jlong` as suggested in the issue?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4589

From rriggs at openjdk.java.net  Thu Jun 24 21:06:54 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 24 Jun 2021 21:06:54 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v5]
In-Reply-To: 
References: 
Message-ID: <54edtW9elwxhlAIae0aLuKTH1gJlEjkZNMH9ftxDjFM=.88829484-660a-43bb-b3fa-34350f816a62@github.com>

> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Enabled logging of filter factory actions and added logging.properties config file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/85/files
  - new: https://git.openjdk.java.net/jdk17/pull/85/files/0ac107e4..89df22e7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=03-04

  Stats: 99 lines in 6 files changed: 91 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85

PR: https://git.openjdk.java.net/jdk17/pull/85

From bpb at openjdk.java.net  Thu Jun 24 21:08:02 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 24 Jun 2021 21:08:02 GMT
Subject: [jdk17] RFR: 8256919: BCEL: Utility.encode forget to close
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 20:36:29 GMT, Joe Wang  wrote:

> Fix a regression caused by the previous BCEL update. The issue was fixed in the current BCEL repo with a reversal of the previous code, adding back "gos.close();". Note however, doing so will result in a warning: [try] explicit call to close() on an auto-closeable resource. This fix calls finish() instead.

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/141

From naoto at openjdk.java.net  Thu Jun 24 21:12:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Jun 2021 21:12:00 GMT
Subject: [jdk17] RFR: 8256919: BCEL: Utility.encode forget to close
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 20:36:29 GMT, Joe Wang  wrote:

> Fix a regression caused by the previous BCEL update. The issue was fixed in the current BCEL repo with a reversal of the previous code, adding back "gos.close();". Note however, doing so will result in a warning: [try] explicit call to close() on an auto-closeable resource. This fix calls finish() instead.

`@Last Modified:` needs to be updated. Otherwise looks good.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/141

From bpb at openjdk.java.net  Thu Jun 24 21:16:06 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 24 Jun 2021 21:16:06 GMT
Subject: RFR: 6633375: FileOutputStream_md.c should be merged into
 FileOutputStream.c
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 20:01:27 GMT, Brian Burkhalter  wrote:

> Merge identical Unix and Windows versions of FileOutputStream_md.c into single, common FileOutputStream.c.

The `fileOpen()`, `writeSingle()`, and `writeBytes()` functions called here all expect to receive a field ID. This might be worth investigating as a separate issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4589

From naoto at openjdk.java.net  Thu Jun 24 21:25:00 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Jun 2021 21:25:00 GMT
Subject: RFR: 6633375: FileOutputStream_md.c should be merged into
 FileOutputStream.c
In-Reply-To: 
References: 
Message-ID: <-jwDV86mbLMgNwCbVDRRvXjY61c9DbIM9dpnjC4QNlw=.46d51913-3387-43c7-a5ee-975300b469ce@github.com>

On Thu, 24 Jun 2021 20:01:27 GMT, Brian Burkhalter  wrote:

> Merge identical Unix and Windows versions of FileOutputStream_md.c into single, common FileOutputStream.c.

Fine by me.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4589

From bpb at openjdk.java.net  Thu Jun 24 21:25:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 24 Jun 2021 21:25:00 GMT
Subject: RFR: 6633375: FileOutputStream_md.c should be merged into
 FileOutputStream.c
In-Reply-To: <-jwDV86mbLMgNwCbVDRRvXjY61c9DbIM9dpnjC4QNlw=.46d51913-3387-43c7-a5ee-975300b469ce@github.com>
References: 
 <-jwDV86mbLMgNwCbVDRRvXjY61c9DbIM9dpnjC4QNlw=.46d51913-3387-43c7-a5ee-975300b469ce@github.com>
Message-ID: 

On Thu, 24 Jun 2021 21:20:29 GMT, Naoto Sato  wrote:

> Fine by me.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4589

From mchung at openjdk.java.net  Thu Jun 24 21:27:07 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 24 Jun 2021 21:27:07 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:

> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
> 
> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Further details can be found in the original PR.
> 
> Testing: jtreg and jck testing with no regressions. A new regression test was developed.

This is a risky area and I agree it needs some bake time. The fix has been ready for some time but it takes longer than we hope to get this reviewed and approved (I was one causing the delay).  I am not uncomfortable getting this in JDK 17 but I will  not object if others think this should be fixed in JDK 18 (and backport to 17 update if desirable) as this is a long standing issue and no urgency to get this fixed.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From joehw at openjdk.java.net  Thu Jun 24 21:41:48 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 24 Jun 2021 21:41:48 GMT
Subject: [jdk17] RFR: 8256919: BCEL: Utility.encode forget to close [v2]
In-Reply-To: 
References: 
Message-ID: 

> Fix a regression caused by the previous BCEL update. The issue was fixed in the current BCEL repo with a reversal of the previous code, adding back "gos.close();". Note however, doing so will result in a warning: [try] explicit call to close() on an auto-closeable resource. This fix calls finish() instead.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  update LastModified

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/141/files
  - new: https://git.openjdk.java.net/jdk17/pull/141/files/27840892..8cd786ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=141&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=141&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/141.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/141/head:pull/141

PR: https://git.openjdk.java.net/jdk17/pull/141

From joehw at openjdk.java.net  Thu Jun 24 21:41:48 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 24 Jun 2021 21:41:48 GMT
Subject: [jdk17] RFR: 8256919: BCEL: Utility.encode forget to close
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 20:36:29 GMT, Joe Wang  wrote:

> Fix a regression caused by the previous BCEL update. The issue was fixed in the current BCEL repo with a reversal of the previous code, adding back "gos.close();". Note however, doing so will result in a warning: [try] explicit call to close() on an auto-closeable resource. This fix calls finish() instead.

Thanks Naoto, updated. Thanks Lance and Brian for the quick review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/141

From naoto at openjdk.java.net  Thu Jun 24 21:48:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Jun 2021 21:48:06 GMT
Subject: [jdk17] RFR: 8256919: BCEL: Utility.encode forget to close [v2]
In-Reply-To: 
References: 
 
Message-ID: <0KgmflI9O_ZDI5aZOKGyp9uYPeuGWVGP4_JK6ZlQAHo=.9ca65a4d-04ba-4f3d-bd1e-81ac97dfc60e@github.com>

On Thu, 24 Jun 2021 21:41:48 GMT, Joe Wang  wrote:

>> Fix a regression caused by the previous BCEL update. The issue was fixed in the current BCEL repo with a reversal of the previous code, adding back "gos.close();". Note however, doing so will result in a warning: [try] explicit call to close() on an auto-closeable resource. This fix calls finish() instead.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update LastModified

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/141

From kvn at openjdk.java.net  Thu Jun 24 23:00:05 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 24 Jun 2021 23:00:05 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 17:02:03 GMT, Scott Gibbons  wrote:

>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
>> 
>> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
>> 
>> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
>> 
>> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
>> 
>> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
>> 
>> 
>> Benchmark Name | Base Score | Optimized Score | Gain
>> -- | -- | -- | --
>> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
>> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
>> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
>> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
>> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
>> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
>> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
>> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
>> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
>> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
>> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
>> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
>> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
>> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
>> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
>> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
>> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
>> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
>> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
>> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
>> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
>> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
>> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
>> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
>> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
>> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
>> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
>> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
>> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
>> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
>> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
>> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
>> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
>> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
>> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
>> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26
>
> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed Windows register stomping.

Latest update fixed TestBase64.java test issue.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4368

From duke at openjdk.java.net  Thu Jun 24 23:03:08 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 24 Jun 2021 23:03:08 GMT
Subject: Withdrawn: 8173970: jar tool should have a way to extract to a
 directory
In-Reply-To: 
References: 
Message-ID: 

On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2752

From bpb at openjdk.java.net  Fri Jun 25 00:13:21 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 00:13:21 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0
 not consistent with InputStream when at EOF
Message-ID: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>

Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.

-------------

Commit messages:
 - 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

Changes: https://git.openjdk.java.net/jdk/pull/4591/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6766844
  Stats: 16 lines in 2 files changed: 11 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4591.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4591/head:pull/4591

PR: https://git.openjdk.java.net/jdk/pull/4591

From joehw at openjdk.java.net  Fri Jun 25 01:07:06 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 25 Jun 2021 01:07:06 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF
In-Reply-To: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
Message-ID: 

On Fri, 25 Jun 2021 00:04:48 GMT, Brian Burkhalter  wrote:

> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.

Marked as reviewed by joehw (Reviewer).

Looks good to me. Maybe add the bug id to the @bug tag of the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From bpb at openjdk.java.net  Fri Jun 25 01:39:21 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 01:39:21 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
Message-ID: 

> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  6766844: Add bug ID to test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4591/files
  - new: https://git.openjdk.java.net/jdk/pull/4591/files/3ea4e18d..68b6f089

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4591.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4591/head:pull/4591

PR: https://git.openjdk.java.net/jdk/pull/4591

From bpb at openjdk.java.net  Fri Jun 25 01:39:22 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 01:39:22 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF
In-Reply-To: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
Message-ID: 

On Fri, 25 Jun 2021 00:04:48 GMT, Brian Burkhalter  wrote:

> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.

Yeah I overlooked adding the bug ID to the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From vdyakov at openjdk.java.net  Fri Jun 25 02:08:00 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Fri, 25 Jun 2021 02:08:00 GMT
Subject: [jdk17] RFR: 8269036:
 tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create
 failed - Resource busy"
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 21:59:43 GMT, Alexander Matveev  wrote:

> Looks like another "Resource busy" issue similar to recent fixes for "hdiutil convert" and "hdiutil detach". Workaround in same way by repeating "create" command. Modified RetryExecutor to pass write to file flag, otherwise "hdiutil create" might deadlock.
> Also, repeat is done only for creating DMG using size instead of creating from app image. In some cases create DMG from app image might run for very long time and eventually fail, this is why fallback to create DMG from size was added.

@andyherrick please review

-------------

PR: https://git.openjdk.java.net/jdk17/pull/122

From sviswanathan at openjdk.java.net  Fri Jun 25 03:23:08 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 25 Jun 2021 03:23:08 GMT
Subject: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512
 [v7]
In-Reply-To: 
References: 
 
 
Message-ID: <6kkhnovupJKFv06Bz6fi1bpme2eOrsytWTs34mU5g0c=.f7f01265-f4ce-4607-af39-daecd7d5ef90@github.com>

On Thu, 24 Jun 2021 14:50:01 GMT, Vladimir Kozlov  wrote:

>> Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing Windows build warnings
>
> The rest of testing hs-tier1-4 and xcomp is finished and clean.
> So this is the only failure. I attached hs_err file to RFE.

Thanks a lot @vnkozlov for the review and test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From github.com+6704669+asgibbons at openjdk.java.net  Fri Jun 25 03:23:09 2021
From: github.com+6704669+asgibbons at openjdk.java.net (Scott Gibbons)
Date: Fri, 25 Jun 2021 03:23:09 GMT
Subject: Integrated: 8268276: Base64 Decoding optimization for x86 using
 AVX-512
In-Reply-To: 
References: 
Message-ID: <6kPmBbPIBQ8tVmezz0Rp22gFotQ7nF2e0i93njbGI5k=.f0e06a2f-506f-41e9-bdbf-004fbc2b3398@github.com>

On Fri, 4 Jun 2021 20:55:51 GMT, Scott Gibbons  wrote:

> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. Also allows for performance improvement for non-AVX-512 enabled platforms. Due to the nature of MIME-encoded inputs, modify the intrinsic signature to accept an additional parameter (isMIME) for fast-path MIME decoding.
> 
> A change was made to the signature of DecodeBlock in Base64.java to provide the intrinsic information as to whether MIME decoding was being done.  This allows for the intrinsic to bypass the expensive setup of zmm registers from AVX tables, knowing there may be invalid Base64 characters every 76 characters or so.  A change was also made here removing the restriction that the intrinsic must return an even multiple of 3 bytes decoded.  This implementation handles the pad characters at the end of the string and will return the actual number of characters decoded.
> 
> The AVX portion of this code will decode in blocks of 256 bytes per loop iteration, then in chunks of 64 bytes, followed by end fixup decoding.  The non-AVX code is an assembly-optimized version of the java DecodeBlock and behaves identically.
> 
> Running the Base64Decode benchmark, this change increases decode performance by an average of 2.6x with a maximum 19.7x for buffers > ~20k.  The numbers are given in the table below.
> 
> **Base Score** is without intrinsic support, **Optimized Score** is using this intrinsic, and **Gain** is **Base** / **Optimized**.
> 
> 
> Benchmark Name | Base Score | Optimized Score | Gain
> -- | -- | -- | --
> testBase64Decode size 1 | 15.36 | 15.32 | 1.00
> testBase64Decode size 3 | 17.00 | 16.72 | 1.02
> testBase64Decode size 7 | 20.60 | 18.82 | 1.09
> testBase64Decode size 32 | 34.21 | 26.77 | 1.28
> testBase64Decode size 64 | 54.43 | 38.35 | 1.42
> testBase64Decode size 80 | 66.40 | 48.34 | 1.37
> testBase64Decode size 96 | 73.16 | 52.90 | 1.38
> testBase64Decode size 112 | 84.93 | 51.82 | 1.64
> testBase64Decode size 512 | 288.81 | 32.04 | 9.01
> testBase64Decode size 1000 | 560.48 | 40.79 | 13.74
> testBase64Decode size 20000 | 9530.28 | 483.37 | 19.72
> testBase64Decode size 50000 | 24552.24 | 1735.07 | 14.15
> testBase64MIMEDecode size 1 | 22.87 | 21.36 | 1.07
> testBase64MIMEDecode size 3 | 27.79 | 25.32 | 1.10
> testBase64MIMEDecode size 7 | 44.74 | 43.81 | 1.02
> testBase64MIMEDecode size 32 | 142.69 | 129.56 | 1.10
> testBase64MIMEDecode size 64 | 256.90 | 243.80 | 1.05
> testBase64MIMEDecode size 80 | 311.60 | 310.80 | 1.00
> testBase64MIMEDecode size 96 | 364.00 | 346.66 | 1.05
> testBase64MIMEDecode size 112 | 472.88 | 394.78 | 1.20
> testBase64MIMEDecode size 512 | 1814.96 | 1671.28 | 1.09
> testBase64MIMEDecode size 1000 | 3623.50 | 3227.61 | 1.12
> testBase64MIMEDecode size 20000 | 70484.09 | 64940.77 | 1.09
> testBase64MIMEDecode size 50000 | 191732.34 | 158158.95 | 1.21
> testBase64WithErrorInputsDecode size 1 | 1531.02 | 1185.19 | 1.29
> testBase64WithErrorInputsDecode size 3 | 1306.59 | 1170.99 | 1.12
> testBase64WithErrorInputsDecode size 7 | 1238.11 | 1176.62 | 1.05
> testBase64WithErrorInputsDecode size 32 | 1346.46 | 1138.47 | 1.18
> testBase64WithErrorInputsDecode size 64 | 1195.28 | 1172.52 | 1.02
> testBase64WithErrorInputsDecode size 80 | 1469.00 | 1180.94 | 1.24
> testBase64WithErrorInputsDecode size 96 | 1434.48 | 1167.74 | 1.23
> testBase64WithErrorInputsDecode size 112 | 1440.06 | 1162.56 | 1.24
> testBase64WithErrorInputsDecode size 512 | 1362.79 | 1193.42 | 1.14
> testBase64WithErrorInputsDecode size 1000 | 1426.07 | 1194.44 | 1.19
> testBase64WithErrorInputsDecode size   20000 | 1398.44 | 1138.17 | 1.23
> testBase64WithErrorInputsDecode size   50000 | 1409.41 | 1114.16 | 1.26

This pull request has now been integrated.

Changeset: c37988d0
Author:    Scott Gibbons 
Committer: Sandhya Viswanathan 
URL:       https://git.openjdk.java.net/jdk/commit/c37988d0793b24d98d285530dfda69999a227937
Stats:     753 lines in 12 files changed: 735 ins; 4 del; 14 mod

8268276: Base64 Decoding optimization for x86 using AVX-512

Reviewed-by: erikj, sviswanathan, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/4368

From joehw at openjdk.java.net  Fri Jun 25 05:49:05 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 25 Jun 2021 05:49:05 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Add bug ID to test

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From alanb at openjdk.java.net  Fri Jun 25 07:59:02 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 25 Jun 2021 07:59:02 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: <4kE_IYULrGs8m1G5FK1xL0MPfWlcXVRO6wOZvF9AeME=.e4e21bc2-b7a9-4dba-b1d0-01054ae674dd@github.com>

On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Add bug ID to test

I realize I submitted this issue a long time ago but I think we have to proceed with caution as it is changing long standing behavior. Reading with len==0 will arise with code that is reading in a loop and the "previous read" completely fills the array and reads all remaining bytes. It's possible that there is existing code that will break with this change. I've added the "csr" label for now. If this changes goes ahead then it will need a release note too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From chris.hegarty at oracle.com  Fri Jun 25 08:25:42 2021
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 25 Jun 2021 08:25:42 +0000
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
 
Message-ID: <7D591CD3-EB75-4C58-99A5-77F7163CBC9E@oracle.com>



> On 24 Jun 2021, at 22:27, Mandy Chung  wrote:
> 
> On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:
> 
>> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
>> 
>> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
>> 
>> Further details can be found in the original PR.
>> 
>> Testing: jtreg and jck testing with no regressions. A new regression test was developed.
> 
> This is a risky area and I agree it needs some bake time. The fix has been ready for some time but it takes longer than we hope to get this reviewed and approved (I was one causing the delay).  I am not uncomfortable getting this in JDK 17 but I will  not object if others think this should be fixed in JDK 18 (and backport to 17 update if desirable) as this is a long standing issue and no urgency to get this fixed.

Fixing initially in 18, allowing some ?bake? time, then considering a backport to a 17 update, seems prudent.

-Chris.

From chegar at openjdk.java.net  Fri Jun 25 08:48:05 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 25 Jun 2021 08:48:05 GMT
Subject: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when
 accessing an arrayClass with a protected inner class as component class
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 18:42:23 GMT, Mandy Chung  wrote:

> `Lookup::accessClass` should determine the accessibility of the element type.  An array class is accessible if and only if its element type is accessible.
> 
> This also fixes a spec bug to document `@throws NullPointerException` if the argument is null.
> 
> Please review the CSR:
>     https://bugs.openjdk.java.net/browse/JDK-8269312

Marked as reviewed by chegar (Reviewer).

test/jdk/java/lang/invoke/t8150782/TestFindClass.java line 42:

> 40: 
> 41: import org.testng.annotations.*;
> 42: import p.Foo;

maybe a stray import?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/137

From aefimov at openjdk.java.net  Fri Jun 25 10:22:04 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Fri, 25 Jun 2021 10:22:04 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 24 Jun 2021 12:01:04 GMT, Patrick Concannon  wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> Kind regards,
>> 
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269124: Added instanceof pattern variables

Marked as reviewed by aefimov (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4552

From dfuchs at openjdk.java.net  Fri Jun 25 10:40:00 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 25 Jun 2021 10:40:00 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v5]
In-Reply-To: <54edtW9elwxhlAIae0aLuKTH1gJlEjkZNMH9ftxDjFM=.88829484-660a-43bb-b3fa-34350f816a62@github.com>
References: 
 <54edtW9elwxhlAIae0aLuKTH1gJlEjkZNMH9ftxDjFM=.88829484-660a-43bb-b3fa-34350f816a62@github.com>
Message-ID: 

On Thu, 24 Jun 2021 21:06:54 GMT, Roger Riggs  wrote:

>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enabled logging of filter factory actions and added logging.properties config file

test/jdk/java/io/Serializable/serialFilter/logging.properties line 75:

> 73: # messages:
> 74: java.io.serialization.level = FINER
> 75: 

duplicate settings?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/85

From myano at openjdk.java.net  Fri Jun 25 12:24:20 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Fri, 25 Jun 2021 12:24:20 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on localized
 Windows platform
Message-ID: 

Hi all,

Could you please review the 8269373 bug fixes?

These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.

-------------

Commit messages:
 - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform

Changes: https://git.openjdk.java.net/jdk/pull/4594/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269373
  Stats: 14 lines in 6 files changed: 5 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4594.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594

PR: https://git.openjdk.java.net/jdk/pull/4594

From herrick at openjdk.java.net  Fri Jun 25 13:42:05 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 25 Jun 2021 13:42:05 GMT
Subject: [jdk17] RFR: 8269036:
 tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create
 failed - Resource busy"
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 21:59:43 GMT, Alexander Matveev  wrote:

> Looks like another "Resource busy" issue similar to recent fixes for "hdiutil convert" and "hdiutil detach". Workaround in same way by repeating "create" command. Modified RetryExecutor to pass write to file flag, otherwise "hdiutil create" might deadlock.
> Also, repeat is done only for creating DMG using size instead of creating from app image. In some cases create DMG from app image might run for very long time and eventually fail, this is why fallback to create DMG from size was added.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/122

From yyang at openjdk.java.net  Fri Jun 25 13:42:22 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 25 Jun 2021 13:42:22 GMT
Subject: RFR: 8269383: New java.nio.ByteOrder.isBigEndian and isLittleEndian
 methods
Message-ID: 

Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian. There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank.

Thanks!

-------------

Commit messages:
 - add new methods

Changes: https://git.openjdk.java.net/jdk/pull/4595/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4595&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269383
  Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4595.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4595/head:pull/4595

PR: https://git.openjdk.java.net/jdk/pull/4595

From yyang at openjdk.java.net  Fri Jun 25 13:47:20 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 25 Jun 2021 13:47:20 GMT
Subject: RFR: 8269384: Determine native byte order for StringUTF16 via
 ByteOrder
Message-ID: 

Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.

-------------

Commit messages:
 - replace

Changes: https://git.openjdk.java.net/jdk/pull/4596/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4596&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269384
  Stats: 17 lines in 2 files changed: 3 ins; 13 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4596.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4596/head:pull/4596

PR: https://git.openjdk.java.net/jdk/pull/4596

From david.lloyd at redhat.com  Fri Jun 25 13:51:18 2021
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 25 Jun 2021 08:51:18 -0500
Subject: RFR: 8269383: New java.nio.ByteOrder.isBigEndian and
 isLittleEndian methods
In-Reply-To: 
References: 
Message-ID: 

Is this better than the current solution of `nativeOrder() ==
BIG_ENDIAN` other than reducing a few keystrokes?

On Fri, Jun 25, 2021 at 8:45 AM Yi Yang  wrote:
>
> Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian. There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank.
>
> Thanks!
>
> -------------
>
> Commit messages:
>  - add new methods
>
> Changes: https://git.openjdk.java.net/jdk/pull/4595/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4595&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8269383
>   Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/4595.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/4595/head:pull/4595
>
> PR: https://git.openjdk.java.net/jdk/pull/4595
>


-- 
- DML ? he/him


From qingfeng.yy at alibaba-inc.com  Fri Jun 25 14:01:59 2021
From: qingfeng.yy at alibaba-inc.com (Yi Yang)
Date: Fri, 25 Jun 2021 22:01:59 +0800
Subject: =?UTF-8?B?UmU6IFJGUjogODI2OTM4MzogTmV3IGphdmEubmlvLkJ5dGVPcmRlci5pc0JpZ0VuZGlhbiBh?=
 =?UTF-8?B?bmQgaXNMaXR0bGVFbmRpYW4gbWV0aG9kcw==?=
In-Reply-To: 
References: ,
 
Message-ID: <4310464e-9b6e-48b6-8b71-d527b9ff7dfc.qingfeng.yy@alibaba-inc.com>

Hi David,

In my humble option, it is reasonable to provide APIs to check whether the underlying platform is big-endian/little-endian.For most cases, we want a checking(byte order) rather than retrieving(byte order).


------------------------------------------------------------------
From:David Lloyd 
Send Time:2021 Jun. 25 (Fri.) 21:52
To:Yi Yang 
Cc:core-libs-dev ; nio-dev 
Subject:Re: RFR: 8269383: New java.nio.ByteOrder.isBigEndian and isLittleEndian methods

Is this better than the current solution of `nativeOrder() ==
BIG_ENDIAN` other than reducing a few keystrokes?

On Fri, Jun 25, 2021 at 8:45 AM Yi Yang  wrote:
>
> Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian. There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank.
>
> Thanks!
>
> -------------
>
> Commit messages:
>  - add new methods
>
> Changes: https://git.openjdk.java.net/jdk/pull/4595/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4595&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8269383
>   Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/4595.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/4595/head:pull/4595
>
> PR: https://git.openjdk.java.net/jdk/pull/4595
>


-- 
- DML ? he/him

From pconcannon at openjdk.java.net  Fri Jun 25 14:01:39 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 25 Jun 2021 14:01:39 GMT
Subject: RFR: 8268469: Update java.time to use switch expressions [v6]
In-Reply-To: 
References: 
Message-ID: <_S-W524nYA-9n6JslzK4lZ6Nh_uohDPAclBLKkEV3Pg=.3b36641e-43f2-4a47-938a-1511062d486a@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions?
> 
> Kind regards,
> Patrick

Patrick Concannon 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 remote-tracking branch 'origin/master' into JDK-8268469
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - 8268469: Removed alignment of arrow operators in some cases; reverted logic of switch/case in LocalDate
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - 8268469: Removed excessive spacing; corrected misplaced comments
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - Merge remote-tracking branch 'origin/master' into JDK-8268469
 - 8268469: Update java.time to use switch expressions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4433/files
  - new: https://git.openjdk.java.net/jdk/pull/4433/files/a841c3cf..c8c1ab55

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4433&range=04-05

  Stats: 7048 lines in 208 files changed: 1680 ins; 5063 del; 305 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4433.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4433/head:pull/4433

PR: https://git.openjdk.java.net/jdk/pull/4433

From kcr at openjdk.java.net  Fri Jun 25 14:11:02 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 25 Jun 2021 14:11:02 GMT
Subject: RFR: 8269383: (bf) ByteOrder should expose methods to test if
 platform is big or little endian
In-Reply-To: 
References: 
Message-ID: <22ALydS6BrOxknBj5cmYF0_x8PAdRF09MpPKvedq88E=.646ed741-a2c0-4cac-9444-2255f60b3401@github.com>

On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang  wrote:

> Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian(e.g. #4596 ). There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank.
> 
> Thanks!

If this is accepted as a new enhancement, it will need a CSR.

Personally, I don't see enough justification for such a convenience method, but this isn't my area, so my opinion doesn't carry any weight.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4595

From rriggs at openjdk.java.net  Fri Jun 25 14:54:45 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Jun 2021 14:54:45 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v6]
In-Reply-To: 
References: 
Message-ID: 

> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Update logging of faults in jdk.serialFilterFactory to log only the exception message
  Simplify the logging.properties to only the needed settings

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/85/files
  - new: https://git.openjdk.java.net/jdk17/pull/85/files/89df22e7..ca66a7b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=85&range=04-05

  Stats: 69 lines in 2 files changed: 0 ins; 65 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85

PR: https://git.openjdk.java.net/jdk17/pull/85

From chegar at openjdk.java.net  Fri Jun 25 15:12:04 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 25 Jun 2021 15:12:04 GMT
Subject: RFR: 8269383: (bf) ByteOrder should expose methods to test if
 platform is big or little endian
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang  wrote:

> Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian(e.g. #4596 ). There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank. For most cases(in JDK or in user code), we want a checking(byte order) rather than retrieving(byte order).
> 
> Thanks!

On the face of it, I do like this API enhancement. I've coded similar myself a number of times, well isBigEndian. Is there any other potential benefits, performance or otherwise, that than be achieved by such an API?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4595

From dfuchs at openjdk.java.net  Fri Jun 25 15:15:01 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 25 Jun 2021 15:15:01 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v6]
In-Reply-To: 
References: 
 
Message-ID: <8yMFMPdoGhaz0OU1PGy0-xrfzdYpXVaa1l-usfUnV2M=.eb1683de-132d-419c-b714-319ac44aff9e@github.com>

On Fri, 25 Jun 2021 14:54:45 GMT, Roger Riggs  wrote:

>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update logging of faults in jdk.serialFilterFactory to log only the exception message
>   Simplify the logging.properties to only the needed settings

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/85

From avoitylov at openjdk.java.net  Fri Jun 25 15:24:06 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 25 Jun 2021 15:24:06 GMT
Subject: [jdk17] Withdrawn: JDK-8266310: deadlock between System.loadLibrary
 and JNI FindClass loading another class
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:

> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
> 
> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Further details can be found in the original PR.
> 
> Testing: jtreg and jck testing with no regressions. A new regression test was developed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From avoitylov at openjdk.java.net  Fri Jun 25 15:24:05 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 25 Jun 2021 15:24:05 GMT
Subject: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and
 JNI FindClass loading another class
In-Reply-To: 
References: 
Message-ID: 

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov  wrote:

> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.
> 
> This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Further details can be found in the original PR.
> 
> Testing: jtreg and jck testing with no regressions. A new regression test was developed.

OK, let it bake in 18 first.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/96

From bpb at openjdk.java.net  Fri Jun 25 15:25:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 15:25:00 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Add bug ID to test

I had the same misgivings after creating this PR and thought that a CSR would be in order.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From yyang at openjdk.java.net  Fri Jun 25 15:34:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 25 Jun 2021 15:34:01 GMT
Subject: RFR: 8269383: (bf) ByteOrder should expose methods to test if
 platform is big or little endian
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang  wrote:

> Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian(e.g. #4596 ). There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank. For most cases(in JDK or in user code), we want a checking(byte order) rather than retrieving(byte order).
> 
> Thanks!

Hi Chris,

> Is there any other potential benefits, performance or otherwise, that than be achieved by such an API?

Unfortunately not. It's more like the enhancement of API expressiveness. Since these operations are trivial, these APIs will not improve/degrade the performance. Although we can use `@IntrinsicCandidate` to intrinsify it for potential? performance benefit, but I don't think it's necessary at present(and in future...), but I think they are good candidates of `@ForceInline` annotations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4595

From pconcannon at openjdk.java.net  Fri Jun 25 15:46:07 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 25 Jun 2021 15:46:07 GMT
Subject: Integrated: 8268469: Update java.time to use switch expressions
In-Reply-To: 
References: 
Message-ID: <22x8QVnC2tuHPg-JQpi-WYksxTGQsfjdUWSOWrLfj0Y=.9a564411-20dd-4d20-935e-bf0b3b3f5937@github.com>

On Wed, 9 Jun 2021 15:41:59 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` packages to make use of the switch expressions?
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 1d167978
Author:    Patrick Concannon 
URL:       https://git.openjdk.java.net/jdk/commit/1d167978e53603ccf1599f476143391e7db51992
Stats:     342 lines in 22 files changed: 6 ins; 87 del; 249 mod

8268469: Update java.time to use switch expressions

Reviewed-by: lancea, naoto, dfuchs, iris, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/4433

From shade at openjdk.java.net  Fri Jun 25 15:52:05 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 25 Jun 2021 15:52:05 GMT
Subject: RFR: 8269384: Determine native byte order for StringUTF16 via
 ByteOrder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang  wrote:

> Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.

Adding new dependencies in `String` quite probably risks bootstrapping issues. There is a reason why `String` calls into its own native methods for this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4596

From Alan.Bateman at oracle.com  Fri Jun 25 15:56:43 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 25 Jun 2021 16:56:43 +0100
Subject: RFR: 8269383: New java.nio.ByteOrder.isBigEndian and
 isLittleEndian methods
In-Reply-To: 
References: 
 
Message-ID: <01373e49-6986-19f5-a4fd-e8e2f35a520c@oracle.com>

On 25/06/2021 14:51, David Lloyd wrote:
> Is this better than the current solution of `nativeOrder() ==
> BIG_ENDIAN` other than reducing a few keystrokes?
I wouldn't expect many developers would need to be concerned with the 
platform endianness, it's more likely going to be something advanced, 
maybe a high performance library or something interaction with the 
native code or the platform. So it would be just a convenience, you can 
already can use ByteOrder.nativeOrder()? and test if it returns BIG or 
LITTLE_ENDIAN.

-Alan

From psandoz at openjdk.java.net  Fri Jun 25 16:02:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 25 Jun 2021 16:02:03 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v5]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: 

On Wed, 23 Jun 2021 11:58:06 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving javadoc.

Bootstrap method looks. At first i thought why not let the class label just be an actual `Class.class` instance, signaling that target enum class should be used, but then thought perhaps it's better to be more literal: clarity of inputs, unlikely label lists will be shared, and further it might be easier to adapt them.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 227:

> 225:                                       String invocationName,
> 226:                                       MethodType invocationType,
> 227:                                       Object... labels) throws NullPointerException,

I don't think there are any benefits to declaring the runtime exceptions in the method declaration.

Other bootstrap methods declare a checked exception when certain linkage constraints are violated (and the line between whats an `IllegalArgumentException` or an explicit linkage checked exception can be blurry). In your case, given the simplicity i think what you have is ok. We could refine later with a specific checked exception for switch linkage violations.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 256:

> 254:         if (labelClass == Class.class) {
> 255:             if (label != enumClassTemplate) {
> 256:                 throw new IllegalArgumentException("illegal Class label: " + label);

Can we refine the message to state the class label is not equal to the enum class that is the target of the switch? LIkewise in the `else` block to state the label is not of class String or the target enum class.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/81

From naoto at openjdk.java.net  Fri Jun 25 16:21:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Jun 2021 16:21:05 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Add bug ID to test

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From mchung at openjdk.java.net  Fri Jun 25 16:45:06 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 25 Jun 2021 16:45:06 GMT
Subject: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when
 accessing an arrayClass with a protected inner class as component class
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Jun 2021 08:44:54 GMT, Chris Hegarty  wrote:

>> `Lookup::accessClass` should determine the accessibility of the element type.  An array class is accessible if and only if its element type is accessible.
>> 
>> This also fixes a spec bug to document `@throws NullPointerException` if the argument is null.
>> 
>> Please review the CSR:
>>     https://bugs.openjdk.java.net/browse/JDK-8269312
>
> test/jdk/java/lang/invoke/t8150782/TestFindClass.java line 42:
> 
>> 40: 
>> 41: import org.testng.annotations.*;
>> 42: import p.Foo;
> 
> maybe a stray import?

Yup. Will remove it.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/137

From bchristi at openjdk.java.net  Fri Jun 25 16:52:09 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 25 Jun 2021 16:52:09 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 25 Jun 2021 14:54:45 GMT, Roger Riggs  wrote:

>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update logging of faults in jdk.serialFilterFactory to log only the exception message
>   Simplify the logging.properties to only the needed settings

Marked as reviewed by bchristi (Reviewer).

test/jdk/java/io/Serializable/serialFilter/SerialFilterFunctionTest.java line 49:

> 47:         // Enable logging
> 48:         System.setProperty("java.util.logging.config.file",
> 49:                 System.getProperty("test.src", ".") + "/logging.properties");

Is `System.setProperty()` needed if it's already being set with -D ?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/85

From mchung at openjdk.java.net  Fri Jun 25 17:31:21 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 25 Jun 2021 17:31:21 GMT
Subject: [jdk17] RFR: JDK-8269351: Proxy::newProxyInstance and
 MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
Message-ID: 

`java.lang.reflect.Proxy::newProxyInstance` and `java.lang.invoke.MethodHandleProxies::asInterfaceInstance` do not specify how to deal with sealed interfaces.  These APIs should reject  sealed interface with `IllegalArgumentException` which is thrown if the given interface is invalid.

Please review CSR:
    https://bugs.openjdk.java.net/browse/JDK-8269396

-------------

Commit messages:
 - JDK-8269351: Proxy.newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces

Changes: https://git.openjdk.java.net/jdk17/pull/148/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=148&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269351
  Stats: 101 lines in 4 files changed: 97 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/148.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/148/head:pull/148

PR: https://git.openjdk.java.net/jdk17/pull/148

From bpb at openjdk.java.net  Fri Jun 25 17:34:08 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 17:34:08 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Add bug ID to test

CSR JDK-8269399 created.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From rriggs at openjdk.java.net  Fri Jun 25 17:36:03 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Jun 2021 17:36:03 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v6]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 25 Jun 2021 16:48:45 GMT, Brent Christian  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update logging of faults in jdk.serialFilterFactory to log only the exception message
>>   Simplify the logging.properties to only the needed settings
>
> test/jdk/java/io/Serializable/serialFilter/SerialFilterFunctionTest.java line 49:
> 
>> 47:         // Enable logging
>> 48:         System.setProperty("java.util.logging.config.file",
>> 49:                 System.getProperty("test.src", ".") + "/logging.properties");
> 
> Is `System.setProperty()` needed if it's already being set with -D ?

Fooey; belt and suspenders not needed here.
In some cases, I used the static initializer to avoid adding command line arguments that would
obscure the command line arguments being tested.
In this case, the log may be interesting for debugging but not integral to the test correctness.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/85

From rriggs at openjdk.java.net  Fri Jun 25 17:55:05 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Jun 2021 17:55:05 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Add bug ID to test

The spec for ByteArrayInputStream.read(byte[], off, len) is pretty specific about returning -1 if there is nothing to read.
The spec inherited from InputStream doesn't supercede javadoc of BAIS.
If the implementation is going to change then the spec will need to change too.
It seems safer to document the inconsistency and avoid the risk of infinite loops.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From bpb at openjdk.java.net  Fri Jun 25 17:55:05 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 17:55:05 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
 
Message-ID: 

On Fri, 25 Jun 2021 17:49:37 GMT, Roger Riggs  wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6766844: Add bug ID to test
>
> The spec for ByteArrayInputStream.read(byte[], off, len) is pretty specific about returning -1 if there is nothing to read.
> The spec inherited from InputStream doesn't supercede javadoc of BAIS.
> If the implementation is going to change then the spec will need to change too.
> It seems safer to document the inconsistency and avoid the risk of infinite loops.

@RogerRiggs I agree.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From naoto at openjdk.java.net  Fri Jun 25 18:29:01 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Jun 2021 18:29:01 GMT
Subject: Integrated: 8266901: Clarify the method description of
 Duration.toDaysPart()
In-Reply-To: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
References: <5ZfGdVGkXMZdV5Si0otfBSI-TdGD50UkBv5v9bS2khQ=.59b5369a-5aec-4d7c-b5c4-7293c6b806ee@github.com>
Message-ID: 

On Mon, 21 Jun 2021 18:22:26 GMT, Naoto Sato  wrote:

> Please review this doc clarification fix to `toDaysPart()` method. CSR will also be filed accordingly.

This pull request has now been integrated.

Changeset: 223759fb
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk/commit/223759fb8af4a28f8ff8563e438ca285a87a9f2d
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8266901: Clarify the method description of Duration.toDaysPart()

Reviewed-by: bpb, rriggs, lancea, iris, scolebourne

-------------

PR: https://git.openjdk.java.net/jdk/pull/4542

From joehw at openjdk.java.net  Fri Jun 25 18:46:11 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 25 Jun 2021 18:46:11 GMT
Subject: [jdk17] Integrated: 8256919: BCEL: Utility.encode forget to close
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 20:36:29 GMT, Joe Wang  wrote:

> Fix a regression caused by the previous BCEL update. The issue was fixed in the current BCEL repo with a reversal of the previous code, adding back "gos.close();". Note however, doing so will result in a warning: [try] explicit call to close() on an auto-closeable resource. This fix calls finish() instead.

This pull request has now been integrated.

Changeset: d799563a
Author:    Joe Wang 
URL:       https://git.openjdk.java.net/jdk17/commit/d799563ac06d66acea6dbd9cb1fe78b253e8a0e7
Stats:     73 lines in 2 files changed: 72 ins; 0 del; 1 mod

8256919: BCEL: Utility.encode forget to close

Reviewed-by: lancea, bpb, naoto

-------------

PR: https://git.openjdk.java.net/jdk17/pull/141

From mchung at openjdk.java.net  Fri Jun 25 18:46:30 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 25 Jun 2021 18:46:30 GMT
Subject: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when
 accessing an arrayClass with a protected inner class as component class [v2]
In-Reply-To: 
References: 
Message-ID: 

> `Lookup::accessClass` should determine the accessibility of the element type.  An array class is accessible if and only if its element type is accessible.
> 
> This also fixes a spec bug to document `@throws NullPointerException` if the argument is null.
> 
> Please review the CSR:
>     https://bugs.openjdk.java.net/browse/JDK-8269312

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  remove extra import

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/137/files
  - new: https://git.openjdk.java.net/jdk17/pull/137/files/96da75be..0579507f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=137&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=137&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/137/head:pull/137

PR: https://git.openjdk.java.net/jdk17/pull/137

From joehw at openjdk.java.net  Fri Jun 25 18:42:06 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 25 Jun 2021 18:42:06 GMT
Subject: RFR: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML [v3]
In-Reply-To: 
References: 
 
Message-ID: <4-MzATtNgjB2elb0jDtPdjgxxxsp5jMrDVqzkKcGaqw=.a09dbf1f-aa36-4d0b-9448-c35d474d1fc9@github.com>

On Wed, 23 Jun 2021 07:34:06 GMT, Masanori Yano  wrote:

>> Hi all,
>> 
>> Could you please review the 8268457 bug fixes?
>> 
>> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
>> This fix changes the processing for non-surrogate pairs to the else condition.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessally comments and add eof line

Hi Masanori, you may now type /integrate in a new comment when you're ready. I'll then sponsor your change. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From jlaskey at openjdk.java.net  Fri Jun 25 19:01:11 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 25 Jun 2021 19:01:11 GMT
Subject: [jdk17] RFR: JDK-8266313 (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes
Message-ID: 

The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.

-------------

Commit messages:
 - non-infinite to finite
 - Use limiting
 - Remove use of clamping
 - Merge branch 'master' of https://github.com/openjdk/jdk17 into 8266313
 - Javadoc changes

Changes: https://git.openjdk.java.net/jdk17/pull/151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=151&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266313
  Stats: 51 lines in 2 files changed: 22 ins; 4 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/151/head:pull/151

PR: https://git.openjdk.java.net/jdk17/pull/151

From bpb at openjdk.java.net  Fri Jun 25 19:11:11 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 19:11:11 GMT
Subject: Integrated: 6633375: FileOutputStream_md.c should be merged into
 FileOutputStream.c
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 20:01:27 GMT, Brian Burkhalter  wrote:

> Merge identical Unix and Windows versions of FileOutputStream_md.c into single, common FileOutputStream.c.

This pull request has now been integrated.

Changeset: 3fae4b37
Author:    Brian Burkhalter 
URL:       https://git.openjdk.java.net/jdk/commit/3fae4b372065b4293b64514e0679df419cd5c89a
Stats:     77 lines in 2 files changed: 0 ins; 74 del; 3 mod

6633375: FileOutputStream_md.c should be merged into FileOutputStream.c

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/4589

From bpb at openjdk.java.net  Fri Jun 25 19:12:07 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 19:12:07 GMT
Subject: Integrated: 4847239: (spec) File.createTempFile() should make it
 clear that it doesn't create the temporary directory
In-Reply-To: 
References: 
Message-ID: 

On Wed, 23 Jun 2021 00:06:25 GMT, Brian Burkhalter  wrote:

> Augment the specification of `java.io.File.createTempFile(String,String,File)` to clarify its behavior with respect to the `File` parameter `directory`.

This pull request has now been integrated.

Changeset: 68ef21db
Author:    Brian Burkhalter 
URL:       https://git.openjdk.java.net/jdk/commit/68ef21db415fb61ac9690290b692594da6b87ff9
Stats:     115 lines in 2 files changed: 114 ins; 0 del; 1 mod

4847239: (spec) File.createTempFile() should make it clear that it doesn't create the temporary directory

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/4561

From joe.darcy at oracle.com  Fri Jun 25 19:57:43 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 25 Jun 2021 12:57:43 -0700
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v6]
In-Reply-To: 
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 
 
Message-ID: <1af67d23-10a2-915a-8623-a38190fea6b3@oracle.com>

On 6/21/2021 2:02 PM, Paul Sandoz wrote:
> On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang  wrote:
>
>>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    more replacement 2
> All the updates to the check* methods look ok (requires some careful looking!).
>
> I cannot recall what others said about the change in exception messages. @jddarcy any advice here?

Generally, the JDK does not have the text of exception message as a 
supported interface meant to be relied on by users. This doesn't stop 
developers from occasionally parsing those messages, but that is usually 
a sign of a missing API which we try to rectify more directly.

HTH,

-Joe


From weijun at openjdk.java.net  Fri Jun 25 20:11:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 25 Jun 2021 20:11:27 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
Message-ID: 

More refactoring to limit the scope of `@SuppressWarnings` annotations.

Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

-------------

Commit messages:
 - 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

Changes: https://git.openjdk.java.net/jdk17/pull/152/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269409
  Stats: 289 lines in 21 files changed: 161 ins; 64 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From lancea at openjdk.java.net  Fri Jun 25 20:27:59 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 25 Jun 2021 20:27:59 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Changes look good Max

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/152

From bpb at openjdk.java.net  Fri Jun 25 20:34:30 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 20:34:30 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v3]
In-Reply-To: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
Message-ID: 

> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  6766844: Add an @apiNote instead of changing impl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4591/files
  - new: https://git.openjdk.java.net/jdk/pull/4591/files/68b6f089..3152cdc7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=01-02

  Stats: 10 lines in 2 files changed: 5 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4591.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4591/head:pull/4591

PR: https://git.openjdk.java.net/jdk/pull/4591

From bpb at openjdk.java.net  Fri Jun 25 20:47:21 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 20:47:21 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v4]
In-Reply-To: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
Message-ID: 

> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.

Brian Burkhalter 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:

  6766844: Add an API note instead of changing impl

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4591/files
  - new: https://git.openjdk.java.net/jdk/pull/4591/files/3152cdc7..a53849a2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4591.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4591/head:pull/4591

PR: https://git.openjdk.java.net/jdk/pull/4591

From rriggs at openjdk.java.net  Fri Jun 25 20:54:03 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Jun 2021 20:54:03 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v4]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Fri, 25 Jun 2021 20:47:21 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter 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.

src/java.base/share/classes/java/io/ByteArrayInputStream.java line 163:

> 161:      * @apiNote
> 162:      * Unlike the {@link InputStream#read(byte[],int,int) equivalent method}
> 163:      * of {@code InputStream}, this method returns {@code -1} instead of zero

I think I would say superclass method instead of equivalent method.
Or prehaps overridden method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From bpb at openjdk.java.net  Fri Jun 25 20:54:03 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 25 Jun 2021 20:54:03 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v4]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
 
Message-ID: <3O7k2ri3rqthfxZ2TCJ6zTm4hiSK8_dUGgw7GIrl9bU=.918304bc-8800-438a-ac32-7405695e52df@github.com>

On Fri, 25 Jun 2021 20:49:16 GMT, Roger Riggs  wrote:

>> Brian Burkhalter 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.
>
> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 163:
> 
>> 161:      * @apiNote
>> 162:      * Unlike the {@link InputStream#read(byte[],int,int) equivalent method}
>> 163:      * of {@code InputStream}, this method returns {@code -1} instead of zero
> 
> I think I would say superclass method instead of equivalent method.
> Or prehaps overridden method.

I think overridden would work best.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From darcy at openjdk.java.net  Fri Jun 25 21:23:03 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 25 Jun 2021 21:23:03 GMT
Subject: [jdk17] RFR: JDK-8269351: Proxy::newProxyInstance and
 MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
In-Reply-To: 
References: 
Message-ID: <_hJo_7WDfbvEHJPwgI1yWvks9XWkCYKE7VyPr4wrK4g=.39c4e7da-5886-4500-a739-2f8986e244a8@github.com>

On Fri, 25 Jun 2021 17:24:58 GMT, Mandy Chung  wrote:

> `java.lang.reflect.Proxy::newProxyInstance` and `java.lang.invoke.MethodHandleProxies::asInterfaceInstance` do not specify how to deal with sealed interfaces.  These APIs should reject  sealed interface with `IllegalArgumentException` which is thrown if the given interface is invalid.
> 
> Please review CSR:
>     https://bugs.openjdk.java.net/browse/JDK-8269396

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/148

From almatvee at openjdk.java.net  Fri Jun 25 21:31:02 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 25 Jun 2021 21:31:02 GMT
Subject: [jdk17] Integrated: 8269036:
 tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create
 failed - Resource busy"
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 21:59:43 GMT, Alexander Matveev  wrote:

> Looks like another "Resource busy" issue similar to recent fixes for "hdiutil convert" and "hdiutil detach". Workaround in same way by repeating "create" command. Modified RetryExecutor to pass write to file flag, otherwise "hdiutil create" might deadlock.
> Also, repeat is done only for creating DMG using size instead of creating from app image. In some cases create DMG from app image might run for very long time and eventually fail, this is why fallback to create DMG from size was added.

This pull request has now been integrated.

Changeset: fb0a95fe
Author:    Alexander Matveev 
URL:       https://git.openjdk.java.net/jdk17/commit/fb0a95fed46a04475697204de576c57f98d5b55a
Stats:     16 lines in 2 files changed: 13 ins; 0 del; 3 mod

8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"

Reviewed-by: asemenyuk, herrick

-------------

PR: https://git.openjdk.java.net/jdk17/pull/122

From valeriep at openjdk.java.net  Fri Jun 25 22:31:04 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 25 Jun 2021 22:31:04 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey  wrote:

>> Sufficient permissions missing if this code was ever to run with SecurityManager. 
>> 
>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>> 
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move TokenPoller to Runnable

src/java.base/share/lib/security/default.policy line 131:

> 129:     permission java.lang.RuntimePermission "accessClassInPackage.com.sun.crypto.provider";
> 130:     permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc";
> 131:     permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*";

Can we just do necessary changes? I noticed that this file seems to have mixed style, i.e. some lines are longer than 80 chars and some break into 2 lines with length less than 80 chars. Since the whole file is mixed, maybe just do what must be changed.

src/java.base/share/lib/security/default.policy line 142:

> 140:     permission java.security.SecurityPermission "clearProviderProperties.*";
> 141:     permission java.security.SecurityPermission "removeProviderProperty.*";
> 142:     permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";

Same "avoid unnecessary changes" comment here.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 952:

> 950:         AccessController.doPrivileged((PrivilegedAction) () -> {
> 951:             Thread t = InnocuousThread.newSystemThread(
> 952:                     "Poller " + getName(),

nit: "Poller " -> "Poller-" (like before)?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 956:

> 954:             assert t.getContextClassLoader() == null;
> 955:             t.setDaemon(true);
> 956:             t.setPriority(Thread.MIN_PRIORITY);

nit: supply this priority value as an argument to the InnocuousThread.newSystemThread() call instead?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1033:

> 1031:         }
> 1032:         cleaner = new NativeResourceCleaner();
> 1033:         AccessController.doPrivileged((PrivilegedAction) () -> {

It seems that the AccessController.doPrivileged((PrivilegedAction) () -> {} is un-necessary? I tried your test without it and test still passes.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1039:

> 1037:             assert t.getContextClassLoader() == null;
> 1038:             t.setDaemon(true);
> 1039:             t.setPriority(Thread.MIN_PRIORITY);

nit: supply this priority value as an argument to the InnocuousThread.newSystemThread() call instead?

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1212:

> 1210: 
> 1211:         this.token = token;
> 1212:         if (cleaner == null) {

This check seems duplicate to the one in createCleaner() call.

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 56:

> 54:                 System.out.println("No NSS config found. Skipping.");
> 55:                 return;
> 56:             }

Move this if-check block of code up before the for-loop?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From valeriep at openjdk.java.net  Fri Jun 25 22:31:05 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 25 Jun 2021 22:31:05 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <4qG15Dx-kJQ6q3hbn3iQ2ALOJpRbMg7YkWxBHGMLpxQ=.598d3a18-213f-4780-82f2-7d854a5c070b@github.com>

On Fri, 25 Jun 2021 19:39:22 GMT, Valerie Peng  wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move TokenPoller to Runnable
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 952:
> 
>> 950:         AccessController.doPrivileged((PrivilegedAction) () -> {
>> 951:             Thread t = InnocuousThread.newSystemThread(
>> 952:                     "Poller " + getName(),
> 
> nit: "Poller " -> "Poller-" (like before)?

It seems that the AccessController.doPrivileged((PrivilegedAction) () -> {} is un-necessary? I tried your test without it and test still passes.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From naoto at openjdk.java.net  Fri Jun 25 23:10:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Jun 2021 23:10:03 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v4]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Fri, 25 Jun 2021 20:47:21 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter 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.

Agree that clarifying the spec would be a much safer solution.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4591

From naoto at openjdk.java.net  Fri Jun 25 23:11:02 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Jun 2021 23:11:02 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

LGTM.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/152

From asemenyuk at openjdk.java.net  Fri Jun 25 23:29:10 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 25 Jun 2021 23:29:10 GMT
Subject: [jdk17] RFR: 8269403: Fix jpackage tests to gracefully handle
 jpackage app launcher crashes
Message-ID: 

jpackage app launcher randomly crashes JVM at termination in EMS enabled JDK builds.
Until the root cause of the issue is understood and fixed let's add a workaround to jpackage tests to run test app few more times if the first attempt resulted in app crash.

-------------

Commit messages:
 - whitespace clean up
 - 8269403: Fix jpackage tests to gracefully handle jpackage app launcher crashes

Changes: https://git.openjdk.java.net/jdk17/pull/153/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=153&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269403
  Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/153.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/153/head:pull/153

PR: https://git.openjdk.java.net/jdk17/pull/153

From valeriep at openjdk.java.net  Fri Jun 25 23:37:06 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 25 Jun 2021 23:37:06 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey  wrote:

>> Sufficient permissions missing if this code was ever to run with SecurityManager. 
>> 
>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>> 
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move TokenPoller to Runnable

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 63:

> 61:             Policy.setPolicy(new SimplePolicy());
> 62:             System.setSecurityManager(new SecurityManager());
> 63:         }

Just curious, why split the loop into 2 and set the SecurityManager in between the two loops? Can't we just set the policy/security manager before the loop?

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 137:

> 135:             perms.add(new SecurityPermission("insertProvider.*"));
> 136:             perms.add(new SecurityPermission("removeProvider.*"));
> 137:         }

The test still pass without the following permission:

             perms.add(new RuntimePermission("accessClassInPackage.sun.*"));
             perms.add(new RuntimePermission("accessClassInPackage.sun.security.pkcs11.*"));
             perms.add(new SecurityPermission("clearProviderProperties.*"));

Remove them?

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh line 142:

> 140:         -Dtest.src=${TESTSRC} \
> 141:         -Dtest.classes=${TESTCLASSES} \
> 142:         -Djava.security.debug=${DEBUG} \

Save these java options and use it for both invocation? This way it's easier to tell that there is no difference among these two except for the extra argument.

test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh line 143:

> 141:         -Dtest.classes=${TESTCLASSES} \
> 142:         -Djava.security.debug=${DEBUG} \
> 143:         MultipleLogins ${TESTSRC}${FS}MultipleLogins.policy || exit 11

There is no MultipleLogins.policy file. The test just uses the internal SimplePolicy object. Maybe just use a string like "useSimplePolicy".

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From weijun at openjdk.java.net  Fri Jun 25 23:40:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 25 Jun 2021 23:40:27 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: 
References: 
Message-ID: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/152/files
  - new: https://git.openjdk.java.net/jdk17/pull/152/files/d8b384df..774eb9da

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From almatvee at openjdk.java.net  Sat Jun 26 02:25:02 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 26 Jun 2021 02:25:02 GMT
Subject: [jdk17] RFR: 8269403: Fix jpackage tests to gracefully handle
 jpackage app launcher crashes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 22:41:10 GMT, Alexey Semenyuk  wrote:

> jpackage app launcher randomly crashes JVM at termination in EMS enabled JDK builds.
> Until the root cause of the issue is understood and fixed let's add a workaround to jpackage tests to run test app few more times if the first attempt resulted in app crash.

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/153

From alanb at openjdk.java.net  Sat Jun 26 06:56:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 26 Jun 2021 06:56:01 GMT
Subject: [jdk17] RFR: JDK-8269351: Proxy::newProxyInstance and
 MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 17:24:58 GMT, Mandy Chung  wrote:

> `java.lang.reflect.Proxy::newProxyInstance` and `java.lang.invoke.MethodHandleProxies::asInterfaceInstance` do not specify how to deal with sealed interfaces.  These APIs should reject  sealed interface with `IllegalArgumentException` which is thrown if the given interface is invalid.
> 
> Please review CSR:
>     https://bugs.openjdk.java.net/browse/JDK-8269396

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/148

From alanb at openjdk.java.net  Sat Jun 26 07:14:00 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 26 Jun 2021 07:14:00 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v4]
In-Reply-To: <3O7k2ri3rqthfxZ2TCJ6zTm4hiSK8_dUGgw7GIrl9bU=.918304bc-8800-438a-ac32-7405695e52df@github.com>
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
 
 <3O7k2ri3rqthfxZ2TCJ6zTm4hiSK8_dUGgw7GIrl9bU=.918304bc-8800-438a-ac32-7405695e52df@github.com>
Message-ID: 

On Fri, 25 Jun 2021 20:50:47 GMT, Brian Burkhalter  wrote:

>> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 163:
>> 
>>> 161:      * @apiNote
>>> 162:      * Unlike the {@link InputStream#read(byte[],int,int) equivalent method}
>>> 163:      * of {@code InputStream}, this method returns {@code -1} instead of zero
>> 
>> I think I would say superclass method instead of equivalent method.
>> Or prehaps overridden method.
>
> I think overridden would work best.

I think it needs to be normative text rather than an apiNote (but I'm happy that it is now a javadoc change rather than a potentially breaking implementation change).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From lancea at openjdk.java.net  Sat Jun 26 11:09:00 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 26 Jun 2021 11:09:00 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: 

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang  wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From mchung at openjdk.java.net  Sat Jun 26 16:50:05 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 26 Jun 2021 16:50:05 GMT
Subject: [jdk17] Integrated: JDK-8269351: Proxy::newProxyInstance and
 MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 17:24:58 GMT, Mandy Chung  wrote:

> `java.lang.reflect.Proxy::newProxyInstance` and `java.lang.invoke.MethodHandleProxies::asInterfaceInstance` do not specify how to deal with sealed interfaces.  These APIs should reject  sealed interface with `IllegalArgumentException` which is thrown if the given interface is invalid.
> 
> Please review CSR:
>     https://bugs.openjdk.java.net/browse/JDK-8269396

This pull request has now been integrated.

Changeset: 3d0d27ce
Author:    Mandy Chung 
URL:       https://git.openjdk.java.net/jdk17/commit/3d0d27ce57b4456b6fab86f05e105241ddf8471e
Stats:     101 lines in 4 files changed: 97 ins; 0 del; 4 mod

8269351: Proxy::newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces

Reviewed-by: darcy, alanb

-------------

PR: https://git.openjdk.java.net/jdk17/pull/148

From forax at univ-mlv.fr  Sat Jun 26 16:52:41 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 26 Jun 2021 18:52:41 +0200 (CEST)
Subject: Release of ASM 9.2
Message-ID: <1786664033.1344516.1624726361471.JavaMail.zimbra@u-pem.fr>

Hi everybody,
we are happy to announce the release of ASM 9.2 which support Java 18 (available via Maven Central).

I still hope to find the time this summer to work of the support of Valhalla new bytecodes.

R?mi

From alanb at openjdk.java.net  Sat Jun 26 16:55:59 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 26 Jun 2021 16:55:59 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: 

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang  wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:

> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
> 52:             (PrivilegedAction) ProcessHandle::current).pid();
> 53: 

The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From alanb at openjdk.java.net  Sat Jun 26 17:06:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 26 Jun 2021 17:06:05 GMT
Subject: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when
 accessing an arrayClass with a protected inner class as component class [v2]
In-Reply-To: 
References: 
 
Message-ID: <9kzESgxxT4BDXlFDF_56W5sk65ilwJFui3pg3wjaWXo=.b5eef6fa-d50e-43a2-8179-3f5835e18156@github.com>

On Fri, 25 Jun 2021 18:46:30 GMT, Mandy Chung  wrote:

>> `Lookup::accessClass` should determine the accessibility of the element type.  An array class is accessible if and only if its element type is accessible.
>> 
>> This also fixes a spec bug to document `@throws NullPointerException` if the argument is null.
>> 
>> Please review the CSR:
>>     https://bugs.openjdk.java.net/browse/JDK-8269312
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove extra import

Looks okay. In passing I think t8150782 is the only test directory using that naming convention. There are several tests using  in the directory name.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/137

From mchung at openjdk.java.net  Sat Jun 26 18:13:01 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 26 Jun 2021 18:13:01 GMT
Subject: [jdk17] RFR: JDK-8266269: Lookup::accessClass fails with IAE when
 accessing an arrayClass with a protected inner class as component class [v2]
In-Reply-To: 
References: 
 
Message-ID: <_m6cLCV3RLCYl4d0K4uU0TC3CN3WLczqFjjlvhI_gxM=.f5e44595-2d21-4003-b37b-138ea5079e2e@github.com>

On Fri, 25 Jun 2021 18:46:30 GMT, Mandy Chung  wrote:

>> `Lookup::accessClass` should determine the accessibility of the element type.  An array class is accessible if and only if its element type is accessible.
>> 
>> This also fixes a spec bug to document `@throws NullPointerException` if the argument is null.
>> 
>> Please review the CSR:
>>     https://bugs.openjdk.java.net/browse/JDK-8269312
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove extra import

I also notice that  `t8150782` outliner.   It'd actually prefer to remove the directory `t8150782` or  place the tests in a directory name with descriptive name.   That can be cleaned up as a separate issue.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/137

From mchung at openjdk.java.net  Sat Jun 26 18:31:11 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 26 Jun 2021 18:31:11 GMT
Subject: [jdk17] Integrated: JDK-8266269: Lookup::accessClass fails with IAE
 when accessing an arrayClass with a protected inner class as component class
In-Reply-To: 
References: 
Message-ID: 

On Thu, 24 Jun 2021 18:42:23 GMT, Mandy Chung  wrote:

> `Lookup::accessClass` should determine the accessibility of the element type.  An array class is accessible if and only if its element type is accessible.
> 
> This also fixes a spec bug to document `@throws NullPointerException` if the argument is null.
> 
> Please review the CSR:
>     https://bugs.openjdk.java.net/browse/JDK-8269312

This pull request has now been integrated.

Changeset: 6eb734a6
Author:    Mandy Chung 
URL:       https://git.openjdk.java.net/jdk17/commit/6eb734a60fdd982c94dd152a803809f148bff582
Stats:     102 lines in 5 files changed: 84 ins; 2 del; 16 mod

8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class

Reviewed-by: chegar, alanb

-------------

PR: https://git.openjdk.java.net/jdk17/pull/137

From weijun at openjdk.java.net  Sat Jun 26 23:59:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sat, 26 Jun 2021 23:59:03 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: 
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 
Message-ID: 

On Sat, 26 Jun 2021 16:53:30 GMT, Alan Bateman  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   one more
>
> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:
> 
>> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
>> 52:             (PrivilegedAction) ProcessHandle::current).pid();
>> 53: 
> 
> The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.

This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From github.com+1701815+mkarg at openjdk.java.net  Sun Jun 27 13:21:12 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sun, 27 Jun 2021 13:21:12 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo
In-Reply-To: 
References: 
Message-ID: 

On Sun, 30 May 2021 17:30:56 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?

I am a bit lost currently. So what actually do I have to do next? You want *me* to write these tests, or shall I just refactor my implementation and *you* will provide these tests (I would prefer that, actually)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From jpai at openjdk.java.net  Sun Jun 27 13:54:39 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 27 Jun 2021 13:54:39 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has
 dir named "." inside
Message-ID: 

Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?

As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).

Alan notes in that issue that:

> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 

This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:

> The elements returned by the iterator are in no specific order. Some file
 systems maintain special links to the directory itself and the directory's
  parent directory. Entries representing these links are not returned by the
  iterator.


The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.

A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.

-------------

Commit messages:
 - 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside

Changes: https://git.openjdk.java.net/jdk/pull/4604/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4604&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251329
  Stats: 173 lines in 3 files changed: 170 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4604.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4604/head:pull/4604

PR: https://git.openjdk.java.net/jdk/pull/4604

From jwilhelm at openjdk.java.net  Sun Jun 27 23:14:43 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 23:14:43 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8258746: illegal access to global field _jvmci_old_thread_counters by terminated thread causes crash
 - 8266269: Lookup::accessClass fails with IAE when accessing an arrayClass with a protected inner class as component class
 - 8269351: Proxy::newProxyInstance and MethodHandleProxies::asInterfaceInstance should reject sealed interfaces
 - 8269260: Add AVX512 and other SSE + AVX combinations testing for tests which generate vector instructions
 - 8269302: serviceability/dcmd/framework/InvalidCommandTest.java still fails after JDK-8268433
 - 8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"
 - 8269074: (fs) Files.copy fails to copy from /proc on some linux kernel versions
 - 8256919: BCEL: Utility.encode forget to close
 - 8269335: Unable to load svml library
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/8bed3534...2d9b73c0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4606&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4606/files
  Stats: 1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4606/head:pull/4606

PR: https://git.openjdk.java.net/jdk/pull/4606

From jwilhelm at openjdk.java.net  Sun Jun 27 23:55:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sun, 27 Jun 2021 23:55:06 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Sun, 27 Jun 2021 23:05:10 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: a29953d8
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/a29953d805ac6360bcfe005bcefa60e112788494
Stats:     1925 lines in 90 files changed: 1452 ins; 227 del; 246 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4606

From yyang at openjdk.java.net  Mon Jun 28 03:28:07 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 28 Jun 2021 03:28:07 GMT
Subject: RFR: 8269384: Determine native byte order for StringUTF16 via
 ByteOrder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang  wrote:

> Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.

Hi Aleksey, do you have a concrete issue/discussion about bootstrapping problems? I don't see it because I can build JDK and passes tier1 tests w/o problems. But I admit this may cause potential problems. In order to reduce potential risks, how about changing the class initialization orders, i.e. initialize UUnsafeConstants_klas earlier, which seems reasonable:


void Threads::initialize_java_lang_classes(JavaThread* main_thread, TRAPS) {
  TraceTime timer("Initialize java.lang classes", TRACETIME_LOG(Info, startuptime));

  if (EagerXrunInit && Arguments::init_libraries_at_startup()) {
    create_vm_init_libraries();
  }

+#ifdef ASSERT
+  InstanceKlass *k = vmClasses::UnsafeConstants_klass();
+  assert(k->is_not_initialized(), "UnsafeConstants should not already be initialized");
+#endif
+
+  // initialize the hardware-specific constants needed by Unsafe
+  initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), CHECK);
+  jdk_internal_misc_UnsafeConstants::set_unsafe_constants();

  initialize_class(vmSymbols::java_lang_String(), CHECK);

  // Inject CompactStrings value after the static initializers for String ran.
  java_lang_String::set_compact_strings(CompactStrings);
  ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/4596

From yyang at openjdk.java.net  Mon Jun 28 03:33:05 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 28 Jun 2021 03:33:05 GMT
Subject: RFR: 8269383: (bf) ByteOrder should expose methods to test if
 platform is big or little endian
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang  wrote:

> Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian(e.g. #4596 ). There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank. For most cases(in JDK or in user code), we want a checking(byte order) rather than retrieving(byte order).
> 
> Thanks!

Okay, it seems that more people do not agree with adding these APIs, I am going to close this proposal.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4595

From yyang at openjdk.java.net  Mon Jun 28 03:33:05 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 28 Jun 2021 03:33:05 GMT
Subject: Withdrawn: 8269383: (bf) ByteOrder should expose methods to test if
 platform is big or little endian
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:30:56 GMT, Yi Yang  wrote:

> Hi, can I have a review of this change that adds two new utility methods for java.nio.ByteOrder? Looking through the whole JDK codebase, most calls of ByteOrder.nativeOrder() is to check if the underlying platform is little-endian/big-endian(e.g. #4596 ). There is no reason to only provide ByteOrder.nativeOrder while leaving big-endian/little-endian checking methods blank. For most cases(in JDK or in user code), we want a checking(byte order) rather than retrieving(byte order).
> 
> Thanks!

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4595

From jpai at openjdk.java.net  Mon Jun 28 03:52:29 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 28 Jun 2021 03:52:29 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads
 to a negative initial size for ByteArrayOutputStream
Message-ID: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>

Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?

The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.

P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

-------------

Commit messages:
 - 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream

Changes: https://git.openjdk.java.net/jdk/pull/4607/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8190753
  Stats: 139 lines in 2 files changed: 138 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

PR: https://git.openjdk.java.net/jdk/pull/4607

From github.com+12689835+blindpirate at openjdk.java.net  Mon Jun 28 07:07:08 2021
From: github.com+12689835+blindpirate at openjdk.java.net (Bo Zhang)
Date: Mon, 28 Jun 2021 07:07:08 GMT
Subject: Withdrawn: 8260621: Avoid memory leak in ImageBufferCache
In-Reply-To: 
References: 
Message-ID: 

On Fri, 29 Jan 2021 05:53:57 GMT, Bo Zhang  wrote:

> Previously, `ImageBufferCache` contains a ThreadLocal field which holds
> strong reference to `ImageBufferCache$BufferReference.class`. When loaded
> from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader`
> in memory forever and never being GCed.
> 
> The fix replace the old `ImageBufferCache$BufferReference` class with
> `WeakReference`, which is verified by provided test.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2307

From alanb at openjdk.java.net  Mon Jun 28 07:07:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 28 Jun 2021 07:07:08 GMT
Subject: RFR: 8260621: Avoid memory leak in ImageBufferCache [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 3 Feb 2021 01:29:02 GMT, Bo Zhang  wrote:

>> Previously, `ImageBufferCache` contains a ThreadLocal field which holds
>> strong reference to `ImageBufferCache$BufferReference.class`. When loaded
>> from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader`
>> in memory forever and never being GCed.
>> 
>> The fix replace the old `ImageBufferCache$BufferReference` class with
>> `WeakReference`, which is verified by provided test.
>
> Bo Zhang 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.

This issue was fixed with PR 3849 so I assume PR 2307 can be closed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2307

From alanb at openjdk.java.net  Mon Jun 28 07:30:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 28 Jun 2021 07:30:06 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: 

On Mon, 28 Jun 2021 03:41:20 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

This may be just moving the problem because writing to the BAOS will fail when the deflated size is too large to fit in a byte array. The zip provider can use a temporary file so maybe it should use that when appending to existing zip entries that are larger than some threshold. At some point we may need deeper changes here, e.g. start out with a BAOS and spill over to a temporary file when the deflated size reaches some threshold.

I didn't study the test too closely but just to mention that tests with zip entries > 2GB can be problematic to test. The test will probably need the @requires tag to limit it to 64-bit systems and maybe some minimum memory size. It may also need testing on a wide range of systems to get some idea of run time. Test machines with spinning rust (HDDs) come to mind.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From alanb at openjdk.java.net  Mon Jun 28 07:55:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 28 Jun 2021 07:55:08 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo
In-Reply-To: 
References: 
Message-ID: <1wX0aTSBFOmNeDvClXNSqfJ4a-fCYG6IYj1J-GQkZHI=.d82f362e-313e-49fa-92c4-02c4cb80696f@github.com>

On Sun, 30 May 2021 17:30:56 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?

> I am a bit lost currently. So what actually do I have to do next? You want _me_ to write these tests, or shall I just refactor my implementation and _you_ will provide these tests (I would prefer that, actually)?

The existing test for InputStream.transferTo mostly exercises the default implementation. There are overrides in other input stream implementation but the test coverage appears to be spotty. This PR adds an overwrite with four implementations and it doesn't appear that these are exercised by any tests. So yes, tests are needed. This PR, or another PR that is integrated in advance, either is fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From jai.forums2013 at gmail.com  Mon Jun 28 08:30:49 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 28 Jun 2021 14:00:49 +0530
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream
In-Reply-To: 
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 
Message-ID: 

Hello Alan,

On 28/06/21 1:00 pm, Alan Bateman wrote:
>
> I didn't study the test too closely but just to mention that tests with zip entries > 2GB can be problematic to test. The test will probably need the @requires tag to limit it to 64-bit systems and maybe some minimum memory size. It may also need testing on a wide range of systems to get some idea of run time. Test machines with spinning rust (HDDs) come to mind.
>
That's a good point and I had completely overlooked it. There's an 
existing test test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java 
(unrelated to this issue) which uses a 5GB sized entry in the zips. In 
fact, the idea of creating the zip entry in this manner was borrowed 
from there. That one doesn't have any @requires for it. However, taking 
a closer look at that existing test, that one just creates these large 
entries but never loads (nor tries to load) those entries into memory 
and probably explains why it doesn't need special care when it comes to 
running the test.

I'll take a look at some other existing tests to see what kind of 
@requires I can add here to make it a bit more selective on where it 
gets run. Thank you for that input.

-Jaikiran



From jpai at openjdk.java.net  Mon Jun 28 09:13:31 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 28 Jun 2021 09:13:31 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v2]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: 

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  add @requires to the new test to selectively decide where the test runs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/8d6f3407..127acbcc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

PR: https://git.openjdk.java.net/jdk/pull/4607

From adinn at openjdk.java.net  Mon Jun 28 09:21:07 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 28 Jun 2021 09:21:07 GMT
Subject: RFR: 8269384: Determine native byte order for StringUTF16 via
 ByteOrder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang  wrote:

> Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.

Hi Yi Yang,

This is more complex than it seems. The general policy is not to change boot order if at all possible and for good reason. there are many ways it can cause unexpected consequences.

Regarding this specific case, UnsafeConstants exists in order to allow class Unsafe to define a few final fields derived from runtime environment/hardware parameters provided as final static *primitive* fields of UnsafeConstants. The relevant fields in UnsafeConstants are injected by the JVM after they have been initialized to dummy values by the class's  method. So, the purpose of the class is simply to pre-cache these runtime/hardware values as Java state, avoiding the need for Unsafe to call out to the JVM using native code. Before UnsafeConstants was defined these constants used to be retrieved using native callouts.

What you are asking for is to make String use the same pre-cache as Unsafe i.e. to expand the set of classes which depend on UnsafeConstants to include String. While that might work as currently defined it is not clear that it will always continue to work in the future. That's because String is a rather special case, much like a primitive class. Instances of String are created to represent literal terms in the language. Note that these String terms are themselves *constants*.

UnsafeConstants is not meant to have any other uses except to cache the runtime-specific/hardware constants used by Unsafe. So, it ought not to depend on other classes. However, it is also important that no other classes depend on it and that includes String. Now imagine someone were to update UnsafeConstants to include an injected String constant -- say, the current setting for LC_LANG, or the processor CPU name or some other legitimate text value derived form the runtime or hardware. Your change would cause a problem because initialization of UnsafeConstants would require String already to be initialized.

Of course, neither of those examples is a likely candidate for inclusion in UnsafeConstants but it is hard to say whether other more realistic cases might arise in future.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4596

From dfuchs at openjdk.java.net  Mon Jun 28 12:24:05 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Jun 2021 12:24:05 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: 
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 
 
Message-ID: 

On Sat, 26 Jun 2021 23:55:46 GMT, Weijun Wang  wrote:

>> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 53:
>> 
>>> 51:     private static final long CURRENT_PID = AccessController.doPrivileged(
>>> 52:             (PrivilegedAction) ProcessHandle::current).pid();
>>> 53: 
>> 
>> The original code separated out the declaration of the PrivilegedAction to avoid this cast. If you move the code from the original static initializer into a static method that it called from initializer then it might provide you with a cleaner way to refactor this. There are several other places in this patch that could do with similar cleanup.
>
> This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.

Why not simply declare a local variable in the static initializer below?


    private static final long CURRENT_PID;
    private static final boolean ALLOW_ATTACH_SELF;
    static {
        PrivilegedAction pa = ProcessHandle::current;
        @SuppressWarnings("removal")
        long pid = AccessController.doPrivileged(pa).pid();
        CURRENT_PID = pid;
        String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
        ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
    }

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From jlaskey at openjdk.java.net  Mon Jun 28 12:36:43 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 28 Jun 2021 12:36:43 GMT
Subject: [jdk17] RFR: JDK-8268236 The documentation of the
 String.regionMatches method contains error
Message-ID: <1wuSOcsVK6niKEGiBzzc2GDlXLAd_ev-s06iIt58uvw=.eb192495-18d6-4a88-9346-1570141f7087@github.com>

The documentation of the String.regionMatches method contains this fragment: this.substring(toffset, len).codePoints(), but String.substring method takes index, not the length, as the second argument.

-------------

Commit messages:
 - Update javadoc

Changes: https://git.openjdk.java.net/jdk17/pull/157/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=157&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268236
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/157.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/157/head:pull/157

PR: https://git.openjdk.java.net/jdk17/pull/157

From herrick at openjdk.java.net  Mon Jun 28 12:54:05 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 28 Jun 2021 12:54:05 GMT
Subject: [jdk17] RFR: 8269403: Fix jpackage tests to gracefully handle
 jpackage app launcher crashes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 22:41:10 GMT, Alexey Semenyuk  wrote:

> jpackage app launcher randomly crashes JVM at termination in EMS enabled JDK builds.
> Until the root cause of the issue is understood and fixed let's add a workaround to jpackage tests to run test app few more times if the first attempt resulted in app crash.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/153

From cgo at openjdk.java.net  Mon Jun 28 13:21:53 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 28 Jun 2021 13:21:53 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server variant
Message-ID: 

Hi,

please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.

I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.

-------------

Commit messages:
 - 8269486: CallerAccessTest fails for non server variant

Changes: https://git.openjdk.java.net/jdk17/pull/159/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=159&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269486
  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/159.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/159/head:pull/159

PR: https://git.openjdk.java.net/jdk17/pull/159

From rriggs at openjdk.java.net  Mon Jun 28 13:26:07 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 28 Jun 2021 13:26:07 GMT
Subject: [jdk17] RFR: JDK-8268236 The documentation of the
 String.regionMatches method contains error
In-Reply-To: <1wuSOcsVK6niKEGiBzzc2GDlXLAd_ev-s06iIt58uvw=.eb192495-18d6-4a88-9346-1570141f7087@github.com>
References: <1wuSOcsVK6niKEGiBzzc2GDlXLAd_ev-s06iIt58uvw=.eb192495-18d6-4a88-9346-1570141f7087@github.com>
Message-ID: <2EJNCiYkUcdh1zVDrihn4dlnlJ94iKfbfYDevWb9dhA=.11364b1d-406d-45c4-b903-474ee8e6f618@github.com>

On Mon, 28 Jun 2021 12:28:06 GMT, Jim Laskey  wrote:

> The documentation of the String.regionMatches method contains this fragment: this.substring(toffset, len).codePoints(), but String.substring method takes index, not the length, as the second argument.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/157

From dfuchs at openjdk.java.net  Mon Jun 28 13:37:06 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 28 Jun 2021 13:37:06 GMT
Subject: [jdk17] RFR: JDK-8268236 The documentation of the
 String.regionMatches method contains error
In-Reply-To: <1wuSOcsVK6niKEGiBzzc2GDlXLAd_ev-s06iIt58uvw=.eb192495-18d6-4a88-9346-1570141f7087@github.com>
References: <1wuSOcsVK6niKEGiBzzc2GDlXLAd_ev-s06iIt58uvw=.eb192495-18d6-4a88-9346-1570141f7087@github.com>
Message-ID: 

On Mon, 28 Jun 2021 12:28:06 GMT, Jim Laskey  wrote:

> The documentation of the String.regionMatches method contains this fragment: this.substring(toffset, len).codePoints(), but String.substring method takes index, not the length, as the second argument.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/157

From dholmes at openjdk.java.net  Mon Jun 28 13:45:03 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 28 Jun 2021 13:45:03 GMT
Subject: RFR: 8269384: Determine native byte order for StringUTF16 via
 ByteOrder
In-Reply-To: 
References: 
 
Message-ID: <2Jp5BzOeruP7jYlUfhmv8PjJYlKxewEbrSFjmvFSg7k=.ab13664e-8dc9-4abf-9936-713b2e83001c@github.com>

On Mon, 28 Jun 2021 03:25:09 GMT, Yi Yang  wrote:

>> Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.
>
> Hi Aleksey, do you have a concrete issue/discussion about bootstrapping problems? I don't see it because I can build JDK and passes tier1 tests w/o problems. But I admit this may cause potential problems. In order to reduce potential risks, how about changing the class initialization orders, i.e. initialize UUnsafeConstants_klas earlier, which seems reasonable:
> 
> 
> void Threads::initialize_java_lang_classes(JavaThread* main_thread, TRAPS) {
>   TraceTime timer("Initialize java.lang classes", TRACETIME_LOG(Info, startuptime));
> 
>   if (EagerXrunInit && Arguments::init_libraries_at_startup()) {
>     create_vm_init_libraries();
>   }
> 
> +#ifdef ASSERT
> +  InstanceKlass *k = vmClasses::UnsafeConstants_klass();
> +  assert(k->is_not_initialized(), "UnsafeConstants should not already be initialized");
> +#endif
> +
> +  // initialize the hardware-specific constants needed by Unsafe
> +  initialize_class(vmSymbols::jdk_internal_misc_UnsafeConstants(), CHECK);
> +  jdk_internal_misc_UnsafeConstants::set_unsafe_constants();
> 
>   initialize_class(vmSymbols::java_lang_String(), CHECK);
> 
>   // Inject CompactStrings value after the static initializers for String ran.
>   java_lang_String::set_compact_strings(CompactStrings);
>   ...

@kelthuzadx , if you want to discuss initialization order changes please take this to hotspot-runtime-dev. Simply building okay and running a few tests can never validate a change in VM initialization order - there are a lot of subtleties involved, platform differences, affect of different flags, etc etc. Thanks @adinn for the details on this specific proposal - I agree that we neither want to make UnsafeConstants unable to use String, nor expose it for use by String.

Backing up a step what is the motivation for change here? Is there something wrong with the way String currently does this? Or is it just that it seemed on the surface that you could skip the native call and "just use Byteorder"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4596

From dholmes at openjdk.java.net  Mon Jun 28 13:49:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 28 Jun 2021 13:49:09 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 13:14:51 GMT, Christoph G?ttschkes  wrote:

> Hi,
> 
> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
> 
> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.

This generally seems fine to me (assuming the Platform utility methods do as would be expected).

One suggestion below.

Thanks,
David

test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java line 53:

> 51: 
> 52:         String libDir = Platform.libDir().toString();
> 53:         String serverDir = Platform.jvmLibDir().toString();

Perhaps `vmDir` would be a more suitable name?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/159

From jlaskey at openjdk.java.net  Mon Jun 28 13:54:10 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 28 Jun 2021 13:54:10 GMT
Subject: [jdk17] Integrated: JDK-8268236 The documentation of the
 String.regionMatches method contains error
In-Reply-To: <1wuSOcsVK6niKEGiBzzc2GDlXLAd_ev-s06iIt58uvw=.eb192495-18d6-4a88-9346-1570141f7087@github.com>
References: <1wuSOcsVK6niKEGiBzzc2GDlXLAd_ev-s06iIt58uvw=.eb192495-18d6-4a88-9346-1570141f7087@github.com>
Message-ID: <8dlwPDrGn_N566R9uVJdsURoNGLbfMx5JkU1Qfa4XNA=.ede778de-6b4a-4d18-9002-3ae28631242a@github.com>

On Mon, 28 Jun 2021 12:28:06 GMT, Jim Laskey  wrote:

> The documentation of the String.regionMatches method contains this fragment: this.substring(toffset, len).codePoints(), but String.substring method takes index, not the length, as the second argument.

This pull request has now been integrated.

Changeset: e4c54463
Author:    Jim Laskey 
URL:       https://git.openjdk.java.net/jdk17/commit/e4c5446340605b112e0918fa9dcb48aaeaa730c8
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8268236: The documentation of the String.regionMatches method contains error

Reviewed-by: rriggs, dfuchs

-------------

PR: https://git.openjdk.java.net/jdk17/pull/157

From stuefe at openjdk.java.net  Mon Jun 28 14:21:08 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Jun 2021 14:21:08 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant
In-Reply-To: 
References: 
Message-ID: <3-t2IsvRkEEp7JI3-LD4xWnvyKMuSdGH8otTXtmS_eg=.85b8754e-3a6d-4e37-8169-2abfee3c77fa@github.com>

On Mon, 28 Jun 2021 13:14:51 GMT, Christoph G?ttschkes  wrote:

> Hi,
> 
> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
> 
> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.

Looks reasonable (Davids suggestion sounds good).

..Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/159

From weijun at openjdk.java.net  Mon Jun 28 14:22:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:49 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
Message-ID: 

On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang  wrote:

>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>> 
>> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more

I'm going to move this to jdk18.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 14:22:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:47 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v3]
In-Reply-To: 
References: 
Message-ID: 

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more refinement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/152/files
  - new: https://git.openjdk.java.net/jdk17/pull/152/files/774eb9da..2e4a8ba7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=152&range=01-02

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/152/head:pull/152

PR: https://git.openjdk.java.net/jdk17/pull/152

From weijun at openjdk.java.net  Mon Jun 28 14:22:51 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 14:22:51 GMT
Subject: [jdk17] RFR: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K [v2]
In-Reply-To: 
References: 
 <8espagHVTHv183MA_Cj9mpzXcYnu7fMSx-1xCzWV4IQ=.032f7cdc-6372-41c7-b1ef-a447a2491480@github.com>
 
 
 
Message-ID: <921aev1Be6BDt-9x6qkx-DqcgpCdUxkxD5nM8WQsNLs=.adbfc2ef-25cf-468a-8b6e-e8aa92aa8e3c@github.com>

On Mon, 28 Jun 2021 12:20:38 GMT, Daniel Fuchs  wrote:

>> This cast is only to tell the compiler which overloaded method to call, and I don't think there will be a real cast at runtime. It might look a little ugly but extracting it into a variable declaration/definition plus a new `initStatic` method seems not worth doing, IMHO.
>
> Why not simply declare a local variable in the static initializer below?
> 
> 
>     private static final long CURRENT_PID;
>     private static final boolean ALLOW_ATTACH_SELF;
>     static {
>         PrivilegedAction pa = ProcessHandle::current;
>         @SuppressWarnings("removal")
>         long pid = AccessController.doPrivileged(pa).pid();
>         CURRENT_PID = pid;
>         String s = VM.getSavedProperty("jdk.attach.allowAttachSelf");
>         ALLOW_ATTACH_SELF = "".equals(s) || Boolean.parseBoolean(s);
>     }

I've just pushed a commit with a different fix:

    private static final long CURRENT_PID = pid();

    @SuppressWarnings("removal")
    private static long pid() {
        PrivilegedAction pa = () -> ProcessHandle.current();
        return AccessController.doPrivileged(pa).pid();
    }

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From cgo at openjdk.java.net  Mon Jun 28 14:52:41 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 28 Jun 2021 14:52:41 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
> 
> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.

Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:

  Renames serverDir to vmDir.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/159/files
  - new: https://git.openjdk.java.net/jdk17/pull/159/files/84b23542..71e0e5b6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=159&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=159&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/159.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/159/head:pull/159

PR: https://git.openjdk.java.net/jdk17/pull/159

From cgo at openjdk.java.net  Mon Jun 28 14:52:42 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 28 Jun 2021 14:52:42 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant
In-Reply-To: 
References: 
Message-ID: <_GqVJ6TpK-MvwTcJV8GWbWGfrPZqiR_7CZ2JhxvskR4=.30eb2331-345f-49c5-b6d8-fa7c733d608f@github.com>

On Mon, 28 Jun 2021 13:14:51 GMT, Christoph G?ttschkes  wrote:

> Hi,
> 
> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
> 
> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.

Thanks for the reviews.

> assuming the Platform utility methods do as would be expected

Yes, the utility method does the switch between "bin" and "lib" for windows and non-windows

https://github.com/openjdk/jdk17/blob/e4c5446340605b112e0918fa9dcb48aaeaa730c8/test/lib/jdk/test/lib/Platform.java#L346-L350

and it does the switch for the variant

https://github.com/openjdk/jdk17/blob/e4c5446340605b112e0918fa9dcb48aaeaa730c8/test/lib/jdk/test/lib/Platform.java#L361-L369

I only have a linux setup, so I tested this with a client and a server VM only on linux.
Sorry, I didn't enable github workflows for my jdk17 fork yet. I did so now and hopefully the next commit will trigger it.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/159

From cgo at openjdk.java.net  Mon Jun 28 14:52:45 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 28 Jun 2021 14:52:45 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 13:44:41 GMT, David Holmes  wrote:

>> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renames serverDir to vmDir.
>
> test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java line 53:
> 
>> 51: 
>> 52:         String libDir = Platform.libDir().toString();
>> 53:         String serverDir = Platform.jvmLibDir().toString();
> 
> Perhaps `vmDir` would be a more suitable name?

Makes sense, thank you.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/159

From rriggs at openjdk.java.net  Mon Jun 28 15:32:05 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 28 Jun 2021 15:32:05 GMT
Subject: [jdk17] RFR: JDK-8266313 (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 18:53:59 GMT, Jim Laskey  wrote:

> The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 648:

> 646:      * power of two then limiting is a simple masking operation. Otherwise, a
> 647:      * new result is re-calculated by averaging the previous result and
> 648:      * {@code nextInt()} until the final result is greater equal zero and less

I don't see how 'averaging' comes from the invocation of boundedNextInt which appears to choose the first candidate that meets the criteria.
The comment also applies to nextLong overloads.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/151

From jlaskey at openjdk.java.net  Mon Jun 28 16:00:09 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 28 Jun 2021 16:00:09 GMT
Subject: [jdk17] RFR: JDK-8266313 (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 15:26:45 GMT, Roger Riggs  wrote:

>> The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 648:
> 
>> 646:      * power of two then limiting is a simple masking operation. Otherwise, a
>> 647:      * new result is re-calculated by averaging the previous result and
>> 648:      * {@code nextInt()} until the final result is greater equal zero and less
> 
> I don't see how 'averaging' comes from the invocation of boundedNextInt which appears to choose the first candidate that meets the criteria.
> The comment also applies to nextLong overloads.

If the first value calculated doesn't meet the criteria, then you either mask (power of 2) or go into this loop with does the averaging. The intent is not to bias the outcome.


                for (long u = r >>> 1;            // ensure nonnegative
                     u + m - (r = u % n) < 0L;    // rejection check
                     u = rng.nextLong() >>> 1) // retry
                    ;

-------------

PR: https://git.openjdk.java.net/jdk17/pull/151

From mchung at openjdk.java.net  Mon Jun 28 16:17:35 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 28 Jun 2021 16:17:35 GMT
Subject: [jdk17] RFR: JDK-8269426: Move tests from
 test/jdk/java/lang/invoke/t8150782 to its parent directory
Message-ID: 

`test/jdk/java/lang/invoke/t8150782` is the only one using that convention. There are several tests under `` directory.  As the tests under `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for `Lookup::accessClass` and `Lookup::findClass`, they can simply be moved to the parent directory.

-------------

Commit messages:
 - JDK-8269426:  Move tests from test/jdk/java/lang/invoke/t8150782 to its parent directory

Changes: https://git.openjdk.java.net/jdk17/pull/162/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=162&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269426
  Stats: 9 lines in 6 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/162.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/162/head:pull/162

PR: https://git.openjdk.java.net/jdk17/pull/162

From asemenyuk at openjdk.java.net  Mon Jun 28 16:59:08 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 28 Jun 2021 16:59:08 GMT
Subject: [jdk17] Integrated: 8269403: Fix jpackage tests to gracefully handle
 jpackage app launcher crashes
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 22:41:10 GMT, Alexey Semenyuk  wrote:

> jpackage app launcher randomly crashes JVM at termination in EMS enabled JDK builds.
> Until the root cause of the issue is understood and fixed let's add a workaround to jpackage tests to run test app few more times if the first attempt resulted in app crash.

This pull request has now been integrated.

Changeset: efe8423d
Author:    Alexey Semenyuk 
URL:       https://git.openjdk.java.net/jdk17/commit/efe8423d8c584f793e05128e7e69feede382b3e7
Stats:     9 lines in 2 files changed: 5 ins; 0 del; 4 mod

8269403: Fix jpackage tests to gracefully handle jpackage app launcher crashes

Reviewed-by: almatvee, herrick

-------------

PR: https://git.openjdk.java.net/jdk17/pull/153

From naoto at openjdk.java.net  Mon Jun 28 17:06:18 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Jun 2021 17:06:18 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes` system
 property
Message-ID: 

Please review this small doc change to the system property. Accompanying CSR has also been created.

-------------

Commit messages:
 - 8269513: Clarify the spec wrt `useOldISOCodes` system property

Changes: https://git.openjdk.java.net/jdk17/pull/163/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=163&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269513
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/163/head:pull/163

PR: https://git.openjdk.java.net/jdk17/pull/163

From dcubed at openjdk.java.net  Mon Jun 28 17:12:19 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 28 Jun 2021 17:12:19 GMT
Subject: [jdk17] RFR: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
Message-ID: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>

A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

-------------

Commit messages:
 - 8269534: Remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

Changes: https://git.openjdk.java.net/jdk17/pull/164/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=164&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269534
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/164.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/164/head:pull/164

PR: https://git.openjdk.java.net/jdk17/pull/164

From tschatzl at openjdk.java.net  Mon Jun 28 17:18:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 28 Jun 2021 17:18:02 GMT
Subject: [jdk17] RFR: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
In-Reply-To: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
References: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
Message-ID: <-c9FPOcv71mdWZKgiakejb-vZeh3Zxq8Y4ZVniLbogI=.d856f392-c8b5-4c37-aab8-1f808d3abc53@github.com>

On Mon, 28 Jun 2021 17:05:49 GMT, Daniel D. Daugherty  wrote:

> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

Lgtm and trivial.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/164

From iignatyev at openjdk.java.net  Mon Jun 28 17:18:02 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 28 Jun 2021 17:18:02 GMT
Subject: [jdk17] RFR: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
In-Reply-To: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
References: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
Message-ID: <46tT_FluMBxBftmZG5JHlr3NNZdrITGiOwu_QKmddx0=.af2a492e-7ef7-4a54-b486-3ca1e554853d@github.com>

On Mon, 28 Jun 2021 17:05:49 GMT, Daniel D. Daugherty  wrote:

> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

Marked as reviewed by iignatyev (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/164

From dcubed at openjdk.java.net  Mon Jun 28 17:22:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 28 Jun 2021 17:22:08 GMT
Subject: [jdk17] RFR: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
In-Reply-To: <46tT_FluMBxBftmZG5JHlr3NNZdrITGiOwu_QKmddx0=.af2a492e-7ef7-4a54-b486-3ca1e554853d@github.com>
References: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
 <46tT_FluMBxBftmZG5JHlr3NNZdrITGiOwu_QKmddx0=.af2a492e-7ef7-4a54-b486-3ca1e554853d@github.com>
Message-ID: <1yv09Kcow1We74im_mS331DWz6S8-3R18wXGdylf73Y=.63902f46-1d43-4ca4-9d6e-582cf601f046@github.com>

On Mon, 28 Jun 2021 17:15:23 GMT, Igor Ignatyev  wrote:

>> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
>
> Marked as reviewed by iignatyev (Reviewer).

@iignatev and @tschatzl - Thanks for the fast reviews.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/164

From dcubed at openjdk.java.net  Mon Jun 28 17:33:07 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 28 Jun 2021 17:33:07 GMT
Subject: [jdk17] Integrated: 8269534: Remove
 java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
In-Reply-To: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
References: <-HWK2yOJlm1QcPeQTOsXqqPLD1ubhwSY8KMSSdiIVmU=.f8a01319-2dda-410e-b6b5-4ada998dd4eb@github.com>
Message-ID: 

On Mon, 28 Jun 2021 17:05:49 GMT, Daniel D. Daugherty  wrote:

> A trivial fix to remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

This pull request has now been integrated.

Changeset: 20640a57
Author:    Daniel D. Daugherty 
URL:       https://git.openjdk.java.net/jdk17/commit/20640a57f3a352a046006d4795afa4a64f4dc92d
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8269534: Remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt

Reviewed-by: iignatyev, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk17/pull/164

From jvernee at openjdk.java.net  Mon Jun 28 17:44:28 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 17:44:28 GMT
Subject: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java
 test failed with concurrent GC
Message-ID: 

This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.

Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.

I've changed these 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks (now handled by the call).

FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.

Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

-------------

Commit messages:
 - Remove whitespace
 - Add Shenandoah test case as well
 - Add zgc requires tags
 - Typo in MACOS_AARCH64_ONLY part
 - Polish
 - Some more build fixes
 - build fixes
 - re-write upcall code to mimic JavaCallWrapper

Changes: https://git.openjdk.java.net/jdk17/pull/149/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=149&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269240
  Stats: 516 lines in 18 files changed: 338 ins; 147 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Mon Jun 28 17:44:29 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 17:44:29 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 17:38:32 GMT, Jorn Vernee  wrote:

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> I've changed these 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks (now handled by the call).
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

src/hotspot/cpu/arm/frame_arm.cpp line 320:

> 318:   return nullptr;
> 319: }
> 320: 

FWIW, stubs were missing on some platforms, and this seems to have been fine before, but now started causing compilation errors, so I've added them here.

src/hotspot/share/runtime/safepoint.cpp line 931:

> 929:     // See if return type is an oop.
> 930:     bool return_oop = nm->method()->is_returning_oop();
> 931:     HandleMark hm(self);

I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark).

src/hotspot/share/runtime/thread.cpp line 1974:

> 1972:   assert(deferred_card_mark().is_empty(), "Should be empty during GC");
> 1973: 
> 1974:   // Traverse the GCHandles

I reduced some duplication here while debugging, but this change is not strictly needed (though a nice cleanup, IMO). Let me know, and I could remove this part if preferred.

test/jdk/java/foreign/stackwalk/TestAsyncStackWalk.java line 78:

> 76:  *   TestAsyncStackWalk
> 77:  */
> 78:  

Suggestion:

test/jdk/java/foreign/stackwalk/TestStackWalk.java line 78:

> 76:  *   TestStackWalk
> 77:  */
> 78:  

Suggestion:

-------------

PR: https://git.openjdk.java.net/jdk17/pull/149

From bpb at openjdk.java.net  Mon Jun 28 17:48:37 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 28 Jun 2021 17:48:37 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v5]
In-Reply-To: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
Message-ID: 

> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 6766844: Move API note of read(byte[],int,int) to normative text
 - 6766844: Change "equivalent" to "overridden"

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4591/files
  - new: https://git.openjdk.java.net/jdk/pull/4591/files/a53849a2..5435fe81

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4591&range=03-04

  Stats: 6 lines in 1 file changed: 2 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4591.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4591/head:pull/4591

PR: https://git.openjdk.java.net/jdk/pull/4591

From lancea at openjdk.java.net  Mon Jun 28 17:56:07 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Jun 2021 17:56:07 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 16:57:15 GMT, Naoto Sato  wrote:

> Please review this small doc change to the system property. Accompanying CSR has also been created.

Looks good Naoto

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/163

From weijun at openjdk.java.net  Mon Jun 28 18:11:07 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 18:11:07 GMT
Subject: [jdk17] Withdrawn: 8269409: Post JEP 411 refactoring: core-libs with
 maximum covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/152

From jlaskey at openjdk.java.net  Mon Jun 28 18:12:34 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 28 Jun 2021 18:12:34 GMT
Subject: [jdk17] RFR: 8266313: (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes [v2]
In-Reply-To: 
References: 
Message-ID: 

> The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Not averaging

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/151/files
  - new: https://git.openjdk.java.net/jdk17/pull/151/files/3b8e19be..bfb61c8d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=151&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=151&range=00-01

  Stats: 14 lines in 1 file changed: 0 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/151/head:pull/151

PR: https://git.openjdk.java.net/jdk17/pull/151

From jlaskey at openjdk.java.net  Mon Jun 28 18:12:36 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 28 Jun 2021 18:12:36 GMT
Subject: [jdk17] RFR: 8266313: (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 28 Jun 2021 15:57:21 GMT, Jim Laskey  wrote:

>> src/java.base/share/classes/java/util/random/RandomGenerator.java line 648:
>> 
>>> 646:      * power of two then limiting is a simple masking operation. Otherwise, a
>>> 647:      * new result is re-calculated by averaging the previous result and
>>> 648:      * {@code nextInt()} until the final result is greater equal zero and less
>> 
>> I don't see how 'averaging' comes from the invocation of boundedNextInt which appears to choose the first candidate that meets the criteria.
>> The comment also applies to nextLong overloads.
>
> If the first value calculated doesn't meet the criteria, then you either mask (power of 2) or go into this loop which does the averaging. The intent is not to bias the outcome.
> 
> 
>                 for (long u = r >>> 1;            // ensure nonnegative
>                      u + m - (r = u % n) < 0L;    // rejection check
>                      u = rng.nextLong() >>> 1) // retry
>                     ;

Yea you're right. I was focused on the divide by two, which appears to be to just remove the sign. Clearer interpretation:


r = rng.nextLong();
n = range;
m = n - 1;                   // mask
for (long u = r / 2;         // ensure nonnegative
     u + m < r;              // rejection check
     u = rng.nextLong() / 2) // retry
    r = u % n;

-------------

PR: https://git.openjdk.java.net/jdk17/pull/151

From mchung at openjdk.java.net  Mon Jun 28 18:15:06 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 28 Jun 2021 18:15:06 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 14:52:41 GMT, Christoph G?ttschkes  wrote:

>> Hi,
>> 
>> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
>> 
>> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renames serverDir to vmDir.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/159

From weijun at openjdk.java.net  Mon Jun 28 18:15:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 18:15:30 GMT
Subject: RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
Message-ID: 

More refactoring to limit the scope of `@SuppressWarnings` annotations.

Sometimes I introduce new methods. Please feel free to suggest method names you like to use.

Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

-------------

Commit messages:
 - copy all code change from jdk17

Changes: https://git.openjdk.java.net/jdk/pull/4615/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4615&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269409
  Stats: 293 lines in 21 files changed: 165 ins; 64 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4615/head:pull/4615

PR: https://git.openjdk.java.net/jdk/pull/4615

From jvernee at openjdk.java.net  Mon Jun 28 18:16:12 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 18:16:12 GMT
Subject: [jdk17] RFR: JDK-8269426: Move tests from
 test/jdk/java/lang/invoke/t8150782 to its parent directory
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 16:09:36 GMT, Mandy Chung  wrote:

> `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. There are several tests under `` directory.  As the tests under `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for `Lookup::accessClass` and `Lookup::findClass`, they can simply be moved to the parent directory.

Hi Mandy,

It looks like the test in question has some test support files associated with it (p/Foo.java & q/Bar.java). I personally think it's nice if tests like these are in a separate directory, so that it's easier to see which test support files belong to which test (and to avoid potential name clashes when 2 tests want to use a support file with the same name).

How would you feel about dropping just the `t` prefix from the test directory & package names? Then it would match the existing tests in `` directories.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/162

From jvernee at openjdk.java.net  Mon Jun 28 18:27:04 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 18:27:04 GMT
Subject: [jdk17] RFR: 8268566: java/foreign/TestResourceScope.java timed
 out
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Jun 2021 15:42:03 GMT, Maurizio Cimadamore  wrote:

> This patch contains another minor tweak to TestResourceScope as we have seen this test timing out at least once (on arm64).
> 
> I realized that some of the logic recently introduced in the test could lead to the test waiting forever: for instance, if all threads are executed right away before the main thread gets a chance to do anything, we'd be in a state where the lock count is zero, and no other thread will update it. I've removed the while loop - as that's not essential to make sure that the test works (what we want is to trigger a close operation that is concurrent with respect some acquire/release).
> 
> I've also lowered the number of threads - which was using 10K - that was good for stress testing, but it's not a good number in more realistic conditions.

LGTM

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/45

From jvernee at openjdk.java.net  Mon Jun 28 18:32:09 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 18:32:09 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 23 Jun 2021 19:21:02 GMT, Roger Riggs  wrote:

>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated spec of Objects.newIdentity with:
>   "The class does not override any of the methods of {@code java.lang.Object}."

test/jdk/java/util/Objects/BasicObjectsTest.java line 48:

> 46:         errors += testNonNull();
> 47:         errors += testNonNullOf();
> 48:         errors += testNewIdentity();

The javadoc of `Objects::newIdentity` claims `[the returned object] can be used for synchronization`. Would it be useful to add a test that tries to synchronize on the result of `Objects.newIdentity` for that as well?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From naoto at openjdk.java.net  Mon Jun 28 18:37:34 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Jun 2021 18:37:34 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this small doc change to the system property. Accompanying CSR has also been created.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refined wording.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/163/files
  - new: https://git.openjdk.java.net/jdk17/pull/163/files/92a8bfc6..3d25418c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=163&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=163&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/163/head:pull/163

PR: https://git.openjdk.java.net/jdk17/pull/163

From lancea at openjdk.java.net  Mon Jun 28 18:44:06 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Jun 2021 18:44:06 GMT
Subject: RFR: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
> 
> Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

The revisions you made as part of the push to JDK 18 look fine Max.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4615

From bpb at openjdk.java.net  Mon Jun 28 18:45:09 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 28 Jun 2021 18:45:09 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 18:37:34 GMT, Naoto Sato  wrote:

>> Please review this small doc change to the system property. Accompanying CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/163

From jvernee at openjdk.java.net  Mon Jun 28 18:49:09 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 18:49:09 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 14:52:41 GMT, Christoph G?ttschkes  wrote:

>> Hi,
>> 
>> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
>> 
>> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renames serverDir to vmDir.

> I only have a linux setup, so I tested this with a client and a server VM only on linux.

The test also passes on my Windows machine with a server VM.

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/159

From mchung at openjdk.java.net  Mon Jun 28 18:59:07 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 28 Jun 2021 18:59:07 GMT
Subject: [jdk17] RFR: JDK-8269426: Move tests from
 test/jdk/java/lang/invoke/t8150782 to its parent directory
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 16:09:36 GMT, Mandy Chung  wrote:

> `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. There are several tests under `` directory.  As the tests under `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for `Lookup::accessClass` and `Lookup::findClass`, they can simply be moved to the parent directory.

That's a fair point.  I personally prefer using a descriptive directory name rather than bug ID since that can give the reader what the tests are intended for.   What about renaming `t8150782` to `accessClassAndFindClass`?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/162

From lancea at openjdk.java.net  Mon Jun 28 19:03:08 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Jun 2021 19:03:08 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 18:37:34 GMT, Naoto Sato  wrote:

>> Please review this small doc change to the system property. Accompanying CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording.

src/java.base/share/classes/java/util/Locale.java line 460:

> 458:  * back to that of before Java SE 17. If the system property is set to
> 459:  * {@code true}, those three current language codes are mapped to their
> 460:  * backward compatible forms. It is only read at Java runtime startup, so a

I had thought about some of some minor word smithing in your prior commit, but chose not to request a change.

In the above sentence,  It could be clearer what "It" is.  Perhaps something along the lines of:

This property is only read at Java runtime startup  and subsequents calls to ...."

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From jvernee at openjdk.java.net  Mon Jun 28 19:06:06 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 19:06:06 GMT
Subject: [jdk17] RFR: JDK-8269426: Move tests from
 test/jdk/java/lang/invoke/t8150782 to its parent directory
In-Reply-To: 
References: 
 
Message-ID: <5ESzmpE26tHciu5sOuA1bwcEI286-VOR_SKskgdoYIU=.ba554756-0cf5-4962-a791-b026986e92e2@github.com>

On Mon, 28 Jun 2021 18:56:24 GMT, Mandy Chung  wrote:

> That's a fair point. I personally prefer using a descriptive directory name rather than bug ID since that can give the reader what the tests are intended for. What about renaming t8150782 to accessClassAndFindClass?

Me too! That sounds like an excellent idea :)

-------------

PR: https://git.openjdk.java.net/jdk17/pull/162

From weijun at openjdk.java.net  Mon Jun 28 19:09:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 28 Jun 2021 19:09:15 GMT
Subject: Integrated: 8269409: Post JEP 411 refactoring: core-libs with maximum
 covering > 10K
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang  wrote:

> More refactoring to limit the scope of `@SuppressWarnings` annotations.
> 
> Sometimes I introduce new methods. Please feel free to suggest method names you like to use.
> 
> Note: this is copied from https://github.com/openjdk/jdk17/pull/152.

This pull request has now been integrated.

Changeset: e9b2c058
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/e9b2c058a4ed5de29b991360f78fc1c5263c9268
Stats:     293 lines in 21 files changed: 165 ins; 64 del; 64 mod

8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/4615

From rriggs at openjdk.java.net  Mon Jun 28 19:10:09 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 28 Jun 2021 19:10:09 GMT
Subject: [jdk17] RFR: 8266313: (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 18:12:34 GMT, Jim Laskey  wrote:

>> The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Not averaging

src/java.base/share/classes/java/util/random/RandomGenerator.java line 644:

> 642:      *
> 643:      * @implSpec The default implementation checks that {@code bound} is a
> 644:      * positive int. Then invokes {@code nextInt()}, limiting the result to

I think if you are refering to the Java type it should be in {@ code xxx }.
"int" - > {@ code int}.  Or use "integer".
Ditto "ints", "long", and "longs" in the overridden methods below.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 674:

> 672:      * If {@code bound} is a power of two then limiting is a simple masking
> 673:      * operation. Otherwise, the result is re-calculated  by invoking
> 674:      * {@code nextInt()} until the result is greater equal {@code origin}

greater equal -> greater than or equal
and in the overloads below (and above)

-------------

PR: https://git.openjdk.java.net/jdk17/pull/151

From mchung at openjdk.java.net  Mon Jun 28 19:16:56 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 28 Jun 2021 19:16:56 GMT
Subject: [jdk17] RFR: JDK-8269426: Rename
 test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass [v2]
In-Reply-To: 
References: 
Message-ID: 

> `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. There are several tests under `` directory.  As the tests under `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for `Lookup::accessClass` and `Lookup::findClass`, they can simply be moved to the parent directory.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Keep the tests under a directory

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/162/files
  - new: https://git.openjdk.java.net/jdk17/pull/162/files/43cf6670..a7f8b892

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=162&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=162&range=00-01

  Stats: 0 lines in 6 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/162.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/162/head:pull/162

PR: https://git.openjdk.java.net/jdk17/pull/162

From jvernee at openjdk.java.net  Mon Jun 28 19:16:58 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 19:16:58 GMT
Subject: [jdk17] RFR: JDK-8269426: Rename
 test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 19:13:45 GMT, Mandy Chung  wrote:

>> `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. There are several tests under `` directory.  As the tests under `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for `Lookup::accessClass` and `Lookup::findClass`, they can simply be moved to the parent directory.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the tests under a directory

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/162

From mchung at openjdk.java.net  Mon Jun 28 19:16:59 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 28 Jun 2021 19:16:59 GMT
Subject: [jdk17] RFR: JDK-8269426: Rename
 test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 16:09:36 GMT, Mandy Chung  wrote:

> `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. There are several tests under `` directory.  As the tests under `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for `Lookup::accessClass` and `Lookup::findClass`, they can simply be moved to the parent directory.

Thanks Jorn.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/162

From iris at openjdk.java.net  Mon Jun 28 19:20:07 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 28 Jun 2021 19:20:07 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 18:37:34 GMT, Naoto Sato  wrote:

>> Please review this small doc change to the system property. Accompanying CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From joehw at openjdk.java.net  Mon Jun 28 19:27:12 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 28 Jun 2021 19:27:12 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 18:37:34 GMT, Naoto Sato  wrote:

>> Please review this small doc change to the system property. Accompanying CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From joehw at openjdk.java.net  Mon Jun 28 19:27:13 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 28 Jun 2021 19:27:13 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 28 Jun 2021 18:45:31 GMT, Lance Andersen  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refined wording.
>
> src/java.base/share/classes/java/util/Locale.java line 460:
> 
>> 458:  * back to that of before Java SE 17. If the system property is set to
>> 459:  * {@code true}, those three current language codes are mapped to their
>> 460:  * backward compatible forms. It is only read at Java runtime startup, so a
> 
> I had thought about some of some minor word smithing in your prior commit, but chose not to request a change.
> 
> In the above sentence,  It could be clearer what "It" is.  Perhaps something along the lines of:
> 
> This property is only read at Java runtime startup  and subsequents calls to ...."

Also, "backward compatible behavior" maybe not needed to be repeated, e.g. "subsequent calls to ... will have no effect.

"back to that of before Java SE 17" -- "of" may be removed.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From rriggs at openjdk.java.net  Mon Jun 28 19:45:34 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 28 Jun 2021 19:45:34 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v5]
In-Reply-To: 
References: 
Message-ID: <7-zpEI8gUqgGhY28nNV-y74sV11y3zf8PllYJX_bUSM=.185f9cc6-6628-40a4-89b5-fe71c1ab9a35@github.com>

> Add java.util.Objects.newIdentity to supply a unique object with identity.
> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add test synchronizing on return value of Objecst.newIdentity()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/112/files
  - new: https://git.openjdk.java.net/jdk17/pull/112/files/eef1029c..f99d0846

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=112&range=03-04

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk17/pull/112

From mchung at openjdk.java.net  Mon Jun 28 19:56:08 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 28 Jun 2021 19:56:08 GMT
Subject: [jdk17] Integrated: JDK-8269426: Rename
 test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 16:09:36 GMT, Mandy Chung  wrote:

> `test/jdk/java/lang/invoke/t8150782` is the only one using that convention. There are several tests under `` directory.  As the tests under `test/jdk/java/lang/invoke/t8150782` are mostly unit tests for `Lookup::accessClass` and `Lookup::findClass`, they can simply be moved to the parent directory.

This pull request has now been integrated.

Changeset: 56240690
Author:    Mandy Chung 
URL:       https://git.openjdk.java.net/jdk17/commit/56240690f62f9048a45a53525efccffdec235a8d
Stats:     9 lines in 6 files changed: 0 ins; 0 del; 9 mod

8269426: Rename test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.java.net/jdk17/pull/162

From jvernee at openjdk.java.net  Mon Jun 28 20:11:10 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Jun 2021 20:11:10 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v5]
In-Reply-To: <7-zpEI8gUqgGhY28nNV-y74sV11y3zf8PllYJX_bUSM=.185f9cc6-6628-40a4-89b5-fe71c1ab9a35@github.com>
References: 
 <7-zpEI8gUqgGhY28nNV-y74sV11y3zf8PllYJX_bUSM=.185f9cc6-6628-40a4-89b5-fe71c1ab9a35@github.com>
Message-ID: <86sSH5LxoqNLqDXJCLfFDfMfaayDXoZELXkIkiAu-3Y=.f5d3bf7f-b602-4578-9660-0ad99ed58587@github.com>

On Mon, 28 Jun 2021 19:45:34 GMT, Roger Riggs  wrote:

>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test synchronizing on return value of Objecst.newIdentity()

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From naoto at openjdk.java.net  Mon Jun 28 20:29:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Jun 2021 20:29:37 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 18:37:34 GMT, Naoto Sato  wrote:

>> Please review this small doc change to the system property. Accompanying CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording.

Thanks. I updated the PR and CSR accordingly. As to removing "of", I think the current form is fine, but I am not a native English speaker, so happy to correct it if it is wrong.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From naoto at openjdk.java.net  Mon Jun 28 20:29:33 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Jun 2021 20:29:33 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review this small doc change to the system property. Accompanying CSR has also been created.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refined wording #2.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/163/files
  - new: https://git.openjdk.java.net/jdk17/pull/163/files/3d25418c..da119219

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=163&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=163&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/163/head:pull/163

PR: https://git.openjdk.java.net/jdk17/pull/163

From naoto at openjdk.java.net  Mon Jun 28 20:33:29 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Jun 2021 20:33:29 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v4]
In-Reply-To: 
References: 
Message-ID: 

> Please review this small doc change to the system property. Accompanying CSR has also been created.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Missed one.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/163/files
  - new: https://git.openjdk.java.net/jdk17/pull/163/files/da119219..3b6ff65d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=163&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=163&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/163/head:pull/163

PR: https://git.openjdk.java.net/jdk17/pull/163

From iris at openjdk.java.net  Mon Jun 28 20:39:03 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 28 Jun 2021 20:39:03 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 20:33:29 GMT, Naoto Sato  wrote:

>> Please review this small doc change to the system property. Accompanying CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From igraves at openjdk.java.net  Mon Jun 28 21:00:20 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 28 Jun 2021 21:00:20 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in character
 classes
Message-ID: 

8199594: Add doc describing how (?x) ignores spaces in character classes

-------------

Commit messages:
 - Updating documentation on comments mode and character class whitespace

Changes: https://git.openjdk.java.net/jdk/pull/4618/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4618&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8199594
  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4618.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4618/head:pull/4618

PR: https://git.openjdk.java.net/jdk/pull/4618

From lancea at openjdk.java.net  Mon Jun 28 21:07:08 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Jun 2021 21:07:08 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 20:33:29 GMT, Naoto Sato  wrote:

>> Please review this small doc change to the system property. Accompanying CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From jwilhelm at openjdk.java.net  Mon Jun 28 22:07:38 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 28 Jun 2021 22:07:38 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8269426: Rename test/jdk/java/lang/invoke/t8150782 to accessClassAndFindClass
 - 8267952: async logging supports to dynamically change tags and decorators
 - 8269534: Remove java/util/concurrent/locks/Lock/TimedAcquireLeak.java from ProblemList.txt
 - 8269403: Fix jpackage tests to gracefully handle jpackage app launcher crashes
 - 8269304: Regression ~5% in 2005 in b27
 - 8268236: The documentation of the String.regionMatches method contains error

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4619&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4619&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4619/files
  Stats: 224 lines in 20 files changed: 163 ins; 15 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4619.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4619/head:pull/4619

PR: https://git.openjdk.java.net/jdk/pull/4619

From joehw at openjdk.java.net  Mon Jun 28 22:27:07 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 28 Jun 2021 22:27:07 GMT
Subject: [jdk17] RFR: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 28 Jun 2021 20:33:29 GMT, Naoto Sato  wrote:

>> Please review this small doc change to the system property. Accompanying CSR has also been created.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one.

Marked as reviewed by joehw (Reviewer).

Thanks for the update. As for "of", apparently the native speakers were fine with it ;-)

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From lance.andersen at oracle.com  Mon Jun 28 22:47:29 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 28 Jun 2021 22:47:29 +0000
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: 

Hi Jaikiran,

This is on my list to look at but did not get to today.

Best
Lance
On Jun 27, 2021, at 11:52 PM, Jaikiran Pai > wrote:

Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?

The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.

P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

-------------

Commit messages:
- 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream

Changes: https://git.openjdk.java.net/jdk/pull/4607/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=00
 Issue: https://bugs.openjdk.java.net/browse/JDK-8190753
 Stats: 139 lines in 2 files changed: 138 ins; 0 del; 1 mod
 Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
 Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

PR: https://git.openjdk.java.net/jdk/pull/4607

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com




From jwilhelm at openjdk.java.net  Mon Jun 28 23:07:44 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 28 Jun 2021 23:07:44 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 103 commits:

 - Merge
 - 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K
   
   Reviewed-by: lancea, naoto
 - 8269433: Remove effectively unused ReferenceProcessor::_enqueuing_is_done
   
   Reviewed-by: kbarrett, tschatzl
 - 8268902: Testing for threadObj != NULL is unnecessary in suspend handshake
   
   Reviewed-by: pchilanomate, dcubed
 - 8269222: Incorrect number of workers reported for reference processing
   
   Reviewed-by: tschatzl, sangheki
 - 8269122: The use of "extern const" for Register definitions generates poor code
   
   Reviewed-by: adinn, kbarrett, kvn
 - 8269003: Update the java manpage for JDK 18
   
   Reviewed-by: minqi
 - Merge
 - 8269261: The PlaceHolder code uses Thread everywhere but is always dealing with JavaThreads
   
   Reviewed-by: ccheung, coleenp
 - 8269129: Multiple tier1 tests in hotspot/jtreg/compiler are failing for client VMs
   
   Reviewed-by: kvn, iveresov
 - ... and 93 more: https://git.openjdk.java.net/jdk/compare/56240690...8863e7a7

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4619/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4619&range=01
  Stats: 27175 lines in 592 files changed: 16042 ins; 9481 del; 1652 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4619.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4619/head:pull/4619

PR: https://git.openjdk.java.net/jdk/pull/4619

From jwilhelm at openjdk.java.net  Mon Jun 28 23:07:45 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 28 Jun 2021 23:07:45 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 21:58:36 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 03d54e6e
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/03d54e6ef1a40ee78b0cc65ca0aea276fbdbc7b7
Stats:     224 lines in 20 files changed: 163 ins; 15 del; 46 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4619

From sean.coffey at oracle.com  Tue Jun 29 00:02:05 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 29 Jun 2021 01:02:05 +0100
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi Valerie,

many thanks for the thorough review. I've taken all your feedback on 
board with the latest push. Some of the test anomalies were a result of 
previous iterations of test edits I had been making.

Regarding the extra edits in 
"src/java.base/share/lib/security/default.policy", I had assumed it 
would be ok to tidy up the module under edit but I've reverted the 
unrelated changes now.

I was doubtful about removing the AccessController.doPrivileged blocks 
around the InnocuousThread.newSystemThread calls given that I wasn't 
sure which path the calling code would come from but on re-examination, 
I think it's ok to remove. The module provides the necessary permissions 
already and use of InnocuousThread solves the original permissions 
issue. Thanks for spotting!

> In test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java 
> :
>
> > +        if (args.length > 0) {
> +            Policy.setPolicy(new SimplePolicy());
> +            System.setSecurityManager(new SecurityManager());
> +        }

> Just curious, why split the loop into 2 and set the SecurityManager in 
> between the two loops? Can't we just set the policy/security manager 
> before the loop?
The test infra requires various permissions including the problem 
setContextClassLoader permission. I figured it was better to set up the 
test infra first and then trigger the security manager.

New edits just pushed for review.

regards,
Sean.


On 25/06/2021 23:31, Valerie Peng wrote:
> On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey  wrote:
>
>>> Sufficient permissions missing if this code was ever to run with SecurityManager.
>>>
>>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>>> Test case coverage extended to cover the SecurityManager scenario.
>>>
>>> Reviewer request: @valeriepeng
>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Move TokenPoller to Runnable
> src/java.base/share/lib/security/default.policy line 131:
>
>> 129:     permission java.lang.RuntimePermission "accessClassInPackage.com.sun.crypto.provider";
>> 130:     permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.misc";
>> 131:     permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*";
> Can we just do necessary changes? I noticed that this file seems to have mixed style, i.e. some lines are longer than 80 chars and some break into 2 lines with length less than 80 chars. Since the whole file is mixed, maybe just do what must be changed.
>
> src/java.base/share/lib/security/default.policy line 142:
>
>> 140:     permission java.security.SecurityPermission "clearProviderProperties.*";
>> 141:     permission java.security.SecurityPermission "removeProviderProperty.*";
>> 142:     permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
> Same "avoid unnecessary changes" comment here.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 952:
>
>> 950:         AccessController.doPrivileged((PrivilegedAction) () -> {
>> 951:             Thread t = InnocuousThread.newSystemThread(
>> 952:                     "Poller " + getName(),
> nit: "Poller " -> "Poller-" (like before)?
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 956:
>
>> 954:             assert t.getContextClassLoader() == null;
>> 955:             t.setDaemon(true);
>> 956:             t.setPriority(Thread.MIN_PRIORITY);
> nit: supply this priority value as an argument to the InnocuousThread.newSystemThread() call instead?
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1033:
>
>> 1031:         }
>> 1032:         cleaner = new NativeResourceCleaner();
>> 1033:         AccessController.doPrivileged((PrivilegedAction) () -> {
> It seems that the AccessController.doPrivileged((PrivilegedAction) () -> {} is un-necessary? I tried your test without it and test still passes.
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1039:
>
>> 1037:             assert t.getContextClassLoader() == null;
>> 1038:             t.setDaemon(true);
>> 1039:             t.setPriority(Thread.MIN_PRIORITY);
> nit: supply this priority value as an argument to the InnocuousThread.newSystemThread() call instead?
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line 1212:
>
>> 1210:
>> 1211:         this.token = token;
>> 1212:         if (cleaner == null) {
> This check seems duplicate to the one in createCleaner() call.
>
> test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 56:
>
>> 54:                 System.out.println("No NSS config found. Skipping.");
>> 55:                 return;
>> 56:             }
> Move this if-check block of code up before the for-loop?
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk17/pull/117

From coffeys at openjdk.java.net  Tue Jun 29 00:07:41 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 29 Jun 2021 00:07:41 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v3]
In-Reply-To: 
References: 
Message-ID: 

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

Sean Coffey 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:

 - Edits from review
 - Merge remote-tracking branch 'origin/master' into pkcs11-perms
 - Move TokenPoller to Runnable
 - 8269034: AccessControlException for SunPKCS11 daemon threads

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/117/files
  - new: https://git.openjdk.java.net/jdk17/pull/117/files/03af6494..e961ff09

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=117&range=01-02

  Stats: 3102 lines in 121 files changed: 2073 ins; 670 del; 359 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/117.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/117/head:pull/117

PR: https://git.openjdk.java.net/jdk17/pull/117

From jai.forums2013 at gmail.com  Tue Jun 29 01:40:42 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 29 Jun 2021 07:10:42 +0530
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream
In-Reply-To: 
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 
Message-ID: <550ba0b1-39e7-8b6c-93eb-cf8c4a138e1c@gmail.com>

Hello Lance,

Please take your time.

-Jaikiran

On 29/06/21 4:17 am, Lance Andersen wrote:
> Hi Jaikiran,
>
> This is on my list to look at but did not get to today.
>
> Best
> Lance
> On Jun 27, 2021, at 11:52 PM, Jaikiran Pai > wrote:
>
> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>
> -------------
>
> Commit messages:
> - 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream
>
> Changes: https://git.openjdk.java.net/jdk/pull/4607/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8190753
>   Stats: 139 lines in 2 files changed: 138 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607
>
> PR: https://git.openjdk.java.net/jdk/pull/4607
>
> [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>

From yyang at openjdk.java.net  Tue Jun 29 02:14:01 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 29 Jun 2021 02:14:01 GMT
Subject: RFR: 8269384: Determine native byte order for StringUTF16 via
 ByteOrder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang  wrote:

> Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.

Thanks for the detailed clarification!

The purpose of this PR is to skip the native call and use ByteOrder. Now I'm convinced that we should not change the initialization order casually, this will break some "future code" and make UnsafeConstants unable to use String.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4596

From david.holmes at oracle.com  Tue Jun 29 02:16:55 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 29 Jun 2021 12:16:55 +1000
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant
In-Reply-To: <_GqVJ6TpK-MvwTcJV8GWbWGfrPZqiR_7CZ2JhxvskR4=.30eb2331-345f-49c5-b6d8-fa7c733d608f@github.com>
References: 
 <_GqVJ6TpK-MvwTcJV8GWbWGfrPZqiR_7CZ2JhxvskR4=.30eb2331-345f-49c5-b6d8-fa7c733d608f@github.com>
Message-ID: 

On 29/06/2021 12:52 am, Christoph G?ttschkes wrote:
> On Mon, 28 Jun 2021 13:14:51 GMT, Christoph G?ttschkes  wrote:
> 
>> Hi,
>>
>> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
>>
>> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.
> 
> Thanks for the reviews.
> 
>> assuming the Platform utility methods do as would be expected
> 
> Yes, the utility method does the switch between "bin" and "lib" for windows and non-windows
> 
> https://github.com/openjdk/jdk17/blob/e4c5446340605b112e0918fa9dcb48aaeaa730c8/test/lib/jdk/test/lib/Platform.java#L346-L350
> 
> and it does the switch for the variant
> 
> https://github.com/openjdk/jdk17/blob/e4c5446340605b112e0918fa9dcb48aaeaa730c8/test/lib/jdk/test/lib/Platform.java#L361-L369
> 
> I only have a linux setup, so I tested this with a client and a server VM only on linux.
> Sorry, I didn't enable github workflows for my jdk17 fork yet. I did so now and hopefully the next commit will trigger it.

You can also trigger it manually. Go to your fork, go to the Actions 
tab, select the workflow, select the branch to run it on.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk17/pull/159
> 

From yyang at openjdk.java.net  Tue Jun 29 02:42:03 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 29 Jun 2021 02:42:03 GMT
Subject: Withdrawn: 8269384: Determine native byte order for StringUTF16 via
 ByteOrder
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 13:40:54 GMT, Yi Yang  wrote:

> Prefer using ByteOrder to compute byte order for StringUTF16 to determining byte order by native method StringUTF16.isBigEndian.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4596

From jjg at openjdk.java.net  Tue Jun 29 04:48:16 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 29 Jun 2021 04:48:16 GMT
Subject: [jdk17] RFR: JDK-8249646: Runtime.exec(String, String[],
 File) documentation contains literal {@link ...}
Message-ID: 

Please review a trivial `noreg-doc` fix for some javadoc tags for `java.lang.Runtime` for JDK17

-------------

Commit messages:
 - JDK-8249646: Runtime.exec(String, String[], File) documentation contains literal {@link ...}

Changes: https://git.openjdk.java.net/jdk17/pull/167/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=167&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249646
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/167.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/167/head:pull/167

PR: https://git.openjdk.java.net/jdk17/pull/167

From sundar at openjdk.java.net  Tue Jun 29 05:06:05 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 29 Jun 2021 05:06:05 GMT
Subject: [jdk17] RFR: JDK-8249646: Runtime.exec(String, String[],
 File) documentation contains literal {@link ...}
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Jun 2021 04:39:28 GMT, Jonathan Gibbons  wrote:

> Please review a trivial `noreg-doc` fix for some javadoc tags for `java.lang.Runtime` for JDK17

LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/167

From iris at openjdk.java.net  Tue Jun 29 05:16:01 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 29 Jun 2021 05:16:01 GMT
Subject: [jdk17] RFR: JDK-8249646: Runtime.exec(String, String[],
 File) documentation contains literal {@link ...}
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Jun 2021 04:39:28 GMT, Jonathan Gibbons  wrote:

> Please review a trivial `noreg-doc` fix for some javadoc tags for `java.lang.Runtime` for JDK17

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/167

From tvaleev at openjdk.java.net  Tue Jun 29 05:50:01 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 29 Jun 2021 05:50:01 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v5]
In-Reply-To: <7-zpEI8gUqgGhY28nNV-y74sV11y3zf8PllYJX_bUSM=.185f9cc6-6628-40a4-89b5-fe71c1ab9a35@github.com>
References: 
 <7-zpEI8gUqgGhY28nNV-y74sV11y3zf8PllYJX_bUSM=.185f9cc6-6628-40a4-89b5-fe71c1ab9a35@github.com>
Message-ID: 

On Mon, 28 Jun 2021 19:45:34 GMT, Roger Riggs  wrote:

>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401: Primitive Objects (Preview)](https://openjdk.java.net/jeps/401) for background.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test synchronizing on return value of Objecst.newIdentity()

Probably it would be better to have an inner class named like `Identity` instead of anonymous class? When debugging or analyzing memory dumps, it would be more user-friendly to see `Objects$Identity` than `Objects$1`.

Probably, not the part of this feature request, but it would be nice to add another method with string parameter, like `Objects.newIdentity("MY SENTINEL")`. The string should be stored in the field and returned from toString(). Again, this would make it easier to find where the object comes from during debugging or memory dump analysis. For the record, here's what we have in IntelliJ IDEA sources (Apache 2.0 licensed):


public final class ObjectUtils {
  private ObjectUtils() { }

  ...

  /**
   * Creates a new object which could be used as sentinel value (special value to distinguish from any other object). It does not equal
   * to any other object. Usually should be assigned to the static final field.
   *
   * @param name an object name, returned from {@link #toString()} to simplify the debugging or heap dump analysis
   *             (guaranteed to be stored as sentinel object field). If sentinel is assigned to the static final field,
   *             it's recommended to supply that field name (possibly qualified with the class name).
   * @return a new sentinel object
   */
  public static @NotNull Object sentinel(@NotNull @NonNls String name) {
    return new Sentinel(name);
  }

  private static final class Sentinel {
    private final String myName;

    Sentinel(@NotNull String name) {
      myName = name;
    }

    @Override
    public String toString() {
      return myName;
    }
  }

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From peter.levart at gmail.com  Tue Jun 29 07:05:03 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Jun 2021 09:05:03 +0200
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <495db34e-48a8-489d-8a86-36ba74870d60@gmail.com>
References: 
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 
 
 
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
 
 
 
 <495db34e-48a8-489d-8a86-36ba74870d60@gmail.com>
Message-ID: <8dc22ac8-01e4-b511-b0e1-0d8c416daa00@gmail.com>

Hi,

On 29/03/2021 12:46, Jaikiran Pai wrote:
>> Given the support of -C/-dir is new and -P is there for backwards 
>> compatibility then I see the choices are:
>>
>>   * Issue an error when -P and -C/-dir are specified together with -x
>>   * Silently ignore the -P option
>>   * Ignore -C/-dir and the behavior is if -xfP was specified.
>>
>>
>> I am leaning towards an error given this is a new feature when -P and 
>> -C/-dir are specified with -x
>
> That sounds reasonable to me. I'll update the PR accordingly to take 
> this into account.
>
> -Jaikiran
>

If we are trying to follow the semantics of tar -C option (gnutar and 
other Unix tar(s)) then I think -P may be combined with -C when 
extracting. The manpage for gnutar says:

 ?????? -C, --directory=DIR
 ????????????? Change to DIR before performing any operations. This 
option is order-sensitive, i.e. it affects all options that follow.

...the meaning is that relative paths from archive get extracted 
relative to current dir (possibly modified by -C) and that absolute 
paths get extracted to their absolute positions (i.e. not affected by 
current dir). The -C option (as implemented by tar) is also useful when 
gathering files/dirs from different base paths into common archive 
structure. Say you have the following (relative) directory/file structure:

dir1/subdir1/a.txt
dir1/subdir1/b.txt
dir1/file1.txt
dir2/subdir2/a.txt
dir2/subdir2/b.txt
dir2/file2.txt

The command:

tar -cf archive.tar -C dir1 . -C ../dir2 .

...will create archive.tar with the following content (notice the 2nd -C 
option is dependent on the 1st: -C literally changes the current 
directory before executing further options):

./
./subdir1/
./subdir1/a.txt
./subdir1/b.txt
./file1.txt
./
./subdir2/
./subdir2/a.txt
./subdir2/b.txt
./file2.txt


When extracting, -C may be used to scatter different relative archive 
files/dirs into different base paths. For example, the archive.tar from 
above can be extracted into original directory structure with the 
following command (empty dir1 and dir2 have to be already present):

tar -xf archive.tar -C dir1 ./file1.txt ./subdir1 -C ../dir2 ./file2.txt 
./subdir2


So here's a hint about the behavior of multiple -C options: if the 
option is -C, it should follow tar -C behavior.


Regards, Peter



From peter.levart at gmail.com  Tue Jun 29 07:16:16 2021
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Jun 2021 09:16:16 +0200
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <8dc22ac8-01e4-b511-b0e1-0d8c416daa00@gmail.com>
References: 
 
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 
 
 
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
 
 
 
 <495db34e-48a8-489d-8a86-36ba74870d60@gmail.com>
 <8dc22ac8-01e4-b511-b0e1-0d8c416daa00@gmail.com>
Message-ID: <75b4dc37-39ba-ee83-6657-de3a2a2d4335@gmail.com>

A word about "compatibility" with other jdk tools...

jar is a specific tool. It was initially conceived to be user-friendly 
with users that are already familiar with tar tool:

"The syntax for the jar command resembles the syntax for the tar command."

Mixing-in behaviors not consistent with tar will make it a strange 
hybrid. Trying to find common ground with other JDK tools will make it 
less flexible.


Regards, Peter


On 29/06/2021 09:05, Peter Levart wrote:
>
> Hi,
>
> On 29/03/2021 12:46, Jaikiran Pai wrote:
>>> Given the support of -C/-dir is new and -P is there for backwards 
>>> compatibility then I see the choices are:
>>>
>>>   * Issue an error when -P and -C/-dir are specified together with -x
>>>   * Silently ignore the -P option
>>>   * Ignore -C/-dir and the behavior is if -xfP was specified.
>>>
>>>
>>> I am leaning towards an error given this is a new feature when -P 
>>> and -C/-dir are specified with -x
>>
>> That sounds reasonable to me. I'll update the PR accordingly to take 
>> this into account.
>>
>> -Jaikiran
>>
>
> If we are trying to follow the semantics of tar -C option (gnutar and 
> other Unix tar(s)) then I think -P may be combined with -C when 
> extracting. The manpage for gnutar says:
>
> ?????? -C, --directory=DIR
> ????????????? Change to DIR before performing any operations. This 
> option is order-sensitive, i.e. it affects all options that follow.
>
> ...the meaning is that relative paths from archive get extracted 
> relative to current dir (possibly modified by -C) and that absolute 
> paths get extracted to their absolute positions (i.e. not affected by 
> current dir). The -C option (as implemented by tar) is also useful 
> when gathering files/dirs from different base paths into common 
> archive structure. Say you have the following (relative) 
> directory/file structure:
>
> dir1/subdir1/a.txt
> dir1/subdir1/b.txt
> dir1/file1.txt
> dir2/subdir2/a.txt
> dir2/subdir2/b.txt
> dir2/file2.txt
>
> The command:
>
> tar -cf archive.tar -C dir1 . -C ../dir2 .
>
> ...will create archive.tar with the following content (notice the 2nd 
> -C option is dependent on the 1st: -C literally changes the current 
> directory before executing further options):
>
> ./
> ./subdir1/
> ./subdir1/a.txt
> ./subdir1/b.txt
> ./file1.txt
> ./
> ./subdir2/
> ./subdir2/a.txt
> ./subdir2/b.txt
> ./file2.txt
>
>
> When extracting, -C may be used to scatter different relative archive 
> files/dirs into different base paths. For example, the archive.tar 
> from above can be extracted into original directory structure with the 
> following command (empty dir1 and dir2 have to be already present):
>
> tar -xf archive.tar -C dir1 ./file1.txt ./subdir1 -C ../dir2 
> ./file2.txt ./subdir2
>
>
> So here's a hint about the behavior of multiple -C options: if the 
> option is -C, it should follow tar -C behavior.
>
>
> Regards, Peter
>
>

From github.com+26887752+jaroslavtulach at openjdk.java.net  Tue Jun 29 07:28:09 2021
From: github.com+26887752+jaroslavtulach at openjdk.java.net (Jaroslav Tulach)
Date: Tue, 29 Jun 2021 07:28:09 GMT
Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested
In-Reply-To: 
References: 
Message-ID: <0Mf-bS1H6Xxf0uuo2CF8y0n5KiihoWhrtHeiHPJ1p30=.af12c0ee-3bde-4b5b-95f1-99008f1c3c1f@github.com>

On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach  wrote:

> There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior.

Is there anyone willing to sponsor this PR? What changes shall I make to get your sponsorship?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4280

From plevart at openjdk.java.net  Tue Jun 29 07:42:07 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 29 Jun 2021 07:42:07 GMT
Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested
In-Reply-To: 
References: 
Message-ID: 

On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach  wrote:

> There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior.

Well, if you are willing to take this further, I would suggest you modify the test so that it would only test the "correct" behavior and not also the "incorrect" one. Meaning, you should test annotated elements (class in you case) that are annotated with CLASS retention annotations only (at the time the annotation uses are compiled) and not with mixed set (CLASS and RUNTIME retention) annotations. In that case the outcome is sensible (and useful).
If others agree that adding such test is OK, I can sponsor it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4280

From plevart at openjdk.java.net  Tue Jun 29 08:04:06 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 29 Jun 2021 08:04:06 GMT
Subject: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested
In-Reply-To: 
References: 
Message-ID: <8p9Cm7liswN7nMI89G1Ffhn1yeW8K_ZLcIHN42u39ww=.c8d63ee5-0d75-4f75-bf98-e8e21350a5c1@github.com>

On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach  wrote:

> There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it in this pull request without any changes to the JVM behavior.

To share the information... I contacted one of the original authors of Java annotations, but he doesn't remember anything about the option. Here's the conversation...

On Thu, Jun 3, 2021 at 11:53 PM Peter Levart  wrote:
>
>             There is an undocumented JVM flag called "-XX+PreserveAllAnnotations"
>             which according to JVM code affects the way
>             "RuntimeInvisibleAnnotations" kind of class attributes are treated at
>             runtime. Normally they are ignored (since they normally contain only
>             metadata for annotation types with CLASS retention), but when this flag
>             is passed to JVM, such attributes are also passed to AnnotationParser
>             together with "RuntimeVisibleAnnotations" kind of class attributes.
>
>             So the question is: "What was the original intent of this JVM flag". A
>             debate sprung in a review thread on JDK GitHub and some say that this is
>             probably just a "leftover from an early implementation" and are
>             proposing to deprecate and remove it. Others (me mostly) see some sense
>             in the feature as it allows migrating an annotation type from CLASS
>             retention to RUNTIME without recompiling all the classes that use the
>             annotation. Do you happen to know the original intent of this JVM flag?

On Fri, Jun 4, 2021 at 6:54 AM Neal Gafter  wrote:
>
>         I don?t recall that flag, but my suspicion is that it was used to assist testing.
>         If you ask me, I think the ecosystem would be better without it.

On 04/06/2021 15:56, Neal Gafter wrote:
>
>       One more thing.  You don?t have to recompile uses of an annotation to migrate 
>       from class to runtime retention.  You only have to recompile the attribute declaration.

On Fri, Jun 4, 2021 at 7:15 AM Peter Levart  wrote:
>
>     Not really. The AnnotationParser does filter out annotations based on current "retention" 
>     of annotation type which is just a meta-annotation on the annotation type, so it would appear 
>     that only the annotation declaration has to be recompiled, but as I described, the annotation 
>     uses in classes that use the annotation get compiled into two kinds of class attributes: 
>     RuntimeVisibleAnnotations (those with RUNTIME retention) and RuntimeInvisibleAnnotations 
>     (those with CLASS retention). Only those from RuntimeVisibleAnnotations are passed to 
>     AnnotationParser at runtime unless this VM flag is given which makes the VM pass a concatenation 
>     of RuntimeVisibleAnnotations and RuntimeInvisibleAnnotations to the AnnotationParser.
>     So merely changing the annotation retention and recompiling the annotation declaration is not enough. 
>     You have to also either recompile annotation uses or pass this VM flag. 
>     So I was wondering if the flag was actually meant for this purpose.

On 04/06/2021 17:30, Neal Gafter wrote:
>
>     Got it. I don't remember anything about the VM flag, but I doubt it was designed to be used for this purpose.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4280

From sgehwolf at openjdk.java.net  Tue Jun 29 08:25:06 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 29 Jun 2021 08:25:06 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: 
References: 
 
Message-ID: <4TD_2jJOnOQ6-D2eCFdJzF3tQg_H-Vm6IrFcyX_xSIw=.028fbe3f-bc04-4b9c-8b35-a6a450a80f7f@github.com>

On Wed, 23 Jun 2021 13:37:59 GMT, Matthias Baesken  wrote:

>> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
>> 
>> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
>> 
>> 
>>   if (!cg_infos[PIDS_IDX]._data_complete) {
>>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>>     // keep the other controller info, pids is optional
>>   }
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjustments following Severins comments

This looks pretty good now. Looking forward to seeing container tests for this new code.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 559:

> 557:     return OSCONTAINER_ERROR;
> 558:   }
> 559:   // Unlimited memory in Cgroups V2 is the literal string 'max'

Please don't add version specific comments to version agnostic code. Suggestion: "Unlimited memory in cgroups is the literal string 'max' for some controllers, for example the pids controller."

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 268:

> 266:   char * pidsmax_str = pids_max_val();
> 267:   jlong pidsmax = limit_from_str(pidsmax_str);
> 268:   return pidsmax;

Do we need this local variable? Consider using `return limit_from_str(pidsmax_str);` instead.

src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 250:

> 248:   char * pidsmax_str = pids_max_val();
> 249:   jlong pidsmax = limit_from_str(pidsmax_str);
> 250:   return pidsmax;

Same here. Use `return limit_from_str(pidsmax_str);`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From jjg at openjdk.java.net  Tue Jun 29 14:35:05 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 29 Jun 2021 14:35:05 GMT
Subject: [jdk17] Integrated: JDK-8249646: Runtime.exec(String, String[],
 File) documentation contains literal {@link ...}
In-Reply-To: 
References: 
Message-ID: 

On Tue, 29 Jun 2021 04:39:28 GMT, Jonathan Gibbons  wrote:

> Please review a trivial `noreg-doc` fix for some javadoc tags for `java.lang.Runtime` for JDK17

This pull request has now been integrated.

Changeset: 25f9f19a
Author:    Jonathan Gibbons 
URL:       https://git.openjdk.java.net/jdk17/commit/25f9f19af9831e151a39518020aefa2c18fd7217
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8249646: Runtime.exec(String, String[], File) documentation contains literal {@link ...}

Reviewed-by: sundar, iris

-------------

PR: https://git.openjdk.java.net/jdk17/pull/167

From weijun at openjdk.java.net  Tue Jun 29 15:50:20 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 29 Jun 2021 15:50:20 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
Message-ID: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>

Add a cache to record which source has called `System::setSecurityManager` and only print out warning lines once for each.

-------------

Commit messages:
 - renaming variables, two callers in test
 - one warning for each caller

Changes: https://git.openjdk.java.net/jdk17/pull/166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=166&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269543
  Stats: 47 lines in 2 files changed: 34 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/166/head:pull/166

PR: https://git.openjdk.java.net/jdk17/pull/166

From rriggs at openjdk.java.net  Tue Jun 29 16:44:04 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 29 Jun 2021 16:44:04 GMT
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v5]
In-Reply-To: 
References: 
 <7-zpEI8gUqgGhY28nNV-y74sV11y3zf8PllYJX_bUSM=.185f9cc6-6628-40a4-89b5-fe71c1ab9a35@github.com>
 
Message-ID: 

On Tue, 29 Jun 2021 05:47:03 GMT, Tagir F. Valeev  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test synchronizing on return value of Objecst.newIdentity()
>
> Probably it would be better to have an inner class named like `Identity` instead of anonymous class? When debugging or analyzing memory dumps, it would be more user-friendly to see `Objects$Identity` than `Objects$1`.
> 
> Probably, not the part of this feature request, but it would be nice to add another method with string parameter, like `Objects.newIdentity("MY SENTINEL")`. The string should be stored in the field and returned from toString(). Again, this would make it easier to find where the object comes from during debugging or memory dump analysis. For the record, here's what we have in IntelliJ IDEA sources (Apache 2.0 licensed):
> 
> 
> public final class ObjectUtils {
>   private ObjectUtils() { }
> 
>   ...
> 
>   /**
>    * Creates a new object which could be used as sentinel value (special value to distinguish from any other object). It does not equal
>    * to any other object. Usually should be assigned to the static final field.
>    *
>    * @param name an object name, returned from {@link #toString()} to simplify the debugging or heap dump analysis
>    *             (guaranteed to be stored as sentinel object field). If sentinel is assigned to the static final field,
>    *             it's recommended to supply that field name (possibly qualified with the class name).
>    * @return a new sentinel object
>    */
>   public static @NotNull Object sentinel(@NotNull @NonNls String name) {
>     return new Sentinel(name);
>   }
> 
>   private static final class Sentinel {
>     private final String myName;
> 
>     Sentinel(@NotNull String name) {
>       myName = name;
>     }
> 
>     @Override
>     public String toString() {
>       return myName;
>     }
>   }

@amaembo Good suggestion for the Valhalla API and implementation.  Today, only the hashCode() identifies an Object.
For JDK17, it will continue to be a raw Object() instance.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/112

From forax at univ-mlv.fr  Tue Jun 29 17:31:14 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 29 Jun 2021 19:31:14 +0200 (CEST)
Subject: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method
 [v5]
In-Reply-To: 
References: 
 <7-zpEI8gUqgGhY28nNV-y74sV11y3zf8PllYJX_bUSM=.185f9cc6-6628-40a4-89b5-fe71c1ab9a35@github.com>
 
 
Message-ID: <65175879.1277671.1624987874979.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Roger Riggs" 
> To: "core-libs-dev" 
> Sent: Mardi 29 Juin 2021 18:44:04
> Subject: Re: [jdk17] RFR: 8269096: Add java.util.Objects.newIdentity method [v5]

> On Tue, 29 Jun 2021 05:47:03 GMT, Tagir F. Valeev  wrote:
> 
>>> Roger Riggs has updated the pull request incrementally with one additional
>>> commit since the last revision:
>>> 
>>>   Add test synchronizing on return value of Objecst.newIdentity()
>>
>> Probably it would be better to have an inner class named like `Identity` instead
>> of anonymous class? When debugging or analyzing memory dumps, it would be more
>> user-friendly to see `Objects$Identity` than `Objects$1`.
>> 
>> Probably, not the part of this feature request, but it would be nice to add
>> another method with string parameter, like `Objects.newIdentity("MY
>> SENTINEL")`. The string should be stored in the field and returned from
>> toString(). Again, this would make it easier to find where the object comes
>> from during debugging or memory dump analysis. For the record, here's what we
>> have in IntelliJ IDEA sources (Apache 2.0 licensed):
>> 
>> 
>> public final class ObjectUtils {
>>   private ObjectUtils() { }
>> 
>>   ...
>> 
>>   /**
>>    * Creates a new object which could be used as sentinel value (special value to
>>    distinguish from any other object). It does not equal
>>    * to any other object. Usually should be assigned to the static final field.
>>    *
>>    * @param name an object name, returned from {@link #toString()} to simplify the
>>    debugging or heap dump analysis
>>    *             (guaranteed to be stored as sentinel object field). If sentinel is
>>    assigned to the static final field,
>>    *             it's recommended to supply that field name (possibly qualified
>>    with the class name).
>>    * @return a new sentinel object
>>    */
>>   public static @NotNull Object sentinel(@NotNull @NonNls String name) {
>>     return new Sentinel(name);
>>   }
>> 
>>   private static final class Sentinel {
>>     private final String myName;
>> 
>>     Sentinel(@NotNull String name) {
>>       myName = name;
>>     }
>> 
>>     @Override
>>     public String toString() {
>>       return myName;
>>     }
>>   }
> 
> @amaembo Good suggestion for the Valhalla API and implementation.  Today, only
> the hashCode() identifies an Object.
> For JDK17, it will continue to be a raw Object() instance.

We should try to have a very limited API surface for now.
We want to let the door open to having Object being both an identity class (when used with "new") and an abstract class (when inherited) by using two different generic specialization of the same class or whatever other scheme we come before Valhalla is complete.

> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk17/pull/112

R?mi

From jlaskey at openjdk.java.net  Tue Jun 29 17:36:30 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 29 Jun 2021 17:36:30 GMT
Subject: [jdk17] RFR: 8266313: (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes [v3]
In-Reply-To: 
References: 
Message-ID: 

> The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Clean up follow up
 - Clean up wording

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/151/files
  - new: https://git.openjdk.java.net/jdk17/pull/151/files/bfb61c8d..b87d22fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=151&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=151&range=01-02

  Stats: 24 lines in 1 file changed: 3 ins; 0 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/151/head:pull/151

PR: https://git.openjdk.java.net/jdk17/pull/151

From jlaskey at openjdk.java.net  Tue Jun 29 17:39:07 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 29 Jun 2021 17:39:07 GMT
Subject: [jdk17] RFR: 8266313: (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <_fOWk7yTw5JHZj0VKWKhqS9EQDdoRvHD0tescWzcERw=.487345e5-ddcd-4573-b8c9-6c113ecd80a7@github.com>

On Mon, 28 Jun 2021 19:07:09 GMT, Roger Riggs  wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Not averaging
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 644:
> 
>> 642:      *
>> 643:      * @implSpec The default implementation checks that {@code bound} is a
>> 644:      * positive int. Then invokes {@code nextInt()}, limiting the result to
> 
> I think if you are refering to the Java type it should be in {@ code xxx }.
> "int" - > {@ code int}.  Or use "integer".
> Ditto "ints", "long", and "longs" in the overridden methods below.

Updated

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 674:
> 
>> 672:      * If {@code bound} is a power of two then limiting is a simple masking
>> 673:      * operation. Otherwise, the result is re-calculated  by invoking
>> 674:      * {@code nextInt()} until the result is greater equal {@code origin}
> 
> greater equal -> greater than or equal
> and in the overloads below (and above)

Updated

-------------

PR: https://git.openjdk.java.net/jdk17/pull/151

From valeriep at openjdk.java.net  Tue Jun 29 17:47:07 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 29 Jun 2021 17:47:07 GMT
Subject: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon
 threads [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Jun 2021 00:07:41 GMT, Sean Coffey  wrote:

>> Sufficient permissions missing if this code was ever to run with SecurityManager. 
>> 
>> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>> 
>> Reviewer request: @valeriepeng
>
> Sean Coffey 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:
> 
>  - Edits from review
>  - Merge remote-tracking branch 'origin/master' into pkcs11-perms
>  - Move TokenPoller to Runnable
>  - 8269034: AccessControlException for SunPKCS11 daemon threads

Update looks good. Thanks, Valerie

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/117

From rriggs at openjdk.java.net  Tue Jun 29 17:52:09 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 29 Jun 2021 17:52:09 GMT
Subject: [jdk17] RFR: 8266313: (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 29 Jun 2021 17:36:30 GMT, Jim Laskey  wrote:

>> The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Clean up follow up
>  - Clean up wording

Thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/151

From lancea at openjdk.java.net  Tue Jun 29 18:01:10 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 29 Jun 2021 18:01:10 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v2]
In-Reply-To: 
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 
Message-ID: 

On Mon, 28 Jun 2021 09:13:31 GMT, Jaikiran Pai  wrote:

>> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>> 
>> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>> 
>> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @requires to the new test to selectively decide where the test runs

Thank you for looking into this issue.  

I ran your current test 150 times and the max runtime was 25 seconds, most cases were in the 18-20 second range on our slower test boxes.  

As part of looking at what happens with a file whose deflated size is > 2gb, I would add a specific test which is a manual test to validate that there is no issue when we cross the 2gb threshold.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1954:

> 1952:         } else {
> 1953:             os = new ByteArrayOutputStream((e.size > 0 && e.size <= MAX_ARRAY_SIZE)? (int)e.size : 8192);
> 1954:         }

The proposed change will address the specific issue shown in the bug.   As Alan points out, there could be an issue if the deflated size is > 2gb.  It would be good to look into that as part of your proposed fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From dfuchs at openjdk.java.net  Tue Jun 29 18:50:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 29 Jun 2021 18:50:08 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
Message-ID: 

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang  wrote:

> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.

src/java.base/share/classes/java/lang/System.java line 337:

> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
> 336:     }
> 337: 

I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From rriggs at openjdk.java.net  Tue Jun 29 19:26:04 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 29 Jun 2021 19:26:04 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
Message-ID: 

On Tue, 29 Jun 2021 18:47:23 GMT, Daniel Fuchs  wrote:

>> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.
>
> src/java.base/share/classes/java/lang/System.java line 337:
> 
>> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
>> 336:     }
>> 337: 
> 
> I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.

Using a HashSet could use the callerClass as the key and be a stable reference for having given the message.
or use a ConcurrentHashMap>, boolean> and avoid any separate synchronization that would be needed with a HashSet or HashMap.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From naoto at openjdk.java.net  Tue Jun 29 19:29:04 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 29 Jun 2021 19:29:04 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on
 localized Windows platform
In-Reply-To: 
References: 
Message-ID: 

On Fri, 25 Jun 2021 12:10:18 GMT, Masanori Yano  wrote:

> Hi all,
> 
> Could you please review the 8269373 bug fixes?
> 
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.

>From a peek at the bug report, I could not find out the exact cause why they are failing. Have you figured it out?

As to the fix itself, I would rather avoid hardcoding `en-US` in the argument. Would that be replaced with the launching process' locale?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4594

From weijun at openjdk.java.net  Tue Jun 29 19:39:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 29 Jun 2021 19:39:03 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
Message-ID: 

On Tue, 29 Jun 2021 19:23:26 GMT, Roger Riggs  wrote:

>> src/java.base/share/classes/java/lang/System.java line 337:
>> 
>>> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
>>> 336:     }
>>> 337: 
>> 
>> I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.
>
> Using a HashSet could use the callerClass as the key and be a stable reference for having given the message.
> or use a ConcurrentHashMap>, boolean> and avoid any separate synchronization that would be needed with a HashSet or HashMap.

If I switch to a "non-weak" set or map, then it seems I can safely use the source string as the key. Will using the Class object as a key prevent them from unloading?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From rriggs at openjdk.java.net  Tue Jun 29 19:59:59 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 29 Jun 2021 19:59:59 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
 
Message-ID: <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>

On Tue, 29 Jun 2021 19:35:40 GMT, Weijun Wang  wrote:

>> Using a HashSet could use the callerClass as the key and be a stable reference for having given the message.
>> or use a ConcurrentHashMap>, boolean> and avoid any separate synchronization that would be needed with a HashSet or HashMap.
>
> If I switch to a "non-weak" set or map, then it seems I can safely use the source string as the key. Will using the Class object as a key prevent them from unloading?

Using a synchronized WeakHashMap with the class as the key would not prevent class unloading.
Using a non-weak set or map to strings would keep the strings around for the life of the runtime.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From weijun at openjdk.java.net  Tue Jun 29 21:22:05 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 29 Jun 2021 21:22:05 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
 
 <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>
Message-ID: 

On Tue, 29 Jun 2021 19:57:24 GMT, Roger Riggs  wrote:

>> If I switch to a "non-weak" set or map, then it seems I can safely use the source string as the key. Will using the Class object as a key prevent them from unloading?
>
> Using a synchronized WeakHashMap with the class as the key would not prevent class unloading.
> Using a non-weak set or map to strings would keep the strings around for the life of the runtime.

I hope this is uncommon but if that class is created by a `ClassLoader` again and again then it will be different each time. I'll investigate more.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From coffeys at openjdk.java.net  Tue Jun 29 22:56:07 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 29 Jun 2021 22:56:07 GMT
Subject: [jdk17] Integrated: 8269034: AccessControlException for SunPKCS11
 daemon threads
In-Reply-To: 
References: 
Message-ID: 

On Tue, 22 Jun 2021 13:26:41 GMT, Sean Coffey  wrote:

> Sufficient permissions missing if this code was ever to run with SecurityManager. 
> 
> Cleanest approach appears to be use of InnocuousThread to create the cleaner/poller threads.
> Test case coverage extended to cover the SecurityManager scenario.
> 
> Reviewer request: @valeriepeng

This pull request has now been integrated.

Changeset: 0d745ae8
Author:    Sean Coffey 
URL:       https://git.openjdk.java.net/jdk17/commit/0d745ae8fde5cab290dc8c695d2906f9a98c491c
Stats:     95 lines in 5 files changed: 53 ins; 17 del; 25 mod

8269034: AccessControlException for SunPKCS11 daemon threads

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk17/pull/117

From jwilhelm at openjdk.java.net  Wed Jun 30 00:39:07 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 00:39:07 GMT
Subject: RFR: Merge jdk17
Message-ID: 

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8269034: AccessControlException for SunPKCS11 daemon threads
 - 8269529: javax/swing/reliability/HangDuringStaticInitialization.java fails in Windows debug build
 - 8269232: assert(!is_jweak(handle)) failed: wrong method for detroying jweak
 - 8268884: C2: Compile::remove_speculative_types must iterate top-down
 - 8249646: Runtime.exec(String, String[], File) documentation contains literal {@link ...}
 - 8268699: Shenandoah: Add test for JDK-8268127
 - 8269517: compiler/loopopts/TestPartialPeelingSinkNodes.java crashes with -XX:+VerifyGraphEdges
 - 8269126: Rename G1AllowPreventiveGC option to G1UsePreventiveGC

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/4630/files
  Stats: 127 lines in 11 files changed: 70 ins; 17 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4630/head:pull/4630

PR: https://git.openjdk.java.net/jdk/pull/4630

From jwilhelm at openjdk.java.net  Wed Jun 30 01:25:33 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 01:25:33 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 00:31:34 GMT, Jesper Wilhelmsson  wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: ee526a2e
Author:    Jesper Wilhelmsson 
URL:       https://git.openjdk.java.net/jdk/commit/ee526a2ea840aedb97b23538f9d624acbccebc97
Stats:     127 lines in 11 files changed: 70 ins; 17 del; 40 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4630

From jwilhelm at openjdk.java.net  Wed Jun 30 01:25:32 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 30 Jun 2021 01:25:32 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: 
References: 
Message-ID: <8_fkYpZLlCG8Nj5dx5WhuZsWDbFnUHu4OWWY735hdr0=.625da0e5-831e-4c10-afbc-aa5364fba16b@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 113 commits:

 - Merge
 - 8269615: Fix for 8263640 broke Windows build
   
   Reviewed-by: iklam, dcubed
 - 8269268: JDWP: Properly fix thread lookup assert in findThread()
   
   Reviewed-by: kevinw, amenkov, sspitsyn
 - 8260540: serviceability/jdwp/AllModulesCommandTest.java failed with "Debuggee error: 'ERROR: transport error 202: bind failed: Address already in use'"
   
   Reviewed-by: sspitsyn, kevinw
 - 8263640: hs_err improvement: handle class path longer than O_BUFLEN
   
   Reviewed-by: iklam, minqi, dholmes
 - 8269417: Minor clarification on NonblockingQueue utility
   
   Reviewed-by: kbarrett, iwalulya
 - 8269530: runtime/ParallelLoad/ParallelSuperTest.java timeout
   
   Reviewed-by: dholmes, coleenp
 - 8269126: Rename G1AllowPreventiveGC option to G1UsePreventiveGC
   
   Reviewed-by: iwalulya, kbarrett
 - 8261579: AArch64: Support for weaker memory ordering in Atomic
   
   Reviewed-by: adinn, shade
 - 8268821: Split systemDictionaryShared.cpp
   
   Reviewed-by: erikj, ccheung, iklam
 - ... and 103 more: https://git.openjdk.java.net/jdk/compare/0d745ae8...be964f2e

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4630/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4630&range=01
  Stats: 30219 lines in 619 files changed: 17676 ins; 10608 del; 1935 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4630.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4630/head:pull/4630

PR: https://git.openjdk.java.net/jdk/pull/4630

From bpb at openjdk.java.net  Wed Jun 30 01:26:03 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Jun 2021 01:26:03 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v5]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Mon, 28 Jun 2021 17:48:37 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 6766844: Move API note of read(byte[],int,int) to normative text
>  - 6766844: Change "equivalent" to "overridden"

[CSR](https://bugs.openjdk.java.net/browse/JDK-8269399) revised to match.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From alanb at openjdk.java.net  Wed Jun 30 06:35:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 30 Jun 2021 06:35:05 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
 
 <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>
 
Message-ID: 

On Tue, 29 Jun 2021 21:18:35 GMT, Weijun Wang  wrote:

>> Using a synchronized WeakHashMap with the class as the key would not prevent class unloading.
>> Using a non-weak set or map to strings would keep the strings around for the life of the runtime.
>
> I hope this is uncommon but if that class is loaded by a `ClassLoader` again and again then it will be different each time. I'll investigate more.

WeakHashMap, Boolean>, where the key is the caller, should be okay (assume synchronization of course). Even with applications that do call setSecurityManager then the map is probably going to be one entry. I wouldn't expect it is common to create custom class loaders that load code that sets a security manager, meaning it is more likely that the container sets the SM rather have each plugin/application/whatever try to set the system-wide SM.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From ecki at zusammenkunft.net  Wed Jun 30 07:19:42 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 30 Jun 2021 07:19:42 +0000
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>,
 
Message-ID: 

Hello, sorry for being unpopular, but I just hate it to waste developer resources,

I realy think this deprecation message should be re-considered, it broke a lot of things, the amount of work to implement a caching solution feels like a waste of time and on top of it, there is no clear replacement strategy published yet.

I would restrict deprication (for removal if you really insist) to javadoc and not poison stdout/stderr.

I think we stirred up enough PR that a message was received by maintainers, no need to further damage java reputation by breaking perfectly working inter process interfaces. (This is btw true for all such warnings). And I also think top priority should be to publish a go-forward route which should not depend solely on MR-Jars,

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
Von: security-dev  im Auftrag von Daniel Fuchs 
Gesendet: Tuesday, June 29, 2021 8:50:08 PM
An: core-libs-dev at openjdk.java.net ; security-dev at openjdk.java.net 
Betreff: Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang  wrote:

> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.

src/java.base/share/classes/java/lang/System.java line 337:

> 335:             = Collections.synchronizedMap(new WeakHashMap<>());
> 336:     }
> 337:

I wonder about the use of a WeakHashMap here. That may work well when the source is an interned string (a class name) which will be strongly referenced elsewhere and may be garbage collected if the class is unloaded, but in the case where it contains the name of the source jar then that string will only be referenced by the weak hashmap, and therefore it could be garbage collected any time - which would cause the mapping to be removed. In that case you cannot guarantee that the warning will be emitted only once.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From Alan.Bateman at oracle.com  Wed Jun 30 08:15:13 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Jun 2021 09:15:13 +0100
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
Message-ID: <81d9a604-8586-67fa-39f2-3cc447e1eade@oracle.com>

On 30/06/2021 08:19, Bernd Eckenfels wrote:
> Hello, sorry for being unpopular, but I just hate it to waste 
> developer resources,
>
> I realy think this deprecation message should be re-considered, it 
> broke a lot of things, the amount of work to implement a caching 
> solution feels like a waste of time and on top of it, there is no 
> clear replacement strategy published yet.
>
> I would restrict deprication (for removal if you really insist) to 
> javadoc and not poison stdout/stderr.
>

The purpose of the warning message is to make it very clear that 
applications that call System.setSecurityManager in a running VM will 
fail in the future. It is not hugely different to the "Illegal 
reflective access" warning that were emitted in JDK 9 to JDK 15. Maybe 
you could clarify what you mean by "it broke a lot of things". If you 
have something that is sensitive to warnings going to stderr then I 
would have expected the "Illegal reflective access" warnings to have 
caused a lot more issues.

-Alan.

From cgo at openjdk.java.net  Wed Jun 30 08:36:05 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 30 Jun 2021 08:36:05 GMT
Subject: [jdk17] RFR: 8269486: CallerAccessTest fails for non server
 variant [v2]
In-Reply-To: 
References: 
 
Message-ID: <7mXdDya96fJuU15JqIFCjpgnC02KF9zohBKqHUJ6c2U=.4194a62f-e8b5-4180-b5c8-c23e222621b3@github.com>

On Mon, 28 Jun 2021 14:52:41 GMT, Christoph G?ttschkes  wrote:

>> Hi,
>> 
>> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
>> 
>> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.
>
> Christoph G?ttschkes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renames serverDir to vmDir.

Thanks for the reviews and testing.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/159

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun 30 08:47:24 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 30 Jun 2021 08:47:24 GMT
Subject: RFR: 8269665: Clean-up toString() methods of some primitive wrappers
Message-ID: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com>

As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods.

Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`.

Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first):

public static String toString(byte b) {
    return Integer.toString((int)b, 10);
}

public String toString() {
    return Integer.toString((int)value);
}

Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
public class ByteToStringBenchmark {
    @Benchmark
    public String byteToString() {
        return Byte.toString((byte) 1);
    }
}

Results:

before

Benchmark                                                            Mode  Cnt     Score     Error   Units
ByteToStringBenchmark.byteToString                                   avgt   30    11,648 ?   1,906   ns/op
ByteToStringBenchmark.byteToString:?gc.alloc.rate                    avgt   30  3288,576 ? 418,119  MB/sec
ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm               avgt   30    48,001 ?   0,001    B/op
ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space           avgt   30  3301,804 ? 455,932  MB/sec
ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm      avgt   30    48,158 ?   2,085    B/op
ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space       avgt   30     0,004 ?   0,001  MB/sec
ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm  avgt   30    ? 10??              B/op
ByteToStringBenchmark.byteToString:?gc.count                         avgt   30   202,000            counts
ByteToStringBenchmark.byteToString:?gc.time                          avgt   30   413,000                ms

after

Benchmark                                                            Mode  Cnt     Score     Error   Units
ByteToStringBenchmark.byteToString                                   avgt   30    10,016 ?   0,530   ns/op
ByteToStringBenchmark.byteToString:?gc.alloc.rate                    avgt   30  3673,700 ? 167,450  MB/sec
ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm               avgt   30    48,001 ?   0,001    B/op
ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space           avgt   30  3662,406 ? 205,978  MB/sec
ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm      avgt   30    47,870 ?   1,750    B/op
ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space       avgt   30     0,004 ?   0,002  MB/sec
ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm  avgt   30    ? 10??              B/op
ByteToStringBenchmark.byteToString:?gc.count                         avgt   30   224,000            counts
ByteToStringBenchmark.byteToString:?gc.time                          avgt   30   358,000                ms

-------------

Commit messages:
 - 8269665: Clean-up toString() methods of some primitive wrappers

Changes: https://git.openjdk.java.net/jdk/pull/4633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4633&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269665
  Stats: 10 lines in 4 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4633/head:pull/4633

PR: https://git.openjdk.java.net/jdk/pull/4633

From jlahoda at openjdk.java.net  Wed Jun 30 10:23:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 30 Jun 2021 10:23:32 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v6]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: 

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
> 
> How does this look?

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Reflecting review comments.
 - Merge branch 'master' into JDK-8268766
 - Improving javadoc.
 - Updating javadoc, as suggested.
 - Updating javadoc, code and tests as suggested.
 - Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
 - Adding and fixing test.
 - Merging master.
 - 8268766: Desugaring of pattern matching enum switch should be improved

-------------

Changes: https://git.openjdk.java.net/jdk17/pull/81/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=81&range=05
  Stats: 416 lines in 6 files changed: 278 ins; 68 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

PR: https://git.openjdk.java.net/jdk17/pull/81

From jbhateja at openjdk.java.net  Wed Jun 30 11:02:41 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 30 Jun 2021 11:02:41 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v9]
In-Reply-To: 
References: 
Message-ID: 

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
> 
> 
> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | --
> ? | ? | ? | ? | ? | ? | ? | ? | ?
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
 - 8266054: Removing redundant teat templates.
 - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform.
 - 8266054: Removing redundant test templates.
 - 8266054: Review comments resolution.
 - 8266054: Review comments resolution.
 - 8266054: Review comments resolution.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/a0f32cb1...c60355d7

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3720/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=08
  Stats: 4393 lines in 52 files changed: 4172 ins; 60 del; 161 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

PR: https://git.openjdk.java.net/jdk/pull/3720

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun 30 11:49:51 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 30 Jun 2021 11:49:51 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v2]
In-Reply-To: 
References: 
Message-ID: 

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8268764
 - 8268764: Use Long.hashCode() instead of int-cast where applicable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/27233ae1..12a1d3ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4491&range=00-01

  Stats: 44011 lines in 878 files changed: 23038 ins; 17963 del; 3010 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4491/head:pull/4491

PR: https://git.openjdk.java.net/jdk/pull/4491

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun 30 11:50:52 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 30 Jun 2021 11:50:52 GMT
Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v8]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: 

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

?????? ??????? 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 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - 8268113: Delegate to Double.hashCode()
 - 8268113: Re-use Long.hashCode() where possible

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/f1c8cc7b..4ec7c829

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=06-07

  Stats: 56052 lines in 1127 files changed: 32406 ins; 19375 del; 4271 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun 30 11:52:25 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 30 Jun 2021 11:52:25 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v3]
In-Reply-To: 
References: 
Message-ID: 

> After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
   
   # Conflicts:
   #	src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java
 - Merge branch 'master' into purge-linked-list
 - 8263561: Use sized constructor where reasonable
 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4304/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=02
  Stats: 48 lines in 9 files changed: 0 ins; 2 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4304.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304

PR: https://git.openjdk.java.net/jdk/pull/4304

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jun 30 11:54:57 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 30 Jun 2021 11:54:57 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues.
> 
> However the code like
> 
> private String getSimpleName0() {
>     if (isArray()) {
>         return getComponentType().getSimpleName() + "[]";
>     }
>     //...
> }
> 
> can be improved via replacement of `+` with `String.concat()` call.
> 
> I've used this benchmark to measure impact:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
>   private final Class arrayClass = Object[].class;
>   private Method descriptorString;
> 
>   @Setup
>   public void setUp() throws NoSuchMethodException {
>     //fore some reason compiler doesn't allow me to call Class.descriptorString() directly
>     descriptorString = Class.class.getDeclaredMethod("descriptorString");
>   }
> 
>   @Benchmark
>   public Object descriptorString() throws Exception {
>     return descriptorString.invoke(arrayClass);
>   }
> 
>   @Benchmark
>   public Object typeName() {
>     return arrayClass.getTypeName();
>   }
> }
> 
> and got those results
> 
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    91.480 ?   1.839   ns/op
> descriptorString:?gc.alloc.rate.norm               avgt   60   404.008 ?   4.033    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866 ? 181.589  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702 ?  26.047    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   205.000            counts
> descriptorString:?gc.time                          avgt   60   216.000                ms
> 
> patched
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    65.016 ?   3.446   ns/op
> descriptorString:?gc.alloc.rate                    avgt   60  2844.240 ? 115.719  MB/sec
> descriptorString:?gc.alloc.rate.norm               avgt   60   288.006 ?   0.001    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996 ? 206.939  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955 ?  17.853    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   208.000            counts
> descriptorString:?gc.time                          avgt   60   228.000                ms
> -----------------
> typeName                                           avgt   60    34.273 ?   0.480   ns/op
> typeName:?gc.alloc.rate                            avgt   60  3265.356 ?  45.113  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60   176.004 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454 ? 134.458  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109 ?   6.595    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   240.000            counts
> typeName:?gc.time                                  avgt   60   255.000                ms
> 
> patched
> 
> typeName                                           avgt   60    15.787 ?   0.214   ns/op
> typeName:?gc.alloc.rate                            avgt   60  2577.554 ?  32.339  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60    64.001 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039 ? 147.774  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895 ?   3.511    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   189.000            counts
> typeName:?gc.time                                  avgt   60   199.000                ms
> 
> I think this patch is likely to improve reflection operations related to arrays.
> 
> If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible.
> 
> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here.

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into class-concat
 - 8266972: Use String.concat() in j.l.Class.toSting()
 - Use String.concat() where invokedynamic-based String concatenation is not available

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3627/files
  - new: https://git.openjdk.java.net/jdk/pull/3627/files/81568116..1637571e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=01-02

  Stats: 1193389 lines in 9795 files changed: 577912 ins; 583941 del; 31536 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627

PR: https://git.openjdk.java.net/jdk/pull/3627

From kevinw at openjdk.java.net  Wed Jun 30 13:23:14 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Wed, 30 Jun 2021 13:23:14 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Jun 2021 11:49:51 GMT, ?????? ???????  wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8268764
>  - 8268764: Use Long.hashCode() instead of int-cast where applicable

The changes look good to me, we have done the same thing elsewhere.  This changes things in different functional areas, which is maybe unusual, but seems fine for a small change as long as nobody objects.

Some of the files also need a (C) year update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4491

From psandoz at openjdk.java.net  Wed Jun 30 15:21:03 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 30 Jun 2021 15:21:03 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v6]
In-Reply-To: 
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 
Message-ID: <5LvETl-jl0M3RUn1HU69_5Q-_auEweOY-2psiJH7QN0=.4caaa103-6aac-4caf-be45-a05e6e12e02b@github.com>

On Wed, 30 Jun 2021 10:23:32 GMT, Jan Lahoda  wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Reflecting review comments.
>  - Merge branch 'master' into JDK-8268766
>  - Improving javadoc.
>  - Updating javadoc, as suggested.
>  - Updating javadoc, code and tests as suggested.
>  - Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
>  - Adding and fixing test.
>  - Merging master.
>  - 8268766: Desugaring of pattern matching enum switch should be improved

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/81

From weijun at openjdk.java.net  Wed Jun 30 15:45:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 30 Jun 2021 15:45:25 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller [v2]
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
 
 
 <3yMDt-OG-3J2q1GXCaasKwFlEPR5q2wzx51FlGXtXNM=.47f02455-fd8e-40b1-80e6-e59988e335c1@github.com>
 
 
Message-ID: 

On Wed, 30 Jun 2021 06:32:04 GMT, Alan Bateman  wrote:

>> I hope this is uncommon but if that class is loaded by a `ClassLoader` again and again then it will be different each time. I'll investigate more.
>
> WeakHashMap, Boolean>, where the key is the caller, should be okay (assume synchronization of course). Even with applications that do call setSecurityManager then the map is probably going to be one entry. I wouldn't expect it is common to create custom class loaders that load code that sets a security manager, meaning it is more likely that the container sets the SM rather have each plugin/application/whatever try to set the system-wide SM.

Thanks. Switched to Class as cache key. New commit pushed.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From weijun at openjdk.java.net  Wed Jun 30 15:45:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 30 Jun 2021 15:45:25 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller [v2]
In-Reply-To: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
Message-ID: 

> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  update cache key from String to Class

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/166/files
  - new: https://git.openjdk.java.net/jdk17/pull/166/files/a9188921..c158d4bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=166&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=166&range=00-01

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/166/head:pull/166

PR: https://git.openjdk.java.net/jdk17/pull/166

From jpai at openjdk.java.net  Wed Jun 30 16:05:40 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 30 Jun 2021 16:05:40 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: 

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - an initial proposed test for testing compressed size entry greater than 2gb
 - minor summary update on test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/127acbcc..f519aa47

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=01-02

  Stats: 113 lines in 2 files changed: 112 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

PR: https://git.openjdk.java.net/jdk/pull/4607

From jai.forums2013 at gmail.com  Wed Jun 30 16:15:40 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 30 Jun 2021 21:45:40 +0530
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v2]
In-Reply-To: 
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 
 
Message-ID: 

Hello Lance,

On 29/06/21 11:31 pm, Lance Andersen wrote:
>
> I ran your current test 150 times and the max runtime was 25 seconds, most cases were in the 18-20 second range on our slower test boxes.

Thank you for running those tests. Do you think those timings are good 
enough to let that test stay as a regular automated jtreg test, in 
tier1? I'm guessing this falls in tier1? I haven't yet looked in detail 
the tier definitions of the build.


> As part of looking at what happens with a file whose deflated size is > 2gb, I would add a specific test which is a manual test to validate that there is no issue when we cross the 2gb threshold.

I added a (manual) test to see what happens in this case. I have 
committed the test as part of this PR just for the sake of reference. 
The test is named LargeCompressedEntrySizeTest. The test uses ZipFS to 
create a (new) zip file and attempts to write out a zip entry whose 
deflated/compressed size is potentially greater than 2gb. When I run 
this test case, I consistenly run into the following exception:

test LargeCompressedEntrySizeTest.testLargeCompressedSizeWithZipFS(): 
failure
java.lang.OutOfMemoryError: Required array length 2147483639 + 419 is 
too large
 ??? at 
java.base/jdk.internal.util.ArraysSupport.hugeLength(ArraysSupport.java:649)
 ??? at 
java.base/jdk.internal.util.ArraysSupport.newLength(ArraysSupport.java:642)
 ??? at 
java.base/java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
 ??? at 
java.base/java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:130)
 ??? at 
java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252)
 ??? at 
java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210)
 ??? at 
jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$DeflatingEntryOutputStream.write(ZipFileSystem.java:2016)
 ??? at 
java.base/java.io.FilterOutputStream.write(FilterOutputStream.java:108)
 ??? at 
LargeCompressedEntrySizeTest.testLargeCompressedSizeWithZipFS(LargeCompressedEntrySizeTest.java:104)

which to me is understandable. Is this what you and Alan wanted 
tested/checked? In its current form I don't see a way to write out a 
entry whose deflated size exceeds 2gb, unless the user/caller use the 
"useTempFile=true" option while creating the zip filesystem. FWIW - if I 
do set this "useTempFile=true" while creating that zip filesystem, in 
the LargeCompressedEntrySizeTest, that test passes fine and the 
underlying zip that is created shows a compressed/deflated size as follows:

unzip -lv JTwork/scratch/8190753-test-compressed-size.zip
Archive:? JTwork/scratch/8190753-test-compressed-size.zip
 ?Length?? Method??? Size? Cmpr??? Date??? Time?? CRC-32?? Name
--------? ------? ------- ---- ---------- ----- --------? ----
2147483649? Defl:N 2148138719?? 0% 06-30-2021 21:39 52cab9f8 
LargeZipEntry.txt
--------????????? -------? ---??????????????????????????? -------
2147483649???????? 2148138719?? 0%??????????????????????????? 1 file


I understand that Alan's suggestion holds good and we should have some 
logic in place which switches to using a temp file once we notice that 
the sizes we are dealing with can exceed some threshold, but I guess 
that is something we need to do separately outside of this PR?

-Jaikiran



From myano at openjdk.java.net  Wed Jun 30 16:29:06 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 30 Jun 2021 16:29:06 GMT
Subject: Integrated: 8268457: XML Transformer outputs Unicode supplementary
 character incorrectly to HTML
In-Reply-To: 
References: 
Message-ID: 

On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano  wrote:

> Hi all,
> 
> Could you please review the 8268457 bug fixes?
> 
> The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair.
> This fix changes the processing for non-surrogate pairs to the else condition.

This pull request has now been integrated.

Changeset: 83bce94c
Author:    Masanori Yano 
Committer: Joe Wang 
URL:       https://git.openjdk.java.net/jdk/commit/83bce94cc8a7fb45b0604598411fbecc62000dfd
Stats:     194 lines in 7 files changed: 168 ins; 21 del; 5 mod

8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML

Reviewed-by: lancea, naoto, iris, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/4474

From jpai at openjdk.java.net  Wed Jun 30 16:55:08 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 30 Jun 2021 16:55:08 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller [v2]
In-Reply-To: 
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 
Message-ID: 

On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang  wrote:

>> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update cache key from String to Class

FWIW - I built a local JDK with this PR and gave it a try against one of the original Apache Ant project example where the warnings were previously flooding the stderr. With this change, I now see the warning message just once (as expected) for that example.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/166

From mchung at openjdk.java.net  Wed Jun 30 16:59:13 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 30 Jun 2021 16:59:13 GMT
Subject: [jdk17] RFR: JDK-8262841: Clarify the behavior of
 PhantomReference::refersTo
Message-ID: 

`Reference::refersTo` behaves the same for soft, weak, and phantom references whereas `PhantomReference::get` always returns `null` which is different than soft and weak references. 

This patch clarifies the specification of `PhantomReference` to make it clear that `refersTo` can be used for phantom references.  With `refersTo`, phantom references if not registered in a reference queue are not completely useless.  Update the javadoc of the constructor to reflect that.

I created a CSR to document this spec clarification:
   https://bugs.openjdk.java.net/browse/JDK-8269688

-------------

Commit messages:
 - JDK-8262841: Behavior of PhantomReference.refersTo is not well documented

Changes: https://git.openjdk.java.net/jdk17/pull/181/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=181&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262841
  Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/181.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/181/head:pull/181

PR: https://git.openjdk.java.net/jdk17/pull/181

From kbarrett at openjdk.java.net  Wed Jun 30 16:59:13 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 30 Jun 2021 16:59:13 GMT
Subject: [jdk17] RFR: JDK-8262841: Clarify the behavior of
 PhantomReference::refersTo
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung  wrote:

> `Reference::refersTo` behaves the same for soft, weak, and phantom references whereas `PhantomReference::get` always returns `null` which is different than soft and weak references. 
> 
> This patch clarifies the specification of `PhantomReference` to make it clear that `refersTo` can be used for phantom references.  With `refersTo`, phantom references if not registered in a reference queue are not completely useless.  Update the javadoc of the constructor to reflect that.
> 
> I created a CSR to document this spec clarification:
>    https://bugs.openjdk.java.net/browse/JDK-8269688

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/181

From cgo at openjdk.java.net  Wed Jun 30 17:12:01 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 30 Jun 2021 17:12:01 GMT
Subject: [jdk17] Integrated: 8269486: CallerAccessTest fails for non server
 variant
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 13:14:51 GMT, Christoph G?ttschkes  wrote:

> Hi,
> 
> please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable which controls the native library search path. For non server variants, the second directory is not called "lib/server", but "lib/client", for instance.
> 
> I changed the test case to use the utility methods in `Platform` to get the correct paths, dependent on the VM variant.

This pull request has now been integrated.

Changeset: 1da5d4bb
Author:    Christoph G?ttschkes 
Committer: Mandy Chung 
URL:       https://git.openjdk.java.net/jdk17/commit/1da5d4bb780fc3ab02aa6cddc243fbf1b079851a
Stats:     7 lines in 1 file changed: 0 ins; 3 del; 4 mod

8269486: CallerAccessTest fails for non server variant

Reviewed-by: dholmes, stuefe, mchung, jvernee

-------------

PR: https://git.openjdk.java.net/jdk17/pull/159

From mchung at openjdk.java.net  Wed Jun 30 18:31:25 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 30 Jun 2021 18:31:25 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t.
 reference processing
Message-ID: 

This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.

CSR:
   https://bugs.openjdk.java.net/browse/JDK-8269690

-------------

Commit messages:
 - JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing

Changes: https://git.openjdk.java.net/jdk17/pull/183/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225667
  Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/183/head:pull/183

PR: https://git.openjdk.java.net/jdk17/pull/183

From rriggs at openjdk.java.net  Wed Jun 30 20:01:03 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 30 Jun 2021 20:01:03 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung  wrote:

> This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.
> 
> CSR:
>    https://bugs.openjdk.java.net/browse/JDK-8269690

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/183

From rriggs at openjdk.java.net  Wed Jun 30 20:03:05 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 30 Jun 2021 20:03:05 GMT
Subject: [jdk17] RFR: JDK-8262841: Clarify the behavior of
 PhantomReference::refersTo
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung  wrote:

> `Reference::refersTo` behaves the same for soft, weak, and phantom references whereas `PhantomReference::get` always returns `null` which is different than soft and weak references. 
> 
> This patch clarifies the specification of `PhantomReference` to make it clear that `refersTo` can be used for phantom references.  With `refersTo`, phantom references if not registered in a reference queue are not completely useless.  Update the javadoc of the constructor to reflect that.
> 
> I created a CSR to document this spec clarification:
>    https://bugs.openjdk.java.net/browse/JDK-8269688

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/181

From github.com+5709644+fdesu at openjdk.java.net  Wed Jun 30 20:16:12 2021
From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko)
Date: Wed, 30 Jun 2021 20:16:12 GMT
Subject: RFR: 8268788: Annotations with lambda expressions can still cause
 AnnotationFormatError
Message-ID: 

Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable`  that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc.

This change removes the restriction on parameters count to be zero i.e. lambdas with parameters
would be skipped from validation.

-------------

Commit messages:
 - 8268788: Annotations with lambda expressions can still cause AnnotationFormatError

Changes: https://git.openjdk.java.net/jdk/pull/4642/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4642&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268788
  Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4642/head:pull/4642

PR: https://git.openjdk.java.net/jdk/pull/4642

From lance.andersen at oracle.com  Wed Jun 30 20:18:12 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 30 Jun 2021 20:18:12 +0000
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v2]
In-Reply-To: 
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 
 
 
Message-ID: 

Hi Jaikiran

On Jun 30, 2021, at 12:15 PM, Jaikiran Pai > wrote:

Hello Lance,

On 29/06/21 11:31 pm, Lance Andersen wrote:

I ran your current test 150 times and the max runtime was 25 seconds, most cases were in the 18-20 second range on our slower test boxes.

Thank you for running those tests. Do you think those timings are good enough to let that test stay as a regular automated jtreg test, in tier1? I'm guessing this falls in tier1? I haven't yet looked in detail the tier definitions of the build.

These tests run as part of tier2.

The time for the test run is reasonable .


As part of looking at what happens with a file whose deflated size is > 2gb, I would add a specific test which is a manual test to validate that there is no issue when we cross the 2gb threshold.

I added a (manual) test to see what happens in this case. I have committed the test as part of this PR just for the sake of reference. The test is named LargeCompressedEntrySizeTest. The test uses ZipFS to create a (new) zip file and attempts to write out a zip entry whose deflated/compressed size is potentially greater than 2gb. When I run this test case, I consistenly run into the following exception:

test LargeCompressedEntrySizeTest.testLargeCompressedSizeWithZipFS(): failure
java.lang.OutOfMemoryError: Required array length 2147483639 + 419 is too large
    at java.base/jdk.internal.util.ArraysSupport.hugeLength(ArraysSupport.java:649)
    at java.base/jdk.internal.util.ArraysSupport.newLength(ArraysSupport.java:642)
    at java.base/java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:100)
    at java.base/java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:130)
    at java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252)
    at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210)
    at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$DeflatingEntryOutputStream.write(ZipFileSystem.java:2016)
    at java.base/java.io.FilterOutputStream.write(FilterOutputStream.java:108)
    at LargeCompressedEntrySizeTest.testLargeCompressedSizeWithZipFS(LargeCompressedEntrySizeTest.java:104)

which to me is understandable. Is this what you and Alan wanted tested/checked? In its current form I don't see a way to write out a entry whose deflated size exceeds 2gb, unless the user/caller use the "useTempFile=true" option while creating the zip filesystem. FWIW - if I do set this "useTempFile=true" while creating that zip filesystem, in the LargeCompressedEntrySizeTest, that test passes fine and the underlying zip that is created shows a compressed/deflated size as follows:

unzip -lv JTwork/scratch/8190753-test-compressed-size.zip
Archive:  JTwork/scratch/8190753-test-compressed-size.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
2147483649  Defl:N 2148138719   0% 06-30-2021 21:39 52cab9f8 LargeZipEntry.txt
--------          -------  ---                            -------
2147483649         2148138719   0%                            1 file


I understand that Alan's suggestion holds good and we should have some logic in place which switches to using a temp file once we notice that the sizes we are dealing with can exceed some threshold, but I guess that is something we need to do separately outside of this PR?

Yes the intent would be to add some logic, which might need to be under a property (for now) to specify the size for when to use  a temp file vs BAOS.  Having the value configurable via a property might give us some flexibility for experimentation.

I don?t see why this PR could not be used for this (as it would provide a more complete solution)

Best
Lance

-Jaikiran



[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com




From kbarrett at openjdk.java.net  Wed Jun 30 21:35:01 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 30 Jun 2021 21:35:01 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung  wrote:

> This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.
> 
> CSR:
>    https://bugs.openjdk.java.net/browse/JDK-8269690

Changes requested by kbarrett (Reviewer).

src/java.base/share/classes/java/lang/Runtime.java line 661:

> 659:      * the change of reachability in any particular number of objects
> 660:      * or any particular number of {@link java.lang.ref.Reference Reference}
> 661:      * objects be cleared and enqueued.

perhaps
s/number of objects or any/number of objects, or that any/
s/objects be/objects will be/

src/java.base/share/classes/java/lang/System.java line 1867:

> 1865:      * the change of reachability in any particular number of objects
> 1866:      * or any particular number of {@link java.lang.ref.Reference Reference}
> 1867:      * objects be cleared and enqueued.

Similar suggestion here as for Runtime.gc.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/183

From naoto at openjdk.java.net  Wed Jun 30 22:15:01 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 30 Jun 2021 22:15:01 GMT
Subject: [jdk17] Integrated: 8269513: Clarify the spec wrt `useOldISOCodes`
 system property
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Jun 2021 16:57:15 GMT, Naoto Sato  wrote:

> Please review this small doc change to the system property. Accompanying CSR has also been created.

This pull request has now been integrated.

Changeset: 3e022247
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk17/commit/3e022247d2e80c43393bfdb5888b03210c6975d3
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8269513: Clarify the spec wrt `useOldISOCodes` system property

Reviewed-by: lancea, bpb, iris, joehw

-------------

PR: https://git.openjdk.java.net/jdk17/pull/163

From naoto at openjdk.java.net  Wed Jun 30 21:45:13 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 30 Jun 2021 21:45:13 GMT
Subject: [jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()
Message-ID: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>

A trivial typo fix.

-------------

Commit messages:
 - 8269704: Typo in j.t.Normalizer.normalize()

Changes: https://git.openjdk.java.net/jdk17/pull/187/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=187&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269704
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/187.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/187/head:pull/187

PR: https://git.openjdk.java.net/jdk17/pull/187

From joehw at openjdk.java.net  Wed Jun 30 22:29:57 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 30 Jun 2021 22:29:57 GMT
Subject: [jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()
In-Reply-To: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>
References: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>
Message-ID: <5GIkGnI9eqE0ktm3I7q3uw3yNMy0Ufa80gxmqvzKUpQ=.4a4c7d5f-a6c3-414e-8a0c-3c72c6996fa3@github.com>

On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato  wrote:

> A trivial typo fix.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/187

From prappo at openjdk.java.net  Wed Jun 30 22:35:01 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 30 Jun 2021 22:35:01 GMT
Subject: [jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()
In-Reply-To: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>
References: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>
Message-ID: 

On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato  wrote:

> A trivial typo fix.

Marked as reviewed by prappo (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/187

From mchung at openjdk.java.net  Wed Jun 30 22:47:02 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 30 Jun 2021 22:47:02 GMT
Subject: [jdk17] Integrated: JDK-8262841: Clarify the behavior of
 PhantomReference::refersTo
In-Reply-To: 
References: 
Message-ID: 

On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung  wrote:

> `Reference::refersTo` behaves the same for soft, weak, and phantom references whereas `PhantomReference::get` always returns `null` which is different than soft and weak references. 
> 
> This patch clarifies the specification of `PhantomReference` to make it clear that `refersTo` can be used for phantom references.  With `refersTo`, phantom references if not registered in a reference queue are not completely useless.  Update the javadoc of the constructor to reflect that.
> 
> I created a CSR to document this spec clarification:
>    https://bugs.openjdk.java.net/browse/JDK-8269688

This pull request has now been integrated.

Changeset: 9ac63a6e
Author:    Mandy Chung 
URL:       https://git.openjdk.java.net/jdk17/commit/9ac63a6e08c18ed99b97fe0abcc0ac51b96a563e
Stats:     5 lines in 1 file changed: 2 ins; 2 del; 1 mod

8262841: Clarify the behavior of PhantomReference::refersTo

Reviewed-by: kbarrett, rriggs

-------------

PR: https://git.openjdk.java.net/jdk17/pull/181

From mchung at openjdk.java.net  Wed Jun 30 22:52:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 30 Jun 2021 22:52:39 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 30 Jun 2021 21:29:17 GMT, Kim Barrett  wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Kim's suggestion on the wording
>
> src/java.base/share/classes/java/lang/Runtime.java line 661:
> 
>> 659:      * the change of reachability in any particular number of objects
>> 660:      * or any particular number of {@link java.lang.ref.Reference Reference}
>> 661:      * objects be cleared and enqueued.
> 
> perhaps
> s/number of objects or any/number of objects, or that any/
> s/objects be/objects will be/

That may be clearer.  Updated.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/183

From mchung at openjdk.java.net  Wed Jun 30 22:52:36 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 30 Jun 2021 22:52:36 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: 
References: 
Message-ID: 

> This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.
> 
> CSR:
>    https://bugs.openjdk.java.net/browse/JDK-8269690

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Kim's suggestion on the wording

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/183/files
  - new: https://git.openjdk.java.net/jdk17/pull/183/files/e9765984..020a2d7a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=183&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/183/head:pull/183

PR: https://git.openjdk.java.net/jdk17/pull/183

From iris at openjdk.java.net  Wed Jun 30 23:05:02 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 30 Jun 2021 23:05:02 GMT
Subject: [jdk17] RFR: 8269704: Typo in j.t.Normalizer.normalize()
In-Reply-To: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>
References: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>
Message-ID: 

On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato  wrote:

> A trivial typo fix.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/187

From bpb at openjdk.java.net  Wed Jun 30 23:05:05 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Jun 2021 23:05:05 GMT
Subject: RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF [v5]
In-Reply-To: 
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
 
Message-ID: 

On Mon, 28 Jun 2021 17:48:37 GMT, Brian Burkhalter  wrote:

>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 6766844: Move API note of read(byte[],int,int) to normative text
>  - 6766844: Change "equivalent" to "overridden"

This PR has been superseded by the JDK 17 PR [189](https://github.com/openjdk/jdk17/pull/189).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From bpb at openjdk.java.net  Wed Jun 30 23:07:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Jun 2021 23:07:20 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF
In-Reply-To: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
Message-ID: 

On Wed, 30 Jun 2021 23:00:24 GMT, Brian Burkhalter  wrote:

> Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.

This PR supersedes PR [4591](https://github.com/openjdk/jdk/pull/4591).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/189

From bpb at openjdk.java.net  Wed Jun 30 23:07:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Jun 2021 23:07:20 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF
Message-ID: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>

Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.

-------------

Commit messages:
 - 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

Changes: https://git.openjdk.java.net/jdk17/pull/189/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=189&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6766844
  Stats: 18 lines in 2 files changed: 12 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/189.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/189/head:pull/189

PR: https://git.openjdk.java.net/jdk17/pull/189

From bpb at openjdk.java.net  Wed Jun 30 23:18:09 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Jun 2021 23:18:09 GMT
Subject: Withdrawn: 6766844: ByteArrayInputStream#read with a byte array of
 length 0 not consistent with InputStream when at EOF
In-Reply-To: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
References: <8VHM0lE4BbifocauPaN0JyAa4LFCmfg8nklLIftPnaw=.cd7c128e-dff6-4b5d-a228-b90cb8121f77@github.com>
Message-ID: 

On Fri, 25 Jun 2021 00:04:48 GMT, Brian Burkhalter  wrote:

> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and `read(byte[],int,int)` to return zero per the `InputStream` specification when the byte array actual or specified length is zero.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4591

From bpb at openjdk.java.net  Wed Jun 30 23:21:17 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Jun 2021 23:21:17 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh
Message-ID: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>

Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.

-------------

Commit messages:
 - 8188044: We need Math.unsignedMultiplyHigh

Changes: https://git.openjdk.java.net/jdk/pull/4644/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4644&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8188044
  Stats: 72 lines in 3 files changed: 62 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4644.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4644/head:pull/4644

PR: https://git.openjdk.java.net/jdk/pull/4644

From bpb at openjdk.java.net  Wed Jun 30 23:27:00 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Jun 2021 23:27:00 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh
In-Reply-To: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
Message-ID: 

On Wed, 30 Jun 2021 23:13:06 GMT, Brian Burkhalter  wrote:

> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.

This PR does not address intrinsics for the proposed method; that aspect can be handled subsequently.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4644